FHIR
Without the smoke
FHIR Experience
In the last 4 weeks, we have been busy.
We …
• Prototyped a Device Data Aggregator/Reporter using FHIR
resources.
• Prototyped a FHIR server.
• Participated by voting on the FHIR ballot by providing ballot input
on deficiencies.
• Attempted to develop a FHIR Alert resource. (Concept)
• Participated in the FHIR Connectathon.
• Participated in the FHIR tutorials.
• Worked with Grahame to resolve Device ballot issues.
And that is in addition to our daytime job.
That is a lot of stuff
How is that possible?
• FHIR chooses technologies that allow for rapid
prototyping.
• FHIR has simple documentation that anyone can
understand.
• There are tools and API’s available to facilitate
development.
• There are a lot of online tutorials.
• The FHIR community is more than willing to help.
• The specification is open. (Thanks HL7)
• The players are Agile.
And the Challenge…
A Heated discussion on the level of detail that
should be in a Device Observation Report.
• After evaluating the Device related resources proposed in the
FHIR schema, I have decided to give it thumbs down. The
Device related resources should map to the data model
described in the ISO/IEEE11073-10201 (“DIM”) and at a
minimum support the semantic content that is provided for in
the IHE PCD reporting profiles, which are based on ISO/IEEE
11073 semantics mapped into HL7 v2.6 messages. The
current resources fall far short in supporting the subset of
ISO/IEEE 11073 content that is part of the IHE PCD profiles,
not to mention the rich set of content that can be reported
from medical devices using the ISO/IEEE 11073 information
model and nomenclature.
A wise man in the corner.
Someone (TODO get name) outside the
conversation,
“You are not talking about the same domain. Could it be that a
Device Observation is intended go into the EHR and represent a
clinical observation captured by a device.”
A new understanding
It became clear that there are multiple problem
domains.
• A Device Observation resource, as it was on the
ballot, is intended to capture a clinical
measurement made by a device for storage in an
EHR/EMR. Which is the information that a
clinician would review 10 years from now.
• A Device (Yet to be named) resource is intended
to capture device data that can be used in clinical
applications such as remote monitoring.
Clearly
Different data, different requirements, different
usage.
The discussion around device resources has been confusing and
unproductive. Lets first agree on how to partition the discussion.
RESOURCE BUCKETS
Confusion
Until now,
device resource use cases have been absent
from the discussion.
Dilemma
The number of device resource use cases are
enumerable.
Where do we draw the line?
Proposed Solution
• Define a logical categorization of use case
buckets that device resources fall into.
• Constrain the usage of resources within a
bucket based on the buckets intended use.
This will allow us to,
1. Limit the discussion to one bucket at a time.
2. Limit the scope and usage of a bucket.
What are the buckets?
As a first pass, we have defined the following
Buckets.
• EHR/EMR
• Device Store
• Device Comm (Transport/Messaging/…)
Resource Partitioning
EHR/EMR Device Resources
• EHR/EMR Device Resources are
concerned with information that
would be part of a patient’s long
term record.
• EHR/EMR Device Resources
clinical in nature.
Device Store Bucket
• Device Store resources are
concerned with Device information
that will be used in the monitoring
and treatment of patients.
• Device Store resources are not part
of a patients long term record.
• Device Store resources are not
intended for realtime applications.
• Device Store resources are not full
disclosure resources.
Device Comm Bucket
• Device Comm resources are
intended to provide a transport to
allow device information to be
posted to a restful server for
further processing.
• The Device Comm resources do
not persist as part of some greater
data model.
• The Device Comm resources are
suitable for near realtime
applications.
Before we move on…
• Passing DSTU, simply means that a standard is
ready for trial implementation.
• It is understood and accepted that changes
will need to occur.
– Deficiencies can be addressed without a vote.
• Keep an open mind.
Before we move on…
No idea is bad.
Ideas or concepts that are out of scope will be
need to be captured and tabled for later
discussion.
Current focus
DEVICE STORE BUCKET
Device Store Usecases
• Remote Device View
– Allowing for data to be queried and displayed in a
way that is MDDS conformant.
• Alarm/Alert Reporting
– Allowing for alarm data to be queried and
displayed in a way that is MDDS conformant.
Device Data Resource
• What it currently is,
– Currently equivalent to IHE/PCD-01.
– Represents the metric state of a patient care
device at some point in time.
• What it currently is not,
– Suitable for applications that are MDDS.
Proposed Implementation
My Recommendation
• Evaluate constraints around the resource.
• Understand that the resource will change as
part of a trial implementation.
• Prototype a use case and provide feedback
that will enhance the resource.
A resource need that we would like to help address.
DEVICE STORE BUCKET
ALERTS AND ALARMS
1
Patient is intravenously given a medication that
is known to increase heart rate.
2
Several minutes later, patient goes into
anaphylactic shock, where his/her airways
restrict significantly as a reaction to a
medication.
3
Patients struggles to breath in and out oxygen
due to a restriction in his/her airway, causing
his/her heart rate to increase significantly,
triggering a high heart rate alert on the pulse
oximeter.
4
The pulse-oximeter begins to alarm with both
audio and visual annunciations and displays a
high heart rate message on its display.
BPM 100
HIGH LIMIT
Pulse oximeter generates an Alert Report and
sends it to the Alarm Manager.
5
The Alarm Manager receives the alarm report, and waits 15s to qualify
the event.
After 15s, the Alarm Manager sends an Alarm Message to a Clinician
indicating that the heart rate is high with supporting data; such as
alarm limit breached and value of the breach.
6
The Clinician receives the alarm notification, reviews the
alarm violation (100 BPM) and electronic patient chart and
determines that the violation is due to an administered
medication; which was expected. He takes note to change
limits later.
In the mean time, the patients heart rate increases to 120.
7
As the patient struggles, his/her oxygen level
decrease to a level less than 85% O2 saturation
triggering a low O2 level alert.
The pulse-oximeter continues to alarm but
changes the display message to indicate that the
O2 80
O2 level is low.
LOW LIMIT
8
The Pulse oximeter generates an Alert Report
and sends it to the Alarm Manager. The Alarm
Manager evaluates the Alarm Report and
determines that the additional alarm condition
is of a higher clinical priority.
9
The Alarm Manager immediately sends a
notification to the Clinician as a result of the
Alarm priority change.
10
As the patient continues to struggle, his/her
perfusion decreases and triggers a low perfusion
alert; which is suppressed because a low
perfusion is less clinically relevant than low O2.
11
Postmortum Discussion
• Problems
– The Clinician was only able to see the Alarm violation
that triggered the event (6).
– The Clinician did not have a remote view of the Pulse
oximeter.
– The Clinician was not able to remotely change the
limits, to reflect his decision. (6) Therefor, the only
way he would know that the patient condition
diminished was a change in Alarm Priority.
– The Medication continued to be administered even
though patient was having an adverse reaction.
Alert Monitor IEEE 11073-10201
The Alert Monitor object represents the output
of a device or system alarm processor. As such, it
represents the overall device or system alarm
condition and provides a list of all alarm
conditions of the system in its scope. This list
includes global state information and individual
alarm state information that allows the
implementation of a safetystandard-compliant
alarm display on a remote system.
Alert Monitor
Alarm Monitor
• Contains alarm entry sets for Technical,
Patient and Suspended alarms that are active.
• Maintains alarm priority by ordering of the
alarm entrees within each set.
• Contains a pointer to the alarming metric.
• Contains alarm limit information.
A Good Start