Category Archives: Innovation

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.

The Search for Business Models for Public Health Participation in an HIE

Marcus Cheatham
Health Officer
Mid-Michigan District Health Department

Have you read the recently released report by the Trust for America’s Health “Healthier America 2013”? It is an excellent attempt to summarize the opportunities for public health to transform itself during the roll-out of the Affordable Care Act. Over and over again the urgent need for public health to work hand-in-hand with health care systems is highlighted in the report.

Public health departments must adapt to work with new entities and financing mechanisms in the reformed health system, such as by working with Accountable Care Organizations (ACOs) or within newly capitalized care structures and global health budgets, to help improve health beyond the doctor’s office.

A key component of this, obviously, will be the ability to exchange health information with other parts of the health care systems electronically. Let’s consider my health department’s Children’s Special Health Care Services (CSHCS) program as an example. This program coordinates care for children with qualifying medical conditions. Our health department has an electronic health record (EHR) system. We manage our CSHCS cases using the EHR which works quite well. We are completely paperless—well, almost. In managing these cases we collaborate with Medicaid Health Plans. Information going back and forth between us and the health plans still goes by old-fashioned, messy faxes.  Just this morning, I found two “lost” CSHCS faxes floating around in our copy room.  We would love to join a Health Information Exchange (HIE) so we would be able to exchange this information directly out of our EHR and ditch the faxes.

In fact, last week we met with one of the two big HIEs in our state to talk about doing just that. This HIE offers a sweet product for managing referrals which is exactly what the CSHCS program is looking for. Physicians’ offices in our area are starting to jump aboard the HIE, and even some of the Medicaid health plans are on their system.  We would love to go forward, but there is a snag: the cost.

Participating in the HIE would only cost a few thousand dollars. The problem is that our health department is looking at budget cuts next year of many tens of thousands of dollars. Our state pays for part of public health out of a health fund that is going to take a big hit this year; there is sequestration; and some of the counties in our district are warning that their general funds are still underwater. If joining the HIE allowed us to expand CSHCS, maybe we could use that additional revenue to join the HIE. But the CSHCS caseload is fixed. The way CSHCS is managed in our state, the Medicaid health plans gets first crack at the most lucrative billable services in CSHCS and we get what is left. We actually expect CSHCS revenue to fall, with or without the HIE.

Another complicating factor is that our health department is between two large medical trading areas, each with its own HIE. In order to provide CSHCS services electronically across our district, we would need to join two HIEs, at twice the cost. Most frustrating of all, the two HIEs only exchange information between themselves using a protocol called Direct, which is very limited.  It’s kind of like secure email. It would not permit the kind of exchange we really need to make CSHCS referrals efficiently.

Yet not joining the HIE at this point poses a risk, too. As more and more physicians join the HIE more of them will be making referrals electronically using the HIE’s product. If the health department does not appear in their system because we haven’t joined, referrals for things like women’s health, family planning and the various testing and screening services we offer will start going elsewhere. Now, I don’t think government should be competing with the private sector to deliver these services. My concern is that medically complicated or vulnerable people who should be seen at a health department may miss that opportunity. Our services need to be sustainable so that we can be here for those who need us.

That’s the challenge we are wrestling with now. We need to come up with a business model through which we partner with the health care system and generate the revenue we need to be part of our local HIEs. Fortunately we are in a community where our hospitals are interested in helping us make that happen. We have a meeting scheduled this month to begin exploring potential solutions

*Note blog submission reflects dates in April 2013*

Public Health Informatics Virtual Event on July 16-18, 2013 – Call for Abstracts!

Connect with colleagues at your own convenience!

ph informatics virtual event

This virtual event provides the opportunity to learn and discuss the latest initiatives in public health informatics with attendees from all over the country and internationally. Call for abstracts is now open and will continue until May 31, 2013. This year’s theme is “Strengthening Public Health – Health Care Collaboration.” Abstract submissions are encouraged in the following areas:

1)  Informatics policy and practice: virtual sessions will focus on national and international policy issues and their implications for public health informatics programs; applied informatics projects for programmatic support; and new initiatives

Examples might include:

  • ICD-10 CM/PCS –deadline for implementations 10/1/2014
  • Meaningful Use & Electronic Health Records
  • Interstate data exchange
  • Data exchange to support ACOs

2)  Research & Innovation: virtual sessions will focus on informatics research and technological innovation to public health and clinical settings.

Examples might include:

  • Applying analytics to new and existing data sources
  • Leveraging Big Data for population and public health
  • Learning health systems to support integration of primary care and public health
  • Novel technologies for population and public health education and communication (mobile, web, social media)

3)  Supporting Public Health Evidence Based through Informatics Practice: virtual sessions will focus on strengthening public health through knowledge sharing, evaluation, visualization and reporting.

Examples might include:

  • Evaluation methodologies and findings
  • Decision support for population health Health status and performance management dashboards
  • Community Health Assessments as part of the community health improvement process
  • Return on Investment (ROI) and Value of Information (VOI) analyses for informatics programs and systems

If any of the items above relate to your area of work, do not miss the opportunity to submit an abstract!

Help us get the word out and share this blog post with your colleagues and friends! And if you’re ready to submit an abstract go straight ahead here.

Meeting sponsors include CDC, NACCHO, and ASTHO.