This appeared a day or so ago following up on a blog post a week or so back:
Healthcare Interoperability Is Insanely Complex – That’s Why It’s Not Like an ATM Machine
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.
More here:
(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?
David.
3 comments:
Depends on what you want I guess, Bettina and head of interoperability efforts at ADHA seems clear that real progress has been made in this space and the light at the end of the tunnel is bright. Perhaps these two experts and thought-leaders could come together and work through the obvious differences
well, what do I think:
* getting to a single curated medication list has long been a priority for anyone who does a review of the system. And is an absolute wishlist item for me as a patient
* I've seen estimates for the amount of money it would save (e.g. Royal review). I have no idea how you could estimate something like that - changes to ecosystems that require sweeping behaviour change could affect cost outcomes in all sorts of unexpected ways
* I haven't seen any cost estimates - but they should be easier. my cost estimate for maintaining a curated list (that I did on the back of envelope, which makes it accurate) exceeded the Royal review's claim of money saved by quite a lot
* the information mgmt problems - such as referred to in that blog post I did - are dwarfed by the clinical process problems around accountability for recording proposed and accepted (?) changes carefully
* and then there's the hard problem of inpatient medication management vs outpatient OTC medications (and that of long lasting things done as an inpatient that are important but outside the classic medication framework - are they in scope?)
So: lots of big challenges, and no one could think otherwise... but how can we not chip away at the problem? (Let's not permutate our risks.... we have to try small things)
@3:15 I have knowledge of quite a few bits of anatomy at ADHA but can’t say I have found a head. Who is this appendage you speak of?
Nice effort Grahame keep nudging them along, one fix at a time and they’ll keep coming back for more
Post a Comment