In 2004, then President GW Bush inaugurated the US push toward electronic medical records. Even at that time, it was recognized that if the effort to have a functional system were to be successful, systems would have to talk with one another, that is, be interoperable.
Fundamental to the concept of interoperability is the principle (or hope) of document exchangeability. That is, a patient who enters hospital B in city Y should be able to have information from his visit to hospital A in city X sent electronically and incorporated into the care now being delivered. Interoperability remains a pipe dream. Why?
There are two fundamental forces at play; one is the complexity of the task such that different parts of the scheme do not inherently understand one another. The structure of an order set, for example, requires integration to be metabolized and seen within a narrative of care. Hence narratives are either foregone or synthetic nonsense when left to the cognitive devices of the machine itself. The other force is the economic benefit that large scale system vendors garner by preventing interoperability with other systems. MedX can sell more systems if its clients are "stuck" with buying theirs to maintain harmony within the sum of parts. If a hospital complex as a number of care-settings on campus, and some off-campus, why would they want to risk purchasing an EHR that would not allow conversation between the sites? Of course, they wouldn't. And yet, enterprise vendors are rarely able to deliver on the promise of interoperability even between settings that the vendor has supplied, on or off campus. And that is just the history of a typical single large scale vendor trying to talk to itself. In one language, in one city, in one country. You can image the babel when the conversation "should include" machines created by other vendors, at other locations. It is a mess! The fall back becomes the fail-safe dependable device for transmitting information: paper. No one who works in medicine has been immune to the exasperation of creating coherent and reliable, non-fragmented, data accessible, helpful and supportive, medical records. Pipe dream...
In fact, it has been enough of a distant dream, and enough of a perceived necessity, that the US government has incorporated a requirement for interoperability with an "Interoperability Roadmap" within its plans for increased adoption of electronic records and increased abandonment of paper. Get interoperable, it is saying, or get off the playing field. This command makes some of the big vendors sweat.
But now there arrives on the scene a large vendor with an idea. It is a "now why didn't I think of that" type of ah ha moment when one hears the idea. Epic, perhaps the largest and fastest growing EHR company in the world has said it will solve the interoperability issue by permitting apps t be created, and function within their systems as semi-autonomous modules. We all know apps, they are on our phones, n our iPads, on our computers. Short for "application" an app is the ideal platform with to push interoperability. Apps do not necessarily produce or accept interoperable data, but the vendor that allows an app to function within its technical borders can require that the application is able to function in that respect. If you live in Rome, the vendor might say, do as the Romans.
Of course, this does not solve the overall nightmare of inter-system interoperability, but it puts it into the hands of module vendors who are historically more capable of solving the issue than the big players. The larger nightmare will only be awakened from when a cogent interoperability standard, and standard maintenance format, is adopted and required. Some organizations, for example, HL7 Standards group have been working on this for decades. There are good schemata that can be applied, therefore, to the issue.
The requirement for standards to achieve interoperability is not a new concept. Apps to achieve interoperability is entirely new. Just like the multitude of app vendors one can explore on an Apple or Android device, so the potential for functioning modules within the enterprise EHR systems opens a door that will make clinician choice the center of future EHR purchases. One considers, the app availability and quality, usually when deciding on an Apple versus Android phone. Either that, or one is confident the choices will be sufficient to meet needs.
Can't you see yourself reading app reviews to choose the EHR system for your ER or clinic? Trying out a demo for a few weeks, etc. It is about to be a new world. How the economics, security, reliability of this will work, is currently unknown.
One thing is for sure, Epic, not the darling of many clinicians because of its inherently cumbersome interfaces, content building requirement, and progressively ubiquitous presence, has come up with a terrific idea. Let's see if it comes into play. If it does, small boutique vendors that have fine-tuned the ways to make ERs and clinics hum, will now be able to offer their products to those who have wanted them. It will be like putting a fine stereo system in a car. Hopefully, the music will be good.
Xpress Technologies software platforms- Practice Management, EHR,Billing Services have been fundamentally designed for interoperability though HL7 interface in a plug and play application. Clinicians should hold out hope that software products specifically designed for them will be available and integrate easily with enterprise systems.