Grahame Grieve, the Product Director for FHIR, has recently announced that FHIR release 4 was finalised at the end of 2018 – it has been over a year and a half since the previous version – Standard for Trial Use 3 (STU3). So, what’s new since then?

What is FHIR?

HL7® FHIR® or Fast Healthcare Interoperability Resources is a specification for healthcare interoperability. It defines the format of information in the form of resources to be shared, as well as describing a number of exchange mechanisms – real-time REST, Document and Messages among others (though you can use others if needed).

The progress from FHIR STU3 to Release 4 can be summarised as:

  1. Global adoption
  2. Updated implementation guides
  3. Increased resource maturity
  4. Additionally, related specifications

1. Global adoption

FHIR is now a global healthcare standard, and it is available in every country in the world. It has been adopted by large organisations such as the ONC in the US and NHS in the UK, where FHIR-based APIs enable the seamless exchange of information between different organisations. What’s very exciting for the community is that the list of adopters includes developing countries as well. 

The FHIR community provides tooling, training, and events to help implementers learn more about FHIR. HL7 encourages and supports all adopters of FHIR, from established healthcare networks right through to those starting at the beginning of their healthcare interoperability journey.

The FHIR chat is a community of FHIR users which is free to join and has a large number of streams for the various programmes of work:

  • Country-specific streams
  • General streams like the implementer’s stream
  • Project-specific streams such as the bulk download specification or SMART
  • There’s even a stream for patient empowerment discussions
2. Updated implementation guides

We see an increasing number of Implementation Guides – artifacts that describe how to use FHIR to meet specific requirements often in particular countries. Also, these guides are bringing in new groups to the community – such as the Da Vinci project which is focused on the needs of the payer community as the way we deliver healthcare continues to evolve.

3. Increased resource maturity

There have been a vast number of changes that have occurred since the FHIR STU3 version, both concerning the detail of the individual resources that FHIR defines as well as new resources needed as the scope of FHIR continues to extend.

There’s a tab on each resource page in the specification that describes the changes from the previous version on the ‘R3 diff’ tab) and there’s a complete list of all resource changes as well, this includes the new resources. In addition, the project provides transforms to map between STU3 and R4 in the form of mapping language statements. (Though there will always be the need to check these mappings in practice – completely automated translations for all possible uses is problematic).

Also, most significantly, a number of the resources are now at a maturity level of ‘Normative’ which means any changes to those resources will be backward compatible. If you weren’t aware, all resources have a ‘maturity’ level which indicates how well they have been ‘exercised’ in the real world. The higher the number, the more mature they are and the less likely to change between FHIR releases. This concept of resource maturity has always been the strength and the weakness of FHIR. It does mean that we can be as sure as we can that the resources are ‘fit for purpose’, but it also means that applications need to have a strategy for managing different versions of FHIR.

4. Additionally related specifications

Finally, we see a number of associated standards and projects that build on the ‘FHIR Core’ to address specific implementation issues. These include:

  • SMART App launch– an authentication mechanism based on Outh2
  • CDS-Hooks – for invoking functionality like Decision Support within the context of an EHR (The ‘hook’ part describes how specific workflow events like prescribing can trigger these actions)
  • FHIRcast is a mechanism for different applications to synchronise their context – which patient they have selected, who is the user and so forth
  • Bulk download – a way to extract FHIR resources in bulk, rather than for individual patients

All of these are going to be necessary to support the ecosystem that we are working toward. 

So, what’s coming next? Grahame recently posted the goals for the next release; they are about addressing issues in implementing FHIR, as well as continuing to mature the resources, for example, managing multiple versions of FHIR, migrating between FHIR and other standards, and creating Implementation Guides.

One thing’s for sure though if you are involved in sharing or consuming healthcare information, you need to pay close attention to FHIR.

To learn more about FHIR, read my white paper Enabling the Ecosystem with FHIR which discusses how healthcare information can be made available where and when it is needed.

Go to White Paper