The Bright Elusive Butterfly of Interoperability

Everyone expects that computers should be able to contribute to improving outcomes and reducing the cost of healthcare. Furthermore, it is said that something called interoperability is supposed to be important in realizing these expectations. 

According to Wikipedia, a Jain version of the story of "Six Blind Ben and an Elephant" says:
"That six blind men were asked to determine what an elephant looked like by feeling different parts of the elephant's body. The blind man who feels a leg says the elephant is like a pillar; the one who feels the tail says the elephant is like a rope; the one who feels the trunk says the elephant is like a tree branch; the one who feels the ear says the elephant is like a hand fan; the one who feels the belly says the elephant is like a wall; and the one who feels the tusk says the elephant is like a solid pipe. A king explains to them: 'All of you are right. The reason every one of you is telling it differently is because each one of you touched the different part of the elephant. So, actually the elephant has all the features you mentioned.'"

Interoperability is a lot like the elephant. The government and various groups have each seized a different part of the elephant but have not yet reached the king's level of understanding. Rather than rehash the arguments, let's simply consider what it might mean to a practicing physician.

To start, a general definition: Interoperability is the ability to take some information that was generated somewhere and use it somewhere else.

The most basic kind of interoperability is human readability. This can easily be achieved by any means that allows narrative text documents to be retrieved and read somewhere else. This could include fax, e-mail, snail mail, shared storage in the "cloud," etc. Interoperability is enhanced, even at this level, if the documents to be exchanged are organized and structured similarly - and - if they are legible.

The information being exchanged would have more value if it contained discrete data elements (e.g. height and weight) that could be reliably retrieved and used in a calculation without having to look for variations such as height, Height, and ht in addition to misspellings. Most attempts to achieve this level of interoperability assume that the information must be stored in a highly structured database with predefined elements to accept the incoming information. Of course, to get interoperability in this way the producers and consumers have to agree on the structure of the database and the definition of each element. The number of items that one might need to exchange is, for all practical purposes, infinite and can change unpredictably. As a result this approach is better at generating endless committee meetings than it is at actually exchanging information.

Additional value can be derived by arranging each block of information (e.g. an encounter note) in a standardized text* format that contains internal markers that delineate what is text, what is data, and if data, what kind of data it is, and how or where it is defined. The most practical, and in the _de facto_ standard, way to do this is with XML (eXtensible Markup Language.) XML's sibling HTML demonstrates the power of this approach.

Web browsing is the best and most familiar demonstration of interoperability. Millions of Web sites around the world have created billions of Web pages and you can retrieve and view almost all. This extreme degree of interoperability was not achieved by endless committee meetings trying to agree on every detail of what could/should be put into a Web page. It arises simply because there are browsers that are designed to display properly formatted HTML documents and there are Web page producers who create pages that are properly formatted (because they want their pages to get looked at.) The process is bottom-up and unmanaged. There is no central planning, no HITECH Act and only a few committees, but they only deal with the HTML language, not the content. What is lacking from HTML, but present in XML, are the availability of additional markup elements that allow the data contained within a document to be structurally delimited and augmented.

One XML markup is the HL7 Document Content Architecture (CDA) Specification which is an adopted standard. The good news is that it is a standard. The bad news, in my opinion, is that it relies too heavily on specifying content, rather that concentrating on specifying document structure. I believe that this factor has contributed to the slow pace of its adoption and that there are other, simpler markups that would yield a higher overall degree of interoperability. I say this as one of the CDA's authors.

Unfortunately the feds are pushing interoperability by promoting the creation of highly specified and structured repositories rather than pushing system vendors to all produce output that conforms to a simple, standard markup. In short, ignoring the lesson of the Web, they are trying to do, in a top-down, managed way, something that we know from experience can happen easily in a bottom-up, organic fashion if the right pre-conditions are in place. In this case, the right pre-condition would be a medical Web browser that understood CDA and other common medical XML markups and that could both display readable documents and export the available data for your own uses.

In short, the elusive butterfly of interoperability could be captured for a few million spent on browser development rather that billions thrown at Health Information Exchanges. "Build it and they will come."
 

* Text, because other types of data may be tied to specific software which may not be readily available in the future.