So Microsoft is going to buy Skype for 8.5 billion. Wow. Of course, that’s 8.5 billion of today’s US dollar, which is worth a whole lot less than it used to be a few years back. Still, that’s a lot of money. A whole lot more than Australia is spending on an whole new EHR system.

One of the things that really annoys me about interoperability is the way people often speak about interoperability using a combination of metaphors, similes, parables, and hyperbole. Very often these conjure up completely the wrong comparison, and I think that this is important because many people actually attempt to visualize and understand the task at hand through the use and application of these metaphors.

The single most common metaphor is that of a bridge. “We’re building a bridge between two different systems”, people say. And so they usually are. A bridge is a massive piece of engineering that consumes a great deal of money, and that allows some kind of traffic to cross between two different locations, in  way that wasn’t previously possible. For this reason, the notion of a bridge is a powerful and appropriate metaphor. However it is strictly limited in the scope of its application. Consider the requirements for building a bridge: you need to have solid ground at each end, sufficiently solid to support a series of unmoving structures that hold the bridge itself up. The surface of the bridge is usually immobile too, and composed of a single continuous ribbon (or very few ribbons) broken into a number of logical spans. Healthcare interoperability between systems is not like that; each end is a continuously changing for a variety of reasons, and the exchange between them has all sorts of complexity. A bridge is useful high level metaphor, but not a good way to characterize the solution: it’s just too simple, too static.

In another metaphor, healthcare interoperability is often compared to telecommunications. Most often, someone will hold up their mobile phone, wave it around, point at an old fixed phone connected to the old copper wire system (if it still exists), and ask that since the telecommunications companies can get the technology of the old fixed phones and the new mobile phones to interoperate, why can’t we do it in healthcare too? Well, we should be able to do what exactly? Can you send an sms from your mobile to your analogue phone? No, what you can do is make a voice call from one to the other: the exact same functionality is conveyed between the systems. Well, almost anyone can do that in healthcare too: transfer the same content between exactly the same business processes – it’s just a matter of connecting the network protocols up. The problems that bedevil healthcare interoperability concern mismatches in the semantics of data and the business protocols being implemented.

But next time someone uses this stupid metaphor of a telecommunications system, and how easy it is, you can point them at this Microsoft/Skype deal. $8.5B for some largely free software, and the eco-system? Perhaps that telecommunications stuff people take for granted isn’t that easy after all. $8.5B worth of not very easy.

The right metaphor

In a more general informatics sense, another wrong metaphor is the heavy engineering one, one that compares writing software to building a building. Yes, that’s right, writing software is just like building a building. That is, if you are building a skyscraper in your backyard, where you don’t even know how tall it’s going to be, what materials it’s going to have, or how many entrances and exits it needs to have, and where the purchaser suddenly decides that they want it in a different place halfway through building it – after all, you can just move all the stuff you’ve already built and refactor the floor design, right?

Writing complex software is much more like building a commercial company. You don’t go to an architect and ask them to design you a company, deciding on all the buildings, the prices, the salaries, and writing the procedural documentation before you actually create the company. You build it piece meal, seeing what works, fixing what breaks as it breaks – this is a far more appropriate metaphor for writing software than the static design metaphor.

So what’s a good design metaphor for interoperability? The best one I’ve come across is one many people can appreciate: imagine that you are in a foreign country where hardly anyone speaks any language you know, and then, in the rare case that someone does, they speak it poorly. Now, imagine that your job is to go out and buy yourself a good meal. Most people have been there, done this. It’s a stressful experience, but by judicious use of gestures, carefully restraining your ambition, and a generous display of the appropriate currency, you can usually get something near to what you want, even though you don’t really understand each other. Now there is an appropriate metaphor for interoperability between healthcare systems!

Although you just know that you’re going to pay too much, you get some of the most memorable meals of your life that way (I particularly remember the little backstreet café in Istanbul and the little diner in San Jose, Costa Rica).

p.s. I reckon that this deal has got to ramp up the value of healthcare interoperability 😉