|Home | About | Journals | Submit | Contact Us | Français|
Clinical laboratory outreach business is changing as more physician practices adopt an electronic medical record (EMR). Physician connectivity with the laboratory information system (LIS) is consequently becoming more important. However, there are no reports available to assist the informatician with establishing and maintaining outreach LIS–EMR connectivity. A four-stage scheme is presented that was successfully employed to establish unidirectional and bidirectional interfaces with multiple physician EMRs. This approach involves planning (step 1), followed by interface building (step 2) with subsequent testing (step 3), and finally ongoing maintenance (step 4). The role of organized project management, software as a service (SAAS), and alternate solutions for outreach connectivity are discussed.
Many hospital laboratories have developed or are enhancing their outreach programs (i.e. performing laboratory services for the non-inpatient) to increase their test volumes, utilize excess capacity (i.e. improve productivity), bring on esoteric tests in-house, and consequently ease their financial burden.[1–3] It is estimated that around 90% of hospitals in the USA have some type of laboratory outreach program. Clinical laboratory outreach business appears to be increasing as more physician practices adopt an electronic medical record (EMR). Understandably, physicians want to access their patient's results and electronically order laboratory tests within their own EMR. As a result, client connectivity with a legacy laboratory information system (LIS) is becoming more important in competitive environments.[5,6] Electronic health information exchange is a key component of competing effectively in the laboratory outreach market.
Much attention has been focused on important business strategies aimed at creating and maintaining a successful outreach program. Some of these tactics include aggressive marketing, hiring of a focused sales team, staffing client services, competitive pricing, seeking out managed care affiliations, offering timely and appropriate testing services, providing convenient courier services and last, but not the least, deploying a sophisticated LIS. However, there are no published guidelines for informaticians to follow in order to assist their laboratories in establishing and maintaining outreach LIS–EMR interfaces. This technical note provides a stepwise approach, based upon experience at one institution, to successfully interface an LIS with multiple regional EMRs.
A separate Clinical Pathology LIS (Sunquest version 6.2, Sunquest Information Systems, Tucson, AZ, USA) and Anatomical Pathology LIS (CoPath version 3.1, Cerner Corporation, Kansas City, MO, USA) were utilized by Baystate Reference Laboratories (BRL; Springfield, MA, USA). Many regional physician practices referring their laboratory testing to BRL had acquired a wide variety of EMRs (including eClinicalWorks, MediNotes, SOAPware, NextGen, Script Sure, Sage Medical manager, SSIMED EMRge, Allscripts, Renal Track, ePro, Athena Health, and Practice Partner). In addition to relying on laboratory and hospital information services technical staff, a software as a service (SAAS) business model was employed using Initiate (an IBM company) Exchange platform with additional exchange service components, including Master Data Synchronization Service and TXM Bidirectional Reconciler. Transmission of data in this health information exchange model is illustrated in Figure 1. Data exchange consisted of two components: (a) appliance boxes called Initiate Lynx which are physically located at each end of the data feed and (b) servers at Initiate's datacenter. The Initiate Lynx communication device contains a Linux-based operating system within a small form factor personal computer about the size of a home cable box. Therefore, the laboratory had online access to outreach software (e.g. Master Data Synchronization Service) to build and maintain LIS–EMR interfaces. Initiate also provided assistance with technical operations, implementation and 24 × 7 software and service support by means of a complete monitoring toolset that proactively identifies integration type error conditions along the health exchange network to and from all practices. Data to and from the LIS was transmitted via the hospital's interface engine (SUN eGate) through a firewall to the SAAS vendor's server, from where the converted and remapped data were deployed to all physician EMRs.
A four-stage scheme was employed to establish unidirectional and bidirectional interfaces with physician practice EMRs. This approach involved planning (step 1), followed by interface building (step 2) with subsequent testing (step 3), and finally ongoing maintenance (step 4).
Step 1: The initial planning phase included finance (budget), infrastructure, test volume (tests/year/practice) and backload parameter analysis. “Backload” refers to archival data clients requested to be added to their EMR, determined by performing a retrospective LIS data review specific for each physician client practice. Archival LIS data up to 2 years back were transmitted to select EMRs. At this stage, the identification of resources, roles, and responsibilities was carried out, and a schedule determined.
Step 2: In several EMRs, the test names and codes did not match those used by the LIS. In order to address this discrepancy, the so-called build phase involved the creation of a test compendium for bidirectional interfaces using IBM's Initiate Exchange software, specifically the Master Data Synchronization Service. The test compendium is a practice-specific translation table matching test codes and nomenclature between the computerized physician order entry (CPOE) module in the EMR and those in the LIS. The compendium mapped both order codes [Table 1] and result codes [Table 2] in the HL7 message. As unidirectional interfaces involved only result reporting, no such compendium was required. As no virtual private networks (VPN) were involved in this configuration, all clients required internet connectivity before appliance boxes, as depicted in Figure 1, and this was installed at their end behind the practice's firewall.
Step 3: In the production phase, the laboratory was required to validate secure connectivity, match results to orders, adjust and endorse EMR lab data content and display (using electronic screenshots, EMR printed reports and/or GoToMeeting), as well as reconcile mismatched orders and/or results [Table 3]. The GoToMeeting web conferencing tool allowed the laboratory to securely collaborate online in real time with multiple remote EMR users, to view the display of laboratory data in the downstream EMR system. The TXM Bidirectional Reconciler was run on a dedicated Java 2 enterprise application server in Initiate's secure datacenter.
Step 4: For this monitoring phase, a prior service-level agreement with clients was required, along with a downtime procedure, connectivity monitor, monitoring of EMR and LIS error capture logs, mechanisms to continually check the display of EMR lab data and update the test compendia, as well as a change control procedure for potential software upgrades.
There are several take-home messages from the aforementioned approach used to connect the LIS with multiple disparate EMRs. First, a project management approach is fundamental. Proper planning, organization, and management of resources are necessary to successfully complete any project. Developing an outreach program may require additional resources and alignment of technical efforts with business goals. Second, SAAS in this instance formed a vital component of establishing and maintaining laboratory outreach connectivity. SAAS is a model of software deployment whereby the provider (Initiate in this case) offers a full service solution to customers (our laboratory) for use as a service on demand. In this model, the SAAS vendors host their application on their own servers, providing web-based access to and management of their remote software. The SAAS vendor further provides and supports all hardware, including communication devices on the entire exchange platform. This scalable model permitted the laboratory to focus their budgets on competitive rapid deployment, rather than infrastructure.
Physician connectivity can be accomplished directly through the LIS or hospital information system using an interface engine platform or by means of a separate outreach “wraparound” (kludge) system. The approach described in this technical note provides an example of such a wraparound system. While establishing connectivity directly with the laboratory hospital may take longer and taxes hospital IT resources, this solution offers the client access to all patient medical record information. On the other hand, while specialized wraparound systems may require additional funding, they usually offer more capabilities (e.g. interface reconciler, generation of advanced beneficiary notice forms, etc.) and can support more rapid creation of new connections. Other solutions to connect remote practices with a laboratory include secure web-based portals, allowing clients to submit orders and receive results via the Internet. Physician connectivity with the laboratory often facilitates an infrastructure to establish electronic exchange of all health information (e.g. radiology, cardiology, etc.). This is imperative for retaining clients because physician practices are particularly interested in integrating their EMR to as much clinical information in the patient record as possible. Finally, enhanced LIS features that better support outreach programs, interoperability standards, and improved EMR vendor cooperation are essential for electronically integrating healthcare.
The authors thank Michael J. Connors for his critical review of the manuscript.
Available FREE in open access from: http://www.jpathinformatics.org/text.asp?2010/1/1/5/63829