Law #1: Interoperability: it’s all about the people

Apr 9, 2011

In the ancient pre-history of Healthcare Interoperability (the early 90’s), it was actually hard to get two different systems to exchange bytes with each other. It often required arcane and black magic with serial cables, little black boxes with blinking lights, and weird operating system drivers and commands. If you wanted two different systems to exchange data, it was a major project to get them talking – and you got them talking before you invested in doing anything with the data, in case the whole thing failed at that point. And you kept the data as simple as possible, because the whole thing was likely to blow up in your face anyway. It’s not like that anymore.

The explosion of the internet has lead to a ubiquitous network protocol – TCP/IP – and the widespread availability of higher level protocols, particularly HTTP and other web related protocols. These are supported on every operating system, even the embedded ones, and now on phones as well. It’s no longer any challenge to get any systems to exchange bytes in an orderly fashion.

But it hasn’t got any easier to get interoperability projects to work. In fact, it seems as if it’s gotten harder. And so consumers ask why, why is it so hard to get things to work together in these days of interconnectedness?

That’s because the real problems with interoperability are not technical. They’ve never been technical. It’s the people that are the problem, because IT systems are only extensions of the people who wrote them, who maintain them, who use them. If you want two IT systems to interchange data successfully, you’ve got to get alignment between the people who write them, manage them, and use them. The technical challenges the system maintainers face when making changes are miniscule compared to the problem of getting the various people to agree with each other.

Even when problems manifest as technical challenges – “I can’t do this because of that”, they are almost always symptoms of the real problem: getting enough people to agree with each other. (The main exception to this, things that can really be technical problems, that often are, are performance issues.)

Very often, interoperability projects are created to cause change in the business practices in the institution sponsoring them. This further increases the difficulty of getting people to align, since there is often contention due to the proposed change, and usually considerable lack of clarity over its exact impact on the business practices of the sponsor. And when the business practices are as obscure and undocumented as standard clinical practices, which may vary wildly between institutions, this can be a real problem.

In later posts, I’ll consider the implications of this for choosing people to be involved in interoperability projects, and also discuss the radically different contexts for interoperability.