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/IEEE (“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 semantics mapped into HL7 v2.6 messages. The current resources fall far short in supporting the subset of ISO/IEEE 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 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.

RESOURCE BUCKETS The discussion around device resources has been confusing and unproductive. Lets first agree on how to partition the discussion.

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.

DEVICE STORE BUCKET Current focus

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.

DEVICE STORE BUCKET ALERTS AND ALARMS A resource need that we would like to help address.

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. Pulse oximeter generates an Alert Report and sends it to the Alarm Manager. BPM 100 HIGH LIMIT

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 level is low. O2 80 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 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