Explanation of HL7v4 FHIR (ELI5)
FHIR data is a unique new generation of data 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 FHIR resources and how they are managed.
To start, it is important to understand what FHIR is and is not:
FHIR is not an API, software, or even filetype, but a globally supported standard. It describes how healthcare data should be structured in JSON, XML, or Turtle when transmitted or received via API. APIs (Application Program Interface) are the most common way that computers talk to each other today. It was created to iron out the issues associated with extremely high variability of data in healthcare.
FHIR does not specify how data is stored. While FHIR specifies how data should look 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, and there are an infinite number of methods to do so.
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 user on where they are placed, largely relying on intuition.
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.
There are different versions of FHIR. The most common today is Base R4, however different subversions of FHIR approve or disapprove of the use of certain components of the FHIR standard, making it more narrowly defined in each instance. An example of this is the also popular USCDI.
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. 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 generalized interoperability (data exchange) required between hospitals, payers, the government, and patients.
Concepts
Resources: These are the “Lego blocks' that make up FHIR. Each one of these has its own data structure, and can reference other resources where appropriate. The structure of FHIR is such that all FHIR resources are thrown into a bucket with IDs which reference each other. For example, an Encounter may point to a Patient, a Practitioner, an Organization, and a Location.
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 any location that seems reasonable. For example, race and ethnicity are not predetermined fields in the Patient resource, however these fields may be added by tacking on race and ethnicity extensions. Almost all 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!
Bundles: Bundles are a common Resource type that exist to group resources together. Think of it like a folder. A bundle may contain bundles. They commonly encapsulate all data that makes of the FHIR message.
Notable Features of a FHIR Resource
In a previous blog we covered the basics of FHIR formatting of medical records. Here is a basic “Observation” resource example:
There are a few notable features shown that are common in many resources. Each resource is also assigned an id. This completely up to the user to decide but should be unique to the object. Often this is a hashed representation of the resource as is shown in the example. The resource has a subject (patient reference), an encounter (encounter reference), and internally stores quantity and unit information. It’s also wirth noting that in many “system” instances, FHIR does not store measurement or coding standards, but rather permits the user to point to who defines those systems with a URL.
Multiple Encounters, or even multiple Patients can exist in a Bundle of Resources. There is no limitation.
Programmatically Parsing a FHIR Message
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 be 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 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. There are generally utilities of a valid FHIR message:
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 API message is of course very dependent on the exact need.
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!