Humphrey's Building
200 Independence Avenue, S.W.
Washington, D.C.
Presentation By:
J. Marc Overhage, MD, PhD
Associate Professor, Indiana University School of Medicine
Investigator, Regenstrief Institute for Health Care
Indianapolis, IN
Telephone: 317-630-8685
Facsimile: 317-630-6962
E-mail: moverhage@regenstrief.org
I am sorry that I was not able to appear in person and I appreciate the committee allowing me to participate by telephone.
My name is Marc Overhage and I am an Associate Professor of Medicine at the Indiana University School of Medicine and an Investigator at the Regenstrief Institute for Health Care. I am going to comment today on our experience using the HL7 message standard over the last thirteen years at Wishard Memorial Hospital and the last six years implementing a citywide electronic medical record. Researchers from the Regenstrief Institute organized the ASTM1238 standard committee that was a basis for the HL7 standards in the late 1980s and we have been intimately involved in using and evolving HL7 since then.
We call the citywide project the Indianapolis Network for Patient Care or INPC. The INPC currently connects eleven hospitals from five competing health systems, a large primary care practice, the homeless care network and the county and state health departments. These hospitals provide over 95% of all the inpatient and emergency department care in the Indianapolis Metropolitan Statistical Area as well as a significant fraction of the outpatient laboratory and radiology services. We receive laboratory result data and most of the encounter data in HL7 format directly from the hospitals’ operational systems. In addition, we receive a large variety of data from specific hospitals including:
Should have said something about the kinds of messages used.
Other data such as emergency department logs that we do not receive as HL7 are converted to HL7 and processed for storage using the same systems as are used for data that arrives natively in HL7. We currently process approximately a quarter of a million HL7 messages daily and have processed well over 100 million in total.
As you can imagine we must accept a variety of variations on the HL7 standard with the vast majority of the messages conforming to version 2.2 but we find some version 2.1 and 2.3 as well. The addition of richer data types such as the XPN or extended Person Name in more recent versions has extended the functionality of the standard.
We also use the DICOM standard to receive and process radiographic (conventional radiographs, CT, MRI and ultrasound) and soon echocardiographic and gastroenterologic images as well. The software links these images to the reports describing them and can be retrieved and manipulated using a web based image viewer built into the electronic medical record. We have not adopted the structured reporting functionality of DICOM choosing instead to use HL7 to transmit these results.
We took advantage of the “plug and play” compatibility provided by HL7 to add an electronic laboratory reporting function for public health to the INPC. The ELR system capitalizes on the existing HL7 message processor that reads each message, parses out it’s separate components and then determines whether the result reported might contain evidence of a reportable condition. If the result might carry evidence of a reportable condition, the software places a copy of the HL7 message into another message queue that a reportable condition processor services. This processor assumes that messages are well formed and that the result codes will all be represented by LOINC codes. The software uses the CSTE-CDC or Dwyer tables that define reportable conditions based on LOINC codes of tests that indicate the presence of the condition. We have been identifying and storing reportable conditions in real time for over three years using this approach. These data are available to the county and state health departments for use in case finding and surveillance. Ongoing evaluation studies indicate that we identify cases sooner and more completely than traditional reporting methods. We believe this system demonstrates important components of the NEDSS or National Electronic Diseases Surveillance System project underway at the CDC.
The HL7 and DICOM standards have worked well as a foundation for building a community wide electronic medical record. We chose HL7 for the INPC project for several reasons. First, and most compelling, nearly all clinical computer systems in use can send data as HL7 messages -- it is the most widely supported message standard for the exchange of clinical information between computer systems. In a 1998 survey of hospital CIOs 80% reported that they use HL7 now and 13% more expected to do so in the near future. Second, we can easily map the message content into the INPC’s information model. The fields contained in HL7 messages all have clear semantic “homes” in the INPC’s databases. This degree of compatibility arose partly because the information model and the HL7 message standard have evolved in parallel. Third, we can use a single set of monitoring and control functions for management of the data flows. Fourth, HL7 allows the integration of standard vocabularies/codes. Finally, performance is acceptable. With today’s computing hardware, systems can process the large volumes of HL7 messages that are created in a large integrated delivery system or, as the INPC demonstrates, over an entire community.
The messages created by clinical computer systems do not all conform to the HL7 standard completely. We have managed this variability by inserting message pre-processing software into the stream that modifies the message to better conform to the HL7 standard. The most common variance encountered is that the data are not placed in the proper HL7 field. For example, the units, normal ranges and results will each be sent as a separate HL7 OBX. Alternatively, the OBX-3 field that is designed to carry the actual result will have not only the result, but the normal range, units, an interpretive comment and information about where the test was performed. These problems seem worse when other systems pass the data through. Fairly well formed messages sent from a reference laboratory, stored in a laboratory information system and forwarded to a clinical data repository such as the INPC often become less well structured in the process. In recent years, we have observed, however, that the HL7 messages created by the clinical computer systems are beginning to conform more closely to the standard requiring less pre-processing. Further efforts to educate software developers and vendors on the proper way to implement the standard will accelerate this process. The HL7 Version 3 Reference Information Model or RIM will help ensure that developers create HL7 messages that conform to the standard by providing a clear description and precise definitions.
In summary, we have been able to create a community wide electronic medical record system using HL7 as the primary message standard. HL7 has proven to be a workable choice for information exchange in this very heterogeneous environment and along with DICOM and Internet standards such as JPEG, MPEG and TCP/IP provides for all of our current and anticipated needs. We expect to evolve to HL7 version 3.0 as the developers of commercial clinical information systems are able to develop and deploy that capability but there is no reason to wait until version 3.0 is available to start taking advantage of the strong functionality provided by the current versions.
Thank you for this opportunity to share our experiences. I hope you will found it usefulluseful.