Estimated read time: 7 minutes
Recently, Health Level Seven International’s (HL7) Fast Healthcare Interoperability Resources (FHIR) standard reached a key milestone with version 4—the first normative release of the framework. As the organization continues to build on the momentum toward health care interoperability, HL7 is now focused on version 5, expected to be published in the third quarter of 2020. With the version 4 release, and the ongoing work for version 5, health care professionals can look forward to an increase in normative content, greater standardized access to complete patient records and support for more powerful apps.
The importance of a normative release
A normative standard is one that is guaranteed not to change, at least for a well-specified and extended period. In standards development, a trade-off is often present between the stability of the standard and the rapidly evolving needs of health IT. If a standard’s specification becomes normative too early in its development, it may not be good enough to cover the complexity of health care, or to address the evolving needs of a dynamic environment. But if the specification is too fluid, with rapid emergence of new versions, implementers may not be able to write stable code. Implementations that used different versions won’t be able to “talk” to each other, which negates the value of standardization.
HL7’s FHIR has addressed this trade-off between stability and responsiveness by declaring the core of the standard normative, while allowing other parts to continue to evolve. The infrastructure of FHIR is now frozen, as are two key FHIR resources: Patient and Observation, which includes lab results, vital signs etc. The normative infrastructure includes the overall RESTful API software architectural style, the terminology layers (CodeSystem and ValueSets) and the conformance framework necessary to support testing and validation.
The origins and progressions of FHIR
Given the importance of FHIR, it’s useful to explore where it came from and the promise it offers. These are a few key moments in the evolution of FHIR:
- “Version 2” (V2): Initially released in the late 1980s, it is now in wide use around the world, primarily to send packets of clinical data between admission, discharge and transfer patient registration systems, lab systems, EHRs and more. V2 was highly successful, but implementers complained that the specification was too loose and often required custom tweaking for any two systems to interoperate. An entire interface engine industry arose in response to the overly flexible V2 specification and made interfacing a complex and expensive process for providers and vendors alike. Others complained that V2 messages were not semantic, making it impossible to guarantee that the receiver could understand the clinical meaning of the content.
- “Version 3” (V3): In response to the limitations of V2, HL7 set out to create V3 to address the under-constrained design of V2, and to capture more semantic meaning in each message. Unfortunately, despite more than a decade of hard work by HL7’s many expert volunteers, the V3 standard landed on the “too complicated” side of the standards balancing act. For example, to add semantics, each V3 message was defined by inheriting concepts from a reference implementation model, an attempt to model all of health care data using the smallest number of core concepts possible – including base abstractions such as Act, Entity, Role and Participation. Each new message was expected to map back to the reference implementation model so the clinical meaning of each concept was clear. The process of building messages that could derive from the reference implementation model proved to be difficult, and the imputed semantics were less powerful than expected.Consequently, adoption of V3 was sluggish, with expensive implementations that required hard to find expertise. In contrast to the widespread uptake of V2, V3 languished.
- Fresh Look & Resources for Health: Following the struggles of V3, HL7 created a “Fresh Look” project in late 2011 to explore new approaches to thinking about interoperability standards. After much debate, several HL7 experts, led primarily by Australian informaticist Grahame Grieve, proposed “Resources for Health.” It simplified the complex modeling requirements of V3, and adopted an emerging approach known as RESTful design. RESTful Application Programming Interfaces (APIs) are at the core of HTTP, the standard that powers the internet. In HL7 V3, specialized, custom tools were necessary to work with the messages. In the new "Resources for Health" model, the only tools needed were ordinary web tools that were familiar to thousands of developers. Today’s FHIR is the direct descendant of the "Resources for Health" proposal.
Why FHIR is crucial to interoperability
Why is all this important? The answer lies in the emergence of industry and government demand for standards-based APIs for all health care systems. Interoperability in the V2 and V3 era was based on simple message passing. While adequate for non-real-time, non-interactive data sharing, message passing could not meet the needs of complex and tight system-to-system integrations, such as SMART apps and other real-time data sharing. APIs for health care are not new, but prior to FHIR, there was no applicable standard available, so vendors typically implemented only proprietary APIs. Widespread interoperability is obviously hindered if every connection requires a non-standard approach.
In this context, a seminal event was the emergence of the JASON report which was published November 2014. The report contains a consensus recommendation of renowned experts that called for “a public API” to integrate all the systems of health care. The Office of the National Coordinator for Health Information Technology (ONC) responded to this recommendation with the creation of the JASON Task Force (JTF), a workgroup of the HIT Standards and Policy Committees, which I co-chaired with Micky Tripathi, president and CEO of the Massachusetts eHealth Collaborative. The JTF agreed with the overall JASON recommendations and suggested that ONC consider that the emerging FHIR API could be used to create the “public API” called for by the JASONs. The JTF also recommended that ONC shouldn’t mandate use of FHIR until enough piloting had proven the validity of the design and after the core of the standard became stable enough to justify inclusion in regulatory EHR certification.
These JTF recommendations lead to the creation of the Argonauts, a coalition of vendors and providers who agreed to work with HL7 to implement and test the new FHIR APIs. The Argonauts quickly confirmed the value of FHIR and went on to create a set of implementation guides to ensure that the APIs would be used consistently across vendor systems.
The recommendations to require APIs were adopted by ONC into the 2015 Edition Health IT Certification Criteria, but because FHIR wasn’t yet proven (and was not normative) the current ONC regulation does not specifically require FHIR. But now that FHIR has reached normative status and given the Argonaut’s proof that FHIR is readily deployable, we believe that future ONC certification standards will require FHIR. In fact, ONC’s recent notice of proposed rulemaking suggests that FHIR becomes a required part of an updated 2015 Edition Certification for EHRs. ONC has solicited input from the vendor community and others on whether to require support for the new R4 release or to continue with the current R2 implementations. Most vendors seem to prefer to focus on R4, even though that will require new development effort.
Future state of FHIR
The convergence of these two threads – FHIR as a better interface standard, and APIs as a required part of EHR certification will have profound impact on future interoperability. We are beginning to see many innovative uses of FHIR APIs, such as provider-facing SMART on FHIR pluggable apps, as well as consumer-facing innovations, such as Apple’s Health app that allows for a simple download of core clinical data from EHR portals.
Driven by the broad API requirements in the 21st Century Cures Act, we can expect ONC to significantly expand the scope of EHR certification of required APIs, hopefully closely in sync with HL7’s continued expansion of the FHIR specification. We can expect to see FHIR used in national interchange frameworks, such as proposed by ONC’s Trusted Exchange Framework, and in payer-to-provider interfaces as defined by the payer-led DaVinci Project and the FHIR at Scale Taskforce (FAST).
The latest developments of FHIR are another step forward in delivering more flexible, versatile and efficient health care that will benefit both providers and consumers.
Cerner Open Developer Experience (code) encourages innovators to build apps that advance the health care industry through improved interoperability capabilities. Learn more here.
