Electronic Case Reporting and Public Health Agencies: Steps Toward Processing Electronic Case Reports into an Integrated Disease Surveillance System

Monday, June 5, 2017: 4:44 PM
400B, Boise Centre
Justine F. Maxwell , Tennessee Department of Health, Nashville, TN
Erin Holt , Tennessee Department of Health, Nashville, TN
J. Rebecca Early , Virginia Department of Health, Richmond, VA
Timothy A. Powell , Virginia Department of Health, Richmond, VA
Kathy Turner , Idaho Division of Public Health, Boise, ID
Robert Byres , Idaho Department of Health and Welfare, Boise, ID

BACKGROUND: In 2017, state public health agencies (PHA) must declare readiness to accept Electronic Case Reports (eCR) under Stage 3 of Meaningful Use. To fully leverage the benefits of electronic initial case reports (eICR), PHAs must be ready to receive and process the eICRs into their surveillance systems. Tennessee, Virginia, and Idaho agreed to collaborate on the research and implementation for a common integrated disease surveillance system, the NEDSS Base System (NBS).

METHODS: NBS supports eCR functionality through a Public Health Document Container (PHDC) interface. Although NBS PHDC is based on the underlying standard, HL7 version 3 Clinical Document Architecture, it doesn’t represent the more constrained standard of the eICR Implementation Guide (IG) that certified electronic health record technology will generate. Therefore, mapping the PHDC to the eICR is a necessary first step. The collaboration was split into two areas: 1) data mapping, and 2) file translation based on those mappings. Mapping was divided between Tennessee and Virginia and Idaho supported the translation development using Orion Health’s Rhapsody Integration Engine. The HL7 IG for eICR, six eICR sample xml files, and two PHDC sample xml files were used to map PHDC data elements in the Header, Clinical, and Treatment sections to the eICR IG data elements. Because the eICR contains more comprehensive data, PHDC data elements were mapped to the eICR data elements. Two sample PHDC xml files were imported into NBS to evaluate the user interface (UI).

RESULTS: The majority of PHDC Header data elements mapped directly to the US Header in the eICR with a few exceptions. However, data elements in the Treatment Information section mapped to more than one eICR IG template, including the Medications Administered section and the US Header, Component Of section. Some fields in the Treatment Information section of the PHDC xml sample file did not populate in the UI.

CONCLUSIONS: The mapping project highlighted the extent of the differences between eICR and PHDC and the PHDC’s capacity to support the information in the eICR. Mapping the PHDC to the eICR became increasingly complex as the project progressed. Availability of limited PHDC xml samples to map elements to the eICR could yield mappings lacking PHDC data elements; therefore a fully populated xml PHDC schema is needed. Documenting the xpath location for each data element will be beneficial as we use these mappings to write Rhapsody routes for translation and automated processing.