Data Warehouses and Disease Surveillance — What Can We Do Now?

[In this two-part series, Dale Sanders examines the state of disease surveillance in healthcare, focusing on how data should be collected, stored and leveraged to help identify outbreaks. To read part 1, click here.]

So what do we do in the near term? Is there anything we can do, realistically, to better track the progress of diseases like Ebola, given our existing ecosystem of information systems in healthcare? As you can see from the list below, we could do better than nothing and the existing state of affairs, but any current option has significant shortcomings.

Here are the options that are available right now, listed with their pros and cons:

1. Monitoring ADT messages: This option would use the chief complaint/reason for admission data in an ADT message. The advantage is that it is real-time upon presentation of the patient at a healthcare facility. The disadvantage is the lack of codified, computable data in the data stream, thus requiring some form of natural language processing. Better than nothing, but far from precise. When presenting, chief complaint is usually captured in a free text field in the registration system. A handful of forward-thinking healthcare organizations are starting to codify these chief complaints with SNOMED, using an interface terminology on the front-end of that coded data so that registrars can still enter a lay term for the chief complaint that is mapped to a medically meaningful and computable code in the background. The other disadvantage of this approach is simple: a patient’s complaint does not equal a clinical diagnosis. A complaint of fever and vomiting from a patient might infer Ebola, but only a clinician and a lab test are capable of declaring with certainty that the diagnosis is Ebola. Until that clinically valid data is available, the best we can do is be concerned, but not definite. On a technology level, the other disadvantage of this option is that the chief complaint is frequently a single field in a database; therefore, registrars will usually only capture one complaint — i.e., “headache” or “vomiting” — when there might be several symptoms. Sometimes, the registrar will overload the data capture field with multiple complaints, separated by commas. If this were a good option, then HIEs or common interface engines would be capable of analyzing these ADT messages for this type of content. But there is no widespread occurrence of that in the industry because of the shortcomings to the approach.

2. Analyzing Coded EHR and Other Clinical Data: With this option, we can monitor coded data (SNOMED or ICD) for diagnosis, labs tests and results, and diagnostic imaging. This is the most precise option available, but it is unlikely to ever be a real-time option in healthcare. The way current EHRs are designed, the data that is entered into an EMR for a patient’s encounter is an all-or-nothing commitment. Until the clinician “closes” the encounter with all associated data and notes, the data is not made available for analytics and decision support. This is unfortunate design and behavior because, as I mentioned earlier, there is at least some decision-making value in an incomplete, low-resolution data profile. The alerting engine could be running in the background, looking at these clinical encounters that are only partially complete from a data perspective, whether the clinician is finished with their documentation or not. In any case, as currently designed and practiced, it can be several hours, days, or even weeks before a clinician closes a clinical encounter in an EHR. That’s not exactly opportune for managing a rapidly expanding disease outbreak.
3. Analyzing Coded Data From Billing Systems. This has all the problems of option 2 and more. It’s not unusual for revenue cycle processes and systems to take over 30 days to drop a bill. But in the absence of an EMR, this data is certainly better than nothing for profiling.

There are other options emerging, but they are years away from being integrated into the workflow of current EHRs and clinical processes. There have been several recent studies demonstrating the potential for analyzing social data, such as Twitter and Facebook. And Google has a site dedicated to tracking flu symptoms from search queries. Also, analyzing consumer-purchasing data is a possibility. Several years ago, before Wal-Mart became more secretive and declared their analytics systems their most valuable corporate asset (except for people), I saw a demonstration of their application that could track the sale of products across all of their stores, in near real time. Sales data was available for analysis in their EDW within nine minutes of a transaction at any of their stores, as I recall. One of the more interesting parts of the demonstration was their ability to see the progression of influenza across the US, as inferred by the sale of over-the-counter medications.

Conclusion: Disease Surveillance Needs a Data Warehouse, But…

Our options are not great right now, but with a well-designed and flexible data warehouse, at least healthcare delivery organizations have the beginnings of a solution that can improve in precision as we integrate more and more data, increasing the completeness and resolution of the picture for syndromic surveillance.

If anyone has any other ideas, options, or thoughts on this topic, I would love to hear from you.