Development of an electronic public health case report using HL7 v2.5 to meet public health needs

Abstract

Clinicians are required to report selected conditions to public health authorities within a stipulated amount of time. The current reporting process is mostly paper-based and inefficient and may lead to delays in case investigation. As electronic medical records become more prevalent, electronic case reporting is becoming increasingly feasible. However, there is no existing standard for the electronic transmission of case reports from healthcare to public health entities. We identified the major requirements of electronic case reports and verified that the requirements support the work processes of the local health departments. We propose an extendable standards-based model to electronically transmit case information and associated laboratory information from healthcare to public health entities. The HL7 v2.5 message model is currently being implemented to transmit electronic case reports from Intermountain Healthcare to the Utah Department of Health.

Introduction

Surveillance of communicable and non-communicable diseases is vital for their prevention and control. For this purpose, every state in the USA has a list of “reportable diseases” which specifies the conditions that are reportable in that state and the timeframe by which the conditions are to be reported.¹ When a reportable disease is identified, clinicians and laboratories are required to report the case to public health authorities. In most hospitals, the responsibility for reporting is delegated to an infection preventionist. The information included in a case report is used: (1) to track disease incidence and identify outbreaks; and (2) to allow public health officials to make informed decisions and implement appropriate control measures to prevent the spread of disease. Hence, the quality and timeliness of control measures depend on the quality and timeliness of the reports. Incomplete or delayed case reports can result in new occurrences of disease that could have been prevented.

The current process for public health case reporting in the USA is paper-based, often inefficient, and involves non-standard case report forms that vary by state. In Utah, the case report forms vary by reporting source. For example, over the past 20 years, one healthcare organization included data fields that were added piecemeal over time as requested by public health, and without any review of the continuing utility of data fields. We found no published literature that describes a systematic assessment of the content of case reports to support public health workflow.

Electronic health records (EHRs) are becoming more prevalent and provide new opportunities for electronic case reporting.² Currently, there is no existing standard guideline for the electronic transmission of case reports from healthcare to public health entities. Recently, there have been national efforts to define the data fields to be included in a case report³ and to develop disease-specific implementation guides using the HL7 Clinical Document Architecture.⁴ While these efforts have informed our research and our research has informed their work, there continues to be a need to develop standard guidelines for electronically reporting any reportable condition using currently implemented technologies. We identified the major requirements for electronic case reporting and propose an extendable standards-based model to electronically transmit case information from healthcare to public health entities.

Throughout this paper, the term “case report” will refer to a report sent from healthcare facilities to public health entities.

Background

The reporting process involves multiple steps including case detection, recognition that the case is reportable, extraction of relevant data, and transmission of case information to public health authorities. In general, the state health department is responsible for routing the data to the local jurisdiction where the patient resides, the local health department initiates case investigation and implementation of control measures, and finally, the state health department is responsible for analyzing and disseminating information to key stakeholders and public health partners. Thus, the timely delivery of complete case reports is a crucial step in the reporting process. The current reporting process is mostly paper-based, involving faxed or phoned reports. Manual processes may suffer from several disadvantages, including delays in reporting, missing faxes, incomplete information in a report, and errors in manual data entry.^{5 6 7}

Electronic systems that transmit laboratory data for reportable diseases to health departments have been implemented in a few states. Electronic laboratory reporting (ELR) has increased the volume (2.3–4.4-fold) and timeliness (3.8–7.9 days earlier) of reporting compared with the traditional faxed reports.^{8 9 10 11} In 2007, research in New York City showed that ELR was more timely and complete than paper-based reporting, but it created new problems in data quality, shifted work demands, and required additional skills for data monitoring.¹² While ELR has the potential to have a positive impact on disease reporting, it should not replace the clinician's responsibility to submit case reports to public health.¹³ There are major disadvantages with ELR-based systems: only diseases diagnosed using laboratory tests are identified; and ELR messages often do not include patient demographics, location, and clinical data that are important for public health surveillance and case management. These drawbacks indicate the need for electronic case reporting.

As the use of EHRs becomes more prevalent in the USA, there are increasing opportunities for electronic case reporting. While an electronic case report may contain laboratory results similar to an ELR message, a case report also includes information about patient demographics, clinical findings, and other relevant data that can be extracted from the EHR. Systems that automate the transmission of a case report are being developed, but currently have limited scope.¹⁴ In 2007, the American Health Information Community selected public health case reporting as a priority area. In 2008, the Office of the National Coordinator for Health Information Technology developed a use case for public health case reporting that focuses on information exchange between a provider's EHR, public health organizations, and laboratories.¹⁵ There are national efforts to standardize the process of case reporting from healthcare settings to local or state public health and from state public health to the Centers for Disease Control and Prevention (CDC). There are guidelines published by the CDC to electronically transmit nationally notifiable conditions from public health entities to the CDC,¹⁶ and there is a standard for ELR.¹⁷ However, there is no existing standard for the electronic transmission of a case report from healthcare facilities to public health entities (figure 1).

Figure 1.

Description of existing implementation guides to support reporting to public health authorities.

In the USA, each state requires that a specific set of diseases be reported to public health authorities by a clinician who diagnoses the condition, regardless of laboratory confirmation. In Utah, there are currently 74 diseases on the list of “reportable diseases”. Since 1985, LDS Hospital has been using automated case detection logic, primarily based on laboratory results, to identify reportable diseases.^{18 19} The case report that is generated includes clinical data extracted from the EHR and supporting laboratory information. The system is currently implemented at 21 Intermountain Healthcare hospitals. Case reports are emailed daily to infection preventionists in each facility. Until recently, the local and state health departments in Utah did not have an information system to receive the case reports electronically. Therefore, the current reporting process at Intermountain Healthcare hospitals involves an infection preventionist printing and faxing the reports to the local health departments or the Utah Department of Health (UDOH).

In Utah, a new law was enacted in 2008 that gives the UDOH the authority to require that standards be used for electronic health information exchange.²⁰ To meet this new requirement and improve the efficiency and quality of case reporting, our goal was to develop a standards-based model for sending an electronic case report from a healthcare facility to a public health entity. There are many steps required to realize the goal of improving the reporting process for reportable diseases. A major step is ascertaining the requirements of a case report from the perspective of local and state public health departments. Therefore, the objectives of the research described in this paper were to: (1) describe public health workflow and identify requirements for the case report to support workflow; (2) specify the content for an electronic case report that meets public health needs and is feasible to extract from the EHR; and (3) model the information for a case report and identify standards for concepts and value sets.

Methods

Workflow analysis

To describe public health workflow and identify requirements for the case report to support workflow, it is important to understand the tasks, data systems, and personnel involved with processing case reports at a health department. Local health departments receive reports of reportable diseases from clinics, laboratories, hospitals, state health departments, and patients. The follow-up of a report at the local health department is a complicated process.

In early 2007 and 2008, we conducted preliminary analyses of the work processes associated with managing a case report. In December 2008, a formal workflow analysis using cognitive task analysis techniques was performed to verify the processes and data needed to support the workflow. We observed the tasks performed by various personnel at Salt Lake Valley Health Department, the largest local health department in Utah. These observations along with several interviews of the nurses and case investigators helped document the workflow associated with processing a case report. The workflow was validated with case managers and surveillance practitioners at the UDOH and Davis County Health Department, a local health department in Utah.

Content analysis

To specify the content for an electronic case report that meets public health needs and can be extracted from the EHR, we used several methods and data sources.

First, we examined the content of the current case reports generated from the Intermountain Healthcare EHR that are faxed to public health. The content of the faxed case report represented the data that can be extracted from the EHR and the information considered essential over the past 20 years that the report has been in use.

Second, in late 2007, we reviewed the set of data fields that were identified for inclusion in a Confidential Morbidity Report formulated by the Case Report Standardization Workgroup led by the CDC and the Council of State and Territorial Epidemiologists (CSTE). One of the goals of the Workgroup was to identify a minimum set of common data elements for electronic case reporting from healthcare providers to public health. While we were in the process of ascertaining the content of an electronic case report, the CDC/CSTE workgroup was also in the process of identifying the set of data elements required for case reporting using input from public health epidemiologists from at least seven states.

Third, we gathered data requirements from public health practitioners from the UDOH and two local health departments (Salt Lake Valley Health Department and Davis County Health Department). The health department personnel were practitioners involved with both case investigation (and management) and surveillance because these two activities involve different workflow and data needs, although they are both dependent on case reporting. We met between July 2007 and August 2008 to review the data fields to be included in the report.

Modeling and value set analysis

To model the information for a case report and identify standards for concepts and value sets, we investigated existing and evolving standards. First, we reviewed the guideline for electronic transmission of nationally notifiable conditions from public health entities to CDC using HL7 v2.5¹⁶ and the implementation guide for electronic transmission of ELRs associated with notifiable conditions.¹⁷ We evaluated the strengths, limitations, and heuristics needed to model the information included in a case report. Second, we reviewed existing standards for their use in the message. In particular, we reviewed Logical Observation Identifiers Names and Codes (LOINC), Systematized Nomenclature of Medicine Clinical Terms (SNOMED CT), and other codes and value sets in Public Health Information Network Vocabulary Access and Distribution System (PHIN VADS). For example, we reviewed the National Notifiable Disease Surveillance System (NNDSS) codes in PHIN-VADS²¹ and the “Dwyer tables”²² used for laboratory case detection, particularly for ELR. This analysis was conducted by a team of collaborators with experience in public health epidemiology, microbiology, and biomedical informatics. We used the CliniClue Browser²³ to map Utah's 74 reportable conditions²⁴ to SNOMED CT (international version 0807).

Results

Workflow analysis

The workflow associated with receiving and investigation of case reports at local health departments can be divided into seven processes.

1. Triage. The triage task begins with the initial receipt of a report. The main goals of triage are to identify the requirement of additional information before the report can be further processed, and to determine whether the case belongs to the jurisdiction to which it has been reported. Cases which are reported to the appropriate jurisdiction proceed to the data input phase. Otherwise, cases are forwarded to the state health department to be re-routed to the appropriate jurisdiction.

2. Initial data entry. If the case was previously reported, the surveillance database is updated with any new information. If the case is new, the data is entered in the surveillance database and the case is assigned a unique identifier.

3. Assignment. The assignment process is a manual process and involves the identification of the responsible investigation team for each case.

4. Investigation. The investigation process involves contact tracing, re-contact with the healthcare system to gather more information, and implementation of control measures.

5. Review. This process involves the review of the case by the Nurse Supervisor during or after the case has been investigated by the nurse.

6. Archive case information. After the investigation is completed and reviewed, the data pertaining to the case are stored in the long-term archive which may be electronic or paper-based.

7. Forward closed cases for state surveillance. All the case reports and relevant documents gathered during the case investigation are sent to the state health department after the case investigation is completed, or during an investigation for selected diseases of acute public health concern.

For an electronic case report to have a direct and positive impact on these work processes, we identified the following requirements:

1. Triage process. (a) Include enough information to allow the correct routing to the appropriate jurisdiction. Information regarding the patient address and the patient telephone number is needed to identify the appropriate jurisdiction. (b) Provide the identification of the primary contact person at the reporting facility so the public health official does not waste time seeking who to contact when additional information is required. (c) Include relevant data needed to assess urgency for case triage. The name of the reportable condition, the relevant laboratory results, and the hospitalization status are the minimum required items of information for case triage.

2. Data entry process. (a) Include the required information to link with any associated laboratory report that may arrive separately from the laboratory. The unique specimen accession number will enable automated linkage and reduce effort and time required to manually review and link records. (b) Provide enough information to link the report with existing reports for the same patient and the same reportable condition. Unique patient identifiers from the reporting facility, the test status, and the unique specimen accession number can be used for the linkage.

3. Assignment. Include the name of the reportable condition to enable the automated assignment of cases to nurses.

4. Investigation. (a) Include additional laboratory results to support the information reported, establish whether the case definition is met, and guide treatment, patient education, and control measures. For selected diseases (particularly hepatitis), the investigator must gather additional laboratory information to meet the above requirements. For this purpose, we recommend reporting all results in a laboratory order with the laboratory test that triggered the event. The transmission of all the laboratory results of the ordered panel will obviate the need for the investigator to manually gather this information and simplifies the selection of additional results to extract from the EHR. (b) Include information about medications ordered or administered so the public health investigator has more information to assess the implementation of appropriate control measures. For example, a nurse investigating a case of a child reported with pertussis will need to know that he has received the appropriate antibiotics and may return to school. In addition, this information will help the nurse investigator prioritize cases that need to be investigated.

Content analysis

We identified six categories of information that should be included in a case report. The categories and the specific content are described in table 1a; an expanded table including definitions can be found in table 1b (available as an online data supplement at http://jamia.bmj.com). Although the content requested by different stakeholders was similar, we found a few differences in the opinions of local and state surveillance practitioners and case managers, and between Utah and national (CDC/CSTE) stakeholders. For example, state public health officials did not want to receive the date/time that a specimen was received in the laboratory; however, this information was requested by local public health officials. Similarly, Utah public health authorities requested the unique patient identifier from the medical record system, but this information was not requested by the stakeholders in the CDC/CSTE workgroup tasked with identifying elements for a confidential morbidity report. Finally, we identified data elements that were currently being included in the case report based on past requests for information, but were no longer needed by public health officials (eg, patient room number, if hospitalized). Thus, it was important to involve all the relevant stakeholders in the process of identifying the content of a case report because they had different information needs based on the tasks they performed.

Table 1a.

Required data elements for electronic case reporting (see additional details in online-only table 1b)

Reporting information	Healthcare provider information	Subject information	Clinical information	Diagnostic information	Medications
Date/time alert created	Provider name	Patient name	Name of reportable condition	Ordering clinician name	Current antibiotics
Date of report to public health authority	Provider phone	Patient address	Date of onset	Ordering clinician phone
Reporting system	Provider address	Patient county of residence	Date of diagnosis	Ordering clinician facility
Reporting facility name	Provider ID	Patient telephone	Hospitalization status	Ordering clinician ID number
Reporting contact's name	Provider facility	Patient age	Admit date	Specimen collection date
Reporting contact's phone		Patient date of birth	Admit diagnosis	Test status
Facility phone number		Patient gender	Room number	Source of specimen
Facility address		Ethnicity	Unique patient ID	Test name/detection method
Reporting Contact's email		Race	Medical record number	Test result and comments
Reporting contact's address		Occupation	Encounter number	Lab order accession number
		Pregnancy status of patient	Facility associated with encounter number	Reference range
			Hospital service	Abnormal flags
			Previous admission date	Date of test
			Previous discharge date	Specimen received in lab date/time
				Laboratory name
				Date/time results reported to the ordering provider

Modeling and value set analysis

We used HL7 version 2.5²⁵ to transmit case reports from healthcare to public health entities because this was the latest version in use at the time this project was initiated. This version was acceptable to the Information Technology team at the UDOH who were required to develop the interface to receive the reports. We recommend that the following segments be included in the message structure of an electronic case report: Message Header Segment, Patient Identification, Patient Visit (PV1), Observation Request (OBR), and Observation Result (OBX). A detailed description of the required data elements in a case report with their positions in the HL7 v2.5 message is given in table 1b. This mapping was done using the HL7 v2.5 messaging standard protocol²⁶ by a team of investigators with experience in developing HL7 interfaces and biomedical informatics.

We adopted elements from the guideline for the electronic transmission of nationally notifiable conditions.¹⁶ This guideline addresses the transmission of data from state public health entities to CDC and does not include patient identifiers such as patient family name, patient telephone number, reporting contact etc. It also does not include the patient healthcare system encounter (visit) information and hence does not use the PV1 segment (which we recommend). However, the guideline for national reporting advocates the use of multiple OBR segments to transmit various categories of information. We adopted the Notification Type Identifier (NOTF) and the Associated Laboratory information Identifier (LABRPT) segments used in the national guideline, and hence the message structure we propose includes two OBR segments. Figure 2 illustrates a skeleton of the message structure.

Figure 2.

Key concepts in the proposed message structure.

The first OBR segment (defined as “NOTF” in OBR.4) and its associated OBX segments are used to transmit clinical and other information about the case that is not already included in the HL7 v2.5 Message Header Segment, Patient Identification, PV1, and the new “LABRPT” OBR segment. HL7 recommends transmitting such unspecified observations in OBX.3 using LOINC and the values in OBX.5. While mapping observations to LOINC, we found that certain observations, such as reporting contact's name and phone number do not currently exist in LOINC. We have requested new LOINC codes for these observations. In addition, we found that selected relevant LOINC concepts (eg, date of diagnosis) were specific to cancer. We recommend that LOINC make selected concepts usable across disease categories and also include LOINC codes for concepts relevant to reportable condition reporting.

The second OBR segment (defined as “LABRPT” in OBR.4) and its associated OBX segments are used to transmit laboratory information. This segment mirrors the structure of laboratory information sent in ELR, including the use of LOINC codes in OBX.3 for laboratory test names, and the use of SNOMED CT codes in OBX.5 for test results when appropriate. We include the specimen accession number in the “LABRPT” OBR segment to enable linkage of the case report to the related ELRs arriving separately from the laboratory. Figure 3 shows the structure for OBR segments in the proposed message structure.

Figure 3.

Details of the structure for observation request (OBR) segments in the proposed message structure.

To establish a standard value set for the “name of the reportable condition”, we reviewed several code sets and identified their strengths and limitations for use for the value set of reportable conditions. Some of the important features of an appropriate code for the “name of reportable condition” in a case report are: (1) the concept should be unique; (2) the concept should represent a reportable condition by meeting the case definition; and (3) the concept must represent clinical diagnoses expected in a case report. The requirements for controlled medical vocabularies have been addressed in recent years.²⁷

We assessed the NNDSS codes in PHIN-VADS,²¹ and found that the codes represent the case definitions for conditions tallied for state-based surveillance and for transmission to the CDC, but not the clinical diagnoses expected in a clinical record. In addition, the NNDSS codes represent nationally notifiable conditions and do not currently include conditions that are not nationally reportable. For example, it does not include “influenza-associated hospitalizations” which are reportable in Utah. When we assessed the “Dwyer tables”, we found a table of LOINC to NNDSS mappings used for laboratory case detection. The “Dwyer tables” map a single NNDSS condition to multiple LOINC concepts that represent the various laboratory tests that may be used. The NNDSS codes have the problems already described, and the LOINC mappings only represent single laboratory tests, and thus are not useful for representing conditions based on clinical findings or a series of laboratory tests. The features of the “Dwyer tables” do not meet the requirement that the electronic case report include one unique code for each reportable condition. Hence, we concluded that concepts from the current “Dwyer tables” would not be appropriate for the value set of reportable conditions in the electronic case report.

Next, we assessed SNOMED CT (international version 0807) for its efficacy in standardizing the “name of the reportable condition”. An appropriate code for a single reportable condition is defined as one where the concept and its children reflect the case definition for the reportable condition. We used CliniClue Browser²³ to identify SNOMED CT codes for Utah's 74 reportable conditions (see table 2a for “immediately reportable conditions”; a more detailed version for all reportable conditions, table 2b, is available as an online data supplement at http://jamia.bmj.com). SNOMED CT is useful because it represents clinical diagnoses and we were able to identify appropriate codes for 60 (81%) of the 74 reportable conditions in Utah. However, we found the following issues while mapping the remaining 14 reportable conditions. First, some of the existing concepts do not meet the case definition and do not represent reportable conditions because non-human conditions are included as children in the hierarchy. For example, the current code for campylobacteriosis includes “porcine intestinal adenomatosis”, an animal disorder. Thus we recommend that there be SNOMED CT codes and hierarchy specific for human disorders. Second, there are no codes for some reportable conditions (eg, hepatitis F). We recommend that new codes for the missing conditions be created. Third, certain reportable conditions (eg, typhoid, botulism) are represented by multiple SNOMED CT codes. For a case report to be useful for public health case management and surveillance, it needs to include a single code per reportable condition. The reportable condition for typhoid includes both typhoid infection and typhoid carriers because they require similar public health response and follow-up. Currently, there are two separate codes for typhoid infection and carrier. We recommend that there be a new parent code to represent either infection or a carrier (eg, typhoid infection or carrier) and that the existing infection and carrier codes be included as its children. Similarly, the reportable condition for botulism includes two codes: one code is currently under the parent “clostridial infection”, and the second code is currently under the parent “poisoning”. We recommend that SNOMED create a new code for botulism that includes these existing codes as children.

Table 2a.

SNOMED CT (international version 0807) codes identified for immediately reportable conditions in Utah (see additional details in online-only table 2b)

Immediately reportable conditions
Utah's reportable conditions	SNOMED code	Utah's reportable conditions	SNOMED code	Utah's reportable conditions	SNOMED code
Anthrax	409498004	Meningococcal disease	23511006	Staphyloccus aureus with resistance (VRSA) or intermediate resistance (VISA) to vancomycin isolated from any site	406577000
Botulism	No appropriate code found	Plague	58750007	Syphilis	76272004
Cholera	63650001	Poliomyelitis (paralytic)	240460008	Tuberculosis	No appropriate code found
Diphtheria	397430003	Rabies (human and animal)	14168008	Tularemia	19265001
Haemophilus influenzae (invasive disease)	406583002	Rubella	36653000	Typhoid (cases and carriers)	No appropriate code found
Hepatitis A	25102003	Severe acute respiratory syndrome (SARS)	398447004	Viral hemorrhagic fever	240523007
Measles (rubeola)	14189004	Smallpox	67924001	Yellow fever	16541001

SNOMED CT, Systematized Nomenclature of Medicine Clinical Terms.

In summary, after a review of the above potential code sets, we determined that the use of SNOMED CT would be the most appropriate value set to transmit the “name of the reportable condition” in OBR.31 of the “NOTF” segment. We have submitted our recommendations to SNOMED CT to improve the utility of the codes as a value set for reportable conditions in a case report.

Discussion

Increasing use of EHRs provides an opportunity to improve and automate case reporting, a process that is currently paper-based, inefficient, and often not complete and timely.^{8 9 10 11} Our research addressed the gap in standardized guidance for the electronic transmission of case reports from healthcare to public health entities. Through stakeholder input and assessment and verification of public health workflow, we identified major requirements for electronic case reporting and propose an extendable message model using HL7 version 2.5, LOINC, and SNOMED CT codes. We specified the content for an electronic case report that meets public health needs and is feasible to extract from an EHR. The data requirements address: (1) the initial data needed by public health for the purpose of case investigations and implementation of control measures; and (2) the addition of unique identifiers for the patient and triggering laboratory reports to support automated workflow. These findings are new and go beyond the information typically requested by state public health officials. We have developed an implementation guide for case reporting²⁸ using HL7 v2.5 that can be adopted by other healthcare and public health entities that want to electronically transmit public health case reports.

The HL7 version 2.5 implementation guide we developed has several strengths. First, it supports electronic information exchange and the automatic population of the surveillance database without the need for manual data entry. In contrast, the paper-based reporting process may involve reporting delays, missing faxes, incomplete information in a report, and errors in manual data entry.^{5 6 7} Second, HL7 version 2 interfaces are widely used in healthcare and public health agencies. Therefore, there are existing technical and human resources available to implement a version 2.5 message guide. Third, the implementation guide we developed can be used for any current or future reportable condition and is not disease specific. The name of the reportable condition included in the message should be transmitted using SNOMED CT, but the message can also handle human readable local codes. In contrast, the implementation guides developed using HL7 version 3 Clinical Document Architecture (CDA) are disease specific⁴ and do not currently handle reporting of a previously unspecified condition. Moreover, version 3 interfaces are more complex and not routinely implemented in public health and healthcare settings in the USA. Fourth, the version 2.5 message model we propose can be implemented today and can be modified to include a CDA payload in an OBX segment if reporting facilities have the capability to send CDA-based reports. Fifth, the message guide fulfills the requirements of a new state law for standardized health information exchange.²⁰ Utah Health Information Network, a Utah-based Standards Development Organization, is reviewing the implementation guide for adoption by providers reporting to public health in Utah. The review and adoption process will include input from all Utah Health Information Network member organizations, including stakeholders from multiple healthcare organizations. Therefore, the message guide will be enhanced as needed and represent a practical solution that can be implemented today.

The research findings and the HL7 version 2.5 implementation guide we developed have limitations. First, the HL7 messaging standard is not simple to implement and maintain. However, it is the most widely used medical messaging standard in the USA and several other countries. In addition, HIPAA mandates the use of HL7 v2.2 or later versions to exchange medical data.²⁹ Second, the workflow observations were conducted in only one local health department. However, we validated the workflow findings with the personnel at a second local health department. Third, the content analysis we performed involved personnel from two local and one state health departments in Utah. While this may appear to limit generalizability of the results, we compared our findings with the content defined by the CDC/CSTE workgroup for a confidential morbidity report. We identified the same data fields with the exception of a few additional data fields (eg, unique patient identifier). Fourth, the HL7 message structure we developed does not use the most current version today (May 14, 2009). However, standards continually evolve and it is always necessary to select a reasonable version; at the beginning of the project version 2.5 was the latest version available. Fifth, the HL7 v2.5 messaging standard is based on an implicit information model, not an explicit one. Also, v2.5 does not specify the terminology to be used in specific messages, which leads to multiple ways to implement the same message. Version 2.5 is also based on a “vertical bar” or pipe-delimited format which is not industry standard and does not integrate well with XML tools and the internet. Sixth, we do not use all currently available HL7 version 2.5 segments. For example, previous admission and discharge dates are being sent as OBX segments rather than using PV2.14 and PV2.26, respectively. For the next phase of the project, we will include the PV2 segment in the message structure to transmit information about previous admission and discharge date. Seventh, the use of the implementation guide requires that the healthcare facility and the public health entity have the infrastructure to send and receive HL7 messages. Finally, the content of the case report is not as comprehensive as that proposed for the development of CDA-based case reports, but the implementation will be sooner and does not prohibit the co-development of CDA-based implementation guides. Similarly, the current content of the case report model we developed does not include all the fields included in the proposed position statements for each individual disease designed for national surveillance.³⁰ However, the model can be extended to include other observations and represents the key information requested by public health that is currently capable of being extracted from an EHR.

Current status of implementation

Pilot testing of the implementation guide is being conducted between Intermountain Healthcare and the UDOH. The case reports are sent via Intermountain Healthcare's secure interface eGate; the UDOH has developed the required infrastructure to receive the reports. Between December 2008 and April 2009, the interfaces were under development and testing. The cost to develop the format is estimated to be $5000 and the cost to build the parser is around $16 000. However, this is just the cost to program, debug, and test the case reporting HL7 messages. The parser that was developed relied on a previously developed parser engine at a much higher cost.

By May 14, 2009, over 900 unique cases (daily average: 15 case reports) have been sent from two Intermountain Healthcare hospitals to the UDOH. Unit testing is currently underway to ensure that the data fields are being sent and received correctly in the HL7 v2.5 messages. To validate the messages sent from Intermountain Healthcare to the UDOH, we evaluate the content and format of the messages by comparing the data at Intermountain Healthcare prior to HL7 message translation with the HL7 message data received at the UDOH. We conduct this QA process every 3 months for a week. Our findings are shared with IT teams at Intermountain Healthcare and UDOH and after the corrected messages are put in production, we repeat the QA test.

We will also evaluate the timeliness and completeness of the electronic system compared to the current paper-based system. The current manual reporting process will continue until the evaluation is completed and electronic case reporting has become an integral part of the statewide electronic surveillance system and public health workflow. The infrastructure to integrate the electronic case reports with the new statewide electronic public health surveillance system (UT-NEDSS) and use the data for real-time public health surveillance is underway. We will evaluate the impact of the electronic transmission of case reports on the workflow at the local and state health departments.

Conclusion

We have identified the major requirements for an electronic case report transmitted from healthcare to public health entities. We have also developed an extendable standards-based model using HL7 v2.5 that can be adopted by other healthcare facilities wanting to transmit case information and associated laboratory information to public health. It is expected that the use of this model will have a positive impact on public health surveillance in Utah.