I don't know how many times, I've said this in the past. Interoperability is NOT a switch, it's a dial. There are levels and degrees. We keep hearing that Interoperability doesn't exist in part because every time someone looks at it, the expectation of where the dial should be at doesn't meet provider expectations.
Few people working today remember early command line interface for accessing mail (that link is for the second generation command line). Most people today use some form a GUI based client, many available over the web.
To address this in this post, I'm going to create a classification system for Levels of Interoperability.
Level | Name | Description |
---|---|---|
0 | Absent | We don't even know what data is needed to exchange to solve the user's problem. We may know there's a problem, but that's about as far as we can get. |
1 | Aspirational | We have an idea about what data is needed, and possibly even a model of how that data would be exchanged. This is the stage where early interoperability use cases are often proposed. |
2 | Defined | We've defined the data exchange to the point that it can be exchanged between two systems. A specification exists, and we can test conformance of an implementation. This is the stage that most interoperability in EHR systems achieve after they've gone through some form of certification testing. |
3 | Implementable | An instructional implementation guide exists that describes how to do it. This is more than just a specification. It tells people not just what should appear where, but also gives some guidance about how to do it, some best practices, some things to consider, et cetera. This is the stage that is reached when a specification has been widely implemented in the industry and you can find stuff about it on sites like "Stack trace". |
4 | Available | This is the stage in which most end-users see it. Just because some feature has been implemented doesn't mean everyone has it. We've got self-driving cars. Is there one in your driveway? No. Self-driving cars are not available, even though several companies have "implemented" them. The same is often true with Interoperability features. Many vendors have implemented 2015 Certified EHRs, but not all providers have those versions deployed yet. |
5 | Useful | This is the stage at which users would rather use the feature than not, and see value in it. There's a lot of "interoperability" that solves problems that just a few people care about, and creates a lot more work for other people. If it creates more work, it's likely not reached the useful stage. Interoperability that eliminates effort is more useful. There are some automated solutions supporting problem, allergy and medication reconciliation that are starting to reach the "useful" stage. A good test to see whether an interoperable solution has reached this stage is to determine how much the end-user needs to know about it. The less they need to know, the more likely it's at this stage. |
11 | Delightful | At this stage, interoperability becomes invisible. It works reliably, end users don't need to know anything special about it, et cetera. The interesting thing about this stage is that by the time a product has reached it, people will usually be thinking two or three steps beyond it, and will forget about what they already have does for them. |
The level of interoperability is often measured differently depending on who is looking at it and through what lens. The CFO looks at costs and cost-savings associated with interoperability. Is it free? Does it save them money? If not, they aren't likely to be delighted by it. The CIO will judge it based on the amount of work it creates or eliminates for their staff as well as the direct and indirect costs it imposes or reduces. The CMO will be more interested in understanding whether it's allowed them to reach other goals, and will judge by different criteria. And the end-user will want their job to be easier (at least with regard to the uninteresting parts), and to have more time with patients.
By the time you reach "delightful" (often much before) you get to start all over again with refinement. Consider the journey we've been on in healthcare with the various versions and flavors of HL7 standards. HL7 V1 was never more than aspirational, V2 was certainly defined, though the various new features sub-releases also went through their own cycles. Some features in HL7 V2 even got to the level of delightful for some class of users (lab and ADT interfaces just work, most providers don't even know they are there). By the time the industry reaches perfection, users and industry are already looking for the next big improvement.
Do we have electronic mail? Yes. Is it perfect yet? No. Will it ever be? Not in my lifetime. We'll never have perfect interoperability, because as soon as we do, the bar will change.
Great post. Let's not forget all of the snowflakes out there creating a blizzard of one off requirements. Every domain, problem, venue, etc seems to be special needing some extension, vocabulary, transport, etc. Hard to solve ubiquitous interop challenges when everybody thinks their different.
ReplyDelete