FHIR explained: a healthcare data standard tailored to our times

The number of healthcare data sources in the medical sector is growing as new systems and applications are continuously being added to the workflow. Nowadays, an average hospital in the US uses over 80 systems. A lot of these systems are used by multiple hospitals and are connected to systems used by other healthcare-related institutions and organisations, like pharmacies or labs.

The challenge has been to ensure interoperability between these multiple systems in order to be able to see all the data in one place in real time. This pushed HL7 standards development organisations to create a new standard for the format and a method of clinical and administrative data transfer.

In this article, prepared in cooperation with Łukasz Śliwowski, Principal Business Analyst, we’ll explain what the FHIR standard is about and discuss its architecture and implementation.

What is FHIR in simple terms?

FHIR (Fast Healthcare Interoperability Resources) is a global standard developed by the HL7 organisation, which describes the medical data format for exchanging electronic health records between various medical systems in a unified way.

Before introducing the standard, large hospitals and medical centres had even up to 100 various systems, for example, for laboratory information or hospital bed management, which all used a different data format. This caused many difficulties in data exchange, so HL7 came up with a standard that unified data formats. The goal was to facilitate interoperability between legacy healthcare systems and to make it easy to provide healthcare information on a wide variety of devices to all interested parties.

However, the first versions of the standard, HL7 v.2 developed in the 90s and HL7 v.3 from the early 2000s, were quite difficult in terms of implementation and didn’t meet all the requirements. As a response to that, in 2012, software developers started to work on the first iteration of FHIR.

FHIR was seen as a real game changer, as it incorporated a modern and more standardised information exchange method based on rest API. Another revolutionary advantage of FHIR for the time, was that it was created by software developers, for software developers, unlike earlier HL7 standards developed by clinicians.

The difference lied also in the approach to data format. The standards previous to FHIR used a format that contained a large amount of information, similar to traditional, static data in a PDF. Extracting the relevant information and making it usable in any other format was quite laborious and time-consuming. FHIR, on the contrary, introduced a granular approach to data, which means that only the necessary pieces of data are being transferred. Also, FHIR solved the age-old data reconciliation challenges by leveraging standardised API. Using FHIR, applications can be easily  connected to any electronic health record system and specific data can be easily exchanged between systems.

FHIR is a developer-friendly standard because it uses JSON (XML and Turtle are also an option), which is familiar to almost every software engineer. Data in JSON are unified, giving the idea of what a data model should look like and how the interfaces should be implemented. The implementation of interfaces is based on a concept known as resources.

FHIR architecture: resources, references and profiles

What are resources in FHIR?

Resources are data elements. Each piece of, for example, patient data, such as their name, last name and age, medical history, prescribed medicine, etc., is considered a single resource. For example, you could find out their name, address or phone number in a resource named “patient”. If you’d like to know when a patient was in a hospital, you would have to draw this information from a resource called “encounter”. To learn more about their test results, the right resource would be “observations”. There are 145 resources in total, but only 20 are in common use.

FHIR resources are unified but differ in structure details. There are elements related to metadata (which describes what resource, ID, etc. is being used), possible extensions, narrative and data model. A narrative is a legacy element from the previous standards, which contains a human-readable summary of the clinical and business information for the resource. The core of every resource are data inside JSON tags, which are exchanged between various systems and can be further processed.

FHIR resources are based on the 80/20 rule – the basic FHIR should apply to 80% of cases and the remaining 20% are dedicated to special and rare cases. To be able to manage the latter, FHIR introduced the extensions, which are a standardised way of adding extra data to a resource.

What are profiles in FHIR?

Profiles in FHIR are used to customise resources for specific use cases. Healthcare organisations may specify which resources they want to use.

For example, a children’s clinic requires the information about “next of kin” (parents or legal guardians) to their patients. In such a case, we should define in a profile that a “patient” resource must always include this information in the clinic’s system, while not necessarily in other systems.

In other words, with profiles, FHIR allows the creation of a customised, more specific resource definition by specifying a set of constraints and extensions on the base resource. Thanks to a robust FHIR community, you can also choose from many lists of pre-made, most commonly used profiles for free. They can be found in the FHIR implementation guides (IG), for example, the US Core.

What are references in FHIR?

References are used to apply data granularity. They link a source resource to a target resource, for example, a resource called “Observations” can be linked to a resource named “Patient”. Let’s say that “Observation” relates to a certain patient’s weight measurement. A reference then links to a specific target resource, in this case, a patient’s ID. References make data exchange much simpler.

However, FHIR references don’t allow all patient data to be exchanged easily between hospitals using a single resource. It is possible but necessitates using several dozen FHIR resources to download all the necessary data from one hospital to another.

What are the challenges in implementing FHIR?

Currently, the greatest difficulty in adopting FHIR is the quality of data across various systems. For example, research shows that there’s a wide variation in laboratory naming conventions in EHRs within and between hospitals in the US. The data is often unstructured text or inconsistently recorded, making it difficult to manage.

Is it worth adopting FHIR?

In March 2020, the US Centers for Medicare & Medical Services (CMS) released the Interoperability & Patient Access Rule to further improve electronic health care data exchange – sharing information with patients or between a payer and a provider or between two payers. The reinforcement date for the rule is January 1, 2023.

To enable a more seamless method of exchanging information, the CMS regulations include policies, which require or encourage the implementation of APIs that can connect to mobile apps or to a provider EHR or practice management system. CMS recommends that organisations should use FHIR for implementing the APIs to meet the new requirements. Therefore, now is the right time to adopt the standard as it will soon become a necessity rather than an option.

Our team can help you build software integrated with the FHIR standard that will meet all the requirements of the CMS regulation as well as integrate your current software with another system that uses FHIR. Contact us for more information.