MedCity Influencers

A brief history of FHIR and its impact on connectivity

If standards are the language we use in healthcare, then the industry is missing the telephone lines connecting everyone speaking it.

HL7 FHIR is now five years old and has begun to (slowly) find a bit of traction. I remember thinking at one point how much easier FHIR (pronounced fire) would make my life. At the time, I was on the interface team at Epic, oftentimes banging my head against other HL7 standards. This year, my team at Redox implemented our first FHIR connection in production, and I attended my first FHIR Connectathon. This article will explore the standard, how it operates, and what the future of FHIR will be.

What problems does FHIR solve?

FHIR is a data exchange standard maintained by the Health Level Seven International (HL7), a standards body. FHIR seeks to be the next-generation foundation by which electronic health records (EHRs), digital health applications, and consumers use and exchange structured healthcare data. FHIR aims to supplant existing HL7 standards such as HL7 version 2 (HL7v2) and HL7 version 3 (HL7v3).

In late 2011, the creator of FHIR, Graham Grieve, proclaimed that HL7v3 had failed. HL7v3 was so arcane that no one wanted to touch it. It’s predecessor HL7v2, while successful, was technology that predated the widespread use of the internet. Grieve and a small team worked through HL7 to create an entirely new standard for data exchange. Originally called “Resources for Healthcare”, the standard was subsequently renamed Fast Healthcare Interoperability Resources, producing the handy acronym “FHIR” and subjecting us to cringe-worthy puns for the foreseeable future.

In terms of hauling HL7 into this century, FHIR succeeds. The core of FHIR is a model for healthcare data that requires far less context to understand than HL7v3. The standard also lays out a preferred way of sharing the data (HTTP, the foundation of the web). FHIR, along with SMART on FHIR, lays out security and workflow considerations missing from previous standards. Finally, it makes recommendations about which types of codes to use where. All of these are evolutionary advances, and don’t really change the fundamental nature of HL7 and how people interact with HL7 standards.

The process by which FHIR is developed is the same process that made HL7v2 and HL7v3. The process values consensus, and for that reason, FHIR is well-reasoned and any glaring errors and/or omissions in the resources are likely to be found before publication.

Consensus takes a long time, and FHIR has innovative approaches to deal with it. First, each resource is individually maintained and versioned. FHIR attaches “Maturity Levels” to each resource, a flag indicating how reliable a given component is for use. Patient stands at a 5 —Trial Use. This month (October 2017), FHIR R4 will be released with the first Level 6 “normative” resources, including Patient. The Maturity Level approach means that we can start using Patient resources long before Claim resources are ready for primetime.

Where does FHIR fall short?

FHIR is an evolution of HL7’s existing offerings, and fails to solve some very important problems—some of which may eventually be solved, and some of which can never be solved.

I believe the biggest problem in interoperability is what my colleague Luke Bonney calls The Connectivity Problem:

If standards are the language we use in healthcare, then the industry is missing the telephone lines connecting everyone speaking it. Though so advanced in so many other ways, communication in healthcare currently lives in the land of telegraphs and the pony express.

FHIR relies on EHRs to implement, but it also relies on Health Systems (the ones who buy EHR software) to actually turn the functionality on. Non-cloud EHRs make up the largest part of the EHR market and are leading the charge on FHIR, but each of their thousands of customers need to individually decide to turn on FHIR (which could be a costly licensing and time investment for the health system). What this means for developers is that connecting to Epic, Cerner, or other EHR vendors once is not enough—you need a new set of URLs, credentials, and project managers for each health system you sell to. This feudal system of software deployment leads to inconsistency in the actual data elements.

There has historically been no penalty for not using standardized code systems, and FHIR doesn’t add one, either. Tools like Project Crucible automatically assess whether sites meet the specifications of FHIR, but we’re still in the stage of test servers being tested, not live production-like environments. Meaningful Use tried to make people conform via a certification process, and EHR vendors will inevitably do what they can to get by.

FHIR does not strictly enforce the recommendations that it makes, and is infinitely extensible. Looking at the FHIR standard as a casual observer, you might notice that Patient has a field for what species the patient is, but not a patient’s race. To many, this may seem counter-intuitive, but there are good reasons in the HL7 world for this omission/inclusion. Despite the reasoning, it doesn’t stop it from being vexing for a developer, though.

FHIR offers a framework for extensions so that something like race can be included, but without strong central guidance, we may end up with a landscape that looks a lot like HL7v2—each EHR will start creating their own extensions, or even worse, the government will come in and mandate the use of new extensions from time to time, as they have with CDA under Meaningful Use.

Looking into the future

From the HL7 perspective, the future of FHIR is set in stone—the standards body is 100 percent behind developing and iterating on it as quickly as possible. As I mentioned earlier, 2017 will mark the first “normative” resources available in FHIR, which is a huge milestone for wider adoption and implementation.

HL7 has made strides in engaging the developer community at large (they made their standards free to download in 2012). The FHIR project is open source, and as I recently learned at the FHIR Connectathon, HL7 is a welcoming place. However, the business model behind being a part of the decision-making process is skewed away from smaller companies and toward massive ones who can afford thousand-dollar memberships.

The biggest risk to FHIR is not a competing standard from within HL7 (or out), but rather a return to a lack of standards. Recent interest in EHR vendor “App Stores” has sparked new questions around the value of standards in the world of open EHRs. No doubt EHR vendors are watching carefully which services applications flock to—the FHIR-backed ones or EHR-specific ones.

For an EHR developer, molding the internal data of the EHR to FHIR is a lot of extra work, and despite the improvement FHIR has made to standard iteration time, a vendor-specific API can move an order of magnitude faster. Economics might ultimately be the undoing of FHIR and HL7, and if API consumers are happier connecting to vendor-specific APIs, then FHIR will not catch on with a future of cloud-based digital health applications.

Looking ahead five years, I believe that FHIR will supplant some existing HL7v2 and HL7v3 integrations, expand overall connectivity, and not necessarily create disruptive innovations on its own.

Legacy HL7 interfaces can be evaluated based on cost/benefit of converting to FHIR. Integrations such as scheduling benefit a lot from FHIR’s query-based architecture and will supplant their predecessors. Mission-critical and patient safety interfaces such as ADT will take an approach of “if it ain’t broke…” and stay on HL7v2 potentially indefinitely.

FHIR is opening new avenues of connectivity and new types of data, leading to an overall bigger footprint for data exchange. New areas like genomics are being tackled by FHIR, something that was never included in older versions of HL7. Other areas like clinical research which had half-baked HL7v3 versions will get more exposure. FHIR will be the lingua franca of these emerging areas.

Lastly, FHIR alone will not lead to widespread disruption of the healthcare IT space. The business model and value network of FHIR and HL7 make it impossible for the standard to go beyond its mandate. Nothing has fundamentally changed about how EHRs implement and use standards with FHIR. Real disruptors may use FHIR, but the real change in value and hence disruption is going to come from the “What problems does FHIR not solve?” 

Photo:  sakkmesterke, Getty Images


Avatar photo
Avatar photo

Nick Hatt

Nick is a senior developer and in-house “FHIR-whisperer” at Redox, the platform for healthcare data exchange. He enjoys writing about cloud technology, healthcare standards, and business strategy. At Redox, Nick focuses on support for standards and EHR vendor APIs. Before joining the Redox team, Nick was a developer on the interface team at Epic. He graduated from Oberlin College and currently lives in State College, PA. For more from Nick, be sure to check out other posts here: https://www.redoxengine.com/blog/author/nick-hatt

This post appears through the MedCity Influencers program. Anyone can publish their perspective on business and innovation in healthcare on MedCity News through MedCity Influencers. Click here to find out how.

Shares1
Shares1