HL7 FHIR R4: Decoding the Acronym Soup

HL7 FHIR R4: Decoding the Acronym Soup

What’s the buzz about?

 

Eighteen months in the making, the Fast Healthcare Interoperability Resource (FHIR) Release 4 (R4) came out at the end of 2018.

If the amount of buzz we’re seeing around the news is any indication, this could be an important building block for some of the advances in health care IT we can hope to see in 2019.

To understand the context here, let’s recall that HL7, the ANSI-accredited standards developing organization, is around 30 years old, as is its V2 messaging standard. HL7 solved a lot of problems for health care IT in the 1990s simply by replacing other data sharing mechanisms that were being used at that time. Let us repeat, however, that was in the 1990s. Fast-forward to when HL7’s task force looked at what its path forward should be in around 2012-2013, FHIR was presented as their much-needed solution — their new interoperability standard, starting from scratch, to help do the heavy lifting as health care data needed to move from off-line to on-line, needed to start supporting mobile devices, needed to provide more data transparency, meaningful use, etc.

FHIR hit the scene as a “modern, internet-based approach to connecting different, discrete elements,” even though everyone knew it could never be “all things to all people.” There are simply too many types of data, platforms and numerous workflows at play here.

FHIR has delivered on much of its promise, however, seeing as how it quickly became one of the more popular protocols for joining disparate systems simply because of its ability to address the majority of common use cases on the technical side. And on the business side, its release coincided at the right time (as data standards go), bolstering its potential to actually make and save health care companies money. Moreover, FHIR better equipped HL7 to play ball in the API (Application Programming Interface) world.

Both FHIR and open APIs are considered critical to achieving interoperability, and that’s coming straight from the compliance horse’s mouth, from both the Centers for Medicare and Medicaid Services (CMS) and the Office of the National Coordinator (ONC) for Health IT.

A restaurant analogy to the rescue

To understand the relationship between FHIR and APIs, it might be helpful to build off of an analogy that the Veterans Administration shared — think of an API as a server in a restaurant. You’re sitting at a dining table, hungry, looking at a menu full of choices. The kitchen will be preparing your food, but the server must first communicate your order to the kitchen, and then also deliver your cooked food back to your table. This is the basic role of an API — a messenger that takes requests and tells systems what to do, delivering the finished product back to the user (or diner, in this case).

Where does FHIR fit in? Think of FHIR as giving restaurants (at least the ones using HL7 ingredients) the ability to copy and paste their menus, no matter the cuisine or restaurant location. And rather than having to start over, convert or transform each menu in some way, over and over again. (In more tech-speak, “Regardless of the paradigm, the FHIR ‘resource’ for a particular instance of data is the same.”)

Restaurant examples aside, hopefully we’ve been able to decode some of the mystery floating about in your bowl of “acronym soup” which always seems to be the soup du jour on health care IT menus.

It’s important to note that, as with any technology standards or even devices, there is never a “final” version. Similarly, there’s always a need to innovate other API approaches where FHIR isn’t applicable.

Has FHIR “come of age” with this new normative standard? Will R4 drive more pervasive adoption of FHIR — equipping health care tech vendors with more confidence to develop to FHIR, rather than to their own, internal APIs? Only time will tell.