Why Standards Matter (1): The True Meaning of Interoperability

DAVID C. KIBBE and BRIAN KLEPPER

Americans are generally skeptical of words that otherwise intelligent and articulate people can't pronounce.  "Interoperability," like nu-cu-lar, is one of these. After a while, these words can take on a mystique all their own.

But interoperability is a hugely important word in the context of today's ongoing debate about the use of EHR technology by physicians, hospitals, and patients too. The federal government is going to provide billions of dollars to encourage today's fragmented health care providers to convert from mostly paper to mostly computerized information systems. It is critically important for these systems to talk with one another. We want health data to flow between and among these systems and to be, well, interoperable.  And it isn't now.

So how can this word be so difficult to put into action?  Here's a clue: a lot of people are confused about its meaning. 

At the August 14, 2009 meeting of the Health Information Technology (HIT) Policy Committee, one of the two health IT expert committees advising the Office of the National Coordinator (ONC) and the Department of Health and Human Services (HHS) on the definition of "meaningful use of certified EHR technology," no fewer than four different committee members and at least one ONC staff member acknowledged they "didn't really know" what interoperability means.

Is it about transferring data, or sharing it, or both? Is interoperability a quality of the data, or of the computer systems? Can familiar digital file formats such PDF offer a kind of interoperability if exchanged more readily?  

Is it hard for computer systems to be interoperable, or is there some "low hanging fruit." For example, can some current software systems talk with each other about health data and information? 

And here's a good one: why are even CCHIT-certified EHR products, ones that have been certified for "interoperability," unable to exchange data consistently or reliably?

We're going to try to get to the true meaning of interoperability in this blog post, answering these questions along the way. Let's start with the concept of data (or "content"). The sentence that you're reading now is content, whether its on your computer or in printed form. In either case, the data are the words you're reading and that your brain is interpreting, at least if you can read and you speak English. (Purists may dispute that words can be data, but the word derives from Latin, dare, to give.  So, we're giving you our words as data.)

Then there's format. Mostly likely you're reading this content in a web browser, which uses the HTML file format to display content, mostly text and images. But you could instruct your computer to translate and save this content to other digital file formats, like Portable Document Format (.pdf) or Microsoft Word (.txt, .rtf, or .doc.) These formats work across platforms - Windows, Mac (and sometimes Linux) and have lots of robust features, like security, that most people don't know about or use very often.   But the point is this. Regardless of which of these formats you use, you typically can retrieve and redisplay the information in your file, even with a different computer, a different operating system and a different application.

Even better, because these formats are standardized, content can be transferred electronically over the Web. We can save a digital file, attach it to an email, upload it to a server somewhere, move it around electronically to people virtually anywhere, who can then download it to their phones. If the receiver of the file has software that can display the content -- that is, that knows how to interpret htm, .pdf or .doc files -- then another person can see and understand the content.

Is this content exchange between computers using different operating systems, at different physical locations, using different brands of software, the same thing as "interoperability?" And, if not, then what's missing here? Isn't it useful to patients, doctors, and hospitals to exchange documents containing relevant health information in digital formats like PDF and Word?  

No and Yes! In general, health care quality and efficiency would be improved if personal health content were more accessible to patients, doctors, hospitals and health plans in digital formats like PDF and Word. Finding ways to collect, store, and exchange a portfolio of digital information - text and images - associated with each patient could be enormously valuable. 

And, of course, this is precisely what Microsoft HealthVault and Google Health are, in part, starting to do by hosting services that allow consumers to upload their medical records to secure personal accounts. Recently, we each transferred copies of our Living Wills and Advanced Directives to our Google Health accounts. This wasn't a completely electronic process. It required filling out a paper PDF form, scanning the pages, and then uploading the images to our Google Health accounts, where we and our doctors can retrieve it as necessary. The benefit? Some day this simple procedure could save a lot of unnecessary suffering and cost.

But wait a minute! Because those digital Living Will and Advanced Directives files are in PDF, they're only readable by humans, right? Doesn't interoperability mean that machines can read and interpret the information, without human assistance?

Right. What is "missing" from the plain text in a typical PDF or Word file is a data "structure" that is not only machine-displayable, but machine-readable as well. Of course, text on a browser's HTML page or in a PDF file has a kind of structure.  It's written in a particular language, like English, that uses an alphabet,  and a particular font and type size.  But a more complex structure is required for software to read, interpret, and act upon discrete data in a digital file.

Let's say, for example, that we want to make interoperable the fact that a person has diabetes mellitus. Suppose a medical file's content includes the sentence, "The patient states that she was diagnosed with diabetes mellitus as an adult, but she reports that she has never taken insulin, and she does not think she has ever had high blood pressure or hyperlipidemia." 

It's really hard for a computer program to know where to find the "diagnosis" part of that sentence or to do anything with that information. To achieve the right results, it would need to recognize and accept the text "diabetes mellitus," while excluding "high blood pressure" and "hyperlipidemia." Both high blood pressure and hyperlipidemia are diagnoses, but the patient doesn't have them. Most current applications just aren't that evolved yet.

But suppose that instead of simple narrative text, the data "diabetes mellitus" is identified and placed in a spreadsheet cell, or in a structure known as comma delimited file, or tagged in a computer language known as XML. When content is placed in particular formats within these kinds of structures, software can be programmed to look for, find and pull the "diagnoses" out of the file, and then act on it. It can, for example, place the content in a list or table within a document, or trigger an alert for a lab test that needs to be done, and then send off the alert.  

Structured data is computable, which means that software can go beyond simply displaying the content to recognizing data and taking some action. This is highly desirable for certain routinized tasks where human interaction would slow things down significantly.

So, for most situations the term "interoperable" means that sending and receiving software systems can interpret and act upon structured data. Experts refer to this as "semantic interoperability."  But all it really means is that the machines at either ends of the transmission are capable of recognizing the format, and the structure within the format, and can therefore recognize the data elements, and do something with them.  It won't come as any surprise that if we attach a numerical code to the data, say 250.0 (the code for uncomplicated diabetes in a code set known as ICD-9), then it becomes all that much easier for the software to read, interpret, and act upon that bit of data.   Computers don't handle ambiguity very well, and so like the specificity of numbers.

For information to be interoperable, the structured data must be separate from the often propriety and even unique software applications that create and send, receive and store, the data. We want a structured data set to be understandable and interpretable by different machines running various kinds of operating systems and software.  In the case of structured health care data sets, we want them to be interpretable whether the data were created by EHR technologies from GE Centricity, NextGen, RMD Networks, Epic, Google Health, or PracticeFusion.

So in very practical terms, interoperability means that we can create a structured data set in one vendor's EHR product, and the data set can be read and interpreted by another vendor's product. A list of diagnoses, including "diabetes mellitus 250.0," will be easily understood and properly interpreted by different EHR technology products. Each product will know that 250.0 is a diagnosis and not an immunization, that this information can be extracted and placed in the EHR database's own structure and be associated with other codes for diabetes, but not for cancer, that this content may trigger alerts for certain tests pertaining to diabetes, but not for a family history of rheumatoid arthritis; and so on.

Also, in very practical terms, interoperability requires standards for data structuring, coding, security and so on.  But even more important than the standards themselves is industry-wide agreement about, and adoption of, these standards. A lack agreement on standards results in islands of data, the opposite of interoperability, which is largely where we are now.

So, interoperability depends on an industry agreeing on and adopting standards. XML is perhaps the most important of these standards. More about this in our next blog post.