What is FHIR?
Fast Healthcare Interoperability Resources commonly known as FHIR (pronounced as ‘fire’ 🔥) is a standard defined by HL7(Health Level 7) to promote healthcare information exchange. The standard describes a set of ‘Resources’ and a set of methods for exchanging these resources in many different contexts. The following can be considered as some of the main objectives of FHIR,
- Facilitating interoperability between healthcare systems
- Providing healthcare providers and individuals easy access to healthcare information
- Allowing third-party application developers to provide medical applications which can be easily integrated into existing systems.
Now let’s take a brief look at the history of FHIR.
History 🕑
Interoperability of healthcare systems came to the discussion from the 1980s as hospitals started to using more than one system within its premises. Standards like HL7 2 and HL7 3 addressed interoperability initially. However, with time more and more systems were in use. The data volume available increased and data was available in more places like on home devices and labs outside the hospitals. So, in 2012 HL7 task force began creating a new standard from scratch to replace the outdated 30 year old HL7 2 and complicated HL7 3, which resulted in FHIR. The main goal of the new standard was to allow a user to be in one place and to see all the data in various places.
That is enough with the history I guess, now let’s take a look at how data is represented in FHIR to promote interoperability.
FHIR Resources 🏥
FHIR is based on a set of modular components called ‘Resources’. In simple terms everything in FHIR is a ‘Resource’. The goal behind FHIR is to create a list of Resources that, individually or as a combination, satisfy most common use cases. These Resources form the base for data exchange. As of FHIR v4 there are 145 FHIR Resources defined. FHIR breaks down healthcare data into categories such as patients, observations, laboratory results and many others. Each of these categories will be represented in FHIR specification as a ‘Resource’. A FHIR Resource defines the data elements, constraints on data and data relationships. For example, FHIR Patient Resource defines what are the attributes of a patient record, what are the data constraints and what are the relationships with other resources. The concept of ‘Resources’ provides following advantages.
- Usability — FHIR resources are defined in a manner that they can be understood by technical experts and industrial experts resulting in high adoption.
- Reusability — FHIR resources are designed in a reusable, well structured manner avoiding overcomplication and redundancy of data.
- Performance — Compared to previous data exchange standards FHIR Resources are simpler in their construction making them more suitable for exchange across a network.
FHIR spec divides FHIR Resources into several levels. The image below represents the various levels of FHIR resources. You can learn more about FHIR resources from here.
FHIR Profiling
As we discussed above base FHIR spec. describes a set of base resources that are used in many different contexts in healthcare. However, due to the wide variety of regulations and requirements between jurisdictions in the healthcare ecosystem, FHIR usually requires further adaptation to particular contexts of use. FHIR profiling allows one to author and publish a customized, more specific resource definition, by specifying a set of constraints and/or extensions on the base resource.
For example, the base resource Patient can be modified to make ‘gender’ mandatory. This modified resource can be published as a new FHIR profile. For use in the United States the FHIR base patient resource is modified to get the US Core Patient Profile. Ultimately, interoperability comes from shared profiles as profiles are used by healthcare systems in a certain jurisdiction, use case to exchange data.
FHIR Implementation Guides
An Implementation Guide(IG) is a special FHIR Resource which includes a set of rules about FHIR profiles that should be used in a particular use case(ex: US Core Implementation Guide). It is mainly targeted towards implementers and system integrators and IGs are generally published and available on web. As IGs are machine readable they can also be used to validate an implementation once it is completed.
So, up to now we have covered how FHIR data is represented. Now let’s look at how this represented data is exchanged.
FHIR Data Exchange 🔁
There are several ways defined in FHIR that systems can exchange data, these includes FHIR messages and FHIR documents but the most common way to exchange FHIR data is using RESTful APIs. FHIR defines a set of interactions which can be used to manage FHIR resources. The FHIR API should be developed following the FHIR API spec. FHIR servers can choose which of these interactions are made available and which resource types they support. Let’s take a look at a simple example to understand how FHIR APIs are used practically. Consider a case in which a patient diagnostic report is available on a FHIR server as a ‘DiagnosticReport’ resource. A third-party healthcare application can get this resource using a FHIR REST API and represent the data to the patient/doctor in a readable manner.
Up to here we have covered the basics of FHIR, how data is represented and exchanged.
I am going to stop here for this article. FHIR is a very detailed standard and it is very difficult to summarize it to one article but I hope I gave you a good introduction. You can always go to FHIR docs and learn more. Hope you had a good read. Thank you😊
FHIR Documentation — http://hl7.org/fhir/
