Feature Articles

Published: July 1, 2008
Find more content on:
Middleware: Providing value beyond autoverification

Clinical labs are exploiting middleware to differentiate their services while eliminating mundane tasks.

By: Hunter Bagwell







With every article published and conference presentation given on middleware, the growing perception has been that it is synonymous with autoverification and nothing more. However, while middleware can help with the mundane and error-prone task of results verification, what also must be realized is that it can offer so much more. Otherwise, those labs that have it and those that seek it are not exploiting the full potential and real value of middleware.

Although this article will discuss autoverification, it will also illustrate three key facets of a laboratory's business strategy that middleware is contributing to: operations efficiency and improvement, business continuity, and business expansion.

Operations Efficiency and Improvement

Autoverification. The motivation for labs to implement autoverification is evident, especially considering the following challenges they face: increased financial constraints, decreased reimbursements, increasing testing volumes, increased regulatory constraints, demands for decreased response time, and higher-quality expectations. Adding to the problem is a constantly decreasing pool of qualified lab personnel and growing fatigue among current personnel.

By implementing middleware, autoverification in community, general, and university hospital environments can reach as high as 90%. In reference laboratories, such levels reach 95% or higher. Some of the benefits of middleware include the following:

  • Decreased turnaround times for routine and priority tests, which is immediately followed by a significant decrease in priority tests.
  • Higher consistency in the quality of test results. The results are evaluated consistently across all shifts and all laboratories in a hospital organization.
  • Reduced staff fatigue, which improves the work environment and allows medical technologists to focus on the true problem samples.
  • Special processing requests from physicians can be easily automated and accom­modated, further differentiating laboratory services.
  • With the savings from full-time employees, a growing number of labs are running additional test methods in-house that were traditionally outsourced, or are expanding into the emerging area of molecular testing.

Autoverification is nothing new. Before the massive proliferation of middleware, most attempts at autoverification were done in one area of the lab, usually hematology, with significantly lower autoverification rates. The first labs to implement middleware were trying to fill the gaps (the absence of functionality) in their laboratory information systems (LIS), and their instrumentation and automation systems.

Labs that adopted middleware later realized that it could be configured easier and function better than any system they already had. However, middleware does not replace an LIS, but rather supplements the system's functionality to reach more work areas with higher autoverification levels.

Intelligent Verification. The rules-based decision processing in middleware permits an intelligent verification process, which is the ability to go beyond reference ranges. With middleware, laboratorians can write physician-, ward-, and practice-specific rules that interact in real time with the instrumentation and results production.

Two models of intelligent verification have emerged. In the LIS-centric autoverification process, the middleware supplements the functionality gaps in the LIS by performing all the complex, user-defined evaluations of the data as they pass through the middleware. The middleware sends a hold or no-hold flag and comments to the LIS for the technologists. The non-exception samples are immediately sent to the physicians with the predefined comments. For the exception samples, the technologists use the LIS terminals to review those exceptions identified and comments generated by the middleware before releasing them to the physicians.

Figure 1. Middleware is not replacing the laboratory information system (LIS), but supplementing the functionality to reach higher levels of autoverification in more work areas than before.

The other model is a middleware-centric model in which all the rules, calculations, and reviews of the exceptions are performed on the networkable middleware. In both models, laboratorians can remove the technical barriers and allow higher and more sophisticated levels of autoverification than before (see Figure 1).

Real-Time Repeat, Rerun, and Reflex. As labs replace their older instruments with new-generation instrumentation, they are using middleware to implement real-time repeat, rerun, and reflex testing procedures. In many new-generation instruments, an LIS can send additional testing instructions for a sample while it is being processed. Typically, an LIS interacting with an older instrument cannot process test results and then quickly send repeat, rerun, and reflex instructions to reprocess a sample while it is still on the instrument. Medical technologists would have to locate the sample and place it back on the instrument for additional testing, which consumes valuable time.

Middleware has allowed labora­torians to set up simple to complex repeat, rerun, and reflex decision rules that will send such instructions to new-generation instruments to reprocess samples with no operator intervention. This ability benefits laboratories in several ways. It delivers test results to physicians sooner by mimicking their ordering decisions in rules-based decision processing, and it helps to differentiate a laboratory's services while reducing its costs to produce the results. It also reduces the labor associated with finding the samples to reprocess, which is often not reimbursable.

Real-Time Delta Checking. Delta checking exists in every LIS and is a valuable tool to compare a patient's current test results with historical results. Middleware enhances this utility by:

  • Evaluating the age of previous test results to determine clinical significance.
  • Developing different delta criteria so that, for example, end-stage renal patients are not evaluated the same way as outpatients.
  • Providing the last several results immediately to the medical technologists so they can quickly assess the situation.

Middleware can send instructions back to the instrument to retest a sample before it leaves the instrument. In this manner, the instrument and middleware are interacting with test results production in real time.

Sample Storage and Retrieval

Figure 2. Sample storage and retrieval is one of the most overlooked areas for improvement, yet can yield as much financial savings as autoverification with less effort to implement.

While middleware's contribution to autoverification processes is clear, its value goes beyond autoverification. One area is sample storage and retrieval. Most labs incorporate various manual sample storage and retrieval methods. Some methods are storing intensive, requiring a significant amount of time to place samples in a particular order to make retrieval faster. Other methods are the opposite, in which storage is fast but retrieval is tedious, involving sorting through hundreds of samples (see Figure 2).

Prior market research and numerous customer experiences have shown that retrieving a sample takes about 12–15 minutes and involves at least one full-time employee. While the cost for this non-revenue-generating task is enormous and one of the easiest to solve, it is often overlooked. To help quantify the cost of the sample storage and retrieval process, suppose an average laboratory stores 1500 samples, slides, and cups every day, and takes 2 seconds to store each specimen. The lab also retrieves 2% of its specimens per day for retesting, which takes, on average, 15 minutes per sample. Based on these numbers, the lab is spending 8.33 hours per day storing and retrieving specimens.

Since the sample storage and retrieval procedure requires one dedicated full-time employee, the cost of labor alone is $65,457 per year, based on an average hourly wage of $21.52. However, according to the findings of a middleware poster presentation, compared with the lab example above, the same sample storage and retrieval process using a middleware solution would cost only $10,473 annually, a savings of $54,984.1

Applying middleware to resolve sample storage and retrieval issues has been overlooked due to a lack of attention to the problem. While a lot of time and effort are devoted to autoverification, not much time has been spent on using middleware for sample storage and retrieval. Some middleware solutions that address sample storage and retrieval issues can be implemented in less than a day, require no LIS interfacing, and can pay for themselves in weeks or months. The middleware also provides a platform on which to build other solutions in the laboratory.

Quality Control and Regulatory Compliance

Quality is the cornerstone of a lab's business, and quality control (QC) is one of the most important yet probably least appreciated activities in the laboratory. Few labs have quantified what their existing quality systems cost them in time, effort, and financial expense.

Integrated with autoverification processes, middleware can improve quality and provide consistency across multiple work areas, while saving time and reducing the oversight of quality processes.

Real-Time, Interactive Quality Control. Laboratories commonly waste many hours each week transposing QC information into third-party software, only to discover days or weeks later that they have a quality issue. The labs spend countless hours trying to determine whether it is only them, or if everyone is having the same problem. What such current processes lack is real-time monitoring, direct interaction with results production, and expert analysis tools and information.

Middleware has changed the dynamics of current QC processes by providing consistent compliance and improving quality without undue oversight or financial burden. Middleware not only acts as a real-time conduit of information between the LIS and the instruments, but also provides information to third-party QC software, such as Unity Real Time by Bio-Rad Laboratories (Hercules, CA). While an LIS promotes interfaces to such third-party QC software, it often requires human intervention to extract information from the LIS and manually import it into the QC software.

Middleware eliminates such manual transposing and importing of information, allowing the laboratory to participate in Web-based interlaboratory peer-grouping, which provides the sanity checking and troubleshooting resources.

In addition to reducing data errors and providing QC in real time, middleware's internal QC package or conduits to third party packages allow QC and middleware to be integrated with the lab's results production in real time. When a QC violation occurs, rules-based decision logic in middleware starts immediately flagging and holding those test results affected and promptly alerts the appropriate laboratory staff.

Figure 3. Maintenance management is a good example of laboratorians exploiting the value of middleware to fill the gaps in all laboratory operations.

Maintenance Management. How comfortable do labs feel that the various notebooks tracking their maintenance are up to date and ready for a surprise inspection by the College of American Pathologists? When it comes to middleware functionality (e.g., maintenance management), the traditional definition of middleware (a go-between for the instruments and the LIS) falls apart. If used to its full potential, middleware should be in the middle of the laboratory operations by filling gaps in all the operations (see Figure 3).

Maintenance management allows laboratories to monitor the maintenance of everything, from eye washes and fire extinguishers to how many more tests remain in a reagent bottle. Networkable, electronic reminder systems notify appropriate personnel when maintenance tasks are due. Staff can log their activities and events, and have manufacturer procedures and inserts available for easy reference. Supervisors can also monitor for noncompliance and address that topic before it becomes an issue.

Data Mining. For the vast amounts of information stored and processed by middleware, common software programs such as Microsoft Excel and Crystal Reports assist laboratorians in data mining. Examples of how labs use middleware to data mine include the following:

  • Performing work flow analysis of turnaround times, from the time the sample arrives in the lab until it is placed in storage.
  • Ad-hoc research reports, such as all of the troponin results for the last 60 days for a specific cardiology group, are easily accessible.
  • Conducting mundane tasks such as instrument-to-instrument (including point-of-care) correlation studies, lot-to-lot comparisons, and determining moving averages.

Business Continuity

LIS Backup. Having an LIS down, whether planned or unplanned, has a devastating effect on a laboratory's ability to provide services. For some labs, it is a regular occurrence. For others, it is taken into account as part of their business continuity or contingency planning.

Middleware is not intended to replace an LIS. However, when an LIS is unavailable, middleware provides the critical functions needed to produce test results with a minimal impact on services.

Typical LIS downtime procedures in nonmiddleware laboratories include the following:

  • Finding the downtime labels in storage and manually ordering tests for each sample at each instrument, introducing the risk of numerous errors and increasing tasks during frantic LIS downtime.
  • Results reporting consists of keeping all instrument printouts in a file near the phone in order to read them to the doctors when they call.
  • Creating chartable reports from the numerous instrument printouts, taking a critical resource away from results production.
  • When an LIS comes back on­line, an operator must start the process of manually transmitting the results, accessing all the downtime samples, and rerunning the samples with different labels.

Middleware offers alternative processes during LIS downtime, such as the following:

  • Computers used to access the LIS can also double as order entries to the middleware, and the middleware can print downtime labels on demand if needed.
  • Patient demographics and test information are typed in once, and operations at the instrument level remain the same.
  • Rules-based decision processing detects downtime labels and prints emergency-room and critical-care results automatically to network printers.
  • Results lookup and printing chartable reports are done from any computer in the lab with minimal effort.
  • When an LIS comes back on­line, the middleware can detect and automatically send all the queued results, avoiding the man­ual retransmission of results from each instrument.

For some laboratories, middleware has become a lifeline in such situations. Whether a laboratory experiences planned or unplanned LIS downtime, middleware could be a central component in contingency or disaster recovery planning to allow continuous results production and reporting when an LIS is unavailable.

Business Expansion

Hospital Mergers. Hospital mergers have been occurring more frequently as organizations try to capture economies of scale and create competitive health networks. Inevitably, discussions begin concerning the establishment of a core laboratory by either converting to a common LIS or acquiring complex LIS-to-LIS interfaces and manually relabeling samples as they arrive at the core lab.

In recent years, laboratories are leveraging middleware to ease the technical and financial burdens associated with hospital mergers. By using middleware between each LIS and all laboratory instruments across a newly formed health network, an organization can continue to use their existing LIS systems. It can also shift testing to a central facility and have the core laboratory be a provider to various LIS systems.

Under this new business model, specimens from multiple LIS systems can be tested concurrently on any given instrument, and the test results can be sent to the respective ordering LIS.2 Doing so eliminates the complex LIS-to-LIS interfaces and the manual relabeling of samples coming into the laboratories from other hospitals. The newly formed network can also implement a core laboratory and shared testing in a less costly and more timely manner.

The middleware's rules-based decision processing addresses the differences in the autoverification methodologies of each requesting LIS. The middleware system tailors the information for the requesting LIS based on its requirements. Allowing the rules-based decision processing to handle the data needs of each LIS automatically eliminates the need to train each medical technologist on the nuances of each LIS.

Several health networks have adopted this new, dynamic model. It provides the ability to add other hospitals and LIS systems easily, and simplifies the merger process. It also allows laboratories to serve as production backups for each laboratory and to distribute workloads among many laboratories in the system. If a health organization chooses to migrate to a new LIS, it becomes another LIS to add to the middleware-centric model, which allows testing of the new LIS while concurrently producing patient results with the old LIS.

Outreach Systems

Using the same model defined above, in which the middleware resides between all the information systems and the instrumentation, laboratories can connect various Web-based outreach systems as yet another information system sharing the instrumentation. The outreach system generates its own sample identifications that are attached at the point of draw, and the samples are placed directly on the instruments concurrently with samples from other LIS systems.

When the test results are produced, the middleware sends them to the respective outreach system for results delivery and billing. The laboratorian can offer cus­tomized processing of results for particular physicians or practices to differentiate further their laboratory services. As discussed above, the medical technologist processes the outreach samples in the same manner as other samples, and the middleware flags any exceptions and handles the tailoring of the information for the outreach system.

Rapid implementation of outreach systems in physician offices combined with easy-to-develop rules to mimic physician testing decisions provides hospitals and reference laboratories with highly competitive services to expand their revenues with minimal incremental costs.

Direct-to-Consumer and Direct-Access Testing

Hunter Bagwell is imple­mentation consulting ser­vices manager at Data Innovations Inc. (South Burlington, VT). He can be reached at hwbagwell@

Another potential new revenue stream for the laboratory business expansion model is direct-to-consumer testing, in which a laboratory offers all or selected testing directly to patients. Such services use various front-end systems to collect payment from patients prior to testing. Using appropriate customer identification, the laboratory provides test reports with guidance documents to help patients interpret the results and provides input for the next steps they should take. Samples are processed as any other LIS or outreach sample, and the test results are reported to patients through a front-end system for in-person pickup or on a secure Web site.


The proliferation of middleware has provided a vital tool in helping laboratories implement intelligent autoverification processes. As hospital and laboratory organizations are constantly being challenged, they are asking themselves what else middleware can do. As a result, laboratories are exploiting middleware in many other key areas of their business and are realizing its true value.



1. SJ Zibrat, LA Berg, and RW McLawhon, “Evaluation and Comparison of the Roche PSD1 Task-Targeted Automation System to Manual Postanalytical Methods for Specimen Archiving and Retrieval,” poster presentation at the AACC Annual Meeting, Chicago, July 29–August 2, 2001.

2. M Ballard, “Case Study: Middleware, Im­plementing Middleware Increases Revenue Satisfaction,” Advance for Administration of the Laboratory 15, no. 10 (2006): 94.


Copyright ©2008 IVD Technology


No votes yet