History of FHIR
-
Describe the key limitations of HL7 V2.
HL7 V2’s data format is outdated compared to modern formats like JSON and XML. It also does not support many health-related data types and is not structured enough to support interoperability.
-
Describe the key limitations of HL7 V3.
V3 is structured enough to support interoperability but is difficult to implement and has not been widely adopted.
-
Understand how FHIR is related to HL7 V2 and V3, and how the characteristics of these standards influenced their adoption.
FHIR is structured enough to support interoperability, is simpler than V3, and uses uses common standards like JSON, XML, and REST, so integrates well with non-health-specific software.
FHIR is the third health data standard that the HL7® standards developing organization has developed. The two previous standards are HL7 V2 and HL7 V3.
The history of these standards and how they relate to FHIR is described below.
1 HL7 V2
HL7 released HL7 Version 2 (commonly called “V2” or “HL7 V2”) in 1987, and V2 has been in continuous development for more than 30 years. It is a messaging standard for exchanging clinical data between systems. Though it is widely implemented, V2 does not meet modern health interoperability needs. For example:
V2 predates modern web-based interoperability technology, making integration into current computer systems difficult. V2 uses a custom data format, requiring purpose-built software to read and write V2 messages.
Expand to see an example of a V2 message.From Wikipedia:
MSH|^~\&|MegaReg|XYZHospC|SuperOE|XYZImgCtr|20060529090131-0500||ADT^A01^ADT_A01|01052901|P|2.5 EVN||200605290901|||| PID|||56782445^^^UAReg^PI||KLEINSAMPLE^BARRY^Q^JR||19620910|M||2028-9^^HL70005^RA99113^^XYZ|260 GOODWIN CREST DRIVE^^BIRMINGHAM^AL^35209^^M~NICKELL’S PICKLES^10000 W 100TH AVE^BIRMINGHAM^AL^35200^^O|||||||0105I30001^^^99DEF^AN PV1||I|W^389^1^UABH^^^^3||||12345^MORGAN^REX^J^^^MD^0010^UAMC^L||67890^GRAINGER^LUCY^X^^^MD^0010^UAMC^L|MED|||||A0||13579^POTTER^SHERMAN^T^^^MD^0010^UAMC^L|||||||||||||||||||||||||||200605290900 OBX|1|NM|^Body Height||1.80|m^Meter^ISO+|||||F OBX|2|NM|^Body Weight||79|kg^Kilogram^ISO+|||||F AL1|1||^ASPIRIN DG1|1||786.50^CHEST PAIN, UNSPECIFIED^I9|||AV2 does not provide enough structure to support semantic interoperability across implementations.
V2 does not have a standard approach to sending common types of health data, like PDFs.
More information on the early history of HL7 and the development of V2 can be found here.
2 HL7 V3
HL7 Version 3 (“V3”, released in 2005) was created to address limitations of V2. It included a more rigorous approach to data modeling (the Reference Information Model), and used a common data format (XML).
V3 was not as widely adopted as V2, in part due to its complexity. The C-CDA® standard for clinical documents is the most widely adopted application of V3. For example, the C-CDA standard is used in the Meaningful Use criteria.
3 FHIR
HL7 developed FHIR in the early 2010s to provide a more interoperable alternative to V2 and a simpler alternative to V3.1 Like V3, FHIR uses common data formats (like JSON and XML). It also uses a common architecture (REST) for communication between systems. These design decisions make FHIR-enabled systems easier to integrate with mobile and cloud-based health applications compared to V2.
Recall from FHIR from 1,000 Feet that:
The FHIR specification follows the 80/20 rule to determine which data elements are included in a resource: data elements are typically included only if 80% of relevant systems will use them. Less common data needs are handled through FHIR extensions. This means that FHIR-enabled systems will implement most common data elements consistently.
In late 2014, HL7 released the first official version of FHIR. In 2015, the Office of the National Coordinator for Health Information Technology (ONC) issued the 2015 Edition Cures Act certification criteria, which included an API criteria. While the API criteria did not target a specific standard, many adopted FHIR for the criteria. ONC continued to refine the certification’s criteria through revisions of the 2015 Edition Cures Act, and by 2019, 87% of hospitals in the US were using ONC certified EHRs with FHIR APIs as seen below. (Posnack and Barker 2018)
The late 2010s saw adoption outside of EHRs. For example, Apple uses FHIR in HealthKit for accessing patient health data directly from EHRs. Moreover, three major public cloud vendors (Amazon, Google, Microsoft) provide FHIR-enabled services as well.
3.1 FHIR releases
As of April 2023, the most recent version of the FHIR specification is Release 5 (often referred to as “FHIR R5”). ONC provides a summary of FHIR releases since the first release in 2012:
HL7® FHIR® has evolved through four releases since its initial presentation in May 2012. It has grown from a true draft standard with 49 Resources to its current 145 and continues to expand. In that time the standard has improved and changed to meet the needs of the health information technology community.
Draft standard for trial use 1 (DSTU1)
FHIR’s first publication in September 2013 showed a new way forward for health care data exchange. Draft Standard for Trial Use 1 had 49 resources and focused on two use cases, creating a Personal Health Record on a mobile device and the retrieval of documents, such as encounter or discharge notes, to a mobile device. This initial release sparked the community’s interest in expanding FHIR to cover a wider variety of health care and health IT needs.
Draft standard for trial use 2 (DSTU2)
FHIR grew in market acceptance with the publication of the Draft Standard for Trial Use 2 in 2015. Efforts including the Argonaut Project developed Implementation Guides (IGs) and other technologies to support FHIR adoption by EHR developers and other health IT entities. The structure of Resources was adjusted to make creating extensions easier, allowing for more use cases to be covered without changes to the core standard. New Resources were also added to support non-clinical data, including claims and benefits processing.
The publication of FHIR DSTU2 included the creation of the FHIR Maturity Model (FMM). When new Resources are created, they are not immediately ready for use in live settings; they must be refined and tested for a variety of uses and settings. The FHIR Maturity Model established a set of levels that progressively measure technical advancement, known as maturity. Resource maturity as defined by the FMM begins with an initial draft and achieves final status with implementation in multiple settings. Since the maturity of the FHIR standard overall is not tied to the maturity of Resources, Resources can move up the maturity ladder between FHIR releases. The FMM, which is also applied to other components of the FHIR standard, defines Resource stability with six levels:
FMM0 (Draft) - The resource is still in early development but has been accepted into the FHIR standard.
FMM1 - The Resource has no current technical errors and is believed to address all design goals.
FMM2 - The Resource has been tested and approved at a FHIR Connectathon with multiple FHIR-enabled computer systems tested.
FMM3 - The Resource passed all quality checks and an HL7 community ballot that determines if it is ready for trial use.
FMM4 - The Resource has been tested for functionality for all intended purposes, has been published in a formal HL7 publication, and is operating in at least one prototype system.
FMM5 - The Resource is in use in at least five distinct production systems operating in at least two countries.
Substantive changes at the FMM4 or FMM5 levels that would change usage from those already established or would break compatibility with existing implementations would require significant justification to be accepted and to move forward. After FMM5, a Resource reaches “normative”1 level; at this level, future changes must be backwards compatible so that applications that implement those Resources aren’t at risk of being broken as the FHIR standard changes.
Standard for trial use 3 (STU 3)
FHIR Standard for Trial Use 3 was released in 2017 with improvements to the core Clinical, Administrative, and Financial Resources, improvements to the Clinical Decision Support and Clinical Quality Measure Resources and a new framework for workflow and task management. Additionally, tools were introduced that made FHIR IG creation and publication to the web easier, faster, and more unified.
Release 4 (R4)
As the first release with normative content, the 2019 release of FHIR Release 4 left behind the Trial Use name. Two key clinical Resources, Patient and Observation, were released as normative, along with the RESTful API, the XML and JSON formats, and nine additional Resources.
In 2020, ONC published the Final Rule for the 21st Century Cures Act, establishing FHIR R4 as the standard required for Health IT Certification.
Looking ahead to Release 5 (R5)
FHIR Release 5 will see increased normative content, with over 30 Resources having been nominated by their HL7 Workgroups to be matured to that status. In addition, the community will continue to develop the supportive specifications to FHIR, such as the authorization framework SMART, Clinical Decision Support Hooks (CDS Hooks), and the Bulk Data Transfer specification, which will help implementers create a complete FHIR-based exchange of health care data.
With the maturing of the FHIR IG tools and templates, better integration with public health, imaging, financial management, genomics and other fields will keep FHIR at the forefront of health IT.
NoteNote: FHIR R5 was officially released in March 2023.
References
Footnotes
This blog post from 2011 by Grahame Grieve, one of the primary creators of FHIR, explains how FHIR is informed by V2 and V3.↩︎