Interoperability in Healthcare – Easy to Say, Hard to Do

What exactly do people mean by EHR interoperability (interop)? Perhaps it’s obvious to you. Maybe I’m the only one that is confused. If so, it may be because I have too much experience with the actual nuts and bolts of exchanging data between systems to have any notion of what interoperability might mean to the average physician. Here are some things that I consider to be examples of interoperability:
• The nozzles on gas pumps fit most regular cars.
• A video DVD will play on my computer and on my DVD player.
• I can send and receive e-mail from 10 different applications on both my Mac and my PC.
• Dozens of applications can create and open Microsoft Word documents (of course they don't always look the same, so is that interoperability or not?)

Interoperability is not a functional property that causes something to happen. It is a "non-functional" property (see recent posts below) that merely indicates that something might be capable of functioning in more than one set of circumstances. How and when you might want something to interoperate is up to you if you possess the capability. If you lack the capability it will never happen.

As I have mentioned before, my personal clinical needs for interoperability are minimal. If I can send and receive notes, X-rays and an occasional lab report, I don't care how they get into my hands, fax, postal mail, or some elaborate electronic scheme - that's not interoperability. When I try to read them, if I can, then what I received was interoperable. If I can't read it, then it wasn't interoperable (relative to the relationship between me and the sender). Something I can't read might be readable by someone else, in which case it would be interoperable. Since I can pretty much always read what I receive, I'd rather have paper in my hand than to need to go fishing for it in the computer.

I didn't always feel this way about interoperability. There was I time when I was running a number of applications that required access to the most recent demographic information on our ~4.7 million patients. To realize that, I worked very hard to set up an interface to the mainframe registration system to receive about 30,000 updates a day. It worked quite well but it was not all smooth sailing. Occasionally a clerk would enter something creative in one of the fields causing the interface to choke on the data and lose the update in the process. There was also information, such as the identity of the clinic in which the patient just registered, that we needed desperately but could not get because the mainframe could not supply it.

Implementing this interface was difficult, but why? We were using HL7, the standard protocol. We were using an interface engine specifically designed for routing HL7 messages. The mainframe vendor had assured us before purchase that their product was "HL7 compliant" (except, we later learned, for the chapters they chose to ignore). In spite of that, it took over a year to get this single interface running reliably - a lot of work and endless hours coordinating the efforts of the three players.

No one will deny the value of interoperability any more than would deny the value of mom, apple pie, freedom, or world peace. Who wouldn’t want these things? How can you ever have enough freedom or interoperability? Don't tell me you want interoperability - that's meaningless. Tell me what data you need to send or receive, where and how often. If you approach it that way you'll find that interoperability is hard to define until a specific need has arisen that can be described in minute detail.

When I look at interoperability at ground level I can't avoid asking, for each chunk of data that could perhaps be exchanged, how badly do you need this stuff, really? What do you plan to do during the year that you will be waiting for it to be available through an interface? Will you still need it a year from now or will you have worked out some other procedure? How much are the various vendors going to charge to configure the interface and test it? And, by the way, don't forget that there are often license fees to be paid for each "live" interface. In other words, even if they can specify your interface needs precisely, can you afford them? Is the benefit to patient care sufficient to justify the costs? For some interfaces, especially, internal ones, the answer is unequivocally - yes. For outbound interfaces to various undefined, occasional, external recipients, whether directly or through an HIE, I'm not clear that the answer is yes.

Attempting to answer these questions is doubly difficult because those beating the interoperability drum have their heads in the clouds. Wouldn't it be wonderful…if… But the ifs are never spelled out in detail. Just give me, they say, your tired, your poor, your huddled masses of data yearning to breathe free and we will set it free. Free! As anyone that has tried will tell you, slogans and generalities don't produce interoperability. It takes time, money, hard work, clear thinking, and a well defined target.

Find out more about Daniel Essin and our other Practice Notes bloggers.