Microsoft, Skype, and Bad metaphors for Interoperability

May 10, 2011

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. If you consider the kinds of interoperability that telecommunications companies might be thinking about solving that involve data and business variability, you will realize that mostly they are just getting to them in the last few years, and progress is highly variable: dictating voice to a fax, sms based games, mobile phone convergence[1], etc.

 

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 seen 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 here 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[2].

 

On the subject of metaphors, one enduring metaphor that gets used on a continuous basis is “When you’ve got a hammer, everything is a nail”. This one isn’t getting overused either: it’s something to be very wary of. It just happens so easily; you invest in an infrastructure to solve a problem in a particular fashion, and then you want to re-use it, to leverage your investment. The investment in this case is more than just financial, though it’s the financial element that underwrites it, that gives it real legs. In many cases, leveraging existing investment makes compelling sense – it’s just the cheapest way to solve a problem, both while the solution is developed, and in the future during maintenance, when everything is maintained in the same way. But this can go too far, and the existing concepts and infrastructure end up getting misused (this can be called, “gently forcing it”). This becomes a problem when one stakeholder is in a position to wield undue influence over how a problem is solved; the classic example arises in standards development, where a small committee makes choices that are binding on many implementers.

[1] I love my iPhone!

[2] I particularly remember the little backstreet café in Istanbul and the little diner in San Jose, Costa Rica