A go-between gains ground in the lab

June 2006
Feature Story

Anne Paxton

In laboratories across the country—whether the problem is a technologist shortage, heavy competition, or a clunky laboratory information system—more and more often the answer is middleware:

• The middleware at California Pacific Medical Center, a four-campus center in San Francisco, is barely out of the box. Though it just went live in late April, the Dawning Technologies product is already performing a critical preanalytical labeling task on the 2 million to 3 million chemistry and immunoassay tests a year that the medical center’s automated core laboratory performs.

As a result of removing its hospital LIS as the intermediary between instruments and the outreach LIS, and cutting over to a middleware product a few years ago, Mid America Clinical Laboratories in Indianapolis saw turnaround time decrease overnight by almost five hours, and it suddenly had seven full-time technologist positions that no longer needed to be filled. This year the company is using the same Data Innovations middleware to implement autoverification of results.

Since it completed installation of its Instrument Manager middleware in October 2005 because it was a proven fit with its Roche Diagnostics instruments, the laboratory at Dartmouth-Hitchcock Medical Center, Lebanon, NH, expects its testing volume to rise by seven percent this year and by 25 percent to 30 percent over the next few years—all without adding staff.

Just three examples of why middleware has become one of the hottest IT solutions for laboratories. Sometimes known as rules-based engines or expert systems, middleware is defined as any software that resides between the diagnostic instruments and the laboratory information system. It promises seamless integration with the LIS; speedier, more streamlined operations; and staff savings. And a diverse array of laboratories report that middleware is swiftly transforming from an “add-on” or enhancement to a central component of laboratory operations.

Middleware has grown in popularity because it steps into a breach left by laboratory information system vendors, says Eric Carlyle, clinical director of laboratories for Lanarkshire Hospital in Scotland, which uses middleware from Technidata America Medical Software.

“There are not many LISs of large scale, even globally, and investment in those over the last 20 years has been very poor by comparison with hospital information systems, which are really focused on the electronic patient record and management of the patient. What’s happening in the laboratory is there is a large old-style LIS, and probably people don’t want to disturb it because it’s working satisfactorily.”

“The whole production process in a clinical laboratory is extremely complex, with lots of reruns, checks, and flags of important issues that are patient-critical and life-or-death situations, and all those processes are happening at the same time,” Carlyle says. “So you need to bring more sophisticated control mechanisms into running the laboratory process and optimizing it. And I think that’s where the development of middleware is at present.”

It was a logistical issue with diagnostic instruments that led California Pacific Medical Center to adopt a middleware solution. Sutter Health, which is the CPMC’s parent, was set to sign a systemwide chemistry/ immunoassay automation contract with Dade Behring last year, says Richard Bouton, MT(ASCP), CPMC’s automated core laboratory manager.

But there was a problem: All 28 Sutter facilities have adopted Misys as their standard laboratory information system, and though Misys’ Smart System can give the required container-specific identification to each sample, “to use it, all 28 facilities would have to go live and test the Smart System, even though some of the smaller ones don’t really need it. We couldn’t do that.”

“It was a major deal breaker,” he says. “We said to Dade Behring, ‘Do you have a solution, because otherwise we may not choose you as a vendor?’ And Dade consulted with their informatics people and came up with a solution involving some middleware residing in Misys right now, and middleware provided by Dawning Technologies, to basically work around Misys’ inability in our situation.”

“These instruments were the reasons we looked into middleware. Through middleware, we basically do what needs to be done to get container-specific ID without having to modify Misys,” he says.

The CPMC plans to gradually ramp up its three-cornered contract with Dawning and Dade Behring, Bouton says. “This is a very critical piece of equipment for us right now and it will become more so—meaning if that box goes down we have a lot of trouble.” In effect, the middleware is becoming more and more the LIS. “If it fails, it’s just like your LIS being down, and we’ll be needing a fairly immediate system to switch to a backup.”

But he sees the middleware companies as being more agile in making rapid changes to information systems to suit individual laboratories’ needs. “With the larger companies like Misys or Meditech, in order to implement changes in those systems, it takes a very long period of time and costs a lot of money, and the job doesn’t get done rapidly enough. The middleware companies seem able to fill that gap; they’re quicker and they have more of a ‘can-do’ attitude than the large LIS vendors.”

Mid America Clinical Laboratories, a joint venture of Quest Diagnostics and two Indianapolis hospital groups, conducts 4.5 million tests a year, including about 10,000 outreach tests a day. It turned to middleware because the company’s rapid growth was causing LIS compatibility problems.

“When the joint venture was formed based on the two product lines we had to support, we thought it was important to keep the two LISs we had,” explains Mid America chief information officer Mark Ballard. “Misys Flexilab is great in the hospital management environment. It offers a blood bank module and interfaces well with traditional patient registration in hospital information systems. QLS [a leased custom LIS from Quest] has a whole host of different strengths including billing and reporting pieces to our clients. So we essentially kept both systems intact.”

The problem came as Mid America’s volume rose. “Our LIS-to-LIS interface was fine when we were doing 500 to 1,000 requisitions a night, but as we got into the 2,000 to 3,000 range, the interface between QLS and Misys really started to bog down. It was creating issues with the specimen workflow to our testing areas, as well as delaying results reporting.”

Installing Data Innovations’ Instrument Manager between the two LISs at the core laboratory, Mid America connected all its instruments directly to the middleware and immediately saw a big jump in efficiency and speed. “It allowed us to run specimens labeled from either of the LISs simultaneously on our instrumentation, allowing us to eliminate the bidirectional interface between the LISs, to take out slow relabeling in the front-end processing, and reduce the time we spent in the specimen processing area,” Ballard says. “ So we were able to move arrival of outreach specimens up by about three hours, and that offset the ‘hospital rush hour’ problem we were having.”

So successful was the middleware software, in fact, that Mid America used it to take on two additional projects: in 2001, offering stat outreach services in the areas where it manages hospital-based laboratories, and beginning in 2004, implementing automatic result verification and release in all its laboratories.

“We wanted to tell our hospital clients they could use us for their stat work with one-hour turnaround time, but our configuration in those laboratories still had Misys directly connected to their instruments, and we couldn’t third-party bill directly from Misys since QLS was our billing system. Moving all the instruments into Instrument Manager allowed patient walk-ins to be processed directly in QLS, and reports sent out from QLS without ever going through Misys,” Ballard says.

To implement autoverification, Mid America developed and tested rules within the Data Innovations Instrument Manager, and the LIS was set up to accept all results from the IM without reviewing them. “We had a champion medical technologist from each of the instruments we were putting on autoverification, and they’d go through and write all the rules in ‘med tech speak.’ We’d translate that to ‘IT speak,’ so we just went on what the techs actually did.”

“The whole graphic user interface and way you interact with rules on IM is much more intuitive and much less labor-intensive than trying to implement that same set of rules within the LIS.”

But the transition did have its speed bumps. “There was a really negative reaction from the technologists at first, and there’s really not a whole bunch of sugar coating you can do. We almost had one med tech per instrument prior to implementation, and we took that down to one med tech per two or three instruments,” Ballard says. They didn’t have to lay off anyone. “We just didn’t hire for six to nine months, and we eliminated 12 med tech positions by doing this.”

In the process there was a distinct shift in attitude too. “Autoverification has become standard now, and if we haven’t implemented it on a new instrument after two months, we start getting complaints from the medical technologists and the supervisors.”

As to return on investment, IM has brought significant benefits to the company. “We have about 80 instruments connected, and we pay about 20 percent for the IM connection versus what we were paying for the LIS connection. So in licensing fees alone, we’ve saved $200,000 to $250,000 over the last six years.”

Independence is an added advantage, Ballard says: “We were basically at the whim of the LIS for instrument support, and the vendors were usually behind on writing drivers for new instruments. With middleware we control instrument implementation timelines, not our LIS vendors. Because the LISs see IM as just one large instrument, there’s very little we have to configure on the LIS; it’s all done on the IM level.” The IM Web site, he adds, “always has drivers there for any instrument we’ve purchased.”

He predicts middleware will expand in importance. “Right now we use middleware as a piece of software that gives us flexibility to change something within the laboratory’s operational workflow. We essentially use it for rules processing and for connectivity, but not as much for user interaction as I think we will in the future.”

The technologists now use the user interface piece of the Instrument Manager to hold and release results, he says. “But I think in the future we’ll start to see more of the resulting functions moved down into the middleware. For example, on keyboard entries for a CBC or urinalysis, we still use the keyboard interaction to result the test from the LIS. I think you’ll see that functionality moved back down into middleware for us—so that we can get away from our techs ever having to actually see the LIS to result a test.”

Autoverification was the key objective for the laboratory at Dartmouth-Hitchcock Medical Center when it looked into middleware, says Frank Polito, MBA, MT(ASCP) SC, POC testing/chemistry supervisor.

“We’ve had Cerner Classic’s Millennium as our LIS for probably 20 years, and we hoped to upgrade from it. But our main goal was to work toward laboratory automation. We felt that one box per tech was no longer working; it’s too expensive and too limited. Large automated multisystem platforms are where the future is heading.”

“So we were looking for consolidation, improvements in efficiency, better turnaround time, and probably the biggest thing was looking to allow technologists to concentrate on abnormal tests.”

After six months’ experience with the Data Innovations middleware, which Roche recommended as a fit with its instruments, he says the benefits are clear. For one thing, “with the Roche system we do not get printouts on routine specimens,” Polito says. So paperwork has dropped precipitously. In addition to sharply decreasing technologist time spent on normal results and manual reprogramming for repeat tests, middleware has made it possible for the laboratory to perform serum index screens.

“The reason we weren’t doing these in the past was that there’s no good way to catch all the tests you need to without an automated system. Keeping track of three sets of numbers of 80 or 90 different tests, and tracking age variations too, is just way too much information for any technologist. Without a middleware solution there’s no way to know, out of 200 tests you do, what level it kicks off at.”

Rule-writing for middleware (essentially if/then/else commands based on test results) can be arduous, but the payoff once it’s done is great, says Polito, whose three instruments have more than 840 rules. With the LIS, since the rules are usually based on percentages, “if you had a total bilirubin that jumped from .2 to .4, that would be a 100 percent jump and it would flag it, but there’s no reason to rerun and check it because it’s normal. With middleware you can write rules saying do a retest only if a value is greater or less than this, or if sex and age are certain values. So it’s much more dynamic and it allows you to customize your instrument settings for the laboratory.”

One feature he especially likes is that the middleware allows new rules to be tested without interrupting the lab’s normal operation. “If you’re going to be testing something on a Cerner LIS, we have to stop the instrument production, have the computer people point from a live to a test environment, then run and turn everything back to live. But with Instrument Manager, you can test each rule on each instrument, and that’s what we do quite often.”

As at other laboratories, the medical technologists were skeptical at first. “They just didn’t believe it would work, and there are always little glitches, little gremlins that happen. You can’t anticipate everything. But my biggest focus was I wanted folks to worry about abnormal results. We want them to not waste their brainpower and time on just verify: yes; verify: yes.” That’s what the technologists used to have to do, but now they spend most of their time on the roughly five percent of abnormal results.

Middleware was part of a broad-based laboratory IT upgrade in 2000 at St. John’s Hospital, Springfield, Ill., explains Joseph Parker, MS, MT(ASCP), core laboratory supervisor. When launching a total laboratory automation system, “We basically went with the entire Roche Diagnostics product. We have virtually all the preanalytics including centrifuging, decapping, aliquoting, recapping, and all the analytics, although we don’t have at the back end some of the auto-archiving and auto-transfer of specimens to the refrigerator.”

The middleware connects all of it, he says. “A lot of time middleware is viewed as a number translator or a way to manipulate data, but we use it to actually change orders.”

For example, a hepatitis panel may have four or five tests that could be ordered individually as well as in a panel. “That happens to be a feature of our LIS interface,” he says. “If you order a hepatitis panel on the floor, what comes down our communication line from Misys is not a panel code but six individual orders for breakout tests.”

A special rule written using the middleware orders the preanalytical system, when the six tests come down, to put “hepatitis panel” on the label instead of listing the individual tests. “It’s a semantic thing, but without the middleware, we would have settled for just the test codes that the LIS sends down from the bar-code reader.” That’s a feature the laboratory uses every day, Parker adds.

Though St. John’s hasn’t ventured much into results manipulation, for certain tests the middleware triggers performance of additional tests on the side. “Our pathologists, for example, like to see a small chemistry profile along with the protein electrophoresis reports. It’s just for their use and isn’t a reportable CMP. But it’s something our staff used to have to remember: ‘Oh I have to run a CMP on the phoresis bench because the pathologist wants to see it.’” The middleware rules have made this step automatic. “It all happens quite seamlessly.”

Because the middleware is being used mainly for preanalytical work, says St. John’s core laboratory facilitator Francine Zuber, MS, MT(ASCP), “the technologists do not routinely interact with it and therefore may not realize the scope of activities it’s performing.” But that could change when, as planned, the laboratory develops rules for autoverification and other postanalytical processes.

The major source of efficiencies or return on investment in middleware is likely to emerge from that rule development, Parker says. “The total laboratory automation has proven to be a cost-effective purchase,” and has led to a reduction in workforce, through attrition, of five or six FTEs. “But the payback on the middleware side, given the amount of use we’re giving it, will take much longer until we write more rules for our system.”

For Specialty Laboratories, a large esoteric reference laboratory in Valencia, Calif., middleware is used a little differently, says Kevin Stringer, senior project manager in information systems. “The typical hospital scenario is they have an LIS that manages all the tests on the clinical side and ties into a great number of instruments used to perform those tests. They may involve an internal middleware that negotiates the EDI [electronic data interchange] between those instruments and the LIS.”

Specialty has similar small-scale middleware applications. “But primarily our middleware environment is to allow us EDI communication with our clients,” he says. “So it’s an external middleware application.” The hospital places an order on its LIS, one designed for Specialty, and that comes electronically to Specialty’s middleware systems.

“Our middleware performs a series of translations and manipulations to make it work for our LIS, and then in turn the results are sent back out to the middleware to be re-translated or manipulated to communicate with the client system,” Stringer explains.

Included among Specialty’s major clients are a number with services provided by Dawning Technologies. Using Dawning’s middleware, Stringer manages the interface between Specialty and several Dawning clients that are at the regional and individual levels. “The middleware application takes the data from the individual hospital, translates it into a more standard HL7 format, and allows the data to be communicated to our LIS.”

In the past, Specialty’s services with these clients relied on a manual paper requisition system, which created several problems. “There was more manual data entry, and more chance for errors along the way. Our current arrangement with these facilities allowed us to set up an actual EDI between ourselves and the hospital,” Stringer says.

Health care organizations use the text-based EDI format HL7 message to communicate clinical laboratory information. A normal message has a header, a source, a destination, a patient ID, and so on. Stringer says, “The problem in health care is nothing is standard. Everything is proprietary. So even though we have a base standard that we use to communicate, there are different ‘dialects.’”

It’s similar to what happens when two English-speaking people with regional accents communicate, he says. “I may not understand what they’re saying exactly, so middleware comes in and we basically write rules to move around the information to make sure it fits a language we commonly understand.”

Middleware is an extremely powerful tool, but it’s not an unmixed blessing, cautions Parker of St. John’s Hospital. “The concept of middleware has been popular with laboratorians just because of the limitations we’ve all seen in our LISs. When someone came out with middleware and said what it could do, the green light came on and customers said, ‘Wouldn’t that make my life easy.’ And we look at it even as a system we can use as a backup when the LIS is down. It’s that powerful.”

“But when you get past the glow of that and start working with it, then comes a more complex understanding of the problem. All of a sudden stuff you never had to give much thought to before is thrown in your lap, and that’s probably slowed the implementation a little bit. And maybe that’s the reason there’s not many 400-rule laboratories out there, even though the product has been available for a couple of years.”

Dartmouth’s Polito agrees that there can be a downside to middleware. “There is a lot of pain involved—a lot of hard work and a lot of up-front work.” But based on his own laboratory’s experience, he says, “the benefits that come out of it are incredible.”

Related Links

• Middleware’s “early adopters” are in Europe
• Volunteers need in Guyana