Good Exchange Specifications: Interoperability vs Intraoperability

Feb 28, 2012

There’s two very different approaches to getting systems to exchange data. Interoperability

This way, you get the different system designers to sit around a table on the basis that a common syntax and data model will be agreed to that allows all of them to exchange what needs to be exchanged, without requiring any design changes to the way their systems works - whatever is done can be done on the periphery. And what can be done is therefore constrained to what can be achieved given that none of the participants are willing to make changes to the way their products work. Initially, the outcome is the lowest common denominator of the way that the systems function - all systems are constrained to the dumbest system. Of course, that doesn’t deliver the things that are needed, so the smarter systems need to come up with “extensions” to the basic model so they can do smarter things.

The deficiencies of this approach are obvious. But there’s another way…..

Intraoperability

In this other approach, everybody sits down around the table and agrees how the systems should work, and then everybody goes off and makes their systems work that way - they rework the core of the systems to function in the agreed way. Because all the systems work the same way, then exchange between the systems is easy and straight forward. I call this “intraoperability”, because it’s about operations within a sandbox. There’s no lowest common denominator, and there’s need for extensions or custom negotation.

The second way has fewer deficiencies, but they are much bigger: it’s much harder to get agreement - definitely harder to get agreement to what that one model everyone must follow is, and orders of magnitude harder to get the system designers to sign on to this approach - because everyone wants to do things their own way. Typically, at this point, the system designers (usually vendors) get the blame. But I think it’s not as simple as that - vendors do whatever sells, which is whatever the purchaser wants to buy. The business model for intraoperability rarely works out, because it’s standards writ large - a big price for a big payoff, but who’s going to be paying the price? (as usual, not the ones who benefit)

Application

So both approaches have strengths and weaknesses. In practice, of course, HL7 pursues interoperability, while openEHR is about what I have called intraoperability. Both HL7 and openEHR are pragmatic though, and they compromise for practicality. All the time I’ve been working in HL7, there’s been this mantra: we do not dictate how applications function, only how they exchange data as perceived externally. This often comes up in committee when we are debating design choices. But on the other hand, vendors know that the requirements that lead to HL7 designs are their requirements too, and also that HL7 designs lead to how requirements are understood and represented over the years, and in effect, HL7 standards dictate some aspects of design to systems. In a similar vein, while openEHR chases intraoperability, they’ve made pragmatic decisions about extensibility and design to cater for variance in systems.

This philosophy is tied to the respective business models: HL7 was formed as a vendor consortium (and later providers and governments). All of them have massive investments in existing systems. It generally takes a vendor 10 years or so to effectively redesign production healthcare systems, and the government might take 20 years to effect a change across it’s installed base. So HL7 is driven to pursue interoperability, with a very hands off approach to existing systems On the other hand, openEHR was about intraoperability from the start, so they had to be an opt-in open source consortium, with a gestation period of at least a decade.

And now - openEHR has very nice stuff (content models, tools, ecosystem, community), but still very limited buy-in. I am watching with interest whether the intraoperability approach can scale into being a standard for real world exchange (and since Tom & Co read my blog, that’s not about architecture, technology or models, but about governance and buy in. A few countries are trying it out, I’m waiting to see how it goes). As for HL7 , I think that v3 intended to deliver the benefits of intraoperability without actually paying the piper up front and getting global agreement in the systems. And I don’t think we have to wait any longer to determine how that went.

So what’s the right standard? Should HL7 be more dictatorial to system designers in order to get better interoperability? Now of all times, is this the worst time or the best time?