Not so long ago, when you saw your GP and they referred you to a specialist, you would have to start all over again with your demographics, health history.
Most of us see several healthcare providers at different agencies over time, we visit ERs on weekends, and we have tests done at labs.
A reasonable patient expectation is that your need-to-know patient information will be available to healthcare providers/facilities you visit. But, don’t count on it just yet. In the absence of automation, providers are simply too busy to consolidate your patient data to their EHRs.
It’s not too much of a stretch to expect that if you are on vacation in a foreign country important information relating to you would also be available, on demand, at facilities you are visiting for the first time (again, on a strict need-to-know basis). Don’t count on it just yet.
I notice, at LinkedIn discussions, distinctions being drawn between interoperability and interconnectivity.
I hope we don’t go down the path where all EHRs end up being “standardized”. What is needed is the ability for agencies to exchange data (i.e. interconnectivity).
I seems that every second LinkedIn post on interoperability/interconnectivity at some stage cautions readers with “ … but we are not there yet”. I agree “we” are not yet there in most cases but maintain that we could easily be there, now, and in some cases we are there.
An easy way to demonstrate interconnectivity and how it should work goes like this:
A managed care company that has member clinics can easily ask its members to upload daily progress notes, results of lab tests received etc. to a hub. The clinics already have connectivity with the MCO for submittal of claims. No big deal to set up a separate upload.
It’s also easy for these same agencies toward the end of each working day to upload a list of patients they will be seeing the next day and get back visit reports from other agencies for import to their EHRs.
If a particular EHR cannot dovetail incremental third-party visit data, nothing wrong with logging into the hub on a second screen to at least view patient activity at third-party agencies.
What if you are not a member of an MCO? Here, we need State or Federal hubs.
It’s probably not a good idea to have one central hub but, even with 50 hubs, these could be connected in a ring. If you are in your home town, your healthcare record is going to be at the local hub, if you are traveling, it’s not a big issue to link to your home base hub and download/upload.
There is a second type of needed interconnectivity.
Here, we need to interconnect staff and physical resources so that things go not fall between the cracks moving from one step to the next along a patient care pathway. Bearing in mind a typical hospital must to be able to process several hundreds of patients per day, there is an added need to prioritize tasks, then level and balance workload across staff, all in the context of scarce resources.
Traditional EHRs don’t do a very good job “managing” workflow for the simple reason that they lack R.A.L.B.(Resource Allocation, Leveling and Balancing). The solution is to put it in. We have known how to manage serial and parallel tasks since 1957 (i.e. CPM), even before this.
Healthcare Data Interconnectivity 2015
I don’t buy into the notion that it’s “difficult” to export, package, ship, receive and import patient data. What we should be saying is many software manufacturers “make it difficult”, for customer retention purposes. Given the amount of money these systems cost, it’s not a bad strategy to run some of these “bad” suppliers out of town.
The world has had structured data exchange in the area of international shipping since the early 1960s.
Yes, healthcare is different in that much of the data is unstructured, but given a generic data exchanger you can allow any number of publishers and subscribers to each read/write using their own native data element naming conventions.
Of course, each publisher has to make available a “long name” per data element so that subscribers can know what they are subscribing to otherwise the only hurdle is data transport formats that certain individual subscribers are not able to read.
It follows that the worst case scenario is the one where a formatter has to be written for a particular subscriber and a parser has to be written for the publisher should there be any need for that subscriber to push back data to the publisher. As the number of “standard” data transport formats increases, the demand for custom formats will decrease.
Easy/difficult to write formatters/parsers? Not at all, if you have software that can “sniff” a new data transport format and generate code to get this in/out of a generic data exchanger. The software industry has come a long way from having programmers write code, to adapting code written by others (including themselves) to code written by programs.
So there you have it, a rational and practical solution for interconnectivity in healthcare.
End of . . . .