HL7 FHIR (‘FHIR’) is the fourth and most recent standardized representation of healthcare data for transmission, designed for API exchange between computers.

FHIR stands for “Fast Healthcare Interoperability Resources” and HL7 (Health Level 7) is the organization that created it. Here are some additional pointers:

HL7 FHIR is not an API or software, but a formatting standard. It describes how healthcare data is structured in JSON, XML, or Turtle when transmitted via Application Program Interface (API). APIs are the most common way that computers talk to each other today. HL7 FHIR was created to resolve the high variability of healthcare data that previous standards (HL7 ADT, HL7 CDA) were unable to accommodate.

HL7 FHIR does not specify how data is stored. Once HL7 FHIR data is received by an entity, it is up to that entity to decide how to store the data within, whether it be SQL, OODB, or NoSQL among others.
HL7 FHIR only specifies where most data elements go. It was designed to be an 80/20 solution, whereby uncommon data elements are left to the community to decide where they are placed, largely relying on intuition.
HL7 FHIR still has unstructured data! Yes, HL7 FHIR still contains plenty of unstructured text fields and accommodates unstructured file attachments. Tenasol specializes in extraction of this data.
HL7 FHIR can be used for everything in healthcare! Lab equipment can use HL7 FHIR. Clearing houses can use it. Of course, health records are represented with HL7 FHIR. It was designed to be used for the entirety of healthcare. It can be used in place of HL7 ADT and HL7 CDA.
There are different versions of HL7 FHIR. The most common today are HL7 FHIR Base R4 - the fourth base implementation - and HL7 FHIR USCDI, the federal implementation. These varying implementations have more narrow rules to better define the standard for narrow uses.

HL7 FHIR Adoption

The adoption of HL7 FHIR at any given time is difficult to gauge, but it is rapidly growing to due to how fast it enables healthcare data to travel, and how much more secure it is. Roughly, around 95% of hospitals within the US are using HL7 FHIR internally. Around 80%-90% office-based physicians are using HL7 FHIR internally [ref].

Internationally, over 74 countries are currently using FHIR To some capacity. Among these, the United Kingdom, the United States, Australia, Kenya, Argentina, and Spain are cited as the highest utilizers at present [ref]

international HL7 FHIR adoption — *International HL7 FHIR adoption*

HL7 FHIR Interoperability

Today, many facilities and health plans use HL7 FHIR internally, but few are using it for inter-facility exchange, also called healthcare interoperability. Recently, more electronic medical record systems are required to have HL7 FHIR features to improve interoperability in the long term.

In many indirect capacities, HL7 FHIR is almost required to meet increasing demands on healthcare data speed government policy requirements. Examples of this are prior authorization (used to be 14 days and is shifting to 7 days), and the aforementioned healthcare interoperability to exchange data between patients, hospitals, and the government.

Resource, Extension, and Bundle Components of HL7 FHIR

Resources: HL7 FHIR “Resources“ are the Lego blocks that make up HL7 FHIR messages. Each HL7 FHIR Resource type (such as Patient, or Organization - often capitalized in documentation to emphasize they are an object) has its own data structure, and can reference other FHIR Resources where appropriate. The structure of HL7 FHIR is such that all Resources are thrown into a JSON-formatted bucket with IDs which reference each other. For example, an Encounter may point to a Patient, a Practitioner, an Organization, and a Location.

Below is the full list of HL7 FHIR resources:

Extensions: Any data that does not have a predefined location within HL7 FHIR Resources may be added into a Resource as a “FHIR Extension”. There is no limit on how many extensions may be added to a Resource and what type of data it can be.

For example, race and ethnicity are not predetermined fields in the HL7 FHIR Patient Resource, however these fields may be added by tacking on race and ethnicity extensions with a URL specifying their public definitions. Almost all HL7 FHIR Resources may have extensions added. Literally anything can be added as an extension including photos, 3d files, text, any numeric value, etc. You can even have extensions of extensions!

*Real HL7 FHIR Extension example defining patient race.*

Bundles: HL7 FHIR Bundles are a common HL7 FHIR Resource type that exist to group other Resources together in sub-buckets. Think of it like a file folder. A bundle may contain bundles, which may contain bundles inside of them. They commonly encapsulate all data that make up the HL7 FHIR message.

HL7 FHIR structure — *Depiction of an HL7 FHIR Bundle*

More on HL7 FHIR Resources

In a previous blog we compared HL7 FHIR to HL7 CCDA data structures. Here is a basic FHIR “Observation” Resource example:

There are a few notable features shown that are common in FHIR Resources. Each FHIR Resource is assigned an id. This is completely up to the user to decide, but should be unique to the object and the database the FHIR Resource data is stored in. Often this is a hashed representation of the HL7 FHIR Resource as is shown in the example (‘id’). The Resource has a subject (Patient Resource reference id), an encounter (Encounter Resource reference id), and internally stores quantity and unit information.

Multiple Encounters, or even multiple Patients can exist in a Bundle of HL7 FHIR Resources. There is no limitation. This is the beauty of HL7 FHIR. However, many systems will define constraints around this for consistency.

Parsing HL7 FHIR Messages

The JSON nature of HL7 FHIR messages make them easily parsable, from a technical standpoint but possibly difficult to traverse if there are both a large quantity and variety of Resources present. This is due to the number of references contained withing HL7 FHIR messages. While HL7 CDA files communicate this information by being hierarchical in nature, HL7 FHIR messages offer more flexibility for referencing information.

This may start to look like a graph database as a web of references to different objects is created for complex FHIR Bundle Resources.

FHIR graph database representation — *A graph node-edge representation of an HL7 FHIR bundle.*

Storage of HL7 FHIR Messages

As stated and shown earlier, FHIR data is a JSON in nature, and therefore very difficult to store in a flat database. General utilities of a valid FHIR message include:

It may be stored in a NoSQL DB (Not Only SQL), or data bucket for later use, treating it essentially as a standalone file for general utility.
It may be parsed, broken down, an inserted into a flat or graph database usually with some data loss during the process due to the nesting of FHIR data and the definitions of the flat database.
It may be used for an immediate non-storage related in-memory need.

What a user decides to do with a healthcare FHIR API message is of course very dependent on the exact need.

HL7 FHIR Implementations and Frameworks

Multiple implementations of HL7 FHIR exist. The reason for this is that the HL7 FHIR standard, in its base implementation (currently Revision 4/R4) is considered not narrowly enough defined. These variations come with implementation guides that describe:

which FHIR Resources may and may not be used for the implementation
what data is required or optional for each HL7 FHIR Resource
how data should be formatted in each field of each HL7 FHIR Resource

Implementation guides are tracked on the the FHIR.org website and include:

FHIR Base R4: The current base, minimum restrictions implementation of the HL7 FHIR standard that permits the use of all resources.

FHIR USCDI: The US implementation of HL7 FHIR accepted by most US federal agencies, especially the ONC. It is far more specific in the resources that may be used.

FHIR Davinci Prior Authorization: An Implementation for the data exchange used for prior authorization in treatment and drug approvals.

Converting to HL7 FHIR

*Possibly HL7 FHIR conversions and methodologies*

See our larger blog on converting medical record file types here.

While there exist mappings and tools for loosely converting HL7 ADT to HL7 FHIR and HL7 C-CDA to HL7 FHIR, there are few tools to convert it to back to these legacy standards as the needs are not particularly strong.

Because of the presence of the legacy formats of PDF data and HL7 CCDA data, there is a strong interest in converting these two HL7 FHIR, however it cannot be directly done. Alternatively it is done through:

Wrapping the original file and sending it inside of a FHIR message
Extracting data from the CCDA or PDF and representing it in HL7 FHIR

There are however numerous resources available to flatten HL7 FHIR data for SQL database storage, which are well documented publicly.

Conclusion

HL7 FHIR messages, structured in JSON, offer flexibility in healthcare data exchange but are challenging to traverse due to extensive references between resources. If you are interested in seeing how you can convert your data from HL7 FHIR or products associated with extracting healthcare data from any types of medical record and rendering it as HL7 FHIR messages, please reach out to our sales team!