Grahame Grieve, the Product Director for FHIR, has recently announced that FHIR release 4 was finalized 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?
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 summarized as:
- Global adoption
- Updated implementation guides
- Increased resource maturity
- 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 organizations such as the ONC in the US and NHS in the UK, where FHIR-based APIs enable the seamless exchange of information between different organizations. 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 synchronize 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.
Schedule a meeting at HIMSS with an Orion Health expert, to learn how to enhance your data journey, by leveraging the power of Open APIs to enable the best applications to be developed for every healthcare scenario. Open APIs offer secure access to the rich patient record using innovative industry standards, such as FHIR. As the preferred interoperability standard FHIR is designed to make it easier to exchange all healthcare data between systems in a straightforward and secure manner. Whichever way you choose to improve healthcare, our platform provides you with the right tools and data to help you build innovative applications.