Health IT : focus on FHIR

11 minute(s) read

As I’ve been immerged in e-health interoperability for years, I thought it was time to bring a focus on a major step in this field. I propose to sum-up the main assets and the few drawbacks of this “not that new” standard.

FHIR : another standard to “rule them all” ?

Standards

Definition

FHIR stands for “Fast Healthcare Interoperability Resources”.

It is an international healthcare information exchange standard developed by the HL7 organization. It defines how healthcare information can be exchanged between different computer systems regardless of how it is stored in those systems.

It has the potential to eventually cover all flows provided by health information systems, in every conceivable context. It is best suited for mobility needs and related developments. It benefits from feedback on another HL7 standard : CDA (Clinical Document Architecture).

Evolution and maturity of the HL7 standards

HL7 timeline

FHIR timeline

FHIR release 4 is the latest version and is the first one containing normative content.

What is FHIR ?

  • It is a data model mainly based on the one used in the HL7/IHE world.
  • It relies on conventional web technologies : REST architecture with web services using mainly the HTTP protocol and queries/replies organized and coded with the help of “standard” formats like JSON or XML.
  • It consists of :
    • Tools that will facilitate the adoption of FHIR regardless of the programmation language used (validation tools with schemas/schematrons, FHIR editors, learning tools, etc.).
    • FHIR servers accessible through FHIR API.
    • Open source specifications, free of charge, well documented, fully available online.
    • A very active community of developers (connectathons, FHIR Dev Days, FHIR France community…).
  • The base FHIR specification is a “platform specification” describing a set of core resources, frameworks and APIs.

Last but not least, FHIR is “Fast” (to design and implement).

Specifications

FHIR resources

Definition

A FHIR resource is the smallest interchange unit and has a fixed and clear boundary.

“Core resources” are defined in the FHIR specification : they contain only those attributes that are relevant to 80% of the implementers and allow easy extension for the remaining 20% of elements.

For example, some core resources are : Patient, Appointment, Problem, Medication, Practitioner, Observation (vital signs, lab tests/imaging results…), Encounter (medical consultation, hospital admission…), etc.

Resources are characterized by a definition, some properties, an “identity”, a human-readable and structured content, a base language, a reference to “Implicit Rules” and a version number.

They can be used to exchange and/or store data in order to solve a wide range of healthcare related problems, both clinical and administrative.

Each resource has a maturity level that goes from a “draft” level to a final maturity level which will allow a stable and large scale use. The whole process goes through 5 other successive maturity levels : level 0 “draft” –> levels 1/2/3/4/5 –> normative level.

All the resources (148) are listed here : http://hl7.org/fhir/resourcelist.html

Resource content

Sample

A resource consists of :

  • Metadata : workflow and clinical context (for example, a version identifier or the time of the last update).
  • Narrative : human-readable description of the resource.
  • Elements : resource properties or attributes. For example, here are some elements related to the “Patient” resource : “Name”, “Sex”, “birthDate”.
  • Data types : an element is characterized by a specific data type. For example, the element “birthDate” of the “Patient” resource is based on the data type “Date”.
  • Extensions : sometimes, a resource needs to be extended to additional information and details that should match which a specific context. For example, the patient’s religion can be recorded in some countries, while other countries can’t record it due to different regulations. The “Patient” resource doesn’t include by default the “Religion” element, but it could be extended using a “patient’s religion” extension.

Sample

Resource identity

A resource identity consists of :

  • an endpoint which allows to locate the resource (example: name of the FHIR server and of the main directory),
  • the resource type,
  • and the resource identifier (logicial ID). In fact, it’s a URL which can be used (pasted) in a web browser and which allows to record, update, delete, locate ou retrieve a resource :

Resource identity

How to use them?

FHIR provides an API REST (REpresentational State Transfer) which facilitates the interactions and the operations involving resources by using HTTP requests :

  • Create = POST https://server.com/path/{resource type}
  • Read = GET https://server.com/path/{resource type}/{identifier}
  • Update = PUT https://server.com/path/{resource type}/{identifier}
  • Delete = DELETE https://server.com/path/{resource type}/{identifier}
  • Search = GET https://server.com/path/{resource type}?search criteria
  • Etc.

Resources offer a great modularity : their size is limited and they can be interconnected, interact with each other, be grouped together, etc. They offer too an alternative to the centralization of data by exposing the resources as services. The core resources (Patient, Practitioner, etc.) can be easily collected and manipulated, directly through their own URL.

Bundles

Resources can be grouped in a “bundle” based on several criteria (a bundle is itself a resource), in order to :

  • transmit queries or reply to queries through messages,
  • build a FHIR document which can, for instance, include a style sheet (so it can be correctly formatted and displayed) and a signature.

Bundle

Thanks to bundles, FHIR is therefore able to manage documents, not only flows of structured data. A FHIR document is a bundle that gathers other resources linked together by references, each one having its own life cycle independently of the others.

Profiling

The FHIR specification includes only elements needed by at least 80% of resource users (Pareto law). In addition, the standard offers a profiling process of the resources intended to adapt them for territory or local needs (region or organization). By using a profile, it is possible to define a set of constraints on a specific FHIR resource. Like resources, profiles are charactized by a “maturity level” (from 1 to 5). They can be published and shared online, so others can reuse them in similar use cases.

Here is a sample FHIR profile (constraints) that applies to the Patient resource :

  • You can decide to use the “Name” element and specify in your profile if this element is mandatory, by setting its minimum cardinality to 1.
  • You can decide not to use the element “birthDate” by setting its maximum cardinality to 0.
  • You can also add elements that are not already available in the main resource : for example, you can add the element “hair color” and create an extension for that.

National or regional profiles

Constraints can also be applied to existing profiles by designing derived profiles. A “national profile” can therefore be defined based on a specific resource: for example, a country can apply regional constraints to a core resource (ex : the Patient resource) so it can fit specific needs. This new resource will then become the country’s resource version and acts as its national profile. Any organization will still be able to apply specific constraints to make a derived profile of this national profile. You can even go further and design additional layers (layered profiles). For example, Norway has introduced regional profiles derived from the national profile, in order to incorporate regional differences.

Profiles

Below is an example of the German national profile for Patient : all elements of the core Patient resource are shown whether these are changed compared to the core resource or not.

German profile

CDA vs FHIR

Main differences

CDA (Clinical Document Architecture) is a HL7 standard that solely describes the content of clinical documents through a quite burdensome and verbose structuring. A CDA document constitutes an indivisible “whole” : all the relevant informations are contained in differents sections of a single XML file. The CDA content is made of a structured header and a structured (XML) or unstructured body (pdf, txt, rtf, jpeg or tiff file encoded in Base64) :

CDA document

FHIR is more flexible and allows to manage more use cases than CDA :

  • FHIR can manage “messages” between softwares or softwares components : query, replies, information (ex : in a hospital, the patient administration system informs another component of the hospital information system that a patient has been admitted).
  • FHIR, like CDA, can manage “documents”, for example a radiology report or any document intended to be recorded, shared and/or exchanged.
  • FHIR is not limited to clinical documents : it can manage as well administrative documents, guidelines, etc.
  • A FHIR document can contain resources and it can also contain references (links) to resources or documents (JPEG, PDF…) which are located “elsewhere” on one or many other servers.
  • FHIR is based on lightweight and real-time web services (REST) already used by large scale shared informations systems (Facebook, Twitter, Google…).

The two following examples show how FHIR documents can store or only locate the resources needed for the construction of the whole document.

FHIR document, case 1 : resources are stored in the document

This diagram shows a simple FHIR document, for example a clinical note related to a medication list and blood pressure measurements, in a context of high blood pressure. The document also contains the identity of the author of the document and the identity of the patient who is the subject of the document. In this case, all the resources are included in the FHIR document (bundle).

FHIR document case 1

FHIR document, case 2: resources are distributed

In that case, some resources are located on dedicated servers : for example, directories that handle Patient’s and Practioner’s identities).

FHIR document case 2

Current international context

  • Most of the electronic health records (EHR in hospitals or health records shared on a larger scale like the French Shared Medical Record) are capable of exporting clinical documents using CDA.
  • Their CDA export capabilities are more stable than by exporting documents through FHIR APIs due to anteriority of CDA.
  • That being said, FHIR looks easier et faster to implement by developers than CDA.

FHIR and CDA can coexist side by side!

  • A FHIR document FHIR can contain a link/URL referencing a CDA document stored on another server.
  • A FHIR API can create CDA documments by using FHIR resources or convert FHIR documents into CDA documents for regulatory purposes (ex : probative value archiving).
  • A mapping table can be set in order to extract some sections from a CDA document and then convert them into FHIR resources.
  • Eventually, you can have the choice to provide and exchange either FHIR or CDA documents depending on the characteristics and the constraints of each health information system.

Too much hype about FHIR?

The biggest issue about FHIR is the speed of its introduction and corresponding lack of maturity. The first formal, normalized release (R4) was not approved until early 2019. The term “normalized” is deceiving as FHIR is basically a compilation of many individual mini specifications for the various resources of which in R4 there are only 13 in a final, normalized state out of the close to 148 resources. One could therefore argue that less then 10 percent of the spec is stable and ready for implementation as more than 90 percent can and most likely will have substantial changes to its interface.

FHIR is not “plug-and-play”, even if many e-health IT players thought that FHIR would resolve all the problems of interoperability in the field of e-health :

  • Is FHIR really a standard? It could be, but in fact there are no enforcement mechanisms and EHR vendors and other players have already implemented different versions of FHIR, so it is hard to assume that FHIR could be consistent across implementations.
  • EHR vendors are not implementing all available FHIR APIs and/or are not consistently implementing the entire API. This creates another source of inconsistency. Developers who rely on FHIR for EHR integration must keep track of which EHRs have implemented which APIs. A robust API provided by one EHR may be completely absent in another. And even if two vendors implement the same FHIR API, they may not implement the entire specification for that particular API. What guarantee can be given to the customers ?
  • FHIR extensions are interesting because they allow to lighten the core FHIR specification, but they also undermine standardization. Permissive customizations can result in divergence rather than convergence.

Hype

“Hype cycle” : evolution of the maturity of emerging technologies

Source : http://blog.otechimg.com/2019/12/

Conclusion

It is not all about the hype and the maturity of FHIR, it is about what could help IT players in the field of e-health in the next few years. On this point, FHIR remains a very strong candidate. Its great flexible development and deployment, its versatility, the potentially unlimited number of use cases and many other strenghts must convinced anyone that FHIR is a powerful tool for years to come. It also brings:

  • the native coverage of many needs (Pareto law) without enforcing an overly rigid framework having a lot of constraints,
  • an innovation accelerator due to its deployment speed and technologies and protocols (HTTP, REST…) used which are very well suited to design proofs of concept and demonstrators,
  • the ease of integration with existing standards, which provides all stakeholders with a wide range of design choices and of interoperability arrangements,
  • a particularly well suited tool to structured data flows and treatments, while remaining compatible with a “document based approach”,
  • a very particular interest for mobility and real-time transactions.

You should just be careful and pragmatic about the way to use the R4 release. The next R5 release will probably introduce some changes which could lead to question the appropriateness of developments made on the basis of FHIR R4.

The design choices should therefore preferentially be based on the reference guides provided by the structures which work on the interoperability framework in France (mainly the ANS and Interop’Santé regarding FHIR) and should follow the CI-SIS accurately. On this point, it should be recalled that the transmission of use cases and needs from the field to the ANS is a prerequisite for a broader adoption of FHIR in the CI-SIS.

References

Updated:

Written by
Laurent Guigue

Laurent Guigue

Physician, e-health expert at Santeos/Worldline and photo-addict