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).19 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.20
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.