Our lives would be hell if it weren't for interoperability. You can plug pretty much any electrical appliance into any wall outlet and it will work (Just imagine if you couldn't!). You can create an e-mail on your Mac and someone running the 30-year-old Unix mail program on a dumb terminal can read it. I can send the paper on which I charted a patient's visit by fax to you and you can get a readable copy. These are all examples of interoperability. Is that all there is to it?
To answer that question, one has to know the difference between a functional requirement and a non-functional requirement. Yes, you read that right — not a dysfunctional requirement, but a non-functional requirement. This is a fancy term that computer scientists have come up with to describe requirements that are difficult to specify precisely for a variety of reasons. A few examples should help.
If I've got a 36" wide doorway and I'm buying a new refrigerator, I need to specify that it be able to fit through a 36" wide doorway. If it must be 42" wide, then that puts an upper limit of 36" on the depth. Maybe it must also have a minimum of 25 cubic feet of interior space. These are functional requirements.
There is another class of requirements. You can spot many of them because they end with a "y" or with "ability.” Examples include portability, reliability, security, usability, and, of course, interoperability. Some prefer the term "quality characteristics,” but I prefer to think of them as performance requirements. Any computer system that you or I might actually want to use should be fast enough, secure enough, easy enough to use, and interoperable enough to satisfy us. How fast? That's hard to specify, but if it's too slow you'll know it immediately. How secure? Again, it's hard to say unless there is a break-in, in which case it wasn't secure enough. The same goes for interoperability, which in the case of EHR, refers to whether you can send information to another doctor's EHR and what is sent satisfies the other doctor's need to know about the patient. If the needs of the sender and the recipient are satisfied, then there is enough interoperability.
It gets a bit more complicated in practice because there are really three different types of interoperability:
1. Within an organization: It's rare to find a single system that does absolutely everything. More often, there may be separate systems handling personnel, payroll and staff scheduling, billing, clinical lab ordering and results, and maybe web-based e-prescribing. If it were possible for the patient-scheduling application to access and use data about staff availability from the personnel system that would demonstrate "within" interoperability.
2. Between organizations: This is usually what is meant when people talk about interoperability. How much and what kind of information about patients can be exchanged between organizations? Many EHR wonks aim to establish voluminous standards and specifications that will describe how fine-grained quantitative data can be exchanged. If you read the recent discussion about over-specification, you will probably already have guessed that, while this may be useful in some settings, I believe that 80 percent or more of doctors "between" interoperability needs would be satisfied if there was simply a reliable way to send clinic notes electronically in a format that could be received, stored, and displayed for viewing.
3. With the future: Both the typical computer system, and the software that runs on it, have finite life spans. If you implement an EHR and use it diligently, what will happen to those records when it's time to replace that EHR with a new one? What will happen to those original records when it's time to replace the second EHR with a third one? If you can still access all the records, prove that they haven't been tampered with, and don't have irresolvable references to obsolete codes, then you have achieved "future" interoperability. When it comes to "future" interoperability, EHR users fall into two categories: those that have already experienced the lack of it (i.e., they have already lost records or been unable to use them) and those who have yet to have this experience.
Justice Potter Stewart said of pornography, "I could never succeed in intelligibly [defining pornography]. But I know it when I see it."
Similarly, you may not be able to intelligibly define EHR interoperability, but you will know it when you have enough of it, and you will also know when you don't.
Find out more about Daniel Essin and our other Practice Notes bloggers.
