FHIR LIHT

Part 4:  FHIR LIHT

In Part 3, we tagged consumer home telemedicine as the simplest telemedicine-to-EHR application and therefore a good place to start.

In this part, we’ll look at an integration scheme that will build on FHIR concepts and be targeted at consumer home telemedicine.  We’ll call it Lite Integration for Home Telemedicine using FHIR (FHIR LIHT).

Lite Integration for Home Telemedicine using FHIR LIHT

In this model, we want to get medical device observation information from a consumer home telemedicine system into an HL7 based EHR.  The telemedicine system would typically be browser based and would be comprised of a patient station in a patient’s home and a clinician station at a hospital or clinic from which the EHR would be readily accessible.

The nexus is the PC platform where the clinician logs into both the EHR and telemedicine system.

The telemedicine system handles the Internet communications to get the measurements from the patient station to the clinician station, where on the same platform an EHR session would be open.  The messages containing that information should be in FHIR format.

(It is noted that Remote Patient Monitoring systems typically send data asynchronously directly from the home telemedicine station to a central database, which while technically an EHR is not a hospital HL7 EHR.  In an RPM system, the patient takes measurements independently and a clinician is not actively involved.  Since our focus here is on interactive video-based sessions and HL7 EHRs, this type of data exchange will be covered elsewhere.)

Messaging Should be Bare Bones and Focus on “Observations”

In spite of its odd notation (bars, hats, etc.), HL7 is more concise when it comes to observation messages.  So we’ll use HL7 OBX messages to guide the parameters in the FHIR LIHT to HL7 message conversion.

In this model, the telemedicine system would use FHIR LIHT for medical device observations destined for the EHR, which would use HL7 v2.x.  That means that there would have to be a FHIR LIHT to HL7 conversion at that point.

To minimize that conversion effort, at the HL7 v2.x EHR:

• Limit codes and options.  E.g. specify one code for blood pressure measurements.  For home telemedicine applications it is generally not important to know which arm, or whether the person is standing or sitting or prone for the measurement.  In cases where it is important, such detail could be recorded in Notes.  Identify the best code for each medical device commonly used in home telemedicine:  blood pressure meters, pulse oximeters, spirometers/peak flow meters, weight scale.
• Allow for PDF images with related notes.
• Create the flexibility to accept and process messages where some “required” fields may not be filled in.  It might be okay for the EHR to indicate an error for a message that is missing a required field, but the EHR should allow the message to be accepted.

The Limited Scope of a Home Telemedicine Installation

Take advantage of the limited scope of a home telemedicine installation versus a hospital installation.

A hospital environment has to allow for multiple patients at the same location as well as the same patient at multiple locations.  It also allows for multiple clinicians, changing diagnoses and changing orders.

Home Telemedicine Environment

For the home telemedicine environment, there is a fixed location for each patient.  While there might be changes over time, diagnoses are not dynamic and limited medical devices are involved.

As long as there is a means to get updates into the home telemedicine station, this information can be considered static for FHIR LIHT.  When a home telemedicine station is installed, the following is generally known:

• Patient name and demographics.
• Patient location.
• Clinician name.
• Diagnosis.
• Orders where medical devices measurements are involved.
• Network location of the clinician.

This is information recorded in the EHR.  Any of these elements that are entered into the home telemedicine station, must be done such that they are properly recognized by the EHR.  The most obvious example is that the patient name and ID used by the EHR must also be used by the telemedicine system.

How can FHIR LIHT take advantage of this?

For FHIR LIHT, there is no need to find or create or modify these “resources”.  All this information can be entered into the Patient Station as static information as an installation step to match the corresponding information in the HL7 EHR. 

This reduces the core task of a FHIR LIHT conversion to translating FHIR LIHT observation messages to HL7 OBX messages.

Converting Between HL7 v2 Observation Messages and FHIR Messages

Converting between HL7 v2 observation messages and FHIR messages is straight forward.  The following link shows an example of an HL7 OBX message for a lab test converted to a bundle of FHIR messages.

http://www.ringholm.com/docs/04350_mapping_HL7v2_FHIR.htm

In the example at this link, Section 2.1 illustrates the use of bars, hats, etc. and that non-applicable fields cannot be ignored in the formatting of an HL7 message.  Parsing an HL7 message requires every data element to be in a specified position.  If a data field is not used, a blank space delimited by bars for that field must be included.  It’s not complicated but it is visually confusing.

Section 2.2 shows the FHIR message resources that are needed.  The complete message bundle to handle the HL7 OBX is extensive.  (Not complicated but extensive.)

FHIR LIHT simplifies this bundle by eliminated the need for all the resource messages because that information was entered into the telemedicine system manually during installation (or update).

Eliminating the need for the resource messages doesn’t just make the FHIR less verbose, more importantly, it eliminates the need to find or create or maintain the resources.

Once the HL7 OBX message is created, it has to get to the EHR so that the medical record for that patient is updated.

The co-residency of the telemedicine station and the EHR client station offers the potential of a local transfer of information.  There are means of getting information from the telemedicine window into the EHR window, but they require changes to the EHR system.  That can be avoided by using a message transport method already employed by that facility to get HL7 messages to the EHR.  There are known ways to do this and they will not be discussed here.

FHIR LIHT Provides a Reasonable Path Predicated on Simplification

FHIR LIHT doesn’t solve all the challenges of getting home telemedicine observation measurements into an HL7 EHR.  But it offers a reasonable path predicated on simplification.

That simplification is based on:

• Recognition that consumer home telemedicine is very narrow in scope and data derived from it is limited and well defined.
• Home telemedicine systems would enable entry of certain demographic and medical data that are derived from and match the EHR usage of that data.
• Use of FHIR resources is minimized.
• The HL7 EHR would relax some of its rules for required fields for telemedicine systems.

Consumer home telemedicine with medical devices is a nascent market, but it is expected to be big.  Having no standards for EHR integration will hurt the initial growth of this market sector.  Many companies will try a home-grown approach which will make for a confusing environment which hinders growth.

This approach isn’t perfect and doesn’t handle all situations.  But it does offer a standards based approach that is as easy to implement as a home grown telemedicine-to-EHR solution.

The goal of the FHIR LIHT approach is to make is so easy to get started that many will try using it.  If the ease of implementation results in early success then it can form the basis of a de facto standard.  If it can evolve to become more effective, it could become an official standard.  (We can dream, can’t we?)

View Part 1 of Why is it so Hard to Integrate Telemedicine into EHRs? Which EHR?

View Part 2 of Why is it so Hard to Integrate Telemedicine into EHRs? What not to do.

View Part 3 of Why is it so Hard to Integrate Telemedicine into EHRs? A 20/80 Approach to a Telemedicine-to-EHR Interface