Rx for Ebola: Protect the Perimeter with Decision Support and Surveillance

A man walks into an emergency room with a globally notorious febrile illness wanted for mass killings in other countries.  Instead of being diagnosed and treated, he is released back into the community, continuing to expose health workers and community members without warning.   While this may sound like the September 2014 Ebola virus fumble in Dallas, it was also the scenario that drove the SARS epidemic in 2002-3 when, as today in Africa, health care facilities were a major node of transmission.

Back then, a small cadre of techies and local public health workers developed a scalable process of perimeter screening at emergency departments that fed into a public health surveillance system (the SARS Surveillance Project).   Front line health care workers welcomed a simple decision tool to distinguish routine fevers from possible SARS, allowing them to initiate infection control to protect themselves and their patients.  Health departments received immediate notification of suspect cases and daily trends of respiratory febrile illness.   In a matter of days the system was operational in Milwaukee, and within a few weeks across parts of Ohio, Colorado and Texas too.

The system might be considered laughably simple today (yes, it involved paper, pencil and arithmetic).  It was slapped together with tools at hand and without federal funding.  Nevertheless it scaled far faster than the anticipated SARS epidemic.  (We never found a SARS case, nor were there cases to find in our jurisdictions.)  The Dallas experience proves that a similar approach is needed today.   I hope our old publication might prove useful to today’s Ebola virus fighters.

We failed to get CDC to pick up or even endorse the project.  It fell victim to the “not invented here” syndrome.  (Although we showed we could rapidly scale to EDs serving more than a quarter of the US population, the last conversation ended with “We already work with an emergency department in California, thank you very much” [emphasis mine]).*

A larger question is: are we better equipped to scale up such a system today after US$ billions of investment into health information technology?   The short-term answer is “No”, outside some local centers of excellence.    But there is little reason we couldn’t get there with a little strategic leadership and investment.

Imagine that CDC translates Ebola suspect case definitions (symptoms, signs, travel, sick contacts) into standardized HIT data elements.  Imagine these are loaded into a standards-compliant rules repository accessible to electronic health record systems (EHRs).   Imagine that EHR systems upload these rules to alert triage personnel to ask 4-6 brief questions of febrile patients.   Imagine that responses suggesting Ebola trigger immediate infection control and public health reporting.  Imagine that patients, healthcare workers and the community are protected pending definitive diagnosis.  Imagine that emergency response receives the gift of a head start on the possible emergence of a generation of new cases.

In recent years the pieces of this more automated solution have been largely completed but not assembled and applied: widespread certified EHR use; specifications for capturing most of the needed data elements; methods to distribute clinical decision support rules; specifications for electronic public health reporting.   With a focused vision and public health investment an adaptable system that combines “situational” EHR decision support with surveillance could be achieved fairly rapidly.  In the meantime, I’m told, paper, pencil and basic http are still available to replicate the 2002 approach.


*(In fairness it must be told I joined CDC 8 years later, and during my two years there agency budgets for the public health use of health information technology markedly shrank.  Thus I must share responsibility for the current state, despite efforts to the contrary.)


4 thoughts on “Rx for Ebola: Protect the Perimeter with Decision Support and Surveillance

  1. Pushing public health (PH) CDS rules to systems at the point of care is problematic. How does PH get the list of EHR systems to receive the rules? How does it distribute those rules? (Does it push them out asynchronously, or does each EHR system need to periodically retrieve new rules?) How do we ensure that CDS rules are executed correctly in each of those EHR systems? How do we ensure that a published CDS rule is in fact enabled in all of those systems? (I am sure system managers will be wary of just plugging in executable code, even if it is from a reputable PH source, which means that there will be a delay from publication to actual availability for execution.)

    A better deployment model might be an external CDS service run by PH, which receives a standard set of anonymized data for each encounter/admission, and which might request further info when there are special/emergent circumstances (e.g., travel information may only be necessary when there is an active epidemic). The IHE Request Form for Data Entry (RFD) profile could be the standards-based foundation for such a service, but it would require 1) standing up PH CDS services that could support the data volume (not as much a problem with cloud deployment models), 2) a generic capability for such an interface to be built into EHR systems (many of which already have prototyped RFD), and 3) a mandate for the submission of encounter/admission data to PH (similar to current mandates for infectious disease lab result submission).

    • Thanks for this! I would be interested in others’ comments on the relative virtues of the two solutions. If memory serves, an early CDC CDS pilot in Chicago allowed EHR users to make such calls to a centralized CDS service using info-button standard. One issue is that the “anonymized query” approach might need to scale to massive traffic. Community please weigh in with the advantages and disadvantages of these approaches!

  2. Doesn’t HealtheDecisions allow for external CDS systems to be connected to from EHR? It could be a PH agency, or other group with its own non-PD CDS algorithms.

    While the volume could be massive, this could be accomodated by not having a single system for all requests, but a method for sharing rulesets so that multiple algorithm providers could provide the service so health systems could stand up their own instance that only their hospitals use, etc. etc.

    Even with cloud the volume seems too large. It would require ever encounter and really every transition since any time new data is collected or generated rules may now apply.

    (personal opinion obviously)

Leave a Reply