Don’t Yell FHIR in a Hospital … Yet

The following is a guest blog post by Richard Bagdonas, CTO and Chief Healthcare Architect at MI7.
The Fast Healthcare Interoperability Resource standard, commonly referred to as FHIR (pronounced “fire”) has a lot of people in the healthcare industry hopeful for interoperability between the electronic health record (EHR) systems and external systems — enabling greater information sharing.

As we move into value-based healthcare and away from fee-for-service healthcare, one thing becomes clear: care is no longer siloed to one doctor and most certainly not to one facility. Think of the numerous locations a patient must visit when getting a knee replaced. They start at their general practitioner’s office, then go to the orthopedic surgeon, followed by the radiology center, then to the hospital, often back to the ortho’s office, and finally to one or more physical therapists.

Currently the doctor’s incentives are not aligned with the patient. If the surgery needs to be repeated, the insurance company and patient pay for it again. In the future the doctor will be judged and rewarded or penalized for their performance in what is called the patient’s “episode of care.” All of this coordination between providers requires the parties involved become intimately aware of everything happening at each step in the process.

This all took off back in 2011 when Medicare began an EHR incentive program providing $27B in incentives to doctors at the 5,700 hospitals and 235,000 medical practices to adopt EHR systems. Hospitals would receive $2M and doctors would receive $63,750 when they put in the EHR system and performed some basic functions proving they were using it under what has been termed “Meaningful Use” or MU.

EHR manufacturers made a lot of money selling systems leveraging the MU incentives. The problem most hospitals ran into is their EHR didn’t come with integrations to external systems. Integration is typically done using a 30 year old standard called Health Level 7 or HL7. The EHR can talk to outside systems using HL7, but only if the interface is turned on and both systems use the same version. EHR vendors typically charge thousands of dollars and sometimes tens of thousands to turn on each interface. This is why interface engines have been all the rage since they turn one interface into multiple.

The great part of HL7 is it is standard. The bad parts of HL7 are a) there are 11 standards, b) not all vendors use all standards, c) most EHRs are still using version 2.3 which was released in 1997, and d) each EHR vendor messes up the HL7 standard in their own unique way, causing untold headaches for integration project managers across the country. The joke in the industry is if you have seen one EHR integration, you’ve seen “just one.”

HL7 versions over the years

HL7 version 3.0 which was released in 2005 was supposed to clear up a lot of this integration mess. It used the Extensible Markup Language (XML) to make it easier for software developers to parse the healthcare messages from the EHR, and it had places to stick just about all of the data a modern healthcare system needs for care coordination. Unfortunately HL7 3.0 didn’t take off and many EHRs didn’t build support for it.

FHIR is the new instantiation of HL7 3.0 using JavaScript Object Notation (JSON), and optionally XML, to do similar things using more modern technology concepts such as Representation State Transfer (REST) with HTTP requests to GET, PUT, POST, and DELETE these resources. Developers love JSON.

FHIR is not ready for prime time and based on how HL7 versions have been rolled out over the years it will not be used in a very large percentage of the medical facilities for several years. The problem the FHIR standard created is a method by which a medical facility could port EHR data from one manufacturer to another. EHR manufacturers don’t want to let this happen so it is doubtful they will completely implement FHIR — especially since it is not a requirement of MU.

And FHIR is still not hardened. There have been fifteen versions of FHIR released over the last two years with six incompatible with earlier versions. We are a year away at best from the standard going from draft to release, so plan on there being even more changes.

15 versions of FHIR since 2014 with 6 that are incompatible with earlier versions

Another reason for questioning FHIR’s impact is the standard has several ways to transmit and receive data besides HTTP requests. One EHR may use sockets, while another uses file folder delivery, while another uses HTTP requests. This means the need for integration engines still exists and as such the value from moving to FHIR may be reduced.

Lastly, the implementation of FHIR’s query-able interface means hospitals will have to decide if they must host all of their data in a cloud-based system for outside entities to use or become a massive data center running the numerous servers it will take to allow patients with mobile devices to not take down the EHR when physicians need it for mission-critical use.

While the data geek inside me loves the idea of FHIR, my decades of experience performing healthcare integrations with EHRs tell me there is more smoke than there is FHIR right now.

My best advice when it comes to FHIR is to keep using the technologies you have today and if you are not retired by the time FHIR hits its adoption curve, look at it with fresh eyes at that time. I will be eagerly awaiting its arrival, someday.

About Richard Bagdonas
Richard Bagdonas has over 12 years integrating software with more than 40 electronic health record system brands. He is an expert witness on HL7 and EDI-based medical billing. Richard served as a technical consultant to the US Air Force and Pentagon in the mid-1990’s and authored 4 books on telecom/data network design and engineering. Richard is currently the CTO and Chief Healthcare Architect at MI7, a healthcare integration software company based in Austin, TX.

About the author

Guest Author

Guest Author


  • I’m not sure what the point of this post is, other than to state the obvious in a decidedly negative tone.

  • Maybe the point is that the Feds pump out all these ‘standards’ without actually making any of them actually STANDARD. Nothing truly new here – in all the years that I programmed in, say, COBOL, there were many versions of the language each up to a certain ‘year’s standard, yet there was no way I could take a COBOL program written for say a VAX under VMS and have it work under some IBM system; numerous calls to API’s (system services) were different, sometimes even pure syntax. What is clear in the article is that HL7 is not a real standard into itself – one way to code and connect via API, but a large collection of semi standards created over the years in different environments just the way COBOL is. Each source, vendor, etc. creates what it wants, charges a lot just to connect even to systems that it produced for other providers, charges a lot more to connect to systems from other providers. The effort to have a standard interconnection protocol has been, I believe, a huge expensive failure due to the ‘standard’ not being complete or tight. It sort of reminds me of the comment in the musical My Fair Lady about English – ‘in American they haven’t spoken it in years’! The main character could point out to people the numerous ways of speaking English that he had encountered in his studies. Well I’d say that HL7 and the many API’s and variations makes ‘English’ look standard! What also needs to be said – if the industry won’t standardize, then the Feds should get their act together and do it for them!

  • @R Troy RE “Maybe the point is that the Feds pump out all these ‘standards’ without actually making any of them actually STANDARD”

    The Feds aren’t “pumping out” standards in any way shape or form — that’s done by private SDO’s (‘Standards Development Organizations’) — so I’m not sure what that statement is based on. And if that *is* in fact the point of the post, then it’s even more unhelpful than it if there were no point.

    I’m just curious whether either you or the author have been actively involved in the development of FHIR at all over the past 4 years or so? Have either of you even participated in any FHIR list discussions.. or implementer chats?

    If so, you should both realize that the FHIR community (a) neither views nor presents FHIR as a silver bullet to solve interoperability, and (b) is not responsible for any of the unfortunate hype that surrounds FHIR.

    It would have been great if the author would have attempted to present some solutions to he problems that everyone in the Health IT and interoperability space already knows all too well, rather than simply rehashing them.


  • Thanks for your comment. The point of the article is to present some historical information and the current state of FHIR because I spend a significant amount of time talking to folks that are new to healthcare and expect it to work like other industries.

    I tried to incorporate the business aspects as well as technical aspects to have it meaningful to both techies and business managers.

    The alternative solution is to utilize our product at MI7, but this wasn’t meant to be a sales piece for our software. Simply a place to reference for those building solutions with the FHIR standard before they research where it is in its lifecycle.

    Thanks for reading Thomas.

Click here to post a comment