Background:
This document describes a plan for electronic data transfer of reportable diseases, i.e., electronic laboratory reporting (ELR), from Chicago hospitals to CDPH. To successfully implement a regional system for electronic laboratory reporting, three elements are necessary: standardized software that applies reportable condition business logic to local hospital data, appropriate hardware and network connectivity to ensure reliable data storage and transfer, and the willingness of local HIS departments to participate in the project.
Software Development:
Appropriate software is necessary to transform local hospital laboratory and microbiology data into a desired data set format for CDPH. While each hospital may be able to develop its own solution for filtering and transforming data into formats required for electronic laboratory reporting, the time and personnel costs associated with individual solutions may limit the implementation of ELR in Chicago. Therefore, we describe a single ELR software package that will be used in all interested hospitals. The objective of the ELR software package is to interface with a variety of data formats and transform them into HL7 2.3.1 compliant format based on city specifications. In addition, the program searches microbiology and laboratory data, adds historical data, and merges demographic information from Admission, Discharge and Transfer data. Finally, the software is modular with the ability to add or remove condition specific logic modules or other modules without modifying the existing software.
Technical Approach:
The ELR Solutions Interface Development Team represents a group with diverse skill sets, and includes informaticists and clinicians. The project team will be managed by a project manager, and a medical informaticist, and project manager at CDPH. A project plan for year 1 is described in section E. Requirements for data sources and fields for ELR are listed in section C.e. Individual participating hospitals will be given latitude to decide on appropriate data feeds for use in the ELR interface.
High Level Plan:
Each participating hospital will be asked to provide an extract of data from their microbiology, laboratory, and ADT registration systems. Data can be provided as continuous (via TCP/IP) or batched HL7 data streams, through direct database connections to data marts or static databases (i.e., using ADO.NET or ODBC), or as reports with a pre-specified data structure (i.e., tab-delimited, comma-separated, or other delimiters).
Each participating hospital will be provided a server, if desired, with relevant software installed.
The package will consist of 6 components. These components will be developed in .NET 3.0 and T-SQL, running in Microsoft SQL Server 2005.
Component 1, the data receiver, will be able to accept multiple source data formats (HL7 messages, text files, and direct database connections) and write these data to an onsite local hospital data mart. Component 1 will be designed to allow receipt and translation of any HL7 2.x message.
Component 2, the data translator, will use translation tables to convert local data formats to standard vocabularies as required by ELR (i.e., LOINC and SNOMED).
Component 3, the condition specific logic application, will apply the business logic for ELR reportable conditions to data stored in the local hospital data mart. Each reportable condition will be hard coded as an individual component that can be added to a generic application. Future changes to existing condition reporting, or newly developed reportable conditions, can be accommodated by changes to the condition reporting components.
Component 4, the HL7 parser, will create HL7 2.3.1 messages as described in the city specifications for ELR. These messages will then be forwarded to the city ELR databases using the CDPH choice of data transport, which currently is SSL encrypted https.
Component 5, the acknowledgement file processor, will automatically retrieve and assess the acknowledgement file produced by the ELR system, and allow error correction and batch resending.
Component 6, Help file, will be an html help file that provides detailed guidance for all the above 5 components.
User interaction with the six components above will be integrated into one graphical user interface. For example, using toolstrip buttons that reside on a launch bar, the user will be able to configure and schedule inbound messages, configure and schedule outbound messages, configure the data translator, start the application, stop the application, and launch the help document. The receiver component (component 1) will operate as a windows service and reside in memory, while other components will be executed on demand as scheduled tasks.
Equipment and Networks:
To assure the reliability of such software, designated hardware is necessary at local hospitals. Standardized hardware will help to process large data inflows, allow conditional logic processing, and standardize the installation and configuration of software and databases.
Hardware configuration will be site-specific. Each partner hospital can use a server provided at no charge by the CDPH, if desired. Alternatively, server space may be provided by the partner hospital, provided it meets minimum specifications required for the application. Servers must use the MS Windows Server 2003 operating system and Microsoft SQL Server 2005 database. An example of required hardware specifications is the Dell PowerEdge Energy Smart 2950 with 300 GB storage. This hardware will become part of local HIS systems and should be maintained by each local HIS (i.e., antivirus and updates to operating system); the estimated time for maintenance will be 100 hours annually.
Local HIS/Stakeholder support and cooperation:
Finally, the project will not succeed without local HIS cooperation. To increase the probability of success, we propose minimizing use of local hospital resources by providing hospitals with a product that requires minimal setup and limited ongoing maintenance costs. Providing hardware and ELR software will limit the obligations of hospitals to extracting data from their system and maintaining hardware. All other components of ELR should be overseen by CDPH and/or our team of information technology experts, including changes to reporting requirement, and changes and updates to the application.
Data Feed Specifications (Required Field List):
The following are fields of interest for messages sent to the ELR Application:
Hospital specific information
- Hospital Name
- Hospital ID # (i.e., CLIA number)
- Hospital ID # system (i.e., "CLIA")
- Ordering Facility Name
- Ordering Facility Address
- Ordering Facility Phone Number
- Receiving Application Name (CHESS)
- Receiving Application Facility (CDPH)
- L7 version (2.3.1)
ADT data table
- Patient ID number (i.e., patient and visit numbers)
- Admission Date
- Last Name
- First Name
- Patient Alias
- DOB (YYMMDD)
- Sex
- Race
- Address – Street
- Address – City
- Address – State
- Address – Zip
- Patient Home Phone Number – area code + number
- Patient Work Phone number – area code + number
- Ethnic Group
- Birth Place
- Patient Death indicator
- Patient Death datetime
- Multiple Birth Indicator
Microbiology Data
- Patient ID number (i.e., patient and visit numbers)
- Order Accession Number(s)
- Ordered Test Name
- Specimen source Name
- Organism Name
- Antibiotic Name
- Antibiotic Susceptibility Interpretation
- Antibiotic MIC Value
- Units
- Admit Date
- Order date
- Collect Date
- Receive date
- Plate Date/Lab Process Date
- Result Date
- Final Date
- Result Status
- Ordering Provider Last Name
- Ordering Provider First Name
- Ordering Provider Title (MD etc)
- Ordering Provider ID#
- Ordering Provider Phone Number (area code + number)
- Abnormal Flag
Laboratory Data
- Patient ID number (i.e., patient and visit numbers)
- Order Accession Number(s)
- Ordered Test Name
- Specimen source
- Result
- Admit Date
- Order date
- Collect Date
- Receive date
- Lab Process Date
- Result Date
- Final Date
- Result Status
- Ordering Provider Last Name
- Ordering Provider First Name
- Ordering Provider Title (MD etc)
- Ordering Provider ID#
- Ordering Provider Phone Number (area code + number)
- Abnormal Flag
- Units
- Reference Range
The simplified schematic below represents the data flow that occurs after ELR implementation. The ELR application installed on the ELR server extracts and sends only data mandated to report to CDPH. To allow for the most complete data capture mandated for reporting purposes, data transferred to the local ELR server are stored for up to 90 days.
For more information on the ELR Interface Application please review the Project Documentation.
