Implementation of Epic Beaker Clinical Pathology at an academic medical center

Abstract

Background:

Epic Beaker Clinical Pathology (CP) is a relatively new laboratory information system (LIS) operating within the Epic suite of software applications. To date, there have not been any publications describing implementation of Beaker CP. In this report, we describe our experience in implementing Beaker CP version 2012 at a state academic medical center with a go-live of August 2014 and a subsequent upgrade to Beaker version 2014 in May 2015. The implementation of Beaker CP was concurrent with implementations of Epic modules for revenue cycle, patient scheduling, and patient registration.

Methods:

Our analysis covers approximately 3 years of time (2 years preimplementation of Beaker CP and roughly 1 year after) using data summarized from pre- and post-implementation meetings, debriefings, and the closure document for the project.

Results:

We summarize positive aspects of, and key factors leading to, a successful implementation of Beaker CP. The early inclusion of subject matter experts in the design and validation of Beaker workflows was very helpful. Since Beaker CP does not directly interface with laboratory instrumentation, the clinical laboratories spent extensive preimplementation effort establishing middleware interfaces. Immediate challenges postimplementation included bar code scanning and nursing adaptation to Beaker CP specimen collection. The most substantial changes in laboratory workflow occurred with microbiology orders. This posed a considerable challenge with microbiology orders from the operating rooms and required intensive interventions in the weeks following go-live. In postimplementation surveys, pathology staff, informatics staff, and end-users expressed satisfaction with the new LIS.

Conclusions:

Beaker CP can serve as an effective LIS for an academic medical center. Careful planning and preparation aid the transition to this LIS.

INTRODUCTION

Laboratory information systems (LISs) receive, store, and manage clinical laboratory data.[1,2,3] Clinical laboratories may use a single LIS or multiple ones depending on scope of laboratory testing and desired functionality. While some clinical laboratories have developed their own LISs, many laboratories utilize commercially available software. Commercial LIS products vary in their capabilities.[3] For example, some LIS vendors offer products for blood bank and transfusion medicine while others do not.

Epic Beaker is a relatively new LIS operating within the Epic suite of software applications (Epic Systems, Inc., Madison, WI, USA). Epic is a commonly used electronic health record (EHR) in the United States, and the use of Epic Beaker has the potential to provide an enterprise-wide solution for the laboratory and hospital information systems. Epic Beaker Clinical Pathology (CP) (referred to as “Beaker CP” hereafter) is available as a separate module for users of the Epic EHR. Epic also markets Beaker anatomic pathology (AP) and software for patient scheduling (Cadence), patient registration (Prelude), and revenue cycle (Resolute) in addition to numerous modules for various clinical specialties. Epic does not currently market an LIS module for blood bank/transfusion medicine.

Unlike some other commercial LIS products, Epic Beaker does not interface directly with laboratory instrumentation. The route for interfacing is via middleware software, principally Instrument Manager and Dawning from Data Innovations (Burlington, VT, USA). The reliance of Beaker CP interfacing on middleware from a single vendor raises a potential challenge with respect to instruments that predominantly use middleware from other vendors. In particular, Instrument Manager can be used to interface data from the other middleware system, in some cases essentially functioning as a simple “pass-through” to transmit data from the other middleware to Beaker. This approach necessarily results in data navigating a complex pathway through two middleware products and often additional hardware and firewalls. The reliance on middleware software may also create potential future challenges if there are company mergers or acquisitions that impact the middleware vendor.

The alternative approach is to interface the instrument directly to Instrument Manager; however, this may require development of rules within Instrument Manager that in essence mimic the function of the other middleware. This last option may be difficult or even infeasible in some situations, especially if the other middleware product controls complicated functions such as reflex testing, specimen routing, re-runs, or other instrument actions. Troubleshooting rules and interface issues between two middleware systems and an LIS may be very complicated.

In this report, we describe our experience in implementing Beaker CP at the University of Iowa Hospitals and Clinics (UIHC), a state academic medical center, with a go-live of August 2014. The medical center adopted Epic as its EHR in 2009; however, the laboratory continued using its legacy LIS between 2009 and 2014. This report is written approximately 1 year after Beaker CP implementation to provide perspective on both short- and long-term issues. The implementation of Beaker CP at the medical center was concurrent with implementations of Epic Cadence, Prelude, and Resolute.

TECHNICAL BACKGROUND

Institutional Details

The institution of this study (UIHC) is a 734-bed tertiary care state academic medical center that includes an emergency room with level one trauma capability, pediatric and adult inpatient units, and multiple Intensive Care Units (ICUs) (neonatal, pediatric, cardiovascular, medical, and surgical/neurologic), as well as primary and specialty outpatient services. The UIHC is the largest teaching hospital in the state of Iowa. Outpatient services are located at the main medical campus, as well as at a multispecialty outpatient facility located three miles away. Smaller primary care clinics are located throughout the local region. Since May 2009, the EHR throughout the healthcare system has been Epic. The LIS for all clinical laboratories (including CP and AP) since 1996 has been Cerner “Classic” (Kansas City, MO, USA). Both EHR and LIS are managed by a consolidated information technology department for the medical center, Health Care Information Systems (HCIS).

Pathology Laboratories and Their Informatics

With respect to pathology testing, a core clinical laboratory within the Department of Pathology provides clinical chemistry, hematopathology, and flow cytometry testing. There are also separate clinical laboratories for AP, blood center, and microbiology/molecular pathology located within the main medical campus. Two critical care laboratories (one located near the main operating rooms and another embedded within the neonatal ICU) perform blood gas and other fast turnaround time testing. Nine months after the implementation of Beaker CP, the critical care laboratory near the operating rooms was relocated to the core clinical laboratory.

Table 1 summarizes the preimplementation interfaces for the clinical laboratory instruments that were ultimately impacted by the switch of the LIS to Beaker CP. Prior to Beaker, there were instruments that interfaced directly with Cerner, as well as others that utilized Instrument Manager or Dawning. The main hematology analyzers used the Molis WAM middleware product (Sysmex Inc., Lincolnshire, IL, USA) to interface the analyzers to the Cerner LIS. Up to 2013, the clinical laboratories used Instrument Manager mainly for interfacing to clinical chemistry and coagulation analyzers. As previously reported, the core laboratory uses extensive autoverification rules for chemistry testing within Instrument Manager.[4]

Table 1.

Instrument interfaces

Scope of Laboratory Information System Project

During the strategic decision-making process related to the change in the LIS, it was known that Cerner was to discontinue support for the Cerner Classic LIS product at the end of 2015. Therefore, LIS replacement needed to occur before that date. Hospital administration had also decided to implement the Epic Cadence, Prelude, and Resolute products, replacing functionality provided by products from other vendors. Ultimately, the decision was reached to implement Beaker CP along with the scheduling, registration, and revenue cycle modules from Epic. The alternative approach of uncoupling the Beaker CP project with the other Epic changes would have necessitated a large amount of work in interfacing Beaker with the older revenue system, only to have that functionality replaced by Epic Resolute within 6 months. Beaker 2012 was the version at go-live. An upgrade to Epic 2014 occurred on May 2, 2015. This was still the Epic version at the time this manuscript was submitted.

UIHC went live with the Epic EHR in 2009. For Beaker, UIHC did not use the Epic “model system” as a foundation, instead using the existing test build from the previous LIS. Some reports, outstanding list views, result entry reports, and order inquiry reports were used for starting the model build, but they were revised based on input from subject matter experts (SMEs).

Replacements for the LISs for AP and blood bank/transfusion center were deferred to October 2015. The primary reasons for deferral of Beaker AP for UIHC were (1) Beaker 2012 offered less integration between Epic OpTime and Beaker AP, (2) lack of ability to separate relative value units (RVUs) for multiple pathologists involved in a single case, (3) lack of conditional logic for orders, and (4) no rich text availability in Beaker reports. Beaker 2014 offered a single specimen navigator for microbiology and AP, ability to separate professional charges within the same case (with ability to assign RVUs to a different pathologist than the sign-out pathologist), cascading questions in Epic orders, and rich text formatting for Beaker reports. UIHC has not customized any portion of the Beaker CP system. In general, UIHC does not support highly customized systems. Rather, we use the standard Epic functionality to ensure that we can take each subsequent Epic software version as they become available without need for ongoing maintenance of customization.

Sources of Data

This manuscript summarizes approximately 3 years of time (2 years preimplementation of Beaker CP and roughly 1 year after). The main source of information was the closure document for the LIS project, which was compiled by the HCIS project manager and finalized on October 31, 2014. This document summarized preimplementation and immediate postimplementation meetings, debriefings, and other data summaries. Additional data came from surveys and interviews of pathology and HCIS staff and management as part of the process to assess areas of success and need for improvement. This project was reviewed by the university Institutional Review Board and determined not to constitute human subjects research.

RESULTS

Project Timeline

Table 2 presents a breakdown of the phases for the project. The project initiation (August 1, 2012), with the assignment of a project manager from HCIS, was approximately 2 years before ultimate go-live on August 2, 2014. In October 2012, an LIS executive committee was formed that comprised leadership from pathology (including medical directors and departmental administration), HCIS, and hospital administration. The executive committee made the strategic decision to defer replacement of the LIS for AP and blood bank/transfusion medicine until late 2015.

Table 2.

Project phases and timelines

UIHC generally followed Epic recommendation guidelines (“Flight Plan”) week-by-week through the project. Epic set buckets at 25%, 50%, 75%, and 100% for the build, with dates and deadlines determined for every portion of the project. UIHC used Epic's project implementation plan with four main differences:

First, UIHC completed most of the build prior to workflow validation sessions. The workflow validation sessions were completed using the UIHC build environment, not the Epic model system build. Second, UIHC engaged more SMEs in the hands-on testing. Third, UIHC created spreadsheets for all orderables and resultables. SMEs completed integrated testing for 100% of all orderables and resultable components. Fourth, UIHC had monthly Beaker Milestone readiness assessment meetings for all team members. These status meetings brought together divergent personnel from hardware technical operations, desktop support, LIS builders, interface team, pathology medical directors, and SMEs to discuss progress or difficulties.

The original plan was for a go-live of Beaker CP, Epic Cadence, Epic Prelude, and Epic Resolute in May 2014. This was delayed primarily to allow for additional time to validate the revenue cycle module (Resolute) and to a lesser degree optimize system-wide impacts of switching to the Cadence and Prelude modules. The Beaker CP project was ready to go-live in May 2014 but was delayed to follow the original plan to do a coordinated go-live for the four Epic modules. Figure 1 depicts a timeline summarizing some of the key activities involved in the implementation of Beaker CP. A key to project success was the early assignment of SMEs and the institution of monthly readiness/milestone assessments.

Figure 1.

Timeline for key events in the project

The Beaker CP project involved 1852 orderable laboratory tests with approximately 5660 resultable components. The project utilized 22 full-time equivalent (FTE) SMEs from the laboratory staff, 4 FTEs from the pathology informatics staff, and 9 FTEs from hospital informatics (HCIS). During the project timeline, there was wide variation in hours per week spent on the project from the laboratory or HCIS staff. During time periods with the heaviest validation periods, approximately 40 h/week was required. During time periods with the lowest validation requirements, approximately 4 h/week was needed.

Another key to success was regular engagement of the executive committee in monitoring project progress and deferring some items to post go-live. Examples included postponement of some instrument interfacing, particularly in laboratory areas such as immunopathology (located within the section of AP at UIHC) that had no prior experience with middleware but had some testing (e.g., antinuclear antibody immunofluorescence) migrating to Beaker CP. These decisions used the guiding principle of which issues were go-live critical versus not.

Interfacing of Instruments and Autoverification Rules

As noted in the introduction, Beaker CP does not directly interface with laboratory instrumentation and instead utilizes middleware software from Data Innovations. Table 1 shows the pre-Beaker CP state of the clinical laboratories with respect to instrument interfaces. Depending on instrumentation, there were direct interfaces to the previous LIS (Cerner) or to one of four middleware products (Instrument Manager; Dawning; Molis WAM; or RALS for blood gas analyzers [Alere Informatics, Livermore, CA, USA]). Multiple instruments within the microbiology/molecular pathology laboratory were not interfaced prior to Beaker CP. There were detailed rules in middleware, including for autoverification, for the main chemistry (Roche Diagnostics; interfaced to Cerner via Instrument Manager) and hematology automation lines (Sysmex; interfaced to Cerner via Molis WAM).

In general, the issue of instrument interfacing required extensive resources and discussion between our institution, Epic, Data Innovations, and various instrument vendors, particularly since we were a relatively early adopter of Beaker CP. After deliberation, the LIS executive committee and the medical directors of the clinical chemistry and hematopathology laboratories decided to interface all core laboratory instruments with Instrument Manager, which included the discontinuation of Dawning (urinalysis instruments) and replacement of the interface functionality of Molis WAM (hematology line), as well as the use of Instrument Manager instead of RALS for interfacing of blood gas analyzers (Radiometer; Copenhagen, Denmark; note that interfacing of Radiometer instruments also involves the Radiance software from Radiometer) within the two critical care laboratories. The RALS (Alere) middleware system continued to be used for the Roche Diagnostics Accu-Chek glucose meters.

The most challenging change at UIHC was the development of extensive rules within Instrument Manager to replace the instrument to LIS interface functions of Molis WAM. This switch required significant time investment but ultimately has reduced the number of middleware systems that clinical laboratory personnel need to navigate in managing chemistry and hematology testing. This switch benefited from long-term experience and expertise within the Department of Pathology with Instrument Manager. The alternative approach would have been to use Instrument Manager as a “pass-through” to transmit data from Molis WAM to Beaker. This approach, while certainly viable, carries the challenge of a more complex pathway for data along with additional hardware and firewalls.

In general, autoverification rules were kept within Instrument Manager since these had been extensively developed and utilized for years prior to switching the LIS.[4] There are autoverification rules built within Beaker, but they simply autoverify what Instrument Manager sends. Most tests are set up on the test level when to autoverify, meaning there is a Beaker rule for each one. For example, the rule for serum potassium looks for numeric or text results, then autoverifies. More complexity is introduced with panels of testing such as the basic metabolic panel. Currently, there is not a way to transmit via the interface message to Beaker that a result should be autoverified or not.

For some instruments, interfacing did require use of two middleware products [Table 1]. For example, some of the instruments within the microbiology/molecular pathology laboratory utilize EpiCenter, a middleware product from Becton Dickinson (Franklin Lakes, NJ, USA) that manages microbiology data. Instrument Manager was used to pass data from EpiCenter to Beaker while retaining all of the functionality of EpiCenter.

Preimplementation Challenges

Table 3 summarizes the major challenges encountered in the project. In the preimplementation phase of the project, there were four major technical challenges. The first was that major workflow changes were needed for ordering of microbiology testing. This had substantial impact on the operating rooms and is discussed in more detail in the next section. The second challenge related to obtaining and validating drivers for Instrument Manager to allow for interfacing of all the instruments listed in Table 1. As Beaker CP was a relatively new LIS, drivers did not exist in some cases and had to be developed. This required navigating multiple vendors but was ultimately successful.

Table 3.

Major issues encountered

The third major challenge related to laboratory-initiated orders (LIOs) for samples that came to the laboratories and required laboratory staff to generate orders within the LIS. The process for generating LIOs within Beaker CP was more time-consuming relative to the previous LIS, although intuitively more straightforward for staff with less experience. For several years prior to Beaker go-live, the medical center had been steadily converting inpatient units and clinics to “paperless” ordering, in which the clinical area directly places an LIS label readable by the laboratory instrumentation on the specimen. This replaced a previous system where generic patient identification labels were placed on specimens that were accompanied by paperwork for the laboratory orders. With the transition to Beaker CP, essentially all remaining clinics and inpatient units completed the transition to paperless ordering and collection. One of the additional challenges with Beaker CP was that the date and time of specimen collection needed to be entered by the one collecting the specimen. If this is not done, processing in the laboratory is delayed.

The fourth major challenge impacted the core laboratory. The previous LIS (Cerner) had the flexibility to allow either numeric or alphanumeric results in the same result field. This was used extensively in the core chemistry laboratory to allow for a result of “Hemolyzed,” “Icteric,” or “Lipemic” when indices for these interference parameters exceeded tolerance thresholds for individual tests.[4] When interferences prevented a numeric result from being reported, billing was also credited for the test. Thus, a given chemistry test could output a numeric result (which could be trended or graphed in the EHR) or one of these text results. Beaker CP only permitted a given laboratory-related result field to be either numeric or text (alphanumeric), but not both. The default process for resulting a quantitative test canceled due to interference would be to display “...” in Epic Results Review and thus require additional mouse clicks to see the specific reason for test cancelation. This option was felt to be a step back in customer service since providers were now used to seeing results such as “Hemolyzed” when scanning laboratory values in Epic Result Review (this was the process since 2009). The compromise solution was to create duplicate laboratory-related result fields for most automated chemistry tests (one numeric and one alphanumeric). This required additional complexity within Instrument Manager to determine which result to send to Beaker CP. For instance, for a plasma potassium result determined to be 5.4 mEq/L and absent any flags preventing verification, the numeric result was sent to Beaker and the alphanumeric result suppressed. Conversely, a test canceled due to hemolysis would have the numeric result suppressed from transmission and an alphanumeric result of “Hemolyzed” sent to the EHR. One side benefit of this complexity was the possibility of resulting both numeric and alphanumeric field in cases where the numeric result should post in the chart but the interference result would show as well. This was done postimplementation with a select number of tests with specific ranges of icterus (high bilirubin), an interference that can be very difficult to avoid for patients with ongoing hepatobiliary disorders. Rather than repeatedly canceling tests in patients whose bilirubin cannot be easily lowered, providers could then readily see in Epic Results Review a numeric result and the “Icteric” flag indicating icterus was in a range to possibly affect test results. Rules within Instrument Manager and Beaker can control the precise conditions for this type of arrangement.

Microbiology Workflow

One initial challenge for the laboratory was reconstitution of the master “organism list” and construction of a “tree”-based workflow. Beaker currently allows for 2¹⁶ – 1 or about 64,000 potential results. Organism names are concrete concepts in Beaker. Even though the number of organism names was far <64,000 in our initial design (about 2500 in our legacy Cerner build), the use of the same organism name in multiple discrete test results (e.g., due to different specimen sources or procedures) can combinatorially exceed 64,000. Therefore, a review of the Bruker BioTyper (Bruker, Billerica, MA, USA) database was performed; redundant organisms (e.g., individual species in the Pseudomonas aeruginosa or Bacteroides fragilis groups) were deleted, and the organism list was pared to about 1700 clinically significant organisms. The build process also avoided combinations of organisms and specimen sources or procedures that are irrelevant. These measures in total avoided exceeding the 64,000 test results limit for the microbiology organism build.

A second challenge was construction of “trees,” which are the structures that Beaker uses to guide laboratory workflow. We chose to keep trees straightforward and flexible, with most beginning with a morphologic indication and ending with mass spectrometric identification: staphylococcal, streptococcal, enteric Gram-negative, fastidious Gram-negative (does not grow on MacConkey agar), and yeast. Our medical center microbiology laboratory is a sentinel laboratory, and category A agents must not be worked up in a routine “tree” to avoid use of automated instruments. We therefore constructed a separate “Bacillus” tree to rule out Bacillus anthracis (causative agent of anthrax) by hemolysis and motility, and a “Gram stain” tree that captures other category A agents as well as other organisms that do not fit well into other trees. The trees at our medical center are thus unique and operate differently from stock Beaker CP functionality, which is intended to be a stepwise advancement down the trees until a terminal identification is made. Our medical center's Beaker trees are constructed as category lists, allowing technologists to rapidly move through trees, e.g., by performing a matrix-assisted laser desorption/ionization time-of-flight identification and skipping to the end of a tree without clicking through intermediate steps.

Additional issues encountered included creation of a traceable mechanism for banking isolates, resulting Gram stains within cultures rather than as a separate “test,” “floating” key results such as the Gram stain to make sure they follow a culture-in-progress in the Epic EHR, and patching over an inability to reorder isolates by clinical significance by initiating cultures with five placeholder isolates at a time so that “mixed flora” was always placed last.

Beaker was unable to issue quantitative results (e.g., “100,000 colony-forming units [CFU]/mL” or “100,000 CFU/g”). We therefore created “category lists” for urine cultures that result greater than, less than, or between threshold amounts. This allowed the >100,000 CFU/mL category that meets the Centers for Disease Control and Prevention National Healthcare Safety Network catheter-associated urinary tract infection standard to be passed to infection control through an interface through TheraDoc (Premier, Inc., Charlotte, NC, USA). Other quantitative cultures required a custom solution that may not be applicable to other sites; for example, numbers in quantitative cultures were set up as a new result type to which units are added when displayed in the Epic EHR.

Automatic workflow optimizations included the ability to enter standard rejection criteria as “growth” values in sputum cultures and application of the appropriate charges. For inducible clindamycin resistance, a generic mechanism was created to remove susceptible results if isolates were D-test positive. Cryptococcal antigen titers (IMMY CrAG; IMMY Inc., Norman, OK, USA) were automatically calculated from dilution series and normalized to a predicate method (CALAS; Meridian Life Science Inc., Memphis, TN, USA) by calculations internal to Beaker.

Finally, quality control optimizations were made to the result review process. Specimens could be assigned to one or multiple benches for ease of follow-up (e.g., stat-testing bench and bacteriology bench). Further, after final supervisor review, results could be sent back to individual benches for revision; in this case, specimens with review status set to pending/preliminary were highlighted in pink to assign them high priority and for special attention to quality control.

Because the previous LIS was not interfaced directly to the Epic EHR, microbiology reports were not as cleanly formatted as those interfaced from Beaker CP. Microbiology reports became more effective as exemplified by a common example in Figure 2. Documentation of critical result reporting in Beaker is displayed prominently, with less critical data related to the specimen placed behind a hyperlink.

Figure 2.

Examples of some differences in microbiology reporting in the Epic electronic health record between the previous laboratory information system (Cerner Classic) and Beaker Clinical Pathology. (a) A Cerner Classic report of a positive blood culture for Staphylococcus aureus is in narrative form and mixes both key and extraneous information. The initial Gram stain result can be found under “preliminary” information. (b) A Beaker Clinical Pathology report from a similar case, with key differences labeled numerically. 1: The organism identification is highlighted in yellow and labeled as abnormal with “(A)”. 2: The Gram stain (or stains if multiple bottles) is highlighted and the blood culture bottle (aerobic, anaerobic, or both) that turned positive is indicated. 3: Previous/preliminary results are available for review behind a hyperlink. 4a/4b: Documentation of critical result reporting is displayed prominently (4b), but less critical data related to the specimen is placed behind a hyperlink (4a). Other features such as susceptibility testing and related comments are similar in form and placement

Issues Encountered Soon After Implementation

The major issues encountered shortly after implementation were difficulty reading barcodes on labels and problems with workflow with microbiology orders from the operating rooms. Bar codes were heavily tested as part of mapped record testing by the SMEs. However, one of the main challenges with paperless ordering was improper label placement by nonlaboratory staff. At times, a high percentage of labels created scan errors for various core laboratory analyzers. This required laboratory staff to intervene and manually process orders. Compounding the challenge was that the move to paperless ordering also meant that a large amount of hardware (e.g., label printers) was new to many clinical areas. This led to adoption of “notched” labels that aided in proper alignment of the label on the tubes. In addition, the size of the barcode was shrunk to increase readability on laboratory instruments. Intermittent problems with label ink density resulted in scan errors. Overall, issue with labels required intensive troubleshooting in the short term but was mostly resolved within 2 weeks post go-live. Coupled with ongoing education, the notched labels reduced errors associated with bar code reading failures.

In microbiology, operating rooms had maintained a paper-order workflow even after the rest of the institution steadily converted to paperless ordering from 2010 to 2014. Paper orders allowed many different order types to be placed very quickly on a single specimen (e.g., with a single handwritten description of the specimen or by checking boxes on a single sheet of paper) and without the need for computing resources in the operating rooms. Under Beaker CP in UIHC's Epic build, commonly available specimen sources are available in OpTime and are matched with commonly ordered tests (e.g. the “wound, intra-operative” source has aerobic, anaerobic, acid-fast Bacillus, and fungal cultures available); other uncommon sources and tests require one to leave OpTime and order tests in the Epic EHR. This resulted in a slower workflow that necessitated the following: (1) A new requirement to understand what source to select for a given specimen, (2) in-room computing resources and temporary disengagement of the scrub nurses to enter orders from the case, and (3) a series of keystrokes and clicks that added time to orders in a way that initially meshed poorly with an ingrained workflow that budgeted less time for this procedure. The surgical staff, especially the nursing staff, needed to be trained to generate orders and labels in the new system. Paper was widely regarded to be more rapid, and an initial adjustment period of a month was necessary before the new system was not regarded as critically disruptive to workflow.

Benefits and drawbacks to collaborative workflow were similar to those generally observed in transition from paper-based to computerized provider order entry systems.[5] However, because of the closed-ended nature of the ordering system (as opposed to paper sheets which invited source-and transport-inappropriate ordering and subsequent cancelation of tests in the laboratory), fewer ordering mistakes are now made and internal audits show operating room microbiology ordering to be approximately 99% accurate.

Two other additional minor issues arose postimplementation. One involved “specimen locking,” a phenomenon whereby a result cannot file due to someone else using Beaker CP for the same patient. This happens when another user is in an orders activity (new orders, order inquiry, and order review) for the same patient accession number. Microbiology specimen locking can occur with two people trying to enter susceptibilities on the same accession number at the same time. The error message gives the user and workstation where the specimen is locked. The biggest impact on the UIHC laboratory was to create interface errors that prevented autoverified results transmitted from Instrument Manager from posting in Beaker. Laboratory staff would not realize results had not posted in Beaker CP unless they accessed overdue (late) reports within Beaker. A less common, but potentially even more clinically significant, downstream effect of this phenomenon interrupted reflex orders that followed from an initial laboratory result (e.g., an HIV Western blot order following a positive HIV screen). The solution was to modify the interface to create batch jobs to resend results or reflex orders that did not initially transmit due to specimen locking.

The second relatively minor issue related to calculations and was that Beaker CP was more sensitive to the order in which tests were performed. An example was the urine protein/creatinine ratio. In the previous LIS, the calculation occurred regardless of when the two tests were resulted. In Beaker CP, the calculations “expected” a certain order. This necessitated reworking of the calculation parameters and creation of reports to identify instances where the calculations failed because the order of results was not standard.

Pathologist Sign-out Within Beaker Clinical Pathology

The switch to Beaker CP impacted pathologist sign-out of multiple areas including hematology (excluding AP-like activities such as bone marrow core biopsies), hemoglobin electrophoresis, and serum/urine protein electrophoresis. As an example of pathologist sign-out, serum and urine protein electrophoresis are performed by capillary electrophoresis. Interpretive reports were generated within the Phoresis software package for the Capillarys 2 analyzer (Sebia, Norcross, NC, USA) and then transmitted via Instrument Manager to Beaker.[6] An improvement over Cerner was that the formatting of the text was transmitted accurately to Beaker (e.g., carriage returns were lost when attempting the same process in Cerner) along with the numeric electrophoretic fractions and concentration of the monoclonal protein (if present). Beaker allows for different security levels for trainees (e.g., pathology externs, residents, and fellows) with respect to sign-out. For serum/urine electrophoresis, residents participate in the sign-out process but cannot final verify the results. That function is reserved for attending pathologists. For other functions such as hematology smear review, residents can final verify results. Much of the sign-out process occurs via the outstanding lists which can be customized to show specific categories of tests. An advantage of Beaker CP was the ability to access clinical information on a given patient in Epic during the same session.

Reference Laboratory

The switch to Beaker CP maintained two-way electronic interfaces to three commercial laboratories that served as the major destinations for send-out testing. There were few problems associated with the interfaces, and very few orders require retransmission of completed results from the external reference laboratories. Compared to interfacing using the previous Cerner LIS, there were a few minor challenges. First, 24 h urine collection information must be entered and saved in specimen update prior to electronically sending the order. This information is not available to the ordering provider until the order is finalized. Second, code in Cloverleaf (Infor, New York, NY, USA; interface to Epic) had to be written if two different orders from a reference laboratory could have the same test code (e.g., random and 24-h urine tests). This was accomplished, and results from both orders can transmit from reference laboratories to Beaker. Beaker was able to handle reference laboratory tests with many discrete results; examples include certain panels of metabolism (e.g., amino acid profiles) and complex toxicology profiles.

Data Analytics

Epic Reporting Workbench functionality allowed for a variety of reports to be constructed either for recurrent or ad hoc use. Examples include display of blood culture results for microbiology, monitors of turnaround time for key parameters (e.g., complete blood count, basic metabolic panel, troponin T, coagulation), phlebotomy collect to laboratory receive time, and critical results missing documentation in communication log. One key advantage for staff was that integration within Epic allowed for quick navigation between Beaker and the EHR.

Training Requirements and Impact on Clinical Laboratory Operations and Quality Metrics

Table 4 summarizes the specific training (including number of hours) for the various staff categories that worked with Beaker CP. The training was customized to the specific functionality used by staff. The most extensive training was for phlebotomists, clerks, medical laboratory technicians, and laboratory managers and amounted to slightly more than 12 h. The training was in addition to any time spent by some staff as SMEs or for work on project validation tasks.

Table 4.

Beaker Clinical Pathology training for staff

The Department of Pathology routinely monitors quality metrics from the clinical laboratories including turnaround time and critical value reporting. In general, these metrics either were unchanged or improved following the transition to Beaker [Figure 3 shows six examples]. In the core laboratory, turnaround time for common photometric and ion-selective electrode chemistry tests (e.g., electrolytes, liver enzymes), immunoassays (e.g., troponin T), and hematology tests (e.g., complete blood count, prothrombin time) were unaffected by the switch in LIS. Figure 3a shows turnaround time metrics for chemistry and hematology testing in the UIHC core laboratory and also a smaller laboratory associated with a multispecialty outpatient facility located three miles from the main UIHC campus. Figure 3b shows critical value reporting metrics for the UIHC core laboratory. Rates of autoverification were similar to those reported in a prior publication with the previous LIS.[4]

Figure 3.

Quality metrics before and after switch to Beaker Clinical Pathology. (a) Turnaround time metrics in the University of Iowa Hospitals and Clinics core laboratory and also the smaller clinical laboratory at a multispecialty outpatient facility located in Coralville, Iowa, USA. The ordinate indicates the percentage of tests that meet the turnaround time metrics specified in the legend on the bottom of the graph. All time values start from receipt of specimen in the laboratory. The arrow indicates the switch to Beaker Clinical Pathology. (b) Critical value reporting metrics in the University of Iowa Hospitals and Clinics core laboratory. The ordinate indicates the percentage of tests meeting the metrics for documentation of critical values (assessed by core laboratory quality specialist) and phone call within 15 min. The arrow indicates the switch to Beaker Clinical Pathology

Post Go-live Optimization

As part of post go-live optimization, pathology, hospital, and vendor staff conducted end-user surveys, tours, and interviews of laboratory staff and management. Two surveys assessing multiple aspects of Beaker CP were conducted at 1–2 months (n = 49 respondents) and 3–4 months (n = 105 respondents) following go-live and focused on the following areas (all scores are mean ± standard deviation): LIS support (1–2 months: 3.4 ± 0.2; 3–4 months: 3.6 ± 0.6; 5-point scale), LIS ease of use (1–2 months: 2.7 ± 0.4; 3–4 months: 2.8 ± 0.4; 4-point scale), LIS training (1–2 months: 2.4 ± 0.1; 3–4 months: 2.6 ± 0.1; 4-point scale), LIS efficiency (1–2 months: 3.2 ± 0.7; 3–4 months: 3.2 ± 0.6; 4-point scale), LIS impact on patient care (1–2 months: 3.1 ± 0.5; 3–4 months: 3.2 ± 0.4; 4-point scale), and overall satisfaction (1–2 months: 5.9 ± 1.3; 3–4 months: 6.2 ± 1.5; 10-point scale). Training rated the lowest of these areas, with many user comments related to either lack of specificity of training to particular jobs and/or desire for more hands-on practice to complement classroom learning. Many of the other comments highlight issues described above such as challenges with clinical areas not following desired workflow.

In terms of costs of ownership, instrument interfaces using Instrument Manager are considerably less expensive than instrument interfaces involving the previous LIS. Report writing is now internally funded as opposed to requiring outside vendor costs. UIHC owns an Epic enterprise-wide license which encompasses maintenance and support of all aspects of Epic. Therefore, we are not able to make direct comparison of these costs relative to the previous LIS.

DISCUSSION

This report describes the successful implementation of Beaker CP at an academic medical center. Beaker is a relatively new LIS that operates within the Epic suite of software, an example of using a single vendor for LIS and EHR software.[7] Given that Epic is a common EHR within the United States, it is likely that clinical laboratories adopting Beaker will do so in two main scenarios: The hospital/medical center already has Epic as the EHR (as in the current study) and is adding Beaker or, alternatively, is doing a coordinated switch of the EHR and LIS at the same time. In the current study, the medical center also switched to the Epic modules for revenue cycle (Resolute), scheduling (Cadence), and patient registration (Prelude).

The preimplementation phase for the switch to Beaker encompassed approximately 2 years and involved substantial effort of SMEs, especially with microbiology test build and expansion of the use of the Data Innovations Instrument Manager middleware product. For laboratories planning a switch to Beaker but are not currently using Instrument Manager or use it minimally, sufficient time and effort should be allotted to the issue of interfacing. Another key decision point is where to build autoverification rules. Our institution elected to keep most rules within Instrument Manager, but other sites may find it easier to use Beaker for this function.

Some of the major challenges encountered in the short term following go-live were issues that could happen with any switch in LIS such as issues with printer labels and process change with LIOs. For UIHC, even though Beaker bar codes were heavily tested prior to go-live, the deployment of a large amount of new hardware (particularly label printers) to clinical areas created significant challenges for nonlaboratory staff. The change with the long-lasting impact related to microbiology orders from the operating rooms. The switch from a paper-based order process with the previous LIS to one that required the clinical teams to order within Epic was very challenging and required intensive interventions. Future institutions adopting Beaker as LIS should evaluate this issue carefully with regard to process design and education.

In this project, we found that an LIS executive committee with diverse representation of leadership from pathology, medical center informatics, and hospital administration was very helpful in keeping the overall project on target. Key decisions included postponement of the Beaker CP project due to delays in the revenue cycle project and also deferment of some noncritical issues (e.g., interfacing of certain lower volume instruments) to after go-live. Open communication helped to continually evaluate what is “go-live” critical between all groups impacted by changes in the LIS and avoid mission creep that could interfere with key milestones. From end-user surveys, we also identified training of laboratory staff in Beaker CP as an area that rated the lowest in terms of overall satisfaction. This is an area for future improvement.

We assessed a variety of quality metrics before and after the transition to Beaker CP. Key metrics included turnaround time and critical value reporting in the core laboratory and laboratory in a separate outpatient facility. In general, quality metrics stayed the same or even improved upon the transition to Beaker CP. Overall, the switch to Beaker CP at our institution was a positive one that is functioning well over 1 year from go-live.

Financial Support and Sponsorship

Nil.

Conflicts of Interest

There are no conflicts of interest.