Author Archives: ePublic Health Blog

Free Webinar! – “Beneficial Practices for Improving Biosurveillance: Outbreaks – Lessons Learned from Seasonal Influenza”

Please save the date for the webinar below.  Dr. Ed Baker and Dr. Perry Smith will discuss surveillance efforts regarding the outbreak of seasonal flu.  The NACCHO Informatics group is looking forward to participating in this webinar!

Reserve your Webinar seat now at:
https://www1.gotomeeting.com/register/797109960

In this third webinar in the series, you will hear from Marion County Public Health Department (Indianapolis, IN) staff Shandy Dearth, Epidemiology Administrator, and Melissa McMasters, Coordinator for Immunization and Infections Disease Programs describe their experiences with seasonal flu.  Additionally you will hear from Kathleen Kimball-Baker, Director of the Public Health Practices Project at the Center for Infectious Disease Research and Policy (CIDRAP), a national online practice exchange for emergency preparedness and response professionals.

Webinar hosts, Dr. Ed Baker (Project PI and Research Professor, Health Policy and Management, University of North Carolina at Chapel Hill) and Dr. Perry Smith (Research Professor Epidemiology, State University of New York at Albany and former New York State Epidemiologist), will discuss with the guests and the audience:

  • How does a local health department competently respond to an outbreak of seasonal flu?
  • What are the surveillance challenges in gathering situational awareness information during an outbreak?
  • How can localities best prepare their surveillance systems for responding to outbreaks?
  • What special surveillance challenges does seasonal flu present to health departments?

Public health preparedness and surveillance professionals are invited to participate in this webinar.

Learn about the upcoming webinars in the series: http://sph.unc.edu/nciph/biosurv-webinar

Questions? Contact Carol Gunther-Mohr, Webinar Coordinator, University of North Carolina at Chapel Hill cgm@email.unc.edu

The webinar series is presented by the North Carolina Preparedness and Emergency Response Research Center (NCPERRC) at the University of North Carolina at Chapel Hill with support from the Centers for Disease Control and Prevention, Office of Public Health Preparedness and Response. 

Electronic Laboratory Reporting and the Public Health Workforce

Roland Gamache, PhD, MBA
Senior Director, Informatics
NACCHO

An informative article in this month’s Online Journal of Public Health Informatics, “Estimating Increased Electronic Laboratory Reporting Volumes for Meaningful Use: Implications for the Public Health Workforce,” shows the value electronic laboratory results reporting can bring to the public’s health. The article also describes how electronic reporting can capture the large portion of communicable disease cases that go unreported to better contain the spread of those diseases, confirming the efforts of the Office of the National Coordinator for Health IT (ONC) and the impact of Meaningful Use activities towards achieving these goals.

More complete reporting through Electronic Laboratory Reporting (ELR) allows better prioritization of case investigation by public health, with increased focus on high priority/high impact diseases that pose the greatest threat to a community. This information allows health departments to investigate these events more rapidly and more efficiently, therefore preventing disease. According to Joseph Gibson, PhD, a co-author of this paper, “Without ELR, public health has been like a physician who only gets half of the test results ordered to determine how to treat a patient.”

Public health departments can better protect their community’s health because this information will provide public health practitioners with a more complete picture of the unmet need in the community. This level of information will allow agencies to prioritize their resources more efficiently and effectively.

ELR makes the act of understanding the disease burden in the community more efficient while requiring less time for hospitals and labs to provide information to public health departments.

Additional lab reports are an important part of case investigations. More complete case reporting creates a better picture of actual diseases circulating in a community. An influx in lab reports or more thorough case reports do not hinder case investigations, but strengthens them because they create a better picture of actual diseases that are circulating in the community, and also allows for a larger data bank that can be used for future public health studies.

Nor does ELR increase the amount of disease in a community; it just provides more information about the notifiable diseases. The resources needed by public health required to respond to these diseases are just better understood because this information is reported more often to health departments. If we do not have a clear picture of what is going on in the community, how can public health departments do their job and protect the community?

The National Association of County and City Health Officials and the Association of State and Territorial Health Officials have documented the resource constraints in health departments as highlighted in the article. However, health departments are working with local, state and federal partners to build capacity so they can capitalize on the type of data flow that is envisioned in the scenarios described by this article.

Similarly, ELR has increased efficiency for lab reporting, helping to ensure that electronic case submissions can increase efficiency. Case reports submitted by clinicians with complete information will reduce the burden on public health.

In summary, ELR will improve the health status of the community by allowing health departments to more effectively and efficiently deploy its resources to improve their investigations about the spread of disease in their jurisdictions.

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.