HIT Perspectives: What Version 4 of FHIR Standard Means for Adoption and Innovation

Previous Article

HIT Perspectives – January 2019


What Version 4 of FHIR Standard Means for Adoption and Innovation


By Jocelyn Keegan, Payer Practice Lead 


Updates of standards underlying health information technology (health IT) happen all the time and usually are not newsworthy events outside of the technical community. However, there are exceptions to the rule. Now comes the latest version, or release, of the FHIR (Fast Healthcare Interoperability Resources) standard from Health Level 7 (HL7). It’s a big deal because of what Release 4 (R4) does and what it is expected to do. In short, R4 will deliver greater stability, a broader range of maturity and ensure a more stable shelf life for organizations implementing it. This translates to more certainty, confidence on the specification and a wider range of organizations willing to adopt it.

What is FHIR? FHIR burst on the scene almost 5 years ago as a draft standard that leveraged existing, well-established Web-based standard concepts with a tilt toward support for clinical data exchange. It empowers organizations to leverage agreed upon, consistent data formats and attributes (known as resources) to build an application programming interface (API) to power data exchange across systems. FHIR found its initial home as the standard leveraged by electronic health record  vendors to share clinical data required by meaningful use. FHIR can be and is used as a stand-alone data exchange standard as well as in partnership with existing, widely used standards.

FHIR’s adoption is snowballing. The Office of the National Coordinator for Health IT – is tracking progress. Approximately one-third of certified health IT vendors are using FHIR and nearly half of related developers appear to be using a version of FHIR in combination with another standard. The availability of R4 is expected to accelerate and increase adoption.

This rapid growth is powered by the simplicity it brings to bridge long-standing interoperability gaps across the many disparate systems used today to exchange clinical data between payers and providers and providers and providers. We see the R4 release as the engine to drive the data exchange needed for value-based care. The Da Vinci Project — a collaborative stakeholder group of which I am co-lead—is an example. The group has developed a rapid-cycle, multistakeholder process to leverage FHIR’s resources and technological frameworks to unleash the data needed for value-based care delivery to succeed on a national scale.

A dive into the details. So, what’s new about R4? FHIR Release 4 and the base platform of the standard have passed a normative ballot submitted to the American National Standards Institute (a national accrediting body) for the “normative” designation. What does this mean? On the technical side, this means that future changes should be backward compatible so applications that implement the normative sections of R4 can stay conformant with the standard and not have to reinvent products and services. Translation: if you write to this, future updates and improvements won’t break your code. Significant parts of the standard were changing before being designated as normative. In fact, more than 3,000 edits and updates were made to this most recent version alone.

A significant portion of R4’s elements have received the normative designation. They include the resources that determine how to use terminologies, how to build APIs, as well as data formats and elements that define how to recognize a patient and record patient observations. For the more technical among us, those fully baked aspects are:

  • The RESTful API, the XML and JSON formats, and the basic datatypes
  • The Terminology layer (CodeSystem and ValueSet)
  • The Conformance Framework (StructureDefinition and CapabilityStatement)
  • The key resources Patient and Observation

The impact of R4. In short, R4 will ensure a longer-lasting, more stable platform and greater interoperability. It allows vendors and health IT users to create and implement FHIR-based applications more consistently and uniformly, without worries of near-term obsolescence due to a major change in the standard. Many players will maintain software across the early versions, such as version 2, as they migrate new and existing assets up to this normative version.

Industry experts are waiting to see if the normative designation will be one more step in making FHIR the go-to building block for new and existing clinical workflows. This will dovetail with efforts to improve interoperability as required by the 21st Century Cures Act.

Moving forward. To be sure, all aspects of FHIR R4 will evolve and other elements will be added to the normative designation. HL7’s FHIR Maturity Model helps implementers understand how the various parts of the standard are advancing through the standards development life cycle.

Want to know more? I’d be happy to help. Reach out to me at Jocelyn.keegan@pocp.com.