|Home | About | Journals | Submit | Contact Us | Français|
Electronic laboratory interfaces can significantly increase the value of ambulatory electronic health record (EHR) systems by providing laboratory result data automatically and in a computable form. However, many ambulatory EHRs cannot implement electronic laboratory interfaces despite the existence of messaging standards, such as Health Level 7, version 2 (HL7). Among several barriers to implementing laboratory interfaces is the extensive optionality within the HL7 message standard. This paper describes the rationale for and development of an HL7 implementation guide that seeks to eliminate most of the optionality inherent in HL7, but retain the information content required for reporting outpatient laboratory results. A work group of heterogeneous stakeholders developed the implementation guide based on a set of design principles that emphasized parsimony, practical requirements, and near-term adoption. The resulting implementation guide contains 93% fewer optional data elements than HL7. This guide was successfully implemented by 15 organizations during an initial testing phase and has been approved by the HL7 standards body as an implementation guide for outpatient laboratory reporting. Further testing is required to determine whether widespread adoption of the implementation guide by laboratories and EHR systems can facilitate the implementation of electronic laboratory interfaces.
The use of Electronic Health Record systems (EHRs) in small physician practices remains relatively uncommon. 2–4 Although various barriers to EHR adoption exist, 5,6 observers have identified the major technical barrier as the absence of widely adopted and effective data standards for interoperability. 5–8 Interoperability is important to EHR adoption because the ability to conveniently send and receive clinical data is among the key benefits of “digitizing” health information management. 9 Among the most important applications of interoperability in the outpatient setting is the reporting of laboratory test results. Office physicians spend an average of 74 minutes daily managing laboratory results, and most physicians are dissatisfied with their current paper-based processes for handling laboratory data. 10 Electronic data management can save physicians (and their staffs) time, avoiding paper-based routing, filing, and retrieving of laboratory results. Electronic data also allows easier review of laboratory results via search, flow chart, and graphing functions that are provided by many EHRs. Practicing physicians have cited the ability to import and display laboratory results electronically as one of the most desirable, 11 frequently used, 12 and productive 13 features of ambulatory EHR systems. Beyond convenience, the computer-aided management of laboratory-result data (via “decision support”) is also important for patient safety and quality improvement. The EHRs receiving digitized laboratory results can alert physicians to significant abnormal values, 10 suggest needed laboratory tests when medications are prescribed, 14 and support adherence to preventive screening and disease-management guidelines. 15–17 One study indicated that use of an EHR, per se, does not improve the quality of care in the absence of appropriate decision-support capabilities. 18
Many practices with EHRs, however, cannot realize the benefits enabled by electronic laboratory reporting. A small informal survey conducted by the primary author indicated that many practices that use EHRs lack electronic interfaces (such as those based on HL7 1 ) with their laboratories (see ). Further, small practices may be especially disadvantaged in this regard because laboratories are less likely to develop custom interfaces to EHRs in small practices, 5 which provide less testing volume to offset the expense. Also, small practices generally have fewer resources to finance the customization required to interface their EHR to a laboratory (cost range U.S. $3,000–$15,000). 19,20
The challenge of developing custom laboratory interfaces is compounded by fragmentation among the markets for laboratory services and EHR systems in the United States. The United States Department of Health and Human Services has certified 8,680 hospital laboratories, 5,400 independent commercial laboratories, and 6,500 clinic laboratories to perform testing. 21 At least 35 different laboratory information systems (LISs) are used by laboratories in the United States. 22 In addition, many practices receive test results from multiple laboratories, necessitating multiple interfaces.
Conversely, between 200 and 350 vendors offer ambulatory EHR products in the United States. 19,23,24 Hence, potentially thousands of pairwise interfaces may be required between ambulatory EHR products in physician offices and LIS products in clinical laboratories. In the absence of effective interoperability standards that are widely supported by LIS and EHR products, many of these interfaces will require custom implementation at substantial effort and cost.
In general, four steps are required to implement a laboratory-to-EHR interface 25 :
A highly constrained messaging standard that is supported by most EHR and LIS vendors could greatly reduce the ad hoc negotiation, documentation, and implementation tasks associated with step 3. Although many lab information systems and ambulatory EHR products support the existing HL7 version 2.x messaging standards for laboratory reporting—specifically, the “Observation Report—Unsolicited” (ORU) message type− 26 this standard has not sufficiently reduced the effort inherent in developing laboratory-to-EHR interfaces. One reason for this shortcoming is the extensive optionality within the HL7 standard, a characteristic noted by other developers of HL7-based interfaces. 27
The optionality of a message standard can be characterized as the number of data elements within the standard that are designated as “optional”, i.e., that may either be populated or left NULL in a conformant message instance. The ORU message type in HL7 version 2.5.1 includes 4,132 data elements, counting all the segments, fields, components, and subcomponents (primary author's analysis). Of this total, 3,468 data elements (85%) are designated as optional. A practical significance of a message standard's optionality is that it increases the number of data elements that interoperating partners must consider, agree upon, and implement identically to build a functioning interface based on the message standard. Greater optionality, therefore, can increase the time and effort required to complete steps 3 and 4 of the interface-development process. If many of the optional data elements are never needed or always required for a very specific type of communication (such as the reporting of laboratory results to ambulatory EHRs), then the effort of steps 3 and 4 could be theoretically reduced by defining a subset of the standard for use in that type of communication.
Past recognition of this opportunity has led to the definition of previous HL7 “implementation guides” for laboratory messaging. 28–31 However, none of these implementation guides has been specifically designed for the reporting of laboratory results to ambulatory EHRs in the United States. The project described in this paper sought to develop an HL7 implementation guide that greatly minimized optionality while effectively supporting ambulatory laboratory reporting in the United States.
In 2005, the California HealthCare Foundation 32 convened a technical work group to facilitate outpatient laboratory reporting to EHRs. The group consisted of fifteen representatives from ambulatory EHR vendors, clinical laboratories, physician organizations, government agencies, and HL7. 33 The group embarked on this work guided by the following goals and design principles:
The work group proceeded by reviewing the HL7 version 2.4 and 2.5 ORU message types to define the minimum set of data elements that were generally required for ambulatory laboratory reporting, i.e., the smallest subset of data elements from the HL7 ORU message type that could convey all the technical, clinical, and regulatory information needed for electronically reporting outpatient laboratory results to an EHR. The group also determined the maximum degree of standardized structure and coding that could be widely supported by the participating stakeholders. Often, the group had to weigh the expressed needs of EHR systems for structured and coded data against the near-term capabilities of clinical laboratories to provide such data, often compromising to arrive at a specification that was both useful and broadly implementable. For example, the group agreed to require Logical Observation Identifiers Names and Codes (LOINC) 37 as the identifiers for most tests, but chose not to require the reporting of cultured organisms using SNOMED-CT codes because the participating laboratories indicated that a transition to SNOMED-CT required much greater changes to their systems and processes.
After meeting via teleconferences and in person for a period of 4 months, the group published the EHR-Laboratory Interoperability and Connectivity Specification (“ELINCS”) version 1.0. 34 Over the following two years, the group completed two additional versions. The most recent version was approved and published by HL7 in Jul 2008 as an informative implementation guide for laboratory result reporting in ambulatory care. 35
The HL7 has an optionality of 227 data elements, 93% fewer than that of the standard HL7 ORU message type. The ELINCS work group achieved this significant reduction by designating as “not supported” (prohibited) all optional elements of the ORU message type that it deemed unnecessary or not widely supported by laboratories and/or ambulatory EHRs. These elements included segments containing information already known to or not clinically relevant to the ordering clinician (such as “Next of Kin”, “Patient Visit”, and “Financial Transaction”), fields containing order-related information not useful in laboratory results (such as “Order Callback Phone Number,” “Charge To Practice”, and “Transport Logistics of Collected Sample”), and field components not widely supported by ambulatory EHRs or laboratories (such as “Name Assembly Order”, “Address Validity Range”, and “Code Identifying the Check Digit Employed”).
The work group further reduced optionality by changing the designations of many remaining data elements to “Required” (i.e., they must always be populated), “Required but May Be Empty” (i.e., they must be populated if the laboratory has the data), or “Conditional” (i.e., they must be populated if certain other data elements are populated). For example, the work group designated the field “Performing Organization Name” (OBX-16) as required, because the federal Clinical Laboratory Improvement Amendments (CLIA) regulations require all laboratory reports to specify the laboratory at which the test was performed. 36
The complete ELINCS implementation guide appears in the online appendix and is available from Health Level Seven Inc.
The project team also imposed additional structure and coding constraints on certain of the remaining data elements:
Given the dramatic reduction of optionality in the ELINCS implementation guide through the prohibition of many data elements in the HL7 ORU message type, it was important to determine whether the remaining data elements were sufficient to report laboratory results to ambulatory EHRs in practice. In 2005, six health care organizations, five EHR vendors, and seven clinical laboratories participated in pilot implementation projects based on ELINCS version 1.1 (an earlier but very similar version of the implementation guide described above). lists the participating organizations and implementation projects on which they collaborated. The goals of these projects were to determine 1) whether the defined specification allowed the communication of all necessary information for laboratory reporting in the ambulatory setting, and 2) whether multiple laboratory and EHR systems could technically implement the specification. These goals represented the lower threshold of practical utility for the ELINCS implementation guide.
Following a twelve month testing period, the pilot implementations yielded the following findings:
Some noteworthy lessons emerged from the development and early testing of the ELINCS implementation guide.
The limited scale and duration of the pilot implementations precluded testing whether the adoption of ELINCS as an industry standard could significantly reduce the effort and cost of building laboratory-reporting interfaces. Indeed, there were likely no such savings during the pilot implementations because all participants were implementing the ELINCS implementation guide for the first time. Efficiencies may be expected only when interfaces are implemented between systems that already support the ELINCS implementation guide.
Also, the limited scale of the pilot implementations could not demonstrate conclusively that the ELINCS specification retains sufficient optionality to support all ambulatory laboratory-test reporting. Additional implementations involving other health care organizations, EHR systems, and clinical laboratories are required to make this case or to identify potential gaps in the current implementation guide.
Beyond the need for additional evaluation, the ELINCS implementation guide requires several additional enhancements before it can comprise a “plug and play” interoperability standard for laboratory-result reporting:
The project described in this paper defined an implementation guide for laboratory-result reporting that manifests significantly less optionality than the current HL7 version 2 standard. Based on results from a small number of pilot implementations, several organizations of varying sizes were able to implement ELINCS successfully and the relatively small set of data elements in ELINCS was sufficient to convey the required contents of laboratory results. If the presumed relationship between the degree of optionality in a message standard and the level of effort required to implement data interfaces is valid, widespread adoption of the ELINCS specification among EHR vendors and clinical laboratories could streamline the development of laboratory-reporting interfaces. However, further evaluation is required to demonstrate that the ELINCS implementation guide can in practice deliver such savings and effectively support the result-reporting requirements of most laboratory and ambulatory facilities.
Supported by the California HealthCare Foundation. The authors thank the members of the ELINCS Technical Work Group for their efforts, insights, and perseverance. The authors also appreciate the efforts of the pilot implementation teams, especially the technical personnel who worked diligently to implement the ELINCS specification completely and accurately.
For purposes of this analysis, we classified an element as “Optional” if its designation in the HL7 standard is “Optional” or “Backward Compatibility.” We classified an element as “Required” if its designation is “Required,” “Required But May Be Empty,” “Conditional” or “Conditional But May Be Empty.” For information about these HL7 designations, refer to endnote .