Healthcare Interoperability Is Insanely Complex – That’s Why It’s Not Like an ATM Machine

A couple of articles recently came across my virtual desk that really caused me to pause and think about healthcare interoperability. I’ve long known about many of the challenges of healthcare interoperability. I’ve often said that healthcare interoperability was not a technical problem, but a business problem. However, after reading these two takes on healthcare interoperability, I’d also add that it’s an insanely complex problem. Hopefully, I can illustrate it for those of you who are frustrated that the healthcare interoperability problem isn’t “just solved already.”

The first article comes from Grahame Grieve on is Health Intersections blog. If you’ve been in the healthcare interoperability space, then you certainly know about Grahame. He’s the project lead and product director for the FHIR and HL7 standard. That should be about all you need to know about how deep he is into the weeds of healthcare interoperability, but I’ll add that he’s a really smart guy that truly wants to make healthcare interoperability possible.

This can be seen in his blog post “Hard #FHIR Safety Problem: Synchronization.” If you’re a health IT nerd like me, you’re going to want to read the whole post to really understand the complexity associated with a small slice of the healthcare interoperability challenge: synchronization. For those, that don’t want to read it, here’s his opening description of the problem:

It’s a common thing for implementers to want to do with FHIR: connect to a FHIR server, and make a local copy of the information provided by the server, and then check back occasionally with the server for updates – that is, new resources, or changes to existing resources. (In fact, it might be argued that this is the thing that FHIR is for, based on actual usage).

This simple sounding intention turns out to be very difficult to get right, for all sorts of really important reasons. And that’s a real problem.

Grahame then goes on to outline all of the reasons that a list of medications (and as he mentions, this could apply to a wide variety of data) that’s pulled using a FHIR API can get out of sync when stored on an external system. We don’t need to explain why an out of sync medication list is a problem. That should be clear. However, Grahame very adeptly illustrates how easy it is for a medication list pulled using FHIR can get out of sync. If a medication list isn’t synced properly, then doctors won’t trust it. If they don’t trust it, then the extra data isn’t nearly as useful.

The thing that stood out for me in Grahame’s description of the challenge of health data synchronization is how there’s no clear solution to the problem. In some cases, it’s just a really complex situation. In other cases, it’s a poorly implemented system that retrieves the data and synchronizes the data improperly. This is the easiest case because you can fix it. The most challenging case to me is when many source record systems have implemented something poorly. There’s very little a retrieving system can do to fix something if the source system is giving you data that follows poor practices.

Grahame describes the importance of this problem and why it’s going to be hard to fix this way:

So: any client that it’s keeping it’s own persistent copy of data accessed by a FHIR Search like the above has to consult with each server to find out which of those possible reasons are applicable for the server, and decide what to do about it.

Applications that don’t… are unsafe and shouldn’t be written, marketed, or used. Of course, the users have no way of finding out how an application handles this. Maybe someone will take up the task of reviewing patient apps for safety, but it will be terribly difficult (=expensive) to do that.

I wish there was better advice I could provide, and we’re working on getting better advice, but the problem is the trillions of dollars of legacy systems out there that healthcare providers don’t seem to be in any hurry to replace (with systems that don’t yet exist, mind).

That’s a strong statement about systems that have poorly implemented APIs. The problem is that there’s no enforcement for what he suggests (ie. Unsafe apps not allowed to written, marketed, or used). Although, CMS is trying their darnedest to do everything they can to find a way to penalize those that are selling unsafe software.

No, healthcare interoperability is not as simple as an ATM machine. It’s much more complex and the above illustrates just one slice of the problem.

Come back tomorrow where we’ll highlight a unique patient perspective on healthcare interoperability.

About the author

John Lynn

John Lynn

John Lynn is the Founder of the, a network of leading Healthcare IT resources. The flagship blog, Healthcare IT Today, contains over 13,000 articles with over half of the articles written by John. These EMR and Healthcare IT related articles have been viewed over 20 million times.

John manages Healthcare IT Central, the leading career Health IT job board. He also organizes the first of its kind conference and community focused on healthcare marketing, Healthcare and IT Marketing Conference, and a healthcare IT conference,, focused on practical healthcare IT innovation. John is an advisor to multiple healthcare IT companies. John is highly involved in social media, and in addition to his blogs can be found on Twitter: @techguy.

Add Comment

Click here to post a comment