An informatics solution for informing care delivery of immediate public health risks to their patients.

This paper describes a public health alerting approach that has the potential to improve patient care during a public health outbreak and reduce healthcare costs, streamline the process of public health alert management and dissemination, and heighten the crucial feedback loop between public health officials and clinicians. The approach ties public health alerts into the diagnostic process and allows clinicians to more easily determine when an observed medical condition may be related to a more widespread disease outbreak. A prototype Alert Knowledge Repository (AKR) service using this approach was demonstrated within the Health Information and Management Systems Society (HIMSS) and the Public Health Information Network (PHIN) interoperability showcases in April and September 2009, respectively.

Introduction

Over the past several years, new public health risks have become increasingly visible in the news media. When the West Nile virus was introduced to the United States in 1999, there was little experience in U.S. healthcare communities with this virus, which can cause a severe neuroinvasive disease in about 20 percent of those infected [1]. Beginning in February 2003, a communicable respiratory disease known as Severe Acute Respiratory Syndrome (SARS), later found to be caused by a previously unknown coronavirus, rapidly spread from China to 37 countries [2] in a matter of months, resulting in 8,098 known cases and 774 deaths. In the summer of 2008, peppers containing Salmonella serotype Saintpaul caused the largest recorded food borne outbreak in the United States [3]. In 2009, the World Health Organization (WHO) declared that the spread of a novel H1N1 variety of influenza had reached Phase 6 pandemic levels [4]. These new and emerging diseases pose widespread public health risks and highlight the need for closer communications between health care providers and public health officials responsible for monitoring health risks. This need is greater in an environment where additional demands are being placed on limited public health resources.

In the fall of 2008, the U.S. Centers for Disease Control and Prevention (CDC) convened a meeting to discuss an informatics solution linking the health care community to the immediate concerns of public health. The meeting resulted in collaboration among the CDC, General Electric (GE) Healthcare, the University of Utah (UT), and The Johns Hopkins University Applied Physics Laboratory (JHU/APL). In particular, the participants determined that electronic medical records (EMRs) may potentially enhance the delivery of care by having the most recent public health alert information available for the clinician during the encounter with the patient. An emerging technical specification for EMRs, known as the T.81 or the Retrieval of Medical Knowledge Transaction construct [5], uses the Context-Aware Information Retrieval (Infobutton) as a mechanism to obtain additional health information. Using the T.81 EMR transaction, JHU/APL created an Alert Knowledge Repository (AKR) that permits clinicians to view relevant high priority public health alerts that correspond to the patient they are currently seeing. This article describes a prototype AKR that was demonstrated within the interoperability showcases of two national conferences.

Background

An AKR is an electronic collection of all active public health alerts of importance to the health care of the population. For example, McDonald et al. [6] described a local health information network established in Indiana that included medical record information from fifteen hospitals, and served public health functions for county and state health departments. Maro et al. [7] discussed potential uses of a more general distributed health data network and described how such a network might serve the needs of multiple users, including the U.S. Food and Drug Administration. McMurry et al. [8] discussed the feasibility of an architectural model of a national health data network that uses the Shared Pathology Informatics Network [9] as a template for protecting patient privacy and providing authorized access. Hills et al. [10] described demonstrations of a model health information exchange (HIE) that uses existing semantic and syntactic standards to support data transfer in three types of scenarios: biosurveillance, case reporting, and vaccination. The CDC established a nationwide Health Alert Network (HAN) that provides communications, information, distance-learning, and organizational infrastructure to link local and state health departments to each other and to community first-responders, hospitals and private laboratories. The CDC HAN messaging system is currently capable of directly and indirectly transmitting Health Alerts, Advisories, and Updates. However, transmission is unidirectional and occurs when the state health department transmits an alert, instead of being viewed on demand by the recipient [11].

The concept presented in this article discusses the functions of a prototype AKR that supports the bidirectional exchange of timely public health information using information technology standards, the Internet, and the emerging Nationwide Health Information Network (NHIN). The objectives of NHIN include the establishment of a secure, interoperable network for exchanging health information among state and local governments, community health centers, laboratories, pharmacies, and clinicians. This network will support requests for de-identified health information, with the possibility of case follow up in the event of a public health emergency. Among the public health benefits are the early detection of and rapid cross-jurisdictional response to infectious disease outbreak and improved disease management by clinicians treating patients affected by these outbreaks.

The JHU/APL Center of Excellence in Public Health Informatics working with the CDC defined the initial specifications for an AKR. The AKR uses the T.81 construct to communicate with the GE Healthcare Centricity EMR. The AKR concept of operations is shown in Figure 1. Public health departments can author, view, and edit health alerts with descriptions of case definitions in the AKR. Using the patient data entered in an EMR and the Infobutton feature of the system, a clinician can trigger an automated query of the AKR that includes a de-identified patient profile. The AKR then matches all health alerts relevant to the chief complaint and demographics of the patient, and replies to this query by sending all active public health alerts pertaining to the current health conditions of the patient. Public health alerts retrieved this way can contain the information on the public health event (e.g., case counts, location; disease details; diagnostic procedures; prevention and treatment options; and reporting information). The EMR system can record the alerts viewed by the clinician for further reference and provide a mechanism to allow the clinician to give feedback on the relevancy of the alerts. This feedback may be conveyed back to the AKR, providing public health officials with data on diagnostic relevance of the generated alerts, alert usage, and potential new cases.

Figure 1

Alert Knowledge Repository Interfaces

By intimately tying the public health alerts into the diagnostic process, clinicians may be able to more easily determine when a given medical condition they see in their patients may be related to a more widespread disease outbreak. The public health alerting approach described herein has the potential to improve patient treatment and care in the face of developing disease outbreaks, and may reduce healthcare costs, streamline the process of public health alert management and dissemination, and heighten the crucial feedback loop between public health officials and clinicians.

Design Objectives

The objective of this research is to demonstrate an easy-to-use technical architecture and prototype system to improve communication between public health officials and clinicians. To evaluate the concept and architecture, a prototype AKR was developed that met the functional requirements described below:

The AKR must provide an Alert Management Web Interface (AMWI) for public health officials to author, monitor, and maintain alerts within the repository. The interface must be user friendly, Web-based, and rely on standard computer messaging protocols. The AMWI must have security features that limit access to only those public health officials responsible for entering and maintaining alerts, while access at another level will permit public health and clinical care workers to view but not modify existing alerts.

A desired feature of the authoring function is to provide easy-to-use templates for public health users to create public health alerts. These templates would ease the authoring of alerts, and when entering a disease would search available guidance on the recognition and management of the disease to pre-populate the alert with relevant information needed by the care delivery personnel.

The AKR must leverage the increasing presence of EMR systems and the standardized interfaces for those systems. The system should allow clinicians to request public health alerts based on current data in the patient’s EMR. The clinicians should be able to receive public health guidelines and protocols for their patients with symptoms that match the symptoms of the health condition specified in the public health alert database. The system should also provide clinical providers with up-to-date information on the event, number of cases, any particular population at risk, as well as information on diagnostic evaluation, treatment, prevention, and reporting.

The AKR must include a correlating function that matches the characteristics of a patient’s present illness with elements of the case definition in the public health alert. To perform this function, the AKR should include a natural language processor for categorizing free-text entries of a patient’s chief complaint.

The prototype AKR system was developed and demonstrated on the basis of the functional requirement described above. In the future, the AKR may be used to:

Demonstrate the transmission and integration of public health information into the clinical workflow;

Determine if public health alerting systems can be leveraged to identify specific patients with risk factors related to the health condition identified in the alert;

Evaluate the impact using qualitative approaches based on clinicians’ behaviors;

Determine if this functionality should be considered as a criterion for electronic health record certification.

System Description

To create the AKR, JHU/APL software developers modified a structured messaging software application called InfoShare [12], which was previously developed to share information among public health agencies within the Electronic Surveillance System for the Early Notification of Community-based Epidemics (ESSENCE) disease surveillance system [13]. InfoShare was developed in close collaboration with local public health agencies as part of a public health translational research effort [14]. InfoShare protects the information from unauthorized access, while allowing surveillance monitors in one public health agency to interpret their own data and share their analyses with surveillance monitors in other public health agencies. To mitigate personal health information privacy concerns, the information messages being shared adequately describe the public health situation without requiring identifiable data to be exposed. By using a grid-enabled Web-services interface, a modified standalone version of the Infoshare application was created to share information with users of the National Center of Public Health Informatics (NCPHI) public health research grid [15]. The Web-interface component of the service provides a user-friendly means of data entry and promotes the entry of information into structured fields to enable computer readability. These structured fields permit the information to be used by other visualization, algorithm, decision support, and messaging tools.

The InfoShare application was originally designed to provide a simple and structured method for sharing public health information among public health jurisdictions. For the AKR, the application was modified to provide for the posting of public health alerts derived from epidemiological investigations or from automated syndromic surveillance system alerts. When such investigations are determined by public health officials to be considered of epidemiological and clinical significance, the public health officials may then automatically upload the alert information via the AMWI interface. The archive of alerts provides a repository of immediate public health concerns that may be viewed by public health agencies and also queried by clinicians requesting alert information through their EMR. Software developers from GE Healthcare made modifications to GE’s Centricity EMR to enable it to connect to the prototype AKR. This concept was then demonstrated using the JHU/APL AKR as a Web service, the GE Centricity EMR with the T.81 construct implemented, and the Internet.

Figure 2 illustrates the internal components of the AKR, including the AMWI user interface, a chief complaint text processor, an alert/patient relevance processor, a T.81 message request receiver, a Hyper Text Markup Language (HTML) alert explorer, and the alert database.

Figure 2

Components of the Alert Knowledge Repository

The Alert Management Web Interface (AMWI)

The AMWI allows the public health official to create an alert. The AMWI contains authoring tools and a viewer. If the public health entity uses the ESSENCE disease surveillance system [13], then alert parameters can be transferred to AKR automatically after review by the public health official. If the official does not have a disease surveillance system that has this feature, the authoring tool shown in Figure 3 can be used to create an alert within AKR.

Figure 3

Alert Management Web Interface Authoring Tool

AKR public health alerts contain information including alert date, disease/condition, affected geographic region, relevant case data, as well as recommendations on diagnostic evaluation, treatment, prevention, and reporting. The public health official may enter text comments and color code them according to their level of concern, ranking from highest to lowest as Responding, Investigating, Monitoring, Not Concerned, and Information. These comments may describe the individual public health agency’s interpretation of their data. Only a limited number of the fields in the alert message are shown in Figure 3.

A library of disease templates may be used so that once the disease is entered by the public health official, much of the remaining form can be pre-populated with relevant disease, treatment, and outbreak response information. Health alerts residing in the AKR database are available for retrieval by both public health and healthcare users.

Figures 4 and 5 present alerts within the AKR as viewed from the AMWI interface. The upper portion of the AMWI display (see Figure 4) provides a list of the current alerts. Data elements presented include concern level, the title of the alert, the author of the alert, the beginning and end of the alert, and the date the alert was last modified in the AKR. The last data element is an attempt to place the alert into a syndrome group. The lower portion of the AMWI display (see Figure 5) contains the details of the alert selected. These details include the alert identifier, the author, the urgency, the disease extent of the outbreak, locations where it has been identified, symptoms, information regarding the disease and its management, and any other information public health agencies would like to pass to the clinician.

Figure 4

Upper Portion of the Alert Management Web Interface

Figure 5

Lower Portion of the Alert Management Web Interface

The AMWI interface permits users to quickly search for alerts within the AKR. The Search Criteria at the top of the AMWI display provides a filter for disease categories and concern levels for alerts that are contained within the AKR. As shown in Figure 6, selecting the Salmonella category displays only active Salmonella alerts.

Figure 6

Filtering Alerts Within the AKR Using the Search Criteria Function

The EMR Interface

The AKR has an EMR interface that permits a user of an EMR system to view patient-specific alerts contained within the AKR. When the physician’s office receives the patient, the patient information and current condition is entered into an EMR. The proposed Infobutton function in the EMR generates a query to the AKR to see if patient-specific information matches an active public health alert. The EMR initiates a T.81 transaction query [5] to the AKR. First, the query generates a de-identified profile that includes basic demographic data and symptom information, then sends the profile as a Healthcare Information Technology Standards Panel (HITSP) T.81 request to the AKR. This transaction enables the request and receipt of EMR health information based on specific context parameters using Health Level 7 (HL7) context-aware information retrieval, which is an American National Standards Institute (ANSI) standard. Using any HITSP T.81 compliant third party EMR, authorized users can query for public health alerts relevant to their own particular patient’s chief complaint, demographics, and geographical location. This query returns a report of matching health alerts that may include diagnostic and treatment information.

The alerts in the AKR are matched with the clinician’s EMR-based query (Figure 7). The de-identified patient profile is produced by the EMR as shown on the right hand side of the Figure 7.

Figure 7

Matching an Alert to an EMR Query

The chief complaint is a brief description of the patient’s stated or primary reason for the health care visit. Chief complaints are recorded as free text and may contain misspellings, acronyms, and abbreviations. Included in the AKR query logic is JHU/APL’s Chief Complaint Parser [16]. The Chief Complaint Parser is a Natural Language Processing system that can parse a chief complaint text into disease-related syndrome categories. In the AKR, these categories are mapped via a lookup table to a set of diseases/conditions that are matched in the public health alert. An alert/patient relevance processor matches the EMR query with alerts in the AKR database.

To facilitate matching the health alert with the patient’s data, the chief complaint text processor [16] expands abbreviations and acronyms and performs a parsing of the text (e.g., “Diarrhea” and “Abdominal Cramps”). In the example shown in Figure 7, the AKR contains an alert that closely matches the patient’s parameters. Matches are made on chief complaint, patient demographics (age, race, and gender), and jurisdiction (zip code) in the first instance of the AKR. Future enhancements are planned that provide a more extensive set of matching parameters.

The query from the EMR system to the AKR returns the results of the match to clinicians in the form of a Web page using a Hypertext Transfer Protocol (HTTP). The returned alerts are viewed within the EMR and have the potential to aid in forming a diagnosis and suggesting relevant treatment options. A sample Web page returned by the AKR in response to a T.81 query is shown in Figure 8.

Figure 8

HTTP Formatted Results for a Health Alert Query

Each alert message is a structured collection of fixed-value and free-form data fields. The structured message approach was selected to represent public health alerts. The authors in partnership with public health experts defined a message structure to support the development of a fully configurable repository with fields that sufficiently describe the public health alert. The structure also supported the ability to add special instructions to the alert in the AKR to prompt clinicians to ask specific questions or perform more specific laboratory or radiology tests to confirm or exclude their patient from the public health risk. Additionally, other information that may impact the treatment decisions of the clinician for their patients may be provided.

Results

The AKR prototype was successfully demonstrated within the Interoperability Showcase at the Healthcare Information and Management Systems Society (HIMSS) 2009 conference in Chicago, IL, in April 2009, and again at the seventh annual Public Health Information Network (PHIN) conference in Atlanta, GA, on August 30 through September 3, 2009. These demonstrations were conducted in collaboration with the CDC, GE Healthcare, and the Regenstrief Institute. CDC personnel populated the AKR with several public health alerts, GE Healthcare and Regenstrief Institute accessed the AKR through their EMR systems to demonstrate interoperability, and JHU/APL provided the AKR.

As a result of these live demonstrations, a number of previously unidentified requirements were discovered, as well as gaps in existing HITSP standards. For example, the T.81 requests standard returns query results in an unspecified format and it was found that requiring HTML retrieval allowed the query results to be viewable in the GE EMR software. Additional requirements for the full AKR were initiated based on the results obtained from these demonstrations. These include the ability to provide feedback to the health departments based on the number of alert matches.

Discussion

To better communicate public health alerts to clinicians and improve disease incidence reporting to public health officials, the AKR concept was developed by collaboration among JHU/APL, CDC, and GE Healthcare. The feasibility of this concept and the corresponding technical architecture were successfully demonstrated by a functional prototype of an AKR service at two major national public health informatics conferences. This AKR service utilizes a Web-based secure interface to allow authorized public health officials and clinicians to view and query a database of public health alerts created by public health officials. These public health alerts contain information that may include free text descriptions and interpretations, links to Web sites with additional text and graphical information, and color-coded levels of concern provided by the public health official. These alerts are processed and archived so that they may be shared among public health agencies and queried by clinicians. Clinicians can use the patient’s EMR to perform a query to find a match between a de-identified profile describing their patient’s symptoms and any public health alerts that may be of concern. Therefore, the public health alerts are available to the physician at the time and point of care in lieu of an E-mail or fax distributed via an alerting system.

In the future, the collaborators plan to promote this AKR in the NHIN environment [15]. Still to be determined are whether AKR instances should be local, regional, or national, along with issues such as the logistics of how to synchronize local information with regional or national federated systems. However, the AKR service already has the potential to allow bidirectional communication between clinicians and public health officials with minimal risk to patient privacy. The public health officials would be able to obtain improved disease incidence information and contact information of the physician or hospital seeing the relevant patients so that they may assist in follow-up and public health intervention. To reduce the burden placed on clinicians and prevent “alert fatigue,” the EMR system could be used to mark alerts as “acknowledged” to ensure that previously viewed alerts are not constantly re-transmitted for a given patient profile. The clinician is immediately able to determine if the patient they are seeing is potentially part of a larger public health concern and may obtain advice on how to address relevant public health concerns and possible case management. By improving the communication between public health officials and clinicians, the AKR potentially may help improve patient care and provide for more effective and efficient case identification, public health alert management, and disease outbreak control.