One of the principle liabilities of the paper electronic record is that it is a physical object. It must be stored in a file or archive, and can only be used by one person at a time. Moreover, it is inherently perishable, and must be protected. Database management systems and computers help, but they introduce their own problems, too. First of all, traditional computer systems are also limited in time and space. Computer networks and cloud technology help, but even if records are accessible across networks (with appropriate security, of course!) they are still tied to software, to storage systems, and institutional barriers. We’ve all had the experience of moving to a new area, changing providers or jobs, and suddenly discovering that our health record is, for all intents and purposes, gone. Our new physician does not have access to our records, and critical history may be lost.

Electronic Health Record (EHR) standards and Health Information Exchanges (HIE) exist to solve these problems. At a (seemingly) simple level these are interoperability standards, but from another perspective, the goal is to make the patient record into something that is technology independent, persistent, and ubiquitous. More importantly, the record acquires an existence of its own, it is no longer tied to a particular computer system or piece of hardware. This difference is analogous to the distinction between the text of a printed book, or the book itself.

That sounds attractive doesn’t it? But it is also easier said than done. Software developers, hospitals, and health care organizations have struggled to achieve this level of interoperability, but it always seems to prove elusive. Some consider this a good thing (in the name of privacy), but others consider it a major impediment to healthcare delivery in the modern, mobile world. My point of view is that privacy and security issues can be addressed – and besides, they really existed with paper records, too – but we can’t ignore the problems the electronic health record is meant to solve.

In simple terms, for an electronic record to be useful, it must be understandable, not only by humans, but the systems that must manage those records, and we must know what to do with them. Thinking about books again, I can pick up a book and read and understand it, regardless of how it is bound, or what font it is printed in. Moreover, I can lend the book to someone else and be relatively certain that when he or she reads it, she will have the same general idea of what the author had in mind. Such is not the case with computer records.

The difference is that natural languages have semantics on which we can largely agree. To read a novel, say Gulliver’s Travels, I don’t need to learn a special language, say Swift English. (Then again, if I want to read Finnegan’s Wake, maybe I do need to learn a new language!) By contrast, an electronic record is only usable by one computer system. If I have data that is generated by and used by Cerner, it’s going to take a lot of work to get it to work with Epic, or VISTA. It might seem that standards such as HL7, which provide a common format, will solve this problem, but so far, they have not. Why not?

The reason is that records or documents must be integrated into a new system in a way that makes sense for that system. There are people, often called system integrators, that make entire careers out of doing just this. Even more, there is an entire industry that has developed around this problem. I do not believe the problem is intractable, but I do believe it is hard. Indeed, much of this blog will focus on interoperability, and how we can move closer to achieving it.