Friday, June 07, 2019
Grahame Grieve Points Out Just How Hard Interoperability Can Be. There Are myHR Implications I Believe!
This appeared a day or so ago following up on a blog post a week or so back:
May 30, 2019
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.
(The original blog is linked in the text)
This is an interesting blog as we reflect upon the news reported last Sunday (2/6/2019) of the plans to have 3 different medication lists in the myHR!
We are setting ourselves up for a major fail I believe. I wonder what Grahame thinks of this plan in terms of currency, reliability and patient safety?
Posted by Dr David G More MB PhD at Friday, June 07, 2019