Why FHIR?

MDguna
MDguna
Feb 24, 2018 · 3 min read

FHIR is a new data format defined by HL7 consortium to transfer data between healthcare information systems. FHIR is a new specification based on emerging technologies and HL7 data definitions. HL7 is a predominant technology in healthcare space to transfer data. HL7 version 1 and 2 appear as legacy when they are compared with latest technologies available to exchange data between systems. FHIR tries to catch up the technology stack and functions like a open source technology by supporting JSON format data.

HL7 follows pipe (|) delimiters to separate the data elements. EMR vendors like Cerner, Epic defined their own definitions of HL7 segments and fields. On top of that, Each hospital in United States has customized the HL7 field definition to meet their custom needs. So consuming data in traditional HL7 format requires understanding specs specific to EMR and hospital, and translate those messages to required format. That makes integration with hospital EMR a challenge.

A sample HL7 message from MIEWEB:

MSH|^~\&|SENDING_APPLICATION|SENDING_FACILITY|RECEIVING_APPLICATION|RECEIVING_FACILITY|20110613083617||ADT^A04|934576120110613083617|P|2.3||||
EVN|A04|20110613083617|||
PID|1||135769||MOUSE^MICKE^||19281118|M|||123 Main St.^^Lake Buena Vista^FL³²⁸³⁰||(407)939–1289^^^theMainMouse@disney.com|||||1719|99999999||||||||||||||||||||
PV1|1|O|||||7^Disney^Walt^^MD^^^^|||||||||||||||||||||||||||||||||||||||||

As you can see, each segment is defined by an identifier at the beginning. Like PID identifies the segment as patient identifier segment and PV labels segment as patient visit segment. But, the problem is each section inside the segment may or may not follow the standard definition. EMR systems and hospitals could be making customizations to it. For instance, if you look at PID-5 field in the above example, it has patient name and that is in line with standard HL7 definition. However, EMR system or hospital could be using that filed to display patient gender instead of name. In that case receiving system should customize the processing of these messages based on EMR and hospital specific specs.

That makes integration of new apps with EMR system and other healthcare applications a huge resource intensive effort. It has been discouraging for new applications because of the integration and scalability challenges. And, over the years it has developed as a stigma to abandon new application developers and startups.

FHIR is a new hope to change the direction and bring the application prosperity to healthcare space similar to other industries. FHIR follows JSON format which is widely used across the industries for data transfer between systems. HL7 consortium with its expereince of HL7 development, defined FHIR so that json format could serve healthcare needs.

A sample FHIR messaage structure (JSON) from FHIR:

{
"resourceType" : "Patient",
// from Resource: id, meta, implicitRules, and language
// from DomainResource: text, contained, extension, and modifierExtension
"identifier" : [{ Identifier }], // An identifier for this patient
"active" : <boolean>, // Whether this patient's record is in active use
"name" : [{ HumanName }], // A name associated with the patient
"telecom" : [{ ContactPoint }], // A contact detail for the individual
"gender" : "<code>", // male | female | other | unknown
"birthDate" : "<date>", // The date of birth for the individual
// deceased[x]: Indicates if the individual is deceased or not. One of these 2:
"deceasedBoolean" : <boolean>,
"deceasedDateTime" : "<dateTime>",
"address" : [{ Address }], // Addresses for the individual
"maritalStatus" : { CodeableConcept }, // Marital (civil) status of a patient
// multipleBirth[x]: Whether patient is part of a multiple birth. One of these 2:

With JSON structure, message contains name value pairs and it makes the message consumption easier by getting rid of dependency on data index (PID — 5 = name or gender). However FHIR has risk of typical healthcare proprietary definitions by EMR systems and healthcare providers. For instance, if an EMR systems decides to use Patient.gen instead of Patient.gender then it creates same old problem. However, so far all the EMR vendors are closely aligned with FHIR standards in developing FHIR APIs to read and write data from their EMR system. So the future looks promising…..

With this shift EMR vendors are going to open up their EMR system as a platform to allow external apps to run on top of it. In simple words they are going to act like Android and iOS platform for mobile users and developers. They may take part of the revenue from these apps to gain the ground they have lost by opening up EMR platform.

Author has more than 5 years of HIT leadership experience and 10 years of HIT development experience. Author also co-founded healthcare IT transparency platform — MDguna.

MDguna is an innovative population health analytics platform utilizes big data and machine learning technologies to pioneer healthcare IT products.

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade