Explanation of HL7 FHIR
HL7 FHIR is the fourth standardized representation of healthcare data for transmission.
It is a new data standard whereby the guardrails are narrowly defined, data transfer is fast, but anything is still possible. In this blog we will cover in more detail some of the defining characteristics of what FHIR Resources are and how they are managed. To review other standards, see our blogs on HL7 ADT or HL7 CDA.
To start, it is important to understand what HL7 FHIR is and is not:
FHIR is not an API, software, or even filetype, but a syntax. It describes how healthcare data should be structured in JSON, XML, or Turtle when transmitted via an API. APIs (Application Program Interface) are the most common way that computers talk to each other today. FHIR was created to iron out the issues associated with extremely high variability of data in healthcare that the previous standards (HL7 ADT, HL7 CDA) were each not able to handle.
FHIR does not specify how data is stored. While FHIR specifies how data looks when passed, it does not make any assertions on how to store data that has been transferred with FHIR. That is up to each entity to decide, whether it be SQL, OODB, or NoSQL among others.
FHIR only specifies where most data elements should go in it’s structure. It was designed to be an 80/20 solution, whereby uncommon data elements are up to the community to decide where they are placed, largely relying on intuition.
FHIR still has unstructured data! Yes, FHIR still contains plenty of unstructured text fields and accommodates unstructured file attachments. Tenasol specializes in extraction of this unstructured FHIR data.
FHIR can be used for all healthcare applications! Lab equipment can use FHIR. Clearing houses can use FHIR. Of course, health records may be represented with FHIR. Appointments can be scheduled with FHIR. It was designed to be used for all use cases across the entirety of healthcare. It can be used in place of HL7 ADT and HL7 CDA uses.
There are different versions of FHIR. The most common today is HL7 FHIR R4. This is also called Base R4, and is the fourth base implementation of FHIR. This means there was also an HL7 FHIR R3, however it is not widely used. Other implementations of FHIR approve or disapprove of the use of certain components of the FHIR standard, and specify more required fields, making it more narrowly defined. An example of this is the USCDI implementation of HL7 FHIR which is the federal implementation.
HL7 FHIR Adoption
One might ask how adopted FHIR is by the healthcare community. The answer 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.
Today, many facilities and health plans use FHIR internally, but few are using it for inter-facility exchange, also called healthcare interoperability.
In many indirect capacities, FHIR is almost required to meet increasing demands on healthcare data speed government policy requirements. Examples of this are prior authorization (used to be 30 days and is shifting to 3 days), and the aforementioned healthcare interoperability to exchange data between patients, hospitals, and the government.
3 Core Concepts of HL7 FHIR Data Elements
Resources: HL7 FHIR “Resources“ are the Lego blocks that make up FHIR messages. Each FHIR Resource has its own data structure, and can reference other FHIR Resources where appropriate. The structure of 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.
Table of all HL7 FHIR ‘Resources‘
Extensions: This term gets thrown about a lot when talking about FHIR. Any data that does not have a predefined location within 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 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 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 FHIR Extension example defining patient race.
Bundles: FHIR Bundles are a common 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 makes of the FHIR message.
Depiction of an HL7 FHIR Bundle
Features of a FHIR Resource
In a previous blog we compared FHIR to CCDA data structures. Here is a basic FHIR “Observation” Resource example:
Observation HL7 FHIR Resource
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 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 FHIR Resources. There is no limitation. This is the beauty of FHIR. However, many systems will define constraints around this for consistency.
Programmatically Parsing FHIR Messages
The JSON nature of 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 FHIR messages. While CCD-A files communicate this information by being hierarchical in nature, 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.
Storage/Use of a FHIR Message
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.
Variations of HL7 FHIR
Multiple implementations of 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 FHIR Resource
how data should be formatted in each field of each 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 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 HL7 FHIR
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.
There are however numerous resources available to flatten FHIR data for SQL database storage, which are well documented publicly.
Conclusion
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 FHIR or products associated with extracting healthcare data from any types of medical record and rendering it as FHIR messages, please reach out to our sales team!