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.
IN A NUTSHELL
Here’s what everyone seems most excited about with this latest (R4) FHIR update:
R4 is being hailed as the first “normative” content for FHIR. If you take in to account what FHIR was designed to do for HL7, which was developed 30’ish years ago as mentioned above, this feels like it could be a “giant leap for mankind.” Or at least a giant leap for all of the health care organizations whose developers are in the trenches, working out interoperability challenges. Who could the R4 updates help, specifically? Vendors who are struggling to meet Certified EHR technology guidelines, and pretty much everyone else utilizing HL7 who is still playing catch-up (the majority of U.S. health IT vendors seem to still be using Release 2).
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.