Your Clinical Data is on FHIR...and That's a Good Thing!

FHIR stands for Fast Healthcare Interoperability Resources. It's pronounced just like the word fire, hence the somewhat clever play on words on the article title. It's a standardized way of sharing data formats and elements (known as "resources") and it's also an application programming interface (API) for exchanging electronic health records. The standard was created by the Health Level Seven International (HL7) health-care standards organization, and as of today they've released the fourth FHIR version.

FHIR resources are small, reusable structures that are defined to work with the FHIR API. A resource contains a set of elements defined in a strict hierarchy. There are multiple resources defined in FHIR specifications, you can see some examples in the image below:

One key feature of these resources is that they refer back to other resources. For example: Clinical resources have a reference to an Administration resource (patient) to identify the subject of the clinical content. They can also refer back to within the same resource, for example a Condition can reference an Observation (both are in the Clinical resource) as evidence for a diagnosis.

FHIR is pretty amazing. Its main purpose is to put an end to one of the biggest problems facing healthcare organizations today: interoperability. Currently data is stored, transferred, and interpreted in a variety of different ways. Unfortunately this lack of data standardization affects not only HIT and EHR vendors, but it ultimately also places cumbersome data hurdles in the path of medical providers whose only crime is wanting to provide better patient care.

FHIR solves that problem by facilitating real time exchange of data using web technology. That technology is called JavaScript Object Notation (JSON). JSON is a minimal, readable format for structuring data. It is used primarily to transmit data between a server and web application, as an alternative to the eXtensible Markup Language (XML). Here's what a patient's record looks like using the JSON format, see if you can spot the data embedded within.

Did you find Mr. Donald Duck, his MR number, the company who owns the record, and his picture? If not, take a good look at the syntax again it's all in there.

FHIR ultimately goes for the 80/20 rule. Which means that resources that exist in FHIR cover 80 percent of data elements used in existing healthcare systems. The 20 percent that is left over can be dealt with as FHIR extensions, which are additional resources created at the individual organizational level. These extensions can be shared, but this would only be the case if the data needs are not covered in the initial 80 percent.

So what is the benefit of using something like FHIR versus traditional file sharing formats such as HL7?

First off, FHIR was developed and published by HL7 under an open source license. So it's free to utilize. Secondly, the main focus of FHIR is fast and easy implementation. This means that working interfaces are simple and there are already multiple implementation libraries to kick-start development. Lastly, since FHIR is easier to implement using FHIR directly translates into cost savings and greater ROI than something like HL7 which needs loads more customization.

This article is not meant to go in-depth into HL7 or FHIR. It's meant to be a starting point for clinicians and other healthcare folks that want to learn a little bit more on a very important interoperability topic. I recommend diving into the Principles of Health Interoperability (Third Version) if the reader would like more in-depth detail.