Director of Epidemiology
Marion County Public Health Department
Modular systems vs. the Killer App
I am a great believer in having modular, interoperable systems. I have seen too many “Killer Apps;” too many systems that try to do it all, and end up doing their core function well, but most other things badly, like case investigation systems that try to include analysis and reporting, or analysis systems that try to include data capture modules. As much as possible, I want my health department to have a set of distinct systems, where each system does its function very well, and can work with the other systems to support our entire operation. The staff should only have to learn one interface for inputting encounter data, and only one interface for generating reports, just like we have only one application for working with e-mail. Of course, the separate systems have to communicate with each other, so that our encounter data can get into our reports. In other words, the systems have to be interoperable.
True and false interoperability
When people talk about interoperable systems, they often focus on whether the systems share some coding system like SnoMed, ICD10, or LOINC. Under this very limited view of interoperability, two systems would be considered interoperable if they store their information using the same codes, like ICD-9-CM for diagnosis, “M” for male and “F” for female in the Gender field, etc.. If systems were people, this view might consider two people “interoperable” if they had the same native language.
Sometimes discussions of interoperability also include message standards. Message standards define how information is arranged in the messages sent from one system to another. Message standards define what fields should be sent, in what order, with what separators or labels, in what format (HL7, XML, etc.), and with what coding system. Message standards are analogous to grammar; if interoperability were defined as having a shared message standard, two people might be considered “interoperable” if they used valid sentences in the same language.
But interoperability requires much more than this. It is not just having information that is coded in the same way in two systems. It is not just having standard formats for communicating certain kinds of information. It also requires some kind of connection between the systems, just like communication between people requires a telephone, and e-mail system, or being close enough to hear each other. It also requires the message be properly interpreted, so the information can be used for action. And it requires some appropriate, sensible response, often in the form of a confirmation that the message was received and understood, and perhaps an answer, if the original message was a query. We have all had the experience of talking without understanding, despite using valid sentences in a shared language. A productive exchange requires that each side understands the other, and responds in some relevant way.
Interoperable = shared interface
Until recently, when I tried to assess whether two systems are interoperable, I had a hard time organizing all this in my head. I would think about language, message standards, connections, and vague and diverse functions for interpreting information and responding to it. Fortunately, I learned a much more useful way to think about the crux of interoperability from a developer during a recent meeting about collaborative development of immunization registries. He said that to create one software module that will work with the our many, varied immunization systems, we need to define the interface.
An interface is the point of interaction between systems, like the counter at a fast food restaurant. The interface allows systems to connect and exchange something. Think of a fast-food counter: you state your order, the server tells you the cost, you give some form of payment, and the server gives you your food. Each part of the exchange has certain criteria: you may have to order in English or by pointing, and the payment may have to be with cash or credit card. A system interfaces might define how to send an address and get back a geocoded point location from Google Maps, or how to send a laboratory sample ID from an EHR and get back a laboratory result from a LIMS system. A systems interface defines what can cross between the systems, when, in what form, and the allowed responses. The interface does not define the internal operations of system operates, but it does define the inputs and outputs needed for an exchange between the systems. A well-defined interface defines everything that needs to be done for that exchange to occur; to more, and no less. It precisely defines, for a specific function, what is necessary for systems to interoperate.
So now, when I consider whether systems are interoperable, my central question is, “is there a well-defined interface between these systems?” When I think about making two systems interoperable, I see the task being to develop an interface between them.
Why does this matter?
This concept of interface should be at the core of our conversations about interoperability. I get worried when interoperability discussions are just about language or message format; I worry that public health decision-makers will be misled into investing in systems that are called “interoperable,” when the systems only use the same language or message format, but do not have automatic, built-in functions for communicating and using information from each other. Do not be fooled. Two systems are not interoperable unless they conform to a shared interface. If someone says that a system is interoperable, have them demonstrate how their system sends and receives information from your other systems through a well-defined interface.
Thanks to Nathan Bunker of Dandelion Software and Research for getting me thinking about interfaces this way, the Public Health Informatics Institute for organizing the Immunization Information Systems Joint Development meeting, and the CDC for funding it.