Why FHIR is “better”

August 3, 2017
Nick Hatt Staff Software Engineer, Tech Lead

HL7 is not bashful about the improvements offered in the FHIR standard (see” Why FHIR is better” in the executive summary). Rather than create a lengthy FHIR tutorial, I will examine HL7’s top 10 reasons why FHIR is better and clarify their claims against what we’re actually experiencing today in healthcare.

1. A strong focus on implementation—fast and easy to implement.
2. Multiple implementation libraries, many examples available to kick-start development.

Over the past two years since I wrote the first article, vendors have demonstrated that it’s relatively easy for them to stand up FHIR servers, such as the Epic and Cerner sandboxes. At Redox, we’re still missing some data points about how easy it is for health systems to implement, but we have gone live with our first FHIR connection, and most of the infrastructure already existed.

One of the bigger questions that remain is how standardized each deployment will be. If deployments aren’t standardized, implementation times stretch out. Our first real implementation has been relatively easy, but our product is designed to be flexible.

Project Argonaut’s lasting impact is a set of implementation guides and only time will tell if they actually stick—and how long EHR vendors need to adapt to new and changing profiles for FHIR.

3. Specification is free for use with no restrictions.

Yes, the documentation has also gotten a lot better over the past two years as well. People don’t make a big enough deal about how HL7 standards were not freely available until 2013. To me, this is an underrated reason why the healthcare industry lags on interoperability and innovation. How can a startup hope to integrate with a big EHR if they need to pay to play?

The outstanding issues that the FHIR team is working on are still publicly visible, which is great.

4. Interoperability out-of-the-box—base resources can be used as is, but can also be adapted for local requirements.
5. Evolutionary development path from HL7 Version 2 and CDA—standards can co-exist and leverage each other

Extensions have developed quite a bit since I wrote the first version of this article. The Patient resource, for example, contains fields for what species, breed, and whether or not the Patient is neutered, but not the patient race or ethnicity. This may strike some as odd, but it is somewhat core to how HL7 operates.

What may be more concerning is that extensions are growing on multiple tracks, like the standard list of FHIR extensions, and a different (albeit smaller) list of Project Argonaut extensions.

It’s nice that extensions are specified as code, but I wouldn’t really call it “interoperability out of the box”.

6. Strong foundation in web standards—XML, JSON, HTTP, Atom, OAuth, etc.

Nothing has changed on this front, but real world implementation examples are still lacking. The standard runs the risk of advertising OAuth but actually having slightly different EHR implementations under the hood.

FHIR does weird things, too. As the standard grows, expect more features that aren’t really standardized in any kind of way (outside of FHIR), such as compartments (ways to find all associated resources given one resource).

7. Support for RESTful architectures and also seamless exchange of information using messages or documents.

An interesting takeaway over the last two years it that development of Messages and Documents has kept pace with the rest of the standard. This suggests that there will be a place in the future for Redox-style event messaging, and big bundles of related content in the form of Documents (think CDA).

8. Concise and easily understood specifications.
9. A human-readable wire format for ease of use by developers.
10. Solid ontology-based analysis with a rigorous formal mapping for correctness

Over the past two years, the FHIR has specs have grown in complexity. There may be future efforts to pare things down, but still, there’s a lot to digest—and for people not familiar with existing HL7, there is risk of misinterpreting the specs.

On a positive note, EHR vendor documentation and sandboxes are a more realistic alternative to the base FHIR specs. I’m excited to see those continue to develop in the open.

What’s Next?

FHIR is taking appropriate steps to become the next big thing. Open development and public commentary will help the standard develop and replace its predecessors.

As it stands, FHIR is an incremental improvement over past HL7 standards, not a revolution. The sooner we get off the hype curve and start using it to actually build things, the better.

As we wait on FHIR to be adopted and implemented at scale, vendors must find integration solutions that are flexible enough to satisfy today’s needs with tomorrow’s changes. Check out this post on the “Three Questions You Need to Ask Your Healthcare API Vendor” to make sure you’re prepared.

Editor’s Note: this article was originally published in 2015 and has been updated for accuracy and clarity.

Stay in the know! Subscribe to our newsletter.