LABORATORY INSTRUMENTATION
 |
Figure 1. The DL2000 Data Manager by Beckman Coulter (Fullerton, CA) alerts technologists to important information about samples, and it organizes exceptions and pending results for quick review.
|
While middleware’s contributions to automation’s advantages have not received nearly as much attention, many of those same benefits would be impossible without it. Also known as data management software or expert decision-making software, middleware is software that mediates interactions between laboratory instruments and the laboratory information system (LIS). By using rule-based decision processing, it assists lab personnel in managing laboratory functions. Middleware organizes exceptions and pending results for quick review, and allows a more global view of patients by accessing data from multiple instruments in real time. The hopes that labs have for their automation systems, and the performance and financial payback that they expect, depend in many cases on having effective middleware.
This article explores middleware’s role in lab automation systems, and describes its many advantages. Such advantages include: an efficient system that decreases turnaround time and allows staff to focus on critical patient results for rapid response to clinicians; reducing the potential for medical errors and thereby improving patient safety; and eliminating process delays to create a queueless lab with efficient sample tracking. The article also shows how middleware, in combination with automation, can help hospitals meet a multitude of institutional (and not just laboratory) goals (see Figure 1).
Description of Middleware
To a large extent, middleware fulfills a need created by the inadequacies and inflexibility of an LIS.1 While middleware is not indispensable technically speaking, it is desirable because it improves the integration of the instrumentation, the automation system, the lab’s data management component, and the LIS.
Even though an LIS and middleware have some duplicate functions, an LIS is a compromised solution in those overlapping areas.1 That is, a lab system that does not have middleware will not be as tightly integrated as one that does. In addition, the performance standards of an LIS are not even close to those of advanced middleware when the overlapping functionalities are benchmarked.
 |
Figure 2. The DL2000 can work in tandem with an integrated lab automation system to improve patient safety.
|
Middleware enjoys an additional advantage over an LIS in its physical location. Unlike an LIS, middleware workstations are truly in the middle of a lab system, which allows technologists to integrate the instruments more easily into their daily work flow (see Figure 2). With middleware, all work done on all instruments can be viewed, tracked, and managed from one location. If an LIS is relied on as the software component for a lab system, much of this flexibility and functionality is lost.
Both instrument vendors and third-party vendors offer middleware packages. In some cases, added value to middleware can be obtained through a lab’s instrument vendor. Some of the middleware products have been designed according to an instrument’s specifications, which optimizes its performance.
 |
Figure 3. (click to enlarge) After an operator has acted upon the patient results, actions can be documented and attached to the test results. Per the instructions, an operator only has to type in comments after notifying the physician. All comments become part of the archived record.
|
For example, depending on the product, middleware capabilities can include the following: autoverification of normal results (in which normal results are moved out so that critical patients are prioritized for immediate intervention by the laboratory staff); processing of new orders; relaying of comments or other information to physicians; exceptional data event alerts; critical results alerts; patient misidentification alerts; delta checking; control of multiple processes on multiple instruments; organization of exceptions and pending results for quick review; and automated reflex, repeat, and add-on testing (see Figure 3).
Middleware performs such functions with flexibility because it is based on user-defined rules, or “if/then” algorithms for which users enter the criteria.1 For example, middleware can handle different protocols for reflex testing based on each physician’s preferences, or otherwise manage results for specific physicians’ patients.1
Conditions Favoring Middleware Use
As with lab automation itself, middleware provides a versatile response to a variety of issues. For example, labs are under pressure to improve patient safety. A large majority of information that physicians depend on for diagnostic and treatment decisions comes from the labs.2 In this regard, middleware helps by making lab processes more efficient, speeding up turnaround time (TAT) of test results, and getting results into physicians’ hands more quickly. Doctors can then make faster decisions on critical care cases such as cardiac patients.3
For example, at John T. Mather Memorial Hospital (Port Jefferson, NY), the addition of middleware to the lab’s integrated automation system is considered the major factor responsible for dramatic reductions in TAT. In March 2002, total TAT for a basic metabolic panel was 73 minutes. By March 2005, with middleware and automation fully implemented and the lab’s staff familiar with the system, TAT had dropped to 56 minutes. Similarly, TAT for a seven-test panel of drugs-of-abuse dropped by 116 minutes, a 79% improvement.4
The reference lab at Elmhurst Memorial Healthcare (Elmhurst, IL) also saw improvements in TAT after implementing middleware technology. The technology enabled the lab to meet its goal for delivering timely cardiac troponin I and myoglobin results to the emergency department physicians 90% of the time, compared with 72% before the technology was installed. Preinstallation, the lab met its goal of turning around in-house test results in time for doctors’ morning rounds only 55% of the time; the rate at which that goal is met now is 96%. The goal for turning around a basic metabolic panel in 35 minutes is met 94% of the time, as opposed to only 58% during the preautomation/ middleware era.5
The advent of middleware also means that voluminous, mind-numbing tasks such as verifying normal test results can be handled by software instead of humans. When lab technologists do have to perform tasks that cannot be automated (e.g., validating abnormal results), they bring more energy and focus to the job because middleware has lightened their workloads. For example, the Elmhurst hospital autovalidates about 85% of more than 1 million chemistry, hematology, and immunoassay results.5 This percentage is typical when the middleware’s autovalidation capacity is fully implemented.
 |
Figure 4. (click to enlarge) The DL2000 enables automatic validation and reporting of normal results, according to rules programmed into the software.
|
Healthcare institutions also feel pressured to reduce medical errors, which has been a healthcare priority since the Institute of Medicine (IOM) called attention to a national medical error crisis in a 1999 report.1 A 2005 survey of patients in six industrialized nations confirmed the IOM’s warnings about the U.S. healthcare system. The United States stood out among the other nations in the survey not only for its high rate of medical errors but also for its healthcare system’s inefficiency.6 As with autoverification, middleware helps to reduce errors by minimizing the role of humans (see Figure 4).
Consider those labs that operate without middleware. The decision making is left to technologists who will inevitably make decisions with a degree of variability. In other words, they may make decisions that lab management does not want them to make, which may result in medical errors that harm patients. Middleware eliminates technologist variability and associated errors by always making decisions according to criteria that management has entered into the software. The software also improves efficiency. In fact, its main purpose is to organize and manage the vast amounts of data flowing through the lab.
In addition, middleware helps healthcare facilities meet nonclinical laboratory and institutional goals, such as coping with complex economic pressures. For example, lab managers face an ongoing struggle to keep their lab operations fully and competently staffed, especially due to a shortage of lab technologists that is expected to persist into the future.
Meanwhile, the number of uninsured patients continues to grow, increasing the work load of hospital emergency rooms without the reimbursement to cover the costs. Moreover, lab services that are reimbursed are often reimbursed inadequately. All of these factors, plus competitive pressures, compel hospitals to do more work with fewer resources and fewer people.
However, if an institution’s response is simply to cut staff, it risks an erosion of patient safety, and an increase in medical errors and medical malpractice lawsuits. Lab automation that is mediated with middleware can relieve this economic strain. As with automation in other industries, middleware was developed precisely for overcoming the challenges of doing more work more accurately, with fewer personnel.1 It also helps labs utilize their human resources more effectively. Middleware technology can handle demeaning, routine tasks that erode staff concentration and satisfaction. The remaining tasks are generally those that technologists enjoy and that depend on their special skills and training.
Hospitals also face the challenges of overcrowded emergency rooms (ERs), which are driven by greater numbers of uninsured patients, population growth, and declining numbers of ERs to handle so many new patients. To move existing patients through the ER and free up beds for new patients, lab data must be reported to the ER as quickly as possible. While many labs try to address the issue with process redesign, that is only a partial solution. Lab automation and middleware that is ideally preceded by process redesign is necessary to optimize TAT.7
Finally, advanced middleware will play an important role as two trends progress: the increasing use of molecular testing, and the creation of a national, integrated healthcare information network. As molecular diagnostic information becomes a standard part of the diagnostic mosaic, labs will need software that can manage and analyze the huge increase in data. For diseases to be more precisely identified and for treatment protocols to be personalized to patients, test data will be compared not only with previous results for patients but also other large data sets, such as population studies. Middleware is better designed to perform such functions in real time than the current generation of an LIS. As for the national healthcare information network, the reporting capabilities of middleware are a better fit than an LIS.
Specific Automation Benefits from Middleware
Depending upon a lab’s needs or goals, middleware is not just a management tool that boosts productivity and efficiency. Certain automation functions are not even possible without middleware. If they are possible, they are available in less-than-ideal formats if a lab relies solely on its LIS to perform them. For example, true auto-verification, rather than just delta checking, is the result of an interaction between middleware and an LIS. Its impact on a lab can be profound. Consider that even a modest-sized hospital lab may process more than 1 million tests per year. Quality middleware might verify as much as 80–85% of those tests. Technologists only need to focus on the remaining 15–20%, which significantly reduces the lab’s labor needs and leads to higher work quality for both auto- and manual verification.
Middleware is also needed if labs want to automate reflex, repeat, and add-on testing. Doing so produces time and labor savings for labs. Rather than hunting down samples in storage and putting them back onto the analyzers for testing, a technologist in an automated lab with middleware only needs to review the results from the desired samples at the middleware workstation. Robotics and middleware take over and do the rest, from finding the samples in storage to putting them back on the automation line, as well as testing and reporting the results, including any requisite checks.
 |
Figure 5. (click to enlarge) Patient test information is consolidated into one database, which helps technologists manage results.
|
Middleware can permit a more global view of patients, which enhances the ability of physicians to properly diagnose. For example, the middleware used at John T. Mather Memorial Hospital consolidates information from up to three analyzers, which enables physicians to consider chemistry, immunoassay, or hematology results together rather than separately (see Figure 5).2
Other important functions of middleware include the detection of patient misidentification errors and alerts for exceptional data events and critical values. Some middleware informs technologists when a patient identification number is being used on another patient, which can prevent the potentially catastrophic error of a mismatch between patient and sample. Some middleware alerts technologists of exceptional data events and informs them of the proper protocol to be followed, as defined by the lab’s management.3
Some middleware also alerts technologists when a critical value has occurred, informs them of the protocol to be followed, provides contact information of the proper clinician to be notified, and includes a log of the time that the message was delivered and the name of the person who received it. The value of computerized alerting technology is supported in the research literature. For example, one study examined e-mail alerts to physicians about markedly abnormal test values. In cases where physicians received the alerts, medications were adjusted or discontinued 21.6 hours earlier than when doctors were not e-mailed this information.8
 |
Ron Berman is worldwide director of automation and information systems at Beckman Coulter Inc. (Fullerton, CA). He can be reached at rberman@
beckman.com. |
Discussing middleware in the context of automation systems raises the question of how large does a lab need to be to justify the acquisition of a middleware product. Even modest-sized hospital laboratories can justify the acquisition of an automation system, including middleware. The clinical laboratory at Elmhurst hospital, which serves a 427-bed community hospital, paid for its automation system in just over a year.5 Besides middleware and integrated automation, the lab’s system included tube decapping, aliquotting, repeat testing, dilution, and add-on testing.5
However, even labs that do not have the volume to justify automation can benefit from middleware. In that case, they would simply rely on the software’s data management functions, and not use its process management side.
Conclusion
In the future, the functionality of middleware could be expanded by further integration of cross-laboratory departments, such as hematology and chemistry, or the clinical laboratory with imaging. It is likely that the software will be less apt to undergo major change than the instruments, robotics, and the LIS that it integrates. The latter are bound to become more middleware-friendly as use of the software becomes more widespread. As valuable as middleware is today, its value should continue to grow as the rest of the lab industry adapts to incorporate it.
1. A Paxton, “Smooth Operator in the Lab: Middleware,” CAP Today, February 2006.
2. D Uettwiller-Geiger, “A Lab’s Strategy to Reduce Errors Depends on Automation,” Medical Laboratory Observer, December 2005: 26–29.
3. KE Blick, “State-of-the-Art Data Management Software Minimizes Lab Errors and Speeds Test Reporting to Physicians,” poster presentation at the Seventh Annual National Patient Safety Foundation Conference, Orlando, FL, May 4–6, 2005.
4. D Uettwiller-Geiger, “Enhancing Patient Safety by Integrating Lab Information with Middleware and Facilitating Laboratorian/ Physician Collaborations,” poster presentation at the Eighth Annual National Patient Safety Foundation Conference, San Francisco, CA, May 10–12, 2006.
5. SC Terese, “Investing in Lab Automation Improves Both Service to Physicians and Hospital’s Financial Health,” poster presentation at the 2005 American College of Healthcare Executives Conference on Health Care Management.
6. C Schoen et al., “Taking the Pulse of Health Care Systems: Experiences of Patients with Health Problems in Six Countries,” Health Affairs Web Exclusive, November 3, 2005.
7. KE Blick, “No STAT Testing,” Medical Laboratory Observer, August 2005: 22–26.
8. MJ Ball and JV Douglas, “IT, Patient Safety, and Quality Care,” Journal of Healthcare Information Management 16, no. 1 (2002): 28–33.
