Electronic Exchange of Clinical Laboratory Information: Issues and Opportunities

Prepared for:
Office of the Assistant Secretary for Planning and Evaluation (ASPE)
U.S. Department of Health and Human Services (HHS)

INTRODUCTION

NORC at the University of Chicago is pleased to present this discussion draft of a white paper entitled “Electronic Exchange of Clinical Laboratory Information: Issues and Opportunities” for the Assistant Secretary for Planning and Evaluation (ASPE) at the U.S. Department of Health and Human Services (HHS). As is well known within the health care policy community, the 1999 Institute of Medicine report To Err Is Human: Building a Safer Health System called for better use of information systems as one means to help improve the quality, safety, efficiency and effectiveness of health care delivery in the United States.¹ Subsequently, the President, Congress, and others have set goals challenging the health care sector to move towards wide‐spread and more systematic use of electronic data sharing (commonly referred to as health information exchange or HIE) to support health care delivery and public health goals.

Perhaps no aspect of HIE is more important to helping providers improve care for patients than the ability to seamlessly and electronically order tests from clinical laboratories and retrieve the test results using provider‐based applications such as clinical provider order entry (CPOE) or electronic health records (EHRs). Laboratory information exchange occurring in this manner can facilitate clinical decision support features such as clinical reminders, access to prior clinical laboratory results and closer monitoring of key population health indicators. Giving clinicians and public health officials these capabilities can improve the quality, timeliness and cost‐effectiveness of health care delivery.

The purpose of this white paper is to enhance understanding of the current processes, issues and opportunities involved in the electronic exchange of patient level laboratory information in ambulatory settings. We focus more specifically on the major challenges that federally supported health centers and other safety net provider’s face in establishing and maintaining stable interfaces with their laboratory service providers and in assuring that lab information is available in an accurate, efficient and useful manner. Health centers and safety net providers are central to ensuring access to quality care, improving outcomes and quality of life for persons with chronic illnesses, and eliminating health disparities. Inherent to understanding the challenges faced by health centers is a broader understanding of the issues involved in moving to the use of consistent data exchange standards and implementation approaches for lab information exchange in ambulatory care settings generally.

Our paper walks through several key topics that we have researched through scans of literature published in peer reviewed journals, government reports and industry or online publications as well as through a series of telephone conversations with individuals representing key stakeholders in lab information exchange. Topics addressed here include:

• An overview of the current approaches used for electronic exchange of clinical lab data between provider EHR systems (for safety net providers in particular) and clinical laboratories.
• A review of the key stakeholders involved in lab exchange including ambulatory providers, clinical laboratories, systems and application vendors, regional HIE organizations, provider networks and public health;
• A review of the use of standards to facilitate a more systematic and consistent approach to lab exchange with a particular focus on standards promoted by the Health Information Technology Standards Panel (HITSP);
• A discussion of issues and challenges facing widespread participation in electronic lab exchange in ambulatory settings; and
• A discussion of conclusions particularly as they relate to ongoing federal efforts to facilitate lab exchange and need for additional research and analysis to address what is still unknown.

Prior to discussing each of these topics, we provide a brief background section to elaborate the importance of lab exchange to health care and public policy stakeholders.

IMPORTANCE AND RELEVANCE OF THE PAPER

Based on 2007 data from the Centers for Medicare and Medicaid (CMS) Online Survey, Certification, and Reporting (OSCAR) database, the Centers for Disease Control and Prevention (CDC) estimates that approximately 6.8 billion laboratory tests are performed annually in the U.S.² These lab tests are a critical element in patient care, affecting around 70 percent of clinical decisions.³ However, in an ambulatory setting lab results are not always readily accessible which makes following up on abnormal test results in a timely manner challenging. When test results are not followed by an appropriate response, the quality of care delivered and patients’ safety and satisfaction are compromised.⁴ Also, there is a general agreement among most experts that there are numerous inefficiencies due to same tests being ordered by different ambulatory providers in different locations, lost records and laboratory tests sometimes being over utilized resulting in unnecessary costs of repeat testing.^{5 6} While most laboratories process test orders and perform lab tests in a timely and efficient manner to ensure good turnaround times, there are various issues with the communication of test orders and results between provider offices and clinical laboratories. Many of these issues are largely outside the range of direct control of the clinical laboratories. For these reasons, electronic exchange of lab information in an ambulatory setting can play an integral role in facilitating clinical decisions and avoiding unnecessary or repeated testing by allowing clinicians timely access to patients’ lab information within an EHR.

It is believed that bi‐directional interoperability, or the ability to support seamless exchange of information (not just data) between laboratory information systems and EHRs (primarily lab test results) and EHRs and labs (primarily lab orders) can “reduce medical errors, increase appropriate testing and reduce unnecessary testing, and improve quality and efficiency of health care.” ⁷ Most also agree that assiduous reporting and monitoring of lab results represent key components of quality improvement for the treatment of chronic illnesses such as diabetes, hypercholesterolemia and heart disease. Most recently, the importance of lab test results to health has been demonstrated by dramatic improvements in risk adjustment models following inclusion of patient‐level laboratory results.⁸ Electronic access to lab information through an EHR may offer many features, including real time access to lab results, patient and clinic‐level views of historical lab data, automated alerts in case of abnormal reports, and an integrated, comprehensive view of clinical information and lab reports.⁹ These features can result in a higher quality of care, attributable to a more efficient and comprehensive system of storing and sharing patient information.

Today, electronic exchange of lab test results is increasingly, albeit slowly, being adopted as part of a comprehensive, coordinated patient care system. Even providers that do not use EHRs with built‐in lab exchange interfaces are able to communicate electronically with labs via online portals set up by many of the major clinical laboratories. While electronic exchange with laboratories in this manner represents a form of electronic exchange, leaders in both the laboratory and health care quality sectors note that the ideal form of lab exchange, and the one we focus on in this paper, involves seamless, bi‐directional (e.g. including orders to the laboratory and test results returned to the provider) electronic exchange between a clinical health IT application used by the provider (e.g. an EHR or CPOE system) and the laboratory information system (LIS) directly. We describe this model in greater detail in the next section of the paper.

In his January 2004 State of the Union Address, President Bush emphasized the importance of information technology in health care, noting that “by computerizing health records, we can avoid dangerous medical mistakes, reduce costs and improve care.” With an increasing push towards EHRs encompassing lab data, clinical laboratories are becoming a new and integral addition to networks of providers and other organizations that exchange clinical data electronically. These organizations typically include hospitals, health plans, academic medical centers, integrated delivery networks (IDNs), other providers, and health information exchange organizations (HIEs that also include Regional Health Information Organizations).¹⁰ Exchange of clinical data between provider information systems and laboratory information systems seeks to minimize errors, decrease unnecessary redundancy and help clinicians provide coordinated, timely and improved care.

Conventionally, information transactions between clinicians and laboratories (both test ordering and test results retrieval) occur via fax¸ mail, and dedicated phone lines and printers set up in physician offices. In some cases, patients may even act as carriers of information. There are a number of inconveniences associated with these mechanisms. First, these methods involve lag time in the transfer of test results and do not always allow clinicians to access and review results in a timely fashion. Second, results become available at differing times which makes aggregating incoming lab paper reports in an organized manner an administrative burden. Third, paper results cannot be easily integrated into a computerized provider record and so this mode often requires manual entry of data which is subject to human error.

Another challenge with paper‐based test results is the complexity and lag time associated with obtaining lab test results.¹¹ It is believed that an EHR system’s value increases dramatically with electronic lab results because it makes test results, an important piece in clinical decision‐making, easily available along with other clinical data. Further, these results can be trended over time or integrated with clinical decision support logic. While existing research suggests that electronic lab exchange can improve patient safety and quality of care,¹² it is clear that these benefits can only be achieved if there is tight integration between lab test result data and other clinical data in a computerized patient record.¹³ Overall, evidence from existing research demonstrates that the electronic exchange of information in clinical laboratories should continue to represent a priority for achieving quality and efficiency improvements in health care delivery.

In addition to issues facing all providers seeking to develop electronic connectivity to lab results, safety net providers face a special set of issues and opportunities. On the one hand, because safety net providers treat a large number of the nation’s underserved and chronically ill residents, their efforts may stand to benefit disproportionately from establishment of electronic lab exchange as a means to increase the efficiency and quality of care. On the other hand, safety net providers,¹⁴ including federally funded community health centers, are less likely to use EHRs than other providers. They are also less likely to have the resources to work with clinical laboratories and contribute the resources (human, technical and financial) necessary to achieve robust exchange with their partners. As we shall explore in greater depth, health centers that have access to IT applications and services may be better positioned to realize electronic exchange with clinical labs and reap the benefits, but also face significant technical challenges.

DATA SOURCES AND APPROACH

To gather comprehensive information on electronic exchange of laboratory data we conducted a scan of the available literature using PubMed to search for peer reviewed publications. We also conducted Internet searches to identify government reports and articles from trade publications of relevance to the issues of electronic clinical laboratory data exchange. Given the relative dearth of published or even publicly available materials on this topic, we also conducted a series of phone discussions with major stakeholders representing providers with EHRs currently interfaced with clinical laboratories, their national and regional lab partners, and EHR vendors.

A list of potential initial discussants who participated in these phone meetings as well as the topics covered in the meetings was developed through discussions with ASPE as well as the Health Resources and Services Administration (HRSA). Each call was led by a senior member of our team. The notes taken during the call were summarized for central concepts and themes. Multiple NORC staff collaborated on reporting and interpreting findings.
In an effort to trace the process of lab data exchange in health centers from the point of ordering to the laboratory and back to the provider in the form of results reporting, we began by holding discussions with health center providers and networks and used a classic snowballing technique by asking those networks to identify laboratory representatives with whom they had a business relationship. Similarly, EHR vendors were referred to us by the health centers that were their customers. This approach allowed us to “follow the data” and identify the issues encountered at various stages of exchanging lab information.

While we are not revealing the names of individual discussants or their organizations, we note that we spoke with two large health center networks based in different parts of the United States, one regional health information exchange organization, one integrated delivery network, two large national clinical laboratories, one regional laboratory and one EHR vendor.

In the remainder of the paper we discuss several aspects of electronic exchange of lab information. We begin with an overview of the exchange process and describe the various stakeholders involved in these exchanges as well as the role of standards and regulatory issues. We then discuss issues currently encountered by stakeholders and new opportunities for addressing these issues through cross‐sector collaboration. We end the report with a discussion of conclusions for policy and program officials as well as areas where additional research and analysis are needed.

OVERVIEW OF LABORATORY DATA EXCHANGE IN HEALTH CENTERS

In this section, we review our findings regarding the nature of electronic lab data exchange today, including a brief discussion of the related functions and uses supported by lab exchange, the stakeholders involved, typical processes for setting up an exchange, and a summary of some of the costs involved. We also introduce discussion of the use of standards in lab data exchange which we described in greater detail in the subsequent section. While much of this section is relevant to any ambulatory care provider that is seeking to establish functionality allowing for lab exchange, we focus on health center and health center network specific issues throughout.

Below we provide a basic workflow model which is not representative of all the different processes for exchanging lab information, but outlines common processes used by ambulatory providers and health centers today to exchange information with laboratories.
 

Exhibit 1: Overview of Lab Data Exchange, Provider View

Exhibit 1 above shows the typical functions and stakeholders supported by an interface between an ambulatory care providers’ EHR application and a laboratory information system (LIS). As noted in the diagram, these interfaces may support unidirectional reporting where lab test results are transmitted electronically from the LIS to the providers’ EHR but orders are not transmitted, or bi‐directional reporting where both lab orders originating with the provider and going to the LIS and the results back from the LIS are transmitted electronically through the same interface to a provider EHR.

In all cases, it is important to note that lab exchange involves more than just information passing back and forth between systems. There is a physical specimen (e.g. blood) to be taken from the patient and transferred with a paper requisition to the lab facility for testing and processing. The paper requisition accompanies the test specimen which is sent to a clinical laboratory. The clinical lab processes the order, and sends the results electronically to the host EHR system. We discuss our findings related to ordering and results retrieval below.

Ordering lab tests. We found that there are a few basic workflows associated with ordering clinical labs using a lab exchange interface depending on the presence of a uni‐ or bi‐directional interface. Where a bi‐directional interface is present, orders are placed by clinicians through their EHR. When this occurs, data regarding the patient, clinician, lab test, specimen and other key fields are forwarded to the clinical laboratory’s LIS, typically via a Health Level 7 or HL7 message (described in greater detail on page 14) and the order is assigned a unique identifier.

At the same time, a requisition with this information is printed in hard copy from the provider’s EHR to accompany the physical specimen to the laboratory facility. These requisitions typically include bar codes which map to the unique identifier on the electronic order. Whether the specimen sample (e.g. blood) is taken at the clinician’s own site or at another location, the requisition is attached to the specimen and accompanies it to the laboratory’s testing facility. When the specimen arrives, the bar‐coded requisition is scanned and there is a check to ensure that the data in the LIS for that particular requisition matches the data on the physical requisition and specimen label. Once the appropriate tests are conducted and results determined, these results are entered into the LIS and associated with the appropriate order identifier.

When there is not a bi‐directional interface, the key difference is that the initial order is not transmitted to the laboratory’s LIS directly via the clinician’s EHR. Rather, the order information is submitted to the clinical laboratory’s LIS through a separate process which may involve the use of an online ordering system that is supported by most of the major national laboratories. In this case, it would be typical for the online ordering system to also generate a bar‐coded paper requisition that could be printed and attached to the specimen. In addition, many orders are also forwarded to labs via paper requisition. Linking these orders to an EHR and receiving results electronically requires the use of a consistent order number between the EHR and the reporting laboratory. Without a bi‐directional interface that supports ordering, the clinician office staff must record the order data in two places: the patient’s individual medical chart where the order is noted by the clinician; and the separate online portal where information from that chart is re‐entered by a member of the clinic or health center staff.

Transmitting lab results. Transmitting results is more streamlined from a workflow perspective. After an ordered test is performed, the labs feed the results into their LIS and the interface delivers the laboratory test result along with all of the information identifying the original order (lab order number, patient name, ordering physician, lab ordered, time and date) to the authorized provider on record. In the cases where unidirectional interfaces have been set up the test result is sent to the clinic’s EHR. Once the results are transmitted, the provider reviews the lab results that he or she ordered on a specific screen within the EHR, authenticates the results, and writes off the disposition at which point typically, the result and disposition becomes part of the patient’s clinical record. In the case of one interviewed network, results are first sent electronically to the provider’s task list. If a test result is abnormal, it is routed to the abnormal taskforce, a set of designated providers, other than the ordering physician, who are thus notified of this outcome. This special feature is particularly useful if the ordering clinician is out of town or off‐duty; in such cases, another clinician can intervene and provide timely care. Once a test result is viewed and accessioned (or recorded), it is cleared from the list. The result is then routed to the patient’s record within the EHR. When lab test results are being sent to a stand‐alone EHR, the lab does not directly control the EHR’s display of the lab results. In addition, the lab receives an acknowledgement that a result has been delivered to the EHR but does not receive further verification when a particular test result has been viewed.

In some circumstances, clinicians without interfaced‐EHRs can also view laboratory results electronically either via a portal set up by the clinical laboratory for this use or through a mechanism made available by a state or regional health information exchange. In cases where the labs provide portal access for providers, they have significantly more control over the manner in which test results are displayed and are able to more closely monitor how and when the results are reviewed. In this case, however, even though the information can be viewed electronically, it usually needs to be printed and included in the paper record; it may also be necessary to re‐enter the data into a non‐interfaced EHR.

There is a general agreement among the interviewed representatives that bi‐directional exchange is ideal and an integral part of a comprehensive EHR. Laboratory stakeholders in particular indicated that bi‐directional interfaces are an optimal solution as they do not involve redundant data entry and thus, leave far less room for human error. While the number of bi‐directional interfaces is increasing, one of our laboratory discussants estimated that 70 percent of the interfaces currently used by their lab are unidirectional and only allow for reporting results.

Health Center and Health Center Network Considerations. In addition to the fact that health centers are subject to the issues described above, there are particular issues of note for health centers, health center networks and the populations they serve. In particular, because relatively few health centers have the ability to adopt EHRs on their own, they are less likely to have a sophisticated provider application layer as depicted in Exhibit 1. Given that health centers are focused on quality improvement as a result of their grant obligations and mission and because they treat many chronically ill patients, even if they do not have EHRs, they are likely to have disease registries or other tracking databases where staff enters lab values for specific groups of patients. Currently, there is limited information regarding the use of lab exchange to automate the population of disease registries in the absence of an EHR. However, it is not likely that this occurs often.

Those health centers that have adopted EHRs often do so as part of a consortium of health centers, often referred to as a health center controlled network (HCCN), which allows member health centers to leverage grant dollars and achieve the economies of scale necessary to procure human resources, infrastructure and software in support of clinical applications, such as EHRs and interfaces. While there are many models for how health centers use HCCNs to support their operations, several of these models involve the use of networked applications and interfaces maintained centrally and accessed by member health centers over a secure network.

In the case of a network that provides health centers access to a centrally maintained EHR, establishing laboratory interfaces to that EHR requires a separate set of considerations for each health center and clinical laboratory. A network that administers one EHR works with a series of health centers with multiple sites to establish interfaces with all of their labs. Thus, networks may have to support scores of different versions of an Exhibit 1 workflow in order to provide a consistent level of service. For example, a network serving five health centers who together have 10 health center sites that each work with three laboratories may have to set up and maintain up to 30 unique workflows even though all sites are using the same networked EHR.

Linking the exchange to quality improvement. It is important to note that in order for lab exchange to achieve broader population‐based objectives and provide some return for providers, the workflow associated with the establishment of the exchange cannot end with what is described in Exhibit 1. Instead, additional steps are necessary between the provider’s clinical application or EHR and the registries, reports, alerts or other functionalities that automate the tracking of key lab values and provide feedback, and in some cases decision support, to providers based on lab results. Many EHRs do not come with a built‐in registry capability or even automated reminders to inform providers that, for example, they have diabetic patients who have missed an HbA1c test. Building this functionality and working it into the clinical workflow requires additional effort. However, such enhanced reporting capabilities and registries are increasingly being used to support quality improvement at the point of care and to promote overall population health.

KEY STAKEHOLDERS FOR LAB EXCHANGE

While Exhibit 1 above focuses on three important stakeholders in lab exchange – ambulatory providers, clinical laboratories, and patients – there are a range of additional stakeholders who are either critical to effective lab exchange or who have a keen interest in facilitating wide‐spread and more effective adoption of lab exchange models. First, at the “nuts and bolts” level, clinicians’ participation in lab exchange is dictated by the EHR application they have selected and this greatly influences how the specific installation participates in lab exchange. Similarly, clinical laboratories’ ability to participate in lab exchange is dictated by their LIS and the vendors that develop and support these systems. In addition, other key stakeholders include public health officials who could derive benefit from systems designed to allow electronic notification of reportable conditions and population‐based surveillance. Additionally, public and private payers and purchasers stand to benefit from increased cost‐effectiveness of care.

It is important to note differences between different types of providers and laboratories. Large national laboratories that provide services to thousands of providers around the nation often consider the development of interfaces and online portals for ordering and results retrieval as “value added” services for their clinician customers. Hospital laboratories, regional laboratories, or specialty reference laboratories that are limited geographically or in terms of the services they provide, however, may not have the incentive or capacity to provide these types of “add‐ons.”

For the last several years, almost all laboratories have been compelled to adapt their information management focus and use laboratory information systems (LIS) to automate the routine steps in the daily workflow, including: test ordering; specimen labeling; analytical interfaces between scientific instruments and information systems; reporting results; quality control; efficiency; productivity management; financial services (billing, inventory, forecasting and analysis); reference testing and regulatory compliance. The extent of LIS adoption and their capabilities vary widely among the laboratories. Each large national, commercial laboratory relies on its LIS to support a range of business functions that may include in‐house portal solutions for providers that support ordering laboratory tests. Smaller laboratories primarily use commercially available LIS systems to meet their business needs. Regardless of laboratory size, its LIS is frequently used to facilitate compliance with regulatory requirements including those derived from the Clinical Laboratory Improvement Act (CLIA). CLIA applies to all clinical laboratories performing the testing of human specimens including small physician office labs.¹⁵ Many small physician office labs, however, perform waived tests which are defined as simple laboratory examinations and procedures. These are cleared by the federal government because they employ methodologies that are simple and accurate so that erroneous results would be negligible or pose no reasonable risk of harm to the patient if the test is performed incorrectly.¹⁶ For Laboratories performing only waived testing, CLIA requirements are reduced to primarily obtaining a CLIA certificate and complying with the requirement to follow manufacturers’ instructions.¹⁷ CLIA is described in greater detail below. While some large commercial labs have systems that were developed in house, in recent years a number of large software vendors provide LIS products. The November 2008 College of American Pathologists (CAP) LIS survey results include a self‐reported listing of LIS products.¹⁸ According to the CAP LIS survey there are at least 35 different lab information systems that clinical laboratories may purchase from a variety of vendors. Labs may also choose to purchase or implement only specific components of the LIS from these vendors resulting in a tremendous variability in LIS configurations and implementations from one clinical laboratory to the next. In addition, there are important provider differences that are relevant. Larger provider organizations such as integrated delivery systems and multi‐specialty group practices may be, by virtue of their size and level of integration, in a better position to access resources necessary for adopting EHRs and working with vendors and clinical laboratories to establish exchange. Recent surveys show that a distinct minority of ambulatory health care settings are using EHRs. An even smaller percentage use EHRs that interface with their clinical laboratories’ LIS. An average provider’s office today interfaces with two labs and may also have the capacity to do some lab work itself. Health centers and other safety net providers have relatively little access to resources necessary to achieve exchange except to a limited extent in the context of health center networks. While networks have been demonstrated to be an important vehicle for helping health centers adopt health IT, they are also another stakeholder in the exchange of laboratory information, in addition to EHR vendors, clinical laboratories and the providers themselves.

The next two sections of this paper describe implementation issues associated with lab interfaces including key processes, decisions and use of standards. While these issues affect all providers regardless of the nature of the provider organization involved, we note there are important differences in the abilities of different types of providers to secure the expertise and resources to address these requirements.

IMPLEMENTING AND MAINTAINING A LABORATORY INTERFACE

One of the areas explored in detail with discussants who contributed to this paper was the process used by providers, EHR vendors, and clinical laboratories to develop, implement, and maintain laboratory exchange interfaces. While these interfaces have been used in some form for several years and attempts have been made at the corporate level within large laboratories to standardize implementation, almost all discussants noted that interface implementation is a time‐ consuming and iterative process. Additionally, customization of the interfaces depends on the laboratory and clinical systems being linked, and how each of those systems has been implemented within the lab or the specific health center or network.

Large commercial laboratories report using hundreds of interfaces, each unique and customized based on the host EHR systems and provider preferences with respect to custom order sets. A custom order set may often involve a battery of tests. For example, an admission battery may include a complete blood count, urinalysis, and electrolytes. One of the lab respondents stated that their goal is to have one standard interface for every vendor, but due to the unique environment of each vendor and lack of national standards, the lab ends up having multiple interfaces for every EHR product and is constantly developing new ones. Regional labs may have a smaller number of active interfaces, but will also use a range of different interfaces depending on the EHR systems employed by their customers as well as their customers’ needs. Larger laboratories have initiated corporate interface verification procedures to ensure that new interfaces adhere to the company standards and regulatory requirements. To document compliance with the Clinical Laboratory Improvement Act (see below), labs are required to verify the interfaces of EHR vendors. The interface verification process is largely driven by interface implementation and can take as little as a month or as long as a few years, depending on the vendor and provider requirements. In general, the time taken to validate a bi‐directional interface is approximately twice that of a unidirectional interface.

In addition to the certification requested by the labs, the major EHR vendors have also elected to go through a fairly time and resource intensive process to become certified by the Certification Commission for Health Information Technology (CCHIT).¹⁹ CCHIT is an independent, voluntary, private‐sector initiative whose mission is to accelerate the adoption of health information technology through certification. EHR vendors retain certification for a periodthree years at which point they will have to be recertified. The criteria for certification are revised and vendors need to demonstrate new functionality upon recertification. Currently, vendors are being tested against 2008 criteria that include the ability to receive the HITSP Health Level 7(HL7) version 2.51 laboratory results messaging standards (see below). A list of vendors certified in 2008 can be found on the CCHIT website.²⁰

On the provider and vendor side, there is also the need for substantial investments in the development and implementation of interfaces. The vendor and provider must work with the laboratory to share information on standard database fields and coding used by the EHR and how they are being used. In some cases, they will need to disclose information on the custom fields or functionality being used in a specific way by an individual customer. Provider and vendor staff are also involved in testing interfaces once they are developed and monitoring and reporting issues with the interface to the clinical laboratory. Our discussions revealed that some of the larger provider networks are using interface engines developed by third parties. These networks have their own interface teams that are well‐versed in working with labs and other outside providers to build new interfaces and maintain them.

EHR vendors and labs report that interface planning between the clinical practice and the lab is an iterative process. It is often the case that both the clinical laboratory and the EHR vendor have a set of specifications for interface development and these specifications have to be exchanged and compared against one another as a starting point. National laboratories report that the implementation period is between four and six weeks for bi‐directional interfacing given that the contractual details and finances are straightforward. However, they note that the process can take more or less time depending on the availability of existing interfaces to the same EHR product. The work of HITSP and CCHIT to promote a more standardized approach to the exchange of laboratory information presumably would facilitate this process. However, the current HITSP and CCHIT specifications do not include laboratory orders (although an order use case is underway) or cover all types of lab results and do not include comprehensive specifications regarding the display of laboratory data.
Once implemented, there are also activities necessary for monitoring and maintaining the interface. Providers are often responsible for identifying interface problems because they are in a better position than larger laboratories to notice when lab orders are not being processed or when results messages are received in a manner that cannot be adjudicated by the interface. As noted under the challenges section below, routine adjustments to testing procedures on the laboratory side can result in changes to results codes or other key data elements which can cause interfaces to fail for a period of time until the problem is identified and addressed. The labs report encountering similar issues with changing result codes in cases where they send specimens to referral laboratories for tests that are not performed in‐house.

One area where we were not able to obtain detailed information relates to the cost and pricing of interface development, and how costs are divided among EHR vendors, laboratories and providers. While some large national clinical laboratories may consider working with providers on interface development as part of their regular suite of services, it is clear that EHR vendors have various pricing models and charge providers separately for interface development tasks. In discussion with CCHIT certified EHR vendors, the direct cost of certification is usually absorbed by the vendor. From our discussions, it was evident that the costs – both in terms of payments to software vendors and staff time necessary to monitor and maintain the interface – are borne by the providers who have little financial incentive to bear this cost.

USING STANDARDS TO FACILITATE LAB EXCHANGE

Though not well understood by all stakeholders, messaging and content standards can be critically important to laboratory exchange and other forms of HIE because they facilitate interoperability by encoding health information using a common ‘language’ that can be read by multiple systems. Given the variety of different clinical information systems and the fragmentation of healthcare information, developing and supporting standards for both data content and messages is essential. Standards enforce a common language for exchanging information across disparate health systems and ensure that electronic messages are properly constructed upon receipt.

In the context of our overall model for lab exchange (Exhibit 1), each arrow represents a transaction that involves the electronic transfer of data and information between two entities. That transfer occurs in the form of a “message” that includes a series of data fields as well as the content feeding into those fields. The use of standardized message and content definitions to support these information transactions can substantially increase the interoperability and usefulness of laboratory exchange or other forms of HIE and may substantially reduce the cost of HIE to providers, payers, purchasers and the public over time.

The federal government has played a key role in standards development. HHS established the National Health Information Coordinator position in the Office of the National Coordinator (ONC) in part to facilitate the development of standards‐based electronic health records. Within the ONC, the Office of Interoperability and Standards (OIS) coordinates with other HHS offices to foster the use of standards and certified technology, and advance the development, adoption, and use of health IT standards nationally. The American National Standards Institute’s (ANSI’s) HITSP is a cooperative partnership between public and private sector stakeholders tasked with developing a broadly accepted set of standards that contributes to interoperability and health information exchange, and identifying gaps in standards development. HITSP has been tasked with harmonizing standards, developing nationwide health information network prototypes and recommending necessary changes to standardize diverse security and privacy policies. The goal of this effort is to achieve a widely accepted and useful set of standards that will enable and support widespread interoperability among healthcare software applications.

There are many standards that support the exchange of lab tests and results. The sections below are focused on some key standards and some of the major issues that we have identified as part of this environmental scan. We focus on both standards that are used primarily as messaging standards such as HL7 and others that are content standards such as the Logical Observation Identifiers, Names, and Codes (LOINC). We also address those standards that have been identified by HITSP as recommended for use in laboratory data exchange. Importantly, we discuss each of the key standards in light of the experiences of our discussants in using them and their perceptions regarding their overall usefulness. Our discussion of standards juxtaposes the intent and structure of HITSP standards to the real world experience of using these standards. We note that there are some standards that have been adopted and
widely used, while the use of others is limited. We also discuss that in certain areas, standards have not been embraced by key stakeholders.

HEALTH LEVEL SEVEN (HL7)

HL7 is an accredited, nationally‐recognized standard for electronic data exchange in healthcare environments. HL7 is also a set of messaging standards; the syntax for the message is designed to impose interoperability on various clinical information systems. HL7 has made it possible for laboratories to send reportable data to health departments electronically. In June 2007, HL7 released a new version of its Messaging Standard, V2.51, which supports the data elements that are required by Clinical Laboratory Improvement Act (CLIA) for the exchange of electronic laboratory information. ²¹

The EHR lab results specification, which would allow the reporting of clinical lab results, passed ballot in December 2007, and has been incorporated into the HITSP specifications and achieved full recognition status by the Secretary in June 2008. Of note though is that the 2006 American Health Information Community (AHIC) laboratory result reporting use case provides the following functionality for laboratory results reporting and notification, and, “…is applicable to many types of laboratory tests, including but not limited to: clinical chemistry, hematology, serology, and microbiology.”^{22 23} The current HITSP interoperability specification (IS) 1.0 does not include the ordering of laboratory tests nor does it include resulting for all types of labs, notably anatomic pathology, complex molecular diagnostics, genetic tests and others.^{24 25} These gaps will need to be addressed to support the more ubiquitous exchange of laboratory information.

HL7 has a balloted standard for lab order messages. This is currently supported by HL7 V2. Work is also currently underway to promote a standardized approach to lab orders. In August 2008, the AHIC released additional recommendations for General Laboratory Orders²⁶ for public comment. The AHIC document specifies the various standards that are recommended to support the electronic ordering of laboratory tests by clinicians and the manner in which labs receive and process these orders. When the recommendations are finalized, it will be HITSP’s responsibility to work with existing standard development organizations to develop a messaging specification for lab orders. In addition to the efforts of CCHIT and HITSP, Integrating the Healthcare Enterprise (IHE),²⁷ an organization that is focused on building detailed frameworks for the implementation of standards, has also made available a guide for the trial implementation of lab orders.²⁸

All the labs, health centers and vendors we spoke with for this paper are using HL7 for lab messages. In many cases the HL7 interfaces were implemented before the availability of HITSP standards, and therefore do not uniformly use HL7 version 2.5.1. Even though all of the projects included in this study support the HL7 message standard, the implementations vary and the health centers or networks and labs report the need to work collaboratively to ensure
that the HL7 message segments are appropriately mapped between the sending and receiving systems. The variability in the implementation is largely due to the fact that HL7 V2.x does not use a specific information model, has vague definitions for many data fields and contains many optional fields.^29
30.

Review of the international use of HL7 indicates a growing trend to support HL7 V3 in various European countries. While there is a growing interest internationally, there are no broad scale implementations of HL7 V3 yet. Canada seems to be the furthest ahead and has developed their implementation plan for V3. There are advantages to HL7 V3, notably the use of an information model largely designed to support the interoperability of messages as well as the content of these messages. There are numerous reasons for its limited use in the United States, including: the extensive use of HL7 V2.x by legacy applications; its almost 20 years of industry experience in both private and public sectors; its enormous functionality to support different applications; and excellent vendor support.³¹ Another deterrent to moving from V2 to V3 is an interoperability problem between HL7 v2.x and HL7 v3 messages: there is no well‐defined mapping between HL7 v2.x and v3 messages. Additionally, HL7 V3 does not yet have a balloted standard for lab orders.

LOGICAL OBSERVATION IDENTIFIERS, NAMES, AND CODES (LOINC)

LOINC is a standard that facilitates the exchange and pooling of laboratory tests for clinical care, outcomes management, and research. LOINC was established as universal identifiers for laboratory tests and other clinical observations. The laboratory portion of the LOINC database includes categories of chemistry, hematology, serology, microbiology (including parasitology and virology), and toxicology, as well as categories for drugs and the cell counts. Today, the LOINC standard is maintained by the Regenstrief Institute, Inc.

Although LOINC has been in use for the past 15 to 20 years, it is just now being accepted and used by labs and clinicians for cross‐walking information. All three labs that were involved in this study reported that they have capabilities to code and map LOINC and to send codes along with the results as part of the HL7 message. Large national laboratories indicate that, in general, they have mapped the vast majority of the codes to LOINC. In the context of information exchange, the issue of mapping laboratory codes from multiple sources to LOINC can be quite challenging because of the large number (2,000 to 5,000) of distinct test observations per laboratory.³²

A recent study by the Regenstrief Institute demonstrated that approximately 800 laboratory codes could account for 99 percent of the test results stored in the clinical databases of their collaborating institutions.³³ Consequently, by mapping a small subset of codes, a large fraction of patients would have all their laboratory test results mapped. However, EHR vendors and providers indicate that they rarely receive LOINC codes from clinical laboratories. We found that while the major labs support LOINC, a number of the smaller labs continue to use their own local codes and do not have any mapping to LOINC. In addition, even those labs that have made an effort to map tests to LOINC do not always transmit LOINC codes in results messages. Consequently, depending on the specific market, the labs themselves are not able to send LOINC codes in the results message or do not do so, even if they have the capability.

The labs we spoke with reported concerns that the EHR vendor software may not aggregate and interpret the LOINC mappings correctly, potentially resulting in errors or undefined values when the EHR system receives the information. Therefore, the major labs try to ensure that vendors who ask for LOINC codes know what it means and how to handle the LOINC mapping. Although there are a few examples of LOINC use by organizations such as the Veterans Administration, the Department of Defense, and Kaiser Permanente^{34 35} providers included in the study noted that LOINC is not supported widely in practice, and CCHIT testing of EHRs is the only national driving force for its usage. LOINC codes are very granular and distinguish what type of testing method is used by the lab. For example, there are different LOINC codes for a white blood count that is done manually rather than automatically. While the relevance of the testing methods varies depending on the clinical context, the testing methods do not always materially impact the interpretation of the results by the provider. Thus, depending on the specific example, LOINC codes may also require the implementation of additional logic in the different clinical systems processing this information.

In some cases, the EHR vendors indicated that they have the capacity to map local codes to LOINC but given that the average provider receives results from at least two labs, this would still be a time‐consuming and costly process. EHR vendors also noted that their preference was to consolidate some of the LOINC codes in order to make the implementation more feasible. Today, programmers cannot single‐handedly complete the mapping because it requires extensive clinical knowledge that interface developers may not have. In addition, having a more abstracted version of LOINC would improve the usability and utility of the information being presented to providers.

Given the cost and other challenges with LOINC mapping experienced by labs and EHR vendors, most labs transmit local codes in lieu of standardized LOINC codes. While this approach allows the transmission of lab information to support patient care, it does not support true semantic interoperability between the laboratory information system and the EHR. Consequently, this may limit the ability for lab‐provider exchanges or HITSP standards to be leveraged for regional or nationwide HIE efforts.

UNIFIED CODES FOR UNITS OF MEASURE (UCUM)

The UCUM is a code system intended to include all units of measures contemporarily used in international science, engineering, and business. UCUM facilitates unambiguous electronic communication of quantities together with their units, and the focus of UCUM is electronic as opposed to human communication. UCUM, though heavily based on existing standards for units of measure which include ISO 2955‐1983 and ANSI X3.50‐1986, is recognized by standards experts as being more stable in content and free of ambiguities. Additionally, it assigns a concise semantic to each defined unit. Today, typically the units of measure for lab results are represented in text and not in UCUM. For example, the result for a platelet count is represented as PerMicroLiter (non‐UCUM) instead of the valid UCUM code of μL.³⁶ Representing the units of measure for lab results as text does not support system interoperability; this is one of the major drivers for UCUM. Most respondents agreed that having a standard for the unit of measure could be beneficial, though there are significant issues with respect to securing broad adoption of such a standard.

Laboratory discussants indicated that, in the current lab exchange workflow, the instrument device or intermediary would need to generate the UCUM. Discussants indicated that currently device manufacturers are not required to use UCUM. Instead, the device manufacturers generally use proprietary codes. In order to move to UCUM, these proprietary codes will need to be mapped to UCUM. For the reasons identified above, the lab industry is currently not using UCUM internally and will therefore not be able to send this information out as part of the HL7 message to receiving systems like EHRs.
Discussants noted that HITSP’s focus on the use of UCUM is somewhat problematic given the limited support and market penetration of this standard. Additionally, since units of measure is a CLIA required data element that must be displayed, in a human readable format, to the end user, laboratories are sensitive to validation issues that can arise when EHR vendors receive and display UCUM. It was noted that it often takes a long time for standards to be adopted.

SYSTEMATIZED NOMENCLATURE OF MEDICINE (SNOMED)

SNOMED is a structured collection of clinical terms used in health and healthcare; from a lab perspective, it is used to code test results. It has been around since the late 1970s and has support from a number of the major standards initiatives including HL7, Digital Imaging and Communications in Medicine (DICOM), the Accredited Standards Committee (ACS) X12, and International Organization for Standardization (ISO). SNOMED has also been mapped to ICD 9 and there are efforts underway to map it to ICD10.

In 2003, HHS recommended that SNOMED Clinical Terms (CT) be part of a core set of patient medical information. The government also purchased a perpetual license for SNOMED to make it available to U.S. users at no cost through the National Library of Medicine (NLM).

The major issues encountered with SNOMED relate to its large scale: today, SNOMED consists of approximately 875,000 concepts and two million terms. Consequently, its ongoing development, use, and maintenance are very significant. In addition, SNOMED CT covers many precise areas of laboratory results, but other specialty areas may not be covered in sufficient depth, if at all.

Although SNOMED has been used since the 1970s, the current utilization of SNOMED remains low. Results from a survey conducted by the American Health Information Management Association (AHIMA) assessing uptake of SNOMED CT found that 60 percent of EHR vendors have or plan to obtain a SNOMED CT license and less than 20 percent of vendors indicate that SNOMED CT is currently operational in their applications.³⁷

OBJECT IDENTIFIERS (OIDS)

In order for computers to manipulate information, there is a frequent need to uniquely identify records and data objects in some way. There are many mechanisms for doing so; one currently popular mechanism is via OIDs. The OID mechanism allows for the assignment of globally unique identifiers to any type of object, thus assuring traceability of the object identified as it is propagated across networked applications.

In the context of lab exchange, OIDs may be used to help identify facilities, patients, providers and organizations. For example, if an OID code is assigned to a particular LIS and combined with a locally specific result number, then the combination of the two can uniquely identify the result as it is shared by multiple healthcare providers across a national network. Similarly OIDs can be used to uniquely identify lab orders (order number + lab OID) and alert providers and others to duplicate orders across the network.

Our discussions revealed that there is no real use or support for OIDs in the context of clinical laboratories. Some of the reasons for this lack of support include lack of awareness about OIDs, and technical issues with implementation and management of OIDs. For example, if a health center or other provider receives results from multiple sources that use different OIDs, there may be important technical implementation and workflow issues to consider if the ordering and reporting process is not fully automated. Informants for the study also indicated that the costs for implementing OIDs and the potential benefits to individual participants have not been well articulated.

As the Nationwide Health Information Network (NHIN)³⁸ is established, the ability to uniquely identify labs, providers and organizations to support exchange of health information beyond geographic boundaries willincreasingly important. While the use of OIDs for the NHIN or to support lab exchange at a state or regional level is well understood, there is now no compelling reason for health centers and labs that are directly connected to each other to use OIDs. Additionally, nothing currently prevents an organization from obtaining multiple OIDs for similar purposes, and there is no national OID registry.

CLINICAL LABORATORY IMPROVEMENT AMENDMENTS (CLIA) REQUIREMENTS

Congress passed CLIA (42 CFR 493) in 1988 to establish standards for laboratory testing and ensure the accuracy and reliability of patient test results. CLIA has served as the primary regulatory program governing U.S. clinical laboratory testing since its implementation, and applies to all labs performing testing of human specimens for health assessment. While CLIA regulates physician office labs since many of them perform only waived tests, most CLIA requirements are waived.³⁹ According to the CMS CLIA Database, a June 2008 update identified a total of 206,940 registered labs, of which 126,219 have a CLIA waiver. In addition, there are 108,234 physician office labs, of which 56,291 have a CLIA waiver.⁴⁰

CLIA regulations place the responsibility of accurate and timely reporting and the privacy of laboratory information on the laboratories performing the tests. CLIA applies to all laboratory test results (with modifications as noted previously for laboratories performing only waived testing), and unlike the currently accepted HL7 message implementation guides, it is not limited to a subset of testing. Although CLIA regulations originated in a paper‐based environment, they are written in a manner that would apply to both electronic and paper‐based exchange. Clinical laboratories originally developed interfaces through their own systems to meet CLIA requirements and are now facing increasing pressures as the number of EHRs on the market continues to grow. CLIA also requires that, unless otherwise specified by state law, laboratories send test results only to ‘authorized persons’. Many state laws are stricter than CLIA regulations and require that labs disclose test results only to the ordering physician or designee. Notably, CLIA also defers to State law in all cases for the definition of ‘authorized person.’

In the context of health information exchange, results are sent to a central ‘switch’ and this information is then routed to multiple end points. This creates risks for labs, as they will not be aware of all uses and displays of data. Hence, labs must trust another organization to ensure that all the lab data is transmitted and that test results are displayed accurately in a manner compliant with both CLIA and state laws.

In the context of health information exchange with other EHRs, the need to capture and transmit all of the CLIA data becomes increasingly important. Examples of such data would include the location of the test performed. This data preservation allows one to always determine the source of the lab regardless of the number of transitions that data made en route to the final system. CLIA typically only regulates clinical laboratories to the point of result delivery to the provider’s EHR or office. However, in some cases (for example, an imminent life‐threatening condition or critical/panic values), CLIA further requires that the laboratory assure that the authorized individual was actually informed of the test result. ⁴¹

Although CLIA regulates the timely delivery of test results, there are no current standards or requirements with respect to how, in an EHR or in the context of a RHIO, information is passed back to the lab that the provider has viewed a result. Technically, the EHR can send an HL7 message to inform the laboratory’s LIS that a message has been received, but today there is no specific use case or requirement for an EHR to inform the LIS when the report was actually viewed by the authorized provider. Today, lab portals that are used by health centers and other ambulatory providers allow labs to meet CLIA requirements more easily with respect to data display and timeliness requirements.

In addition to both CLIA and the Health Insurance Portability and Accountability Act (HIPAA), many states have a larger set of confidentiality and data use limitation regulations, policies and laws that must be examined from the context of laboratory information exchange. These variations in confidentiality, privacy, and security practices were evaluated under the Office of the National Coordinators Health Information Exchange Privacy and Security Contract (HIPSC).

Our discussions confirmed that the labs are currently obligated by CLIA to assure that each interface is functional and that the labs are responsible for ensuring that the test results are accurately displayed by the EHR to the authorized person in an appropriate fashion. Clinical Laboratories are also expected to perform this validation at the time of initial installation and periodically under other more stringent requirements from CMS approved accrediting organizations like the College of American Pathologists (CAP) and the Joint Commission. Consequently, CLIA compliance, as opposed to CCHIT certification, therefore extends to all installed instances of lab interfaces and is not limited to a single instance or a one‐time validation. This is an important distinction as CCHIT certification is carried out at a specific time between a specific version of an EHR and the test environment, whereas CLIA verification occurs in an open environment where a wide range of combinations between implementations of LIS and EHRs can occur overtime. Also, as noted previously, while the current HL7 V2.51 implementation guides used in the 2008 CCHIT criteria is CLIA complaint with many clinical labs, including microbiology, it does not cover all test categories. In conclusion, HITSP and CCHIT specifications may not always guarantee that results are displayed to the end user in a compliant manner.

The lab representatives interviewed for this study indicate that they would prefer to not be accountable for how labs are displayed by the EHR system receiving the labs. While the responsibility for ensuring that labs display all the CLIA data accurately to the authorized provider is cumbersome in an environment where a lab has a direct connection with the health center or provider system, in the context of a regional or local health information exchange, where information may be sent from a central location to numerous systems, this is a major impediment. Another issue with respect to this requirement is that some EHRs offer providers different views of the data. For example, a provider may choose a cumulative reporting format to trend patient results. In this case, the lab would have certified some but not all views of the lab results. Finally, while currently CLIA holds labs accountable, it is not clear how this area will evolve in the context of broader HIE or HIT efforts in the future.

CHALLENGES, BARRIERS AND OPPORTUNITIES

As experience with exchange of clinical data between providers and laboratories expands, policy makers and cross‐sector stakeholders will have a greater opportunity to address key structural and process barriers that impede lab exchange. Challenges currently identified range from relatively limited adoption of health IT by ambulatory care providers in general (current estimates indicate that fewer than one in four ambulatory care practices use EHRs) to the cost of developing, validating, and maintaining interfaces. The lack of incentive for providers to invest in electronic capture of patient‐specific laboratory data in the absence of an imperative to report on or track clinical outcomes or participate in quality improvement initiatives also presents a significant challenge. A series of more specific barriers are described below.

Limited use of standards. We found limited evidence that clinical laboratories or EHR vendors have moved towards greater use of standards recommended by HITSP or used as criteria by CCHIT. While we found that clinical laboratories and EHR vendors are “gearing up” and in some cases “ramping up” for use of these standards including LOINC, most are still relying primarily on proprietary data formats and definitions that must be reconciled through one‐off interfaces between the particular implementation of the LIS and a particular implementation of an EHR.

While the ability for lab and clinical software to support some HITSP recommended standards such as LOINC is expanding, we found that laboratories, EHR vendors, HIE organizations and others that have worked to map specific tests to LOINC codes have found this to be a time‐consuming process. There is no empirical evidence regarding the consistency of LOINC code mappings across various laboratories. Also, we found some resistance to the notion that there is a viable business case for labs and EHR vendors to pursue other standards such as UCUM and OIDs. Our study participants also indicate that another key barrier to standards adoption is the lack of easily understood and sufficiently concise implementation guides relating to each of the HITSP recommended standards. There is a strong case for the development of implementation guides that will promote broader use of standards, and to which health centers could refer their laboratory and EHR vendor business partners.

For now, there are some important challenges associated with the use of very basic standards including provider identification. Where EHR and practice management systems have moved to a National Provider Identifier (NPI) based on CMS requirements, many major clinical laboratories use Unique Provider Number (UPN) codes to identify individual providers. In addition, most results and order records within LIS make use of proprietary coding systems that are application specific. When interfaces fail due to changes in results or order codes within an LIS, interfaces to EHR systems need to be updated. One EHR vendor stated that their clients are provided with user‐friendly software in the engine which allows the clinics to enter new codes into their system when a laboratory informs the providers of the new tests. The same EHR vendor is trying to develop a HL7‐ based specification, but has not taken this initiative to HL7 because the application and approval process with the Standards Development Organization (SDO) is a long tedious process.

Limited understanding of best practices in interface development. Because of the various business interests involved in lab exchange and the relative inexperience of most providers with EHR systems, we found little evidence that the health care sector has developed clearly defined best practices around interface development. Each lab respondent described a similar approach to interface development, but it was clear that the process remains relatively loose, with large variations in the time required to set up an interface (between six weeks and six months), the level of effort required, and the exact steps that need to be employed. Such variations may be due to: an inherent variation in the different EHR and LIS systems on the market; the manner in which any given software product is implemented in a clinic or laboratory; differing levels of experience or skills to support interfaces at the provider level; and other inherent variation in inputs. Variations could also be in part a result of the lack of a strong incentive on the part of providers, EHR vendors, labs and LIS vendors to work together to define best practices.

Relationship between use of standards and regulatory compliance. Key regulatory issues relevant to lab exchange include the need for laboratories to verify the screenshot or view of laboratory results under CLIA as well as the privacy and security regulations specific to CLIA, HIPAA and individual State medical information privacy statutes. In general, labs that provide interfaces are familiar with their regulatory responsibilities and have worked out processes to comply with these requirements routinely as part of the interface development process. However, there is limited understanding of how the use of HITSP proposed standards would affect these certification processes. For example, some discussants noted that use of standards such as UCUM may impede regulatory compliance because the UCUM conventions for units of measures for any given lab test are not consistent with what clinicians are used to seeing for the purposes of clinical evaluations. To address clinician needs regarding the representation of results, EHRs may need to maintain a mapping between UCUM and human readable codes. These maps will need to be updated and validated periodically.

Cost considerations. While discussants would not (or in some cases could not) provide specific details regarding the cost and price of developing interfaces, it was clear from our discussions that the costs of establishing lab interfaces are substantial and cover a range of elements, including: the additions to the LIS and EHR software itself; the time required to monitor and maintain the interface, and to identify and resolve problems; and the cost of procuring legal counsel to assure compliance with state and federal laws. Discussants noted that it is challenging to calculate interface costs because there are a number of highly variable factors that contribute to the total. Additionally, messaging standards will influence this expense. The major drivers of the costs of establishing the interface, and those associated with validation and ongoing maintenance, are not entirely clear.

While there are strategies to minimize costs such as using the availability of a lab module as a criterion for EHR selection, there are inevitably costs associated with customization of those pre‐set modules. For example, costs will depend on the way in which the EHR is used in a particular setting and the features of the LIS systems used by the clinical labs to which interfaces are being built. Some larger labs offer free interfacing as a market differentiator. Fees for labs that do charge tend to be nominal. However, EHR vendor costs to clinicians associated with developing a custom interface may be substantial and are not well understood. For large EHR vendors, the direct costs of CCHIT certification are nominal and are part of company strategy to gain market share. Consequently, the costs for certification incurred by these large vendors are not transferred to providers that purchase CCHIT certified systems. The same situation may not hold true for smaller EHR vendors. Both large and small vendors are likely to encounter additional development costs to include functionalities required for CCHIT certification and these costs may impact the price of the EHR.

Discussants stated that there can be significant soft costs associated with the interface implementation. One larger health center network indicated that it has one staff person spending around 20 hours per week on monitoring lab feeds for about 45 interfaces for member health centers. They estimated that two to four hours of the 20 are spent cleaning errors in the system. Another health center network reported having to pay $35,000 up front to the EHR vendor to set up the lab interface specification to support its providers.

Variation and fragmentation among laboratory information systems. We found that there is considerable existing fragmentation in laboratory information systems even within the same larger clinical laboratory corporation. As the large laboratories expand by acquiring regional laboratories, they do not automatically and immediately convert each facility to a single corporate LIS. As a result, lab interfaces must be customized for different LIS systems. In addition, given the complexity and continuous innovation in laboratory sciences, we found that labs are often forced to update results codes for the same test based on differences in methods or instrumentation used in the testing that affect reference ranges. While the relevance of the testing methods varies depending on the clinical context, the testing methods do not always materially impact the interpretation of the results by the provider.

Experience from the regional health information exchange organizations (HIEs) shows that no two laboratories use the same local codes and laboratories change codes frequently as new testing procedures are introduced.⁴² To address this issue HIEs are moving toward LOINC mapping. In most cases, the approach has been incremental whereby the most common lab tests are mapped to LOINC codes.

Limited EHR adoption and availability to HIE systems. Interoperability between provider systems and laboratory systems implies the existence of computerized clinical information systems at provider offices. The most recent research indicates that fewer than one in four physician offices are using EHRs. Another opportunity for interoperable lab exchange could be supported by HIE‐based platforms. However, most ambulatory care providers do not have access to information or data applications supported by HIEs.

Opportunities for standards adoption and identification of best practices. While there are significant barriers to achieving widespread lab exchange, there are also some important opportunities originating from industry, the federal government, and charitable foundations. First, while our respondents indicated that some of the standards being recommended by HITSP are too difficult to implement at this time, most indicated that HITSP and specifically CCHIT play an important role in helping the technology industry move towards adoption of a consistent set of standards to support the lab exchange use cases most important for quality improvement. In particular, it may be useful to explore alignment of certification programs that relate to non‐EHR systems, including those used in hospitals and labs with CCHIT. Given the large investments that labs have made in their existing laboratory information systems they are more likely to upgrade rather than purchase a new system. The return on investment will need to be demonstrated before the laboratory industry will replace existing systems.

In addition, a recent effort sponsored by the California HealthCare Foundation (CHCF) called the EHR‐Lab Interoperability and Connectivity Specification (ELINCS) project has worked to take a step beyond identification of a standard and has mapped out an implementation guide. The guide not only focuses on mapping specific standards to lab results, but also discussed the whole process of using lab exchange to deliver real‐time laboratory results from a lab's information system to an EHR.

As part of ELINCS, CHCF worked to standardize the formatting and coding of electronic messages exchanged between clinical laboratories and EHR systems. The project used LOINC as a tag for each common test, and then refined the process for exchange through a series of pilot studies involving providers, clinical laboratories and integrated delivery systems in the state of California. ELINCS has worked closely with other national and international efforts to develop their specifications and implementation approach. ELINCs has been tested with: a number of the major ambulatory EHR vendors including AllScripts, NextGen, Emdeon and e‐MD; major reference labs such as Quest, LabCorp, and Spectrum; and hospital laboratory information systems including Misys, McKesson and Antek.⁴³ The California HealthCare Foundation has also granted approximately $720,000 to support various ELINCs pilot projects.⁴⁴

CONCLUSIONS

EHR adoption and lab exchange go hand in hand for Quality Improvement (QI) in ambulatory care. Given that safety net providers and health centers, in particular, serve a disproportionate share of chronically ill individuals, QI in health centers depends significantly on close tracking of laboratory results, such as HbA1c and LDL. Health centers typically engage in disease management programs that rely on EHRs and disease registries to track lab‐based indicators among specific populations. As such, having an automated, seamless electronic link between provider systems and laboratory results reporting can serve as an important component of QI.

More needs to be learned about costs, and how to make sure those who benefit pay. While we were able to secure conversations with clinical laboratories and vendors, they were not forthcoming regarding the true cost or prices associated with development of interfaces. Health centers and health center network discussants indicated that while there are some up front costs associated with purchasing interface functionality from vendors and third party interface providers, there are also significant ongoing costs associated with monitoring and maintaining each interface. The latter costs are largely borne by providers and their networks. Because pricing for lab interfaces is often packaged with a broader set of services, additional research is needed to understand the true costs of developing interfaces and how these costs are different if exchange is achieved in the context of a laboratory portal, health information exchange or RHIO.

Little is known about the cost and complexity associated with life cycle cost adoption, validation and maintenance (including managing upgrades) of these standards. Part of the difficulty with estimating costs of establishing and using lab interfaces relates to the complexity of implementation. Our discussions demonstrated that even once an interface is in place and operating for a time, constant monitoring is required to assure that orders and results are validated and adjudicated appropriately as laboratory results codes change or new tests create new interface requirements. The burden of validation on a single provider is multiplied by the number of labs they work with (which is usually dictated by payers). For standards that are currently in use, there exist gaps and limitations that will need to be addressed. While much work has been done with respect to delivery of lab results, new work is underway to outline the standards and specifications to support the ordering of labs. In addition to the technical aspects of standards adoption, completing a more systematic review of costs associated with adopting standards and how the benefits accrue to various participants will help make the business case for standards adoption. The experiences of stakeholders serving as discussants for this paper demonstrate that there is a risk if standards are recommended absent practical assessment of the willingness and ability of stakeholders to implement them. Finally, health center networks that work with multiple providers, sites, and their associated clinical labs may bear a particularly high cost associated with process validations and other maintenance activities.

Widespread adoption of clinical standards takes time. It is important to note that the typical trajectory for adoption of clinical standards in health care may be slower than administrative transactions in health care and other industries. The experience with the slow adoption of SNOMED may be illustrative of the natural trajectory of standards adoption. In the absence of an immediate imperative in the form of a regulatory or business requirement to use standard‐based interoperable HIE, those stakeholders and vendors involved in HIE may not converge on standards for several years. Even with efforts underway to encourage consensus and generate recommendations, the lack of clear incentives to converge on a single set of standards and confusion regarding regulatory requirements may extend this trajectory even further.

It is important to combine standards recommendations with specific implementation approaches and realistic best practices. The efforts of federal agencies, the AHIC, HITSP and various standards development organizations have created momentum for identifying standards for adoption as well as highlighting current gaps that will need to be addressed. To promote information exchange between hospitals, health centers and labs, standards need to be implemented in a consistent and replicable way. By developing detailed and concise guides that outline optimum approaches to implementation, organizations will be able to establish electronic connectivity within a shorter time frame, at a significantly reduced cost and with a limited need for interface expertise. For health centers and networks, which are often resource constrained, this is particularly important. Focused efforts to develop implementation guides for safety net clinics and health centers and their business partners are likely to accelerate standards‐based exchange.

Current standards apply to a limited set of laboratory functions and results. While there are major standards identified that support the exchange of lab information – notably HL7, LOINC, SNOMED, UCUM and OID – there appears to be limited adoption of the standards by laboratories and vendors. Further, standards that apply to anatomical pathology, genetic testing, and other fields have not yet been fully developed. Although the adoption of HL7 V2.x is fairly broad, the variability in its implementation continues to pose challenges. While HL7 V3 can be implemented in a more standard way, experience with V3 is very limited both in the United States and internationally. Today, there are no large scale implementations of V3, and the migration path from V2 to V3 is costly due to the lack of backward compatibility between versions. ⁴⁵

Regulatory Compliance and Certification. Currently, significant regulatory impediments prevent effective laboratory information exchange. In a networked environment, CLIA regulations will need to be re‐examined with respect to who should be held accountable for correct display of lab results to the authorized provider, transmission of data consistent with CLIA requirements, and timeliness of results delivery. While CLIA has many applications, it is important to note that there are many exceptions to CLIA regulations. Most notably, CLIA applies to physician office labs, with modification for waived testing as noted above.⁴⁶ A review of the consistent interpretation of CLIA at a state level is essential. Similarly, State laws and regulations with respect to privacy, data use limitations and confidentiality remain significant barriers and will need to be reviewed from the context of laboratory information exchange. Finally, under CLIA, labs are required to test and verify the integrity of every lab interface they establish with provider offices and health centers.

Additionally, through CMS has approved accrediting organizations like CAP, labs may be periodically required to verify all interfaces with provider offices or health centers. This requirement is considerably different from CCHIT certification where particular versions of a product are certified rather than every implementation of the lab interface.

CCHIT certification currently applies to EHR vendors and looks to both HITSP and the industry on understanding market readiness for the adoption of functions and standards. Assessing the feasibility of similar certification for hospital systems and lab systems may need to be explored. Although, as noted above, such a certification system does not necessarily assure that each interface in the installed base is functioning correctly. For broad scale standards adoption, all of the participants in the chain of information exchange will need to play a role in either sending or receiving data in a consistent way.

Finally, health centers and other safety net providers will continue to face additional barriers to achieving lab exchange. A number of health centers have been able to establish networks to adopt health IT. Health centers, by virtue of their mission and the populations they serve, may also benefit more than other providers from health IT adoption. Yet, the complexity involved in lab exchange and the burdens associated with establishing and maintaining interfaces underscore the particularly difficult path facing safety net providers.

Footnotes

1. Institute of Medicine. To Err Is Human, Building a Safer Health System. November 1999.
2. The Lewin Group. Laboratory Medicine: A National Status Report. May 2008. Available at http://www.futurelabmedicine.org/reports/laboratorymedicine‐anationalst…. Accessed on July 1, 2008.
3. American Health Information Community. Letter to the Honorable Michael O. Leavitt. 2006. Available at http://www.hhs.gov/healthit/ahic/materials/meeting04/ehr/EHRDraftRecs.d… . Accessed on April 16, 2008.
4. Poon EG, Wang SJ, Gandhi TK, Bates DW, Kuperman GJ. Design and Implementation of a Comprehensive Outpatient Results Manager. Journal of Biomedical Informatics. 2003; 36: 80‐91.
5. Weydert JA, Nobbs ND, Feld R, Kemp JD. A Simple, Focused, Computerized Query to Detect Overutilization of Laboratory Tests. Archives of Pathology &Laboratory Medicine. 2005; 129: 1141‐1143.
6. Eisenberg JM, Williams SV, Garner L, Viale R, Smits S. Computer based Audit to Detect and Correct Overutilization of Laboratory Tests. Medical Care. 1977; 15(11): 915‐ 921.
7. The Lewin Group. Laboratory Medicine: A National Status Report. May 2008. Available at http://www.futurelabmedicine.org/reports/laboratorymedicine‐anationalst…. Accessed on July 1, 2008.
8. Tabak YP et al. Using automated clinical data for risk adjustment development and validation of a six disease‐specific mortality predictive models for pay‐for‐performance. Med Care 2007; (45):789‐805.
9. French DH. The Laboratory’s role in the Universal Electronic Health Record. MLO Med Lab Obs. 2006; 38(4): 10‐15.
10. Avalere Health LLC for the Agency for Healthcare Research and Quality. Evolution of state health information exchange: a study of vision, strategy, and progress. 2006. Available at: <http://www.avalerehealth.net/research/docs/StatebasedHealthInformationE…;. Accessed on March 1, 2008.
11. Office of the National Coordinator for Helath Information Technology. Harmonized Use Care for Electronic Health Records (Laboratory Result Reporting). March 19, 2006.
12. D.W. Bates et al. Effect of Computerized Physician Order Entry and a Team Intervention on Prevention of Serious Medication Errors. Journal of the American Medical Association. 1999; 280 (15): 1311‐1316.
13. R. Koppel et al. Role of Computerized Physician Order Entry Systems in Facilitating Medication Errors. Journal of the American Medical Association. 2005; 291 (10): 1197‐1203.
14. Shields AE et al. Adoption of health information technology in community health centers: results of a national survey," Health Affairs 26; 5 (2007)
15. CMS CLIA Regulation
16. CLIA waived and PPM Tests Defined
17. 42 CFR 493.15(e)(1)
18. College of American Pathologists Laboratory Information System Survey. November 2008. Accessed November 19, 2008.
19. Current Ambulatory EHR Criteria. Certification Commission In Health Information Technology. Available at http://www.cchit.org/ambulatory/criteria/. Accessed November 19, 2008.
20. CCHIT Certified 08 Ambulatory EHR. Available at http://www.cchit.org/choose/ambulatory/08/index.asp. Accessed November 19, 2008.
21. Ribick A. HL7 Releases Newest Approved American National Standard: Version 2.5.1. Health Level Seven. June 15, 2007. Available at http://staging.hl7.org/News/Pages/HL7PRESS20070615.pdf. Accessed November 19, 2008.
22. Harmonized Use Case for Electronic Health Records (Laboratory Reporting Use Case), March 19th 2006.
23. HITSP Electronic Health Records Laboratory Results Reporting Interoperability Specification, May 16th, 2008. Version 3.0.
24. HITSP Electronic Health Records Laboratory Results Reporting Interoperability Specification, May 16th, 2008. Version 3.0.
25. Harmonized Use Case for Electronic Health Records ( Laboratory Reporting Use Case), March 19th 2006
26. General Laboratory Orders, Draft AHIC Extension/Gap. August 15th 2008. U.S Department of Health and Human Services, Office of the National Coordinator for Health Information Technology.
27. Integrating the Healthcare Enterprise (IHE). Available at http://www.ihe.net/. Accessed November 19, 2008.
28. Laboratory Technical Framework. Integrating the Healthcare Enterprise (IHE). Available at http://www.ihe.net/TechnicalFramework/index.cfm#laboratory. Accessed November 19, 2008.
29. Dogac A, Namli T, Okcan A, Laleci G, Kabak Y, and Eichelberg M. Key Issues of Technical Interoperability Solutions in eHealth and the RIDE Project. Available at http://ec.europa.eu/idabc/servlets/Doc?id=27836. Accessed November 19, 2008.
30. Ibid.
31. Evolution of HL7 from V2 to V3 – Ms. Iona Singereanu
32. Vreeman DJ, Finnell JT, and Overhage JM. A Rational for Parsimonious Laboratory Term Mapping by Frequency. American Medical Informatics Association (AMIA) 2007 Symposium Proceedings.
33. Ibid.
34. Kaiser Permanente's Convergent Medical Terminology by Dolin RH et al, Stud Health Technol Inform. 2004;107 (Pt 1):346-50
35. Mapping Department of Defense Laboratory Results to Logical Object Identifiers Names and Codes (LOINC®) by Lee Min Lau et al. AMIA 2005 Symposium Proceedings ‐430
36. Commonly Used UCUM Codes for Healthcare Units. http://www.hl7.de/download/documents/ucum/ucumdata.html. Accessed November 19, 2008.
37. SNOMED CT Survey: An Assessment of Implementation in EMR/EHR Applications, Foundation of Reseach and Education (FORE) of the American Health Information Management Association (AHIMA), published online, May 2008.
38. Department of Health and Human Services, National Health Information Network: Background. Available at http://www.hhs.gov/healthit/healthnetwork/background. Accessed November 19, 2008.
39. Ibid.
40. CMS CLIA Database, June 2008.
41. Section §493.1291(g) of the CMS CLIA Regulation
42. Young S. State and Regional Demonstration Projects: Laboratory Exchange.2006. PowerPoint presentation available at http://www.hhs.gov/healthit/ahic/materials/meeting03/ehr/AHRQdemo.ppt. Accessed on November 18, 2008.
43. Implementing the ELINCs Standard: Technical Experiences from the Field – California Healthcare Foundation Issue Brief, October 2007
44. ELINCS: Developing a National Lab Data Standard for EHRs. February 2006. California Healthcare Foundation. Accessed November 19, 2008. www.chcf.org/topics/chronicdisease/index.cfm?itemID=108868&subsection=r….
45. Dogac A, Namli T, Okcan A, Laleci G, Kabak Y, and Eichelberg M. Key Issues of Technical Interoperability
46. CMS Initiatives to Improve Quality Testing Under the CLIA Program, July 2006.

How to Obtain a Printed Copy

To obtain a printed copy of this report, send the title and your mailing information to:

If you are interested in this, or any other ASPE product, please contact the Policy Information Center at (202) 690-6445. Or you may email us at pic@hhs.gov

.