HL7 FHIR® began with an open-ended question: What would health data exchange look like if we started from scratch using modern approaches? To answer this question, HL7 turned to other industries for ideas. Recent interoperability successes pointed strongly to the use of RESTful based APIs.
HL7 FHIR combines the best features of HL7 V2, HL7 V3, and CDA, while leveraging the latest web service technologies. FHIR is based on modular components called “resources.” and these resources can be combined to solve clinical and administrative problems in a practical way. FHIR is still being developed by HL7, but the third Standard for Trial Use became available in 2017, and R4 was published at the end of 2018 which was the first normative edition.
The FHIR standard is based on the following simple five key points:
The impact of many of these key points will be seen throughout the following sections.
Comparison to Existing Standards
HL7 V2 is a well-established standard that works well within institutions to connect applications. However, it is a legacy standard with unique syntaxes, custom tools, and a hefty learning curve for those entering the healthcare IT industry. The design of the standard is also limiting to modern devices and apps that are trying to leverage available patient data. Privacy and security are also difficult to implement. These limitations have become a barrier to patient engagement and making patient data available in the most convenient formats.
HL7 V3 was meant to be the successor of HL7 V2. It leveraged modern standards technologies available at the time while being based on a reference model but ended up being overly complex to implement with a steep learning curve. It also had no backward compatibility with HL7 V2, which made switching to the new standard all the more complex given how embedded HL7 V2 is within the U.S. healthcare system.
HL7 FHIR Differentiators
HL7 FHIR differentiates itself from past standards technologies by focusing on the following:
Focus on those who are implementing the standard
Ensure common scenarios are easily supported
Leverage cross-industry web technologies
Require human readability as base level of interoperability, same as CDA
Make the standard freely available
Deliver flexibility by supporting multiple paradigms and architectures
Provide for modern governance of data
Focus on the Implementers
HL7 FHIR was written with implementers as the target audience in mind. Of high importance was the use of reference implementations, which were incorporated into the design of FHIR from the beginning. Robust testing was deemed important as well for implementers, which led to the availability of public test servers.
Support for Commonly Used Workflows
The content in the core specification is meant to cover the top 80% of use cases. This is similar to the focus of the HL7 V2 standard, only the extensions will be cleaner and easier. The idea is to focus on the real needs of the industry but allow for all the special use cases as well. HL7 V3 was commonly criticized for trying to account for too many use cases in the core standard, thus leading to an overly complex standard that was difficult to achieve.
You might also like
Addressing NHS challenges: the role of next generation interoperability
A vendor-neutral & innately interoperable technology stack can help NHS solve data exchange and data quality challenges.