An Electronic Health Record - Public Health (EHR-PH) System Prototype for Interoperability in 21^st Century Healthcare Systems

Abstract

Information exchange, enabled by computable interoperability, is the key to many of the initiatives underway including the development of Regional Health Information Exchanges, Regional Health Information Organizations, and the National Health Information Network. These initiatives must include public health as a full partner in the emerging transformation of our nation’s healthcare system through the adoption and use of information technology.

An electronic health record - public health (EHR-PH) system prototype was developed to demonstrate the feasibility of electronic data transfer from a health care provider, i.e. hospital or ambulatory care settings, to multiple customized public health systems which include a Newborn Metabolic Screening Registry, a Newborn Hearing Screening Registry, an Immunization Registry and a Communicable Disease Registry, using HL7 messaging standards. Our EHR-PH system prototype can be considered a distributed EHR-based RHIE/RHIO model - a principal element for a potential technical architecture for a NHIN.

INTRODUCTION

On July 21, 2004 the Department of Health and Human Services (DHHS) announced the decade of health information technology (HIT) for “delivering consumer–centric and information-rich health care.”[1] The vision is to build a National Health Information Network (NHIN) of regional health information organizations (RHIO) and exchanges (RHIE). The RHIO and RHIE would in turn be formed of health care providers (HCPs) integrated via electronic health record systems (EHRS) to improve patient safety and deliver quality care. One of DHHS’s goals for the NHIN is to Improve Population Health.

Specific actions toward achieving this include:

• Unifying public health surveillance architecture;

• Streamlining quality and health status monitoring; and

• Accelerating research and dissemination of evidence.

Public health data systems have traditionally been created to support specific program areas (domains) within local and state health departments i.e., newborn screening, birth defects, immunization, communicable disease surveillance, lead poisoning prevention, etc. Systems maintained by these programs are populated with data reported by HCPs often from paper-forms. These public health “siloed” information systems are often custom-made to serve particular programmatic needs and are not interoperable across a health department. Lack of integration across public health programs leads to the inefficient use of resources and frustration among families and HCPs asked to provide the same information, in varying formats, to various programs, at the different time. Most current public health systems do not allow easy aggregation of patient’s information to provide real-time data back to the HCP office. [2]

Because of the automation of clinical data – inpatient and increasingly outpatient – via EHRS, public health programs stand at the threshold of changing the way they can gather programmatic data. The EHRS is a pivotal instrument in integrating clinical and public health data systems - EHR-Public Health (EHR-PH), so public health authorities will have reliable, real-time data to support health policy decisions for better and safer care. [3]

Progress is being made to support a global outlook for public health information solutions. Physical links have been established between first responders and health care industry workers across the country through the Centers for Disease Control and Prevention (CDC) Health Alert Network (HAN) [4]. Data sharing agreements, Memorandums of Understanding, Non-Disclosure Agreements, and other rules of engagement are being executed to facilitate and encourage agencies and organizations to establish secure physical and logical links between systems and applications. The integrated EHR-PH environment has begun to take shape.

The goal of this paper is to describe an EHR-PH system prototype - a collaborative public-private partnership effort to demonstrate the feasibility of reporting EHR data from a HCP to multiple customized, public health systems using the HL7 messaging standard.

METHOD

The EHR-PH system prototype was designed to track reporting from a Hospital of Birth to the four public health programs in the order that represents the information flow across the typical schedule of public health reporting and that covers a period from child’s birth through the first 48 hours of life before discharge. The EHR-PH prototype demonstrates communication between an EHR-Birth Record that is created at the Birth Hospital to the four public health programs responsible for providing services to the infant. These include:

• Newborn Metabolic Disorder Screening (Newborn Screening),

• Newborn Hearing Screening,

• Immunizations and

• Communicable Diseases.

The EHR-PH system prototype showed a range of clinical procedures relevant to public health reporting and vendors whose systems are currently in use by public health agencies to support their programmatic activities (Table 1). As such, our demonstration provided a true representation of system interoperability that can be achieved between clinical care and public health programs and across public health programs within the agency.

Table 1.

EHR-PH System Prototype Partners

Encounter/Settings		Partners
Hospital of Birth	State Health Department	System, Company
EHR-Birth Record	N/A	Healthcare Transaction Base (HTB)™
Newborn Metabolic Screening	Newborn Metabolic Screening Registry	Birth-Data-Works™, MDL
Newborn Hearing Screening	Newborn Hearing Registry	eScreener-Plus™ (eSP), OZ Systems
Immunization Administration	Immunization Registry	Immunization Registry™, STC
Communicable Disease Case	Communicable Disease Registry	Com.Disease Registry™, STC
Integration Engine		OracleAS Integration™

The EHR-PH system prototype demonstrated how healthcare events included in the demonstration for the same newborn can be collated and displayed through one user interface in real time.

The EHR-PH system prototype demonstrated the ability to:

• convert HL7 2.x messages currently used by systems to HL7 3.0,

• transport these messages over Internet and healthcare standard protocols, e.g., MLLP (Minimal Lower Level Protocol) from hospital systems to the integration engine; and HTTP/S (Hypertext Transport Protocol) from clinical to public health settings,

• store this information in a HL7 RIM-based (Reference Information Model) repository for viewing through a web-enabled interface, and

• achieve the interoperability with Commercially-available Off the Shelf (COTS) products.

The electronic data reporting was supported by an Integration engine capable of transforming HL7 messages from 2.x to 3.0. The Healthcare Transaction Base (HTB) was used as a data repository. For the Newborn Screening, Newborn Hearing Screening and Immunization data resided at the source systems. The Communicable Diseases application data resided at HTB. For the purpose of this demonstration, the EHR-Birth Record also resided at HTB.

RESULTS

The high-level architecture of the EHR-PH system prototype is presented in Fig.1. Each component of the system is depicted along with arrows showing data moving into or out of that component.

Fig.1.

EHR-PH System Prototype Architecture

Partners in this demonstration sent or received various 2.x and 3.0 messages transformed and transported by Integration engine. The HTB was used to store and collate healthcare event information received in the form of HL7 3.0 messages from the various systems in real time. Specifically, the Clinical Care system (Hospital of Birth) on the left of the diagram utilized MLLP to transport messages to the Integration engine. The partners for the prototype (Table 1) provided the applications supporting the Public Health Surveillance portion of the diagram (right side) - four state health department programs.

With the exception of Hearing Screening where the hospital and health department had different views into the same patient record, we mimicked system behavior for the Clinical Care components, with the majority of the partner components acting as registries for Public Health Surveillance. For Hearing Screening, the same eSP™ application served dual functions as (1) a patient management system at the Hospital of Birth, and (2) a Registry for tracking and surveillance at the state health department.

The demonstration included the following six steps:

Step 1. EHR-Birth Record

1. The demonstration was initiated at the Hospital of Birth with the creation of the EHR – Birth Record on a Newborn . An HL 7 2.4 ADT (admission / discharge / transfer) message, containing information about the registration of the Newborn at the Hospital was sent to the Integration engine, transformed to a 3.0 Encounter message, and propagated to HTB.

2. Public health programs received the 3.0 Encounter information – the Newborn Screening Registry and Hearing Screening Registry received the Encounter message, while the Immunization Registry received the original 2.4 ADT message.

Step 2. Hearing Screening

1. A Hearing test was conducted on the Newborn at the Hospital of Birth.

2. A 3.0 Observation message with test results was sent via the Integration engine to HTB to update the EHR-Birth Record.

3. The Hearing Screening Registry received a 3.0 Observation message with test results from the Integration engine.

Step 3. Newborn Screening

1. A blood specimen for the Newborn Metabolic Screening was collected from the Newborn at the Hospital of Birth and sent to the Laboratory. The Laboratory analyzed specimen and sent a 3.0 Observation message with the test result through the Integration engine to HTB to update the EHR-Birth Record.

2. The Newborn Screening Registry received the 3.0 Observation message with test results from the Integration engine.

Step 4. Immunization

1. A hepB vaccination was administered to the Newborn at the Hospital of Birth. The Hospital of Birth sent a 3.0 Observation message to through the Integration engine to HTB to update the EHR-Birth record with information on vaccination.

2. The Immunization Registry received the 3.0 Observation message with information on the vaccination from the Integration engine.

Step 5. Communicable Disease Reporting

1. The Newborn had a mandatory reportable communicable disease (e.g., Syphilis). The Laboratory sent a 2.4 ORU message to the Integration engine to be transformed to a 3.0 Observation message before being imported into HTB to update the EHR-Birth Record.

2. The Communicable Disease Registry (CDR) built on top of HTB, utilizing J2EE to communicate with HTB, automatically recognized the report of the disease and started an investigation.

The CDR part of the demonstration is conformant to the communicable disease reporting requirements of the Public Health Information Network (PHIN), Centers for Disease Control and Prevention. [5]

Step 6. Healthcare Enterprise Viewer

A summary of encounters and clinical acts for the Newborn was developed using a series of screens built on top of HTB. These screens utilize a MVC (Model-View-Controller) framework and J2EE to communicate with HTB.

The EHR-PH system prototype was successfully demonstrated at the HL7 sessions on the Interoperability for 21^st Century Health Care Systems at the HL7 meeting, Orlando, FL, January 27, 2005 and HIMSS Convention,Dallas, TX, February 13–17, 2005.

DISCUSSION

Our EHR-PH system prototype (Fig.1) supported data exchange between a clinical setting, an external laboratory and public health programs. The approach accommodated multiple external data sources and each participant was the owner/custodian of its data system. These multiple data systems are interoperable through standards and technical linkages thus producing a virtual EHR. The network infrastructure provided securely encrypted transport of data from and to every participant through multiple firewalls so data could be updated/accessed/viewed/integrated as needed with audit tracking of accessions.

This model allows the data to reside at the data source, e.g., Hospital of Birth, Laboratory or Public Health Agency’s registry (Fig.1), to support the workflow at the source, while the network infrastructure allows the data transport and integration without any alteration whatsoever to existing uses. User views can present more limited data requirements for specific uses based on what the specific user needs to see. These requirements are defined in the network infrastructure and should cover the rights and responsibilities of participants to eliminate misuse and abuse of data and information. In the end, EHR is “subtly” achieved by simply converting data to a canonical format and storing it in a RIM-based repository.

Our prototype is based on standards, meets and/or exceeds CDC PHIN requirements and utilizes replaceable modules – each partner could be easily replaced by another technology that performs the same task. Any integration engine capable of transforming HL7 2.X to 3.0 as well as repository are appropriate and can be used. We chose the particular partners and their products as representative examples of each technology to bring the demonstration to life.

Our prototype represents a distributed, federated, decentralized approach, which can, however, be easily converted into monolithic architecture. It combines data from clinical and public health sources that can be extended to all relevant heterogeneous sources, e.g., geographic, environmental, ecological, housing, etc.. It addresses access control and privacy issues and enforces non-repudiation. It is not vendor-specific. It offers framework for true semantic interoperability of local health information systems, whatever they are.

The following lessons were leant from this demonstration. First, the technology and skills to achieve this level of integration are available today . Second, integration to the individual programs/ technologies represents a real burden. We estimated that up to two third of time building this prototype was spent on mapping and integrating data from the “siloed” data sources. Third, standards like Reference Information Model and HL7 3.0 provide a viable solution. However, agreements on common codes and terminologies will bring us even closer to achieving interoperability. As more vendors become skilled in mapping 2.x to 3.0 and finally when products are available that “speak” a common language like 3.0 we will achieve true interoperability between systems with lesser effort while utilizing the same core technology stack (integration engines and repositories).

Our prototype supported the data reporting from HCP to public health agency’s programs. Special attention should be given to defining what public health data and information might be of interest to HCP to enable bi-directional data interchange between clinical and public health settings. These include data interchange for the provision of direct care, e.g., communicating abnormal results of newborn screening to providers and caregivers in a timely manner to coordinate case management activities [6], as well as a provision of the integrated data on the health status of the population in the community that provider serves.[7]

Our prototype can be considered as an EHR-based RHIE/RHIO model - a principal element for a potential technical architecture for a NHIN.[8] The distributed health information network infrastructure approach demonstrated in the prototype places the user and usage at the center of the process rather than the data collection and storage. It takes full advantage of the “silo” platform independence derived from standards of communication and data exchange beyond that of merely transporting data for re-storage. It has the potential to enable and encourage a richer and broader involvement from all healthcare stakeholders as well as vendors, academia, agencies beyond traditional public health, e.g., environmental and housing agencies, and consumers.

With no modification this model also supports most of the CDC PHIN specifications.[5] The future development of the EHR-PH systems should enable the utilization of PHIN Vocabulary Services, PHIN Messaging Service, PHIN Security Standards, and Common CDC Area Module Services. This further illustrates potential synergies between ongoing efforts in data integration in public health, i.e. PHIN, with those underway at the national level, i.e., NHIN and RHIO/RHIE efforts, and speaks to a “perfect storm” of opportunities to truly improve our private and public health systems to the betterment of all.