Interoperable: Shares a well-defined interface

 Joe Gibson
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
InteroperabilityWhen 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?
miscommunication_jpegThis 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.

Acknowledgements:
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.

Advertisements

3 thoughts on “Interoperable: Shares a well-defined interface

  1. Dave Ross

    Joe,
    Great explanation. I agree completely with your points. Interoperability should mean that content has been sent, received, and properly understood and interpreted. Over the past few years standards development efforts have led many to focus merely on the creation of a standard but has not led to use of the standard in a way that advances a clear health purpose. Your post will be recommended reading for our Informatics Academy students.

    Reply
  2. Michael Coletta

    Joe,

    Great post – nice to see this blog still bringing great content!!

    I agree with everything and would like to push our community to find ways to take the shared understanding of public health business processes that PHII is building and put it into practice. I’ve found (through PHII tutelage) that it all starts with defining the process and understanding the needs. But we need to get beyond describing that and prioritizing processes, taking our shared understanding of processes, and then putting that into the practice of building the integrated interface. Of course this assumes that we have well-functioning modules underneath that are flexible and can use common ways to exchange information. Herein lies the rub – it can often get quite complicated at this juncture and requires not only the understanding and buy in from Public Health leadership, but perseverance and investment of money and more importantly time and effort. How can we get there? How do we push our community to dig in and move ahead? And what are our priorities?

    Reply
  3. Nathan Bunker

    Joe,

    This is an excellent article. It has helped me to better understand the issues at hand when it comes to interoperability. I especially like your description and advocacy for module systems. I had not thought of this problem in this way before. As a software developer I have realized the limits to what I can reasonably create within the time constraints and have moved towards building modular systems that can do one or maybe two things well, and the rest is left to other systems. Your advocacy for supporting good modules and avoiding the idea that a single solution can do it all is very appropriate for public health.

    The largest barrier to moving towards modular systems is the existence of tightly defined interface standards. For example, HL7 version 2 has been around a long time and is a very functional standard, but it contains a great deal of “wiggle” room that allows systems to create conformant but incompatible interfaces. Happily work is going on now to eliminate this variability. In the meantime we need to work together as a public health community to identify areas that could benefit from further standardization.

    Thank you for putting together this great article and furthering public health.

    Reply

Leave a Comment

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s