After successfully navigating my way back home, the HIMSS 2017 conference is now a fading memory of a whirlwind of events – presentations, education sessions, parties and numerous conversations – not to mention thousands of steps through the exhibit hall and beyond. My focus, as always, for the past few years has been the emerging HL7® FHIR® standard. From the Interoperability Showcase and the Innovation Center to numerous booths throughout the exhibit hall, once again this year HIMSS proved to have more FHIR-related announcements, events, sessions and conversations than the year before. In this post, I will share a couple of observations regarding FHIR and the myths and misconceptions overheard at this conference.
Myth 1 – FHIR will cure the common cold, or at least all our interoperability headaches.
This impression of FHIR’s amazing capabilities can be illustrated by an example someone gave where it was explained like this. You can have two different developers of different systems implement a given FHIR resource type and they will both do it the same way, unlike past standards where interpretation led to inconsistency. In other words, by implementing the FHIR standard, implementations will, de facto, be automatically interoperable with other FHIR standard based implementations.
Wow. Really? Can I ask a few questions please?
- When you create a new resource instance on your FHIR implementation, do you return the created resource instance, an OperationOutcome or no content? Related questions: What does your FHIR client expect? What does their FHIR Client expect?
- Does your FHIR implementation support all that resource type’s search parameters? What search logic have you implemented? (Again) What does your FHIR client expect? What does their FHIR Client expect?
The FHIR specification allows for a degree of optionality in what an implementation will support. Understanding that optionality and how to gracefully handle those features at both the client and server level is a key aspect in ensuring interoperable solutions. Helping developers work through resolving these kinds of issues and conflicts using TDD – Test Driven Development – is the reason AEGIS created the Touchstone Project.
Myth 2 – I’ve been working with this FHIR spec for a few months now, so I’m an expert, right?
One of the great aspects of the FHIR specification is that working implementations based on FHIR can be achieved in a relatively short time frame; i.e. a matter of days. Just attend one of the HL7 FHIR Connectathon events and you’ll see what I mean. I know, I’ve been to the last eleven. That being said, getting your working implementation fully integrated and interoperable with other FHIR-based implementations will take a bit more time. And, getting fully conversant with the FHIR specification will also take more than a “bit” of time.
Knowing that expertise in a subject area doesn’t happen in days, weeks or even months, I was surprised to hear from one company’s representatives what amounted to authoritative guidance and direction on FHIR and its uses where I did not recognize that company. I don’t recall seeing them at any of the HL7 FHIR events, nor on any of the HL7 working groups that contribute to the FHIR specification. When asked:
- How long they had been using FHIR? Their reply was “for a few months now”.
- Have you been to any of the HL7 FHIR Connectathons? “No.”
- Involved in any of the HL7 working groups? “No.”
- Contributed anything to the FHIR specification? “No.”
This admitted lack of participation with the specification made me wonder how could they speak with such authority on a specification they, quite frankly, hardly knew?
Please don’t get me wrong. I’ve been working with, participating in and actively contributing to the FHIR specification for almost 4 years now and I’m still learning. I would caution any individual or organization that is only a “few months” into working with a specification, any specification, to refrain from speaking authoritatively on the subject. There are already too many myths and misconceptions out there. Let’s not propagate them or, even worse, start new ones.
Where do you go from here?
Before believing all the hype and over inflated claims you hear about the FHIR specification, get yourself and your organization plugged into the authoritative sources from HL7 and the FHIR community. Here’s a brief list of resources to get you going:
HL7’s FHIR Wiki (your starting point for all things FHIR)
FHIR Chat (Zulip) (be part of the conversation)
HL7’s Home Page (look for all the scheduled FHIR events)
I hope to see you soon at the next HL7 FHIR Connectathons and Working Group Meetings!
One thought on “HIMSS 2017 Debrief – FHIR Myths and Misconceptions”
Great post Richard!
It’s a relief seeing that some are noticing the illusions and myths that are being created around FHIR.
The work and the tectonic shift by the HL7 warriors that brought FHIR to life is laudable to a great extent.
But sometimes I wonder if the FHIR team is getting real-world feedback from those that have to implement this currently and in the future.
Everyone seems to believe that only vendors work with interoperability. Large healthcare systems have to deal with it as well because they are unable to rely on vendors to solve all of their problems. As a matter of fact, vendors only solve a small portion of the interoperability requirements.
We already have RESTful API gateways in place which share information across the spectrum with OAuth2 authorization standards to allow access to entities or (resources). Just to name a couple of technologies.
If being standard means scrapping those efforts and only using FHIR resources and their relationships then we are going to continue down the path of using HL7 where most needed and doing our own stuff elsewhere, just like it has been done with HL7 v2.x and the CCD, I hesitate to even mention HL7 v3.0 because I’ve not yet seen an implemented data model based on the RIM.
If we are going to rely on conformance statements that say what we support and what not then we will end up with the same situation as with DICOM and IHE. In DICOM the non-standard way of using tags by many modalities makes it difficult to integrate with CAD and other similar software. IHE adopters tend to only implement a few transactions of a profile while claiming to conform to the entire profile, XDS-b being a common one.
I don’t think it’s a fault of a particular group, but I don’t think the standards are being built to what has brought us to this current hodge-podge state that we are in. We have tons of legacy systems with data models built with the concepts of the 70s; abhorrent SQL code and ETL that intertwines everything in an almost undecipherable way. Just building the resources requires to get the data out of the cryptic state into an EDW and then presenting the resources to consumer applications whether internal or external in a form that FHIR specifies.
FHIR helps solve the tip of the iceberg problem and it is ideal for new development, but does FHIR help address the underlying massive rock of the iceberg problem? This is where most of the data lives. Some tend to call this rock a “data lake”.
These are just memes from someone that has to work daily with the realities within healthcare systems data.