“Even as more laboratories begin to use middleware, the number of functions and uses for middleware continues to increase
—Gregory R Vail, CEO, Data Innovations, Inc.
CEO SUMMARY: Middleware is attracting attention throughout the laboratory industry. It describes the software applications that bridge instruments and the LIS, or sit on top of the LIS to perform specific functions. Middleware is generally a fast and reliable way to automate tasks and monitor work processes in the lab. In this exclusive interview, Gregory R.Vail, CEO of Data Innovations, Inc., located in Burlington, Vermont, gives lab administrators and pathologists an inside view of the middleware marketplace. Vail’s company was one of the pioneers in creating middleware solutions for use in clinical laboratories. He discusses the first middleware applications by labs in the late 1980’s. He also covers the evolution of middleware during the past two decades and includes insights about how today’s early-adopter labs are using middleware solutions in innovative ways. The interview was conducted by Robert L. Michel, Editor-In-Chief of THE DARK REPORT.
EDITOR: “Middleware” is the new word that’s altering the information technology strategies of laboratories across the country. Your company, Data Innovations, Inc., seems to be at ground zero in this trend. Can you help us understand why middleware is becoming a viable business option?
VAIL: The key to understanding the growing interest in middleware lies in the economics of laboratory operations. On one side are the economics of operating the clinical laboratory. On the other side are the economics of laboratory labor.
EDITOR: Could you elaborate?
VAIL: Every laboratory organization in the United States is feeling pressure to better control its budget. The well-known squeeze of declining reimbursement for laboratory services versus the steady increase in the cost of operations, from instruments to reagents to information technologies, means that all laboratories are under pressure to perform more work with fewer resources.
EDITOR: That’s a widely-accepted view. Please explain how you see the economics of lab labor as an influence.
VAIL: First, many laboratories cannot get enough technical staff to meet their labor needs at any price. In the face of declining reimbursement, it is ever-harder for laboratories to cover the year-to-year increases in labor costs, benefits, healthcare, and the like. Second, the data the laboratory is asked to process is becoming increasingly complex. Collectively, these factors give laboratory administrators and pathologists a powerful motive to look for opportunities to increase laboratory productivity. Middleware solutions can often enhance and boost labor productivity.
EDITOR: On the balance sheet, these are factors of production which fall on the expense side of the balance sheet. Looking at the revenue side, does middleware play any role there for laboratories?
VAIL: That’s a perceptive question and the answer is yes. Many of our hospital lab clients are being asked by their parent health system or owner to develop ways to generate profits again. In particular, many hospital laboratory outreach programs have sprung up specifically because administrators are encouraging laboratories to develop sources of revenue that will generate net profits. By interfacing to both the hospital laboratory information system (LIS) and outreach applications, middleware allows the laboratory to process samples from both.
EDITOR: Your observation is consistent with other vendors who provide products and services to hospital-based laboratories. The number of laboratory outreach programs operating today is significantly higher than 10 years ago.
VAIL: We certainly see that among our laboratory customers.
EDITOR: Now I’d like to drill down into the core issue of laboratory information systems and what is happening in that marketplace that encourages or discourages laboratories from using middleware solutions.
VAIL: As you know, Robert, fewer laboratories are upgrading their LIS. This trend is well established for a number of years. The primary reason why labs are deciding not to upgrade their LIS is that they believe newer generations of LIS products do not add enough improvements to justify the cost of conversion.
EDITOR: It’s basic economics, right?
VAIL: Yes. Laboratories look at the extra functionality of the upgrade LIS option and decide that, for the price, they don’t get much more functionality than what they already have with their existing LIS. Middleware is inexpensive, from both a financial viewpoint and in terms of time to implement and maintain. Furthermore, the better middleware products are licensed in a manner that allows labs to buy only the functionality they need at the time.
EDITOR: THE DARK REPORT has written about why many health systems are spending most of their IT (information technology) dollars on projects to get clinical data repositories to talk to each other. That is required before hospitals and health systems can accomplish another IT priority: a working electronic medical record (EMR). Then there’s the mushrooming use of handheld devices, which can connect to the local area network (LAN) or the Internet by either a base station or wireless connection. Do steady improvements in hardware and software technology play a role in how laboratories view upgrades and enhancements to their informatics capabilities?
VAIL: This is definitely a factor, since laboratories must react and respond to
the needs of their parent hospital or health system.
EDITOR: Seen from this perspective, these are trends now eating away at the traditional healthcare IT platform—that of a self-contained, fat-client software system that has limited interconnectivity or interface with other similar fat-client systems within the healthcare enterprise.
“Middleware is inexpensive, from both a financial viewpoint and in
terms of time to implement and maintain. Furthermore, the better middleware products are
licensed in a manner that allows labs to buy only the functionality they need at the time.”
VAIL: That’s a good way to look at it. Lots of money is being spent right now,
not to upgrade basic clinical software systems that are already doing the job, but to create ways for these existing information “centers” to interface in support of the clinical and operational mission of the hospital and its laboratory. This is precisely where middleware—software products designed to do a specific function—can make a big contribution.
EDITOR: You’ve helped us understand how the IT needs of laboratories and hospitals have evolved. Let’s talk specifically about middleware. What is it and from where did it come?
VAIL: That’s easy, because laboratories were the first healthcare providers to make extensive use of middleware. Middleware started as the interface engine between diagnostic instruments and the LIS. This is also where the Data Innovations’ story begins.
EDITOR: Please continue.
VAIL: In 1989, Brigham and Women’s Hospital in Boston, Massachusetts had a home-grown LIS. As their laboratory added new instruments, there was a need to write interfaces that would connect those instruments to the LIS. Since Brigham’s administrators did not want to distract its in-house IT staff by having them write these interfaces, they contracted with us.
EDITOR: That’s interesting, because Brigham and Women’s is a hospital that has always been progressive in its use of information technology.
VAIL: Yes. It gave us the opportunity to interact with a relatively sophisticated user of healthcare information technology.
EDITOR: Where did this lead you next?
VAIL: As we worked with different instrument vendors to write their interfaces with Brigham’s home-grown LIS, they got to know us. They asked us to create interfaces for their instrument systems with other laboratory clients. So we found ourselves working with a growing number of the nation’s largest in-vitro diagnostic (IVD) manufacturers, writing interface code to enable their instruments to feed data into the LIS products of vendors like McKesson, Veterans Affairs, and Sunquest (now Misys). The result was the genesis of our product, Instrument Manager.
EDITOR: What step came next in the evolution of middleware?
VAIL: As our product proliferated between instruments and the LIS, we began to receive requests to fill gaps in the functionality between the two. The first gap we were tasked to fill is one we call “clustering.” From about 1991 forward, as laboratories placed multiple instruments in their lab, they wanted a software system that would make requests available to multiple available instruments, simultaneously. We were asked to write software programs to accomplish this task. That was our first foray into data management.
EDITOR: But not your last?
VAIL: Hardly! Middleware’s next evolutionary step came when laboratories wanted a software capability to massage raw data produced by the instruments. For example, the need was to take the raw numbers from a pregnancy test, have the software run those numbers against rules, and post the result as a “positive” or “negative”—or flag the result for operator attention.
EDITOR: That sounds like a “rules engine.”
VAIL: Correct, that is certainly what it has grown into. And from that simple start, Data Innovations has been developing many types of rules engines for use in laboratories in the United States, Europe, and the rest of the world. This type of software fits the definition of middleware. It is a software application that sits somewhere between a data-generating source and a data-requiring recipient and often handles delegated tasks with little or no operator involvement.
EDITOR: From this start, I would assume that you’ve been asked to develop software applications to handle any number of functions for laboratories. Over the past decade, did you have any experiences with laboratories that reshaped your thinking about middleware, its uses, and its potential to contribute substantially more than most laboratory administrators and pathologists can conceptualize?
VAIL: As a matter of fact, we did. However, it wasn’t from a single laboratory. It was the lessons we learned when we began to develop products for use in Europe.
EDITOR: That’s intriguing, since there is not much visible exchange of laboratory management techniques occurring regularly between Europe and the United States. What made Europe different and what lessons did you learn that you now use here in the United States?
VAIL: What we discovered when we began to offer our products in Europe was that middleware was a software product that was already in broad use by laboratories there.
EDITOR: In what ways?
VAIL: In the United States, laboratory IT solutions were usually a two-tier arrangement, with instruments on one level and the LIS on the other. In Europe, most laboratories operate in three tiers. The first tier is instruments, the second tier is middleware, and the third tier is either the LIS or HIS (hospital information system).
“What we discovered when we began to offer our products in Europe was that middleware was a software product that was already in broad use by laboratories there.”
EDITOR: Why was Europe different in this regard? Was it because LIS products used in Europe were not so multifunctioned and complex as here? To fill that gap in functionality, were European laboratories using middleware applications to provide specific functions they needed to supplement their “basic” LIS?
VAIL: In a general sense, that is true. Laboratories had a variety of middleware products to use in creating the information technology capabilities they wanted in their laboratories.
EDITOR: Did this more extensive use of middleware cause other differences in laboratory operations in Europe? Did you learn other interesting lessons?
VAIL: From one country to the next, the differences in laboratory operations are influenced by such factors as regulatory requirements, government-versus-private sources of payment, and regional differences in how healthcare is delivered.
EDITOR: Each of those factors would play a role in shaping different approaches to operating clinical laboratories. Did anything change at your company as a result of working in European laboratories?
VAIL: Two things. One, to become a credible software vendor in Europe, we had to develop middleware applications for all the functionalities that were found there. Specimen management modules are one example. By combining the requirements of Europe and the United States, Instrument Manager now surpasses the demands of both regions.
EDITOR: And the other?
VAIL: Two, what we’ve learned about laboratory organization and management in Europe is allowing us to come back to the United States and introduce these management approaches to laboratories here, in combination with the middleware modules needed to make them successful.
EDITOR: Can you offer an example, besides the already-mentioned specimen, of another successful middleware module?
VAIL: There are many, but let’s use specimen routing. For many years, the mechanical systems used to route specimens around clinical laboratories lacked an effective laboratory automation system (LAS) to drive the mechanics. We have implemented an LAS in another of our rules engine add-ons, called Specimen Routing (SR). For instance, SR follows every specimen through the track and can allow for what we call “dynamic reaction” to various events. In real time, it can handle add-on tests, rerun and reflex request determination, and instruments going offline. Essentially, the track is always asking “What do I do next” with individual specimens?
EDITOR: I’ve heard you talk about “manual automation.” Will you explain that?
VAIL: We coined this term for laboratory customers who are using SR functions without mechanical automation in their laboratory. MTs go to the computer and ask the system “what do I do next” with the individual specimen. The system gives them an answer and is tracking the progress of that specimen from pre-analytical through analytical to post-analytical processes.
EDITOR: That’s fascinating.
VAIL: Our system doesn’t care whether it is a mechanical system asking that question or a human. It tracks the specimen, determines the instructions for that specimen, and provides the answer when queried.
EDITOR: Greg, this is interesting background which tells us how the middleware concept first started, as well as some of the ways laboratories can use it now. Here’s a tougher question, but one that interests every lab director and pathologist now reading THE DARK REPORT. How do you see the laboratory industry using middleware in the next, say, 24 to 36 months?
VAIL: My answer will surprise, and I hope not offend, most laboratorians, and it will connect powerfully with those people running laboratories who have already accepted this insight. A clinical laboratory is a manufacturing facility. The parts it works on are specimen samples. The finished product it ships to customers are test results.
EDITOR: Is this concept accepted by many laboratories today?
VAIL: Definitely! More and more laboratories see themselves as a manufacturing facility. Once that mental shift happens, they get great operational results. It gives them the freedom to look outside the lab industry for management methods, operational tools, and software solutions that are generating tremendous gains for non-healthcare businesses. We see this repeatedly with our best-managed laboratory clients.
EDITOR: Your observations are consistent with the experience of hospital laboratories that were first to use Lean and Six Sigma principles to redesign their high-volume core laboratories. In 15-week projects, these labs cut average turnaround time by 50%, while reducing errors and boosting laboratory productivity in the range of 50% each. (See TDR, September 8, 2003.)
“More and more laboratories see themselves as a manufacturing facility. Once that mental shift happens, they get great operational results. It gives them the freedom to look outside the lab industry for management methods…”
VAIL: This is a phenomenon which is catching the attention of more and more laboratory administrators and pathologists. In fact, we’ve created middleware capable of supporting laboratories that operate on Lean and Six Sigma management principles.
EDITOR: Could you elaborate?
VAIL: Of course. As you know, quality management methods are built upon the principle of continuous feedback. Lab instruments are increasingly able to give us more information about individual work processes. We’ve recently enhanced a middleware application we call “Notifier” to take advantage of this. As our system receives data from the instruments, Notifier has the ability to alert the operator when intervention is required. For example, it will turn on a light when the instrument needs reagents. That alerts a roving med tech to come over and service the instrument.
EDITOR: Does Notifier interact with other functions?
VAIL: Sure. For example, it can tie into a quality control (QC) program such as QC OnCall from Bio-Rad. If a QC result violates Westgard Rules, our system can be set up to start holding the subsequent patient results from autoverification. Simultaneously, Notifier will send out an alert that this is happening. That might be an alert on a computer screen, a page, or a similar type of communication method chosen by the laboratory.
EDITOR: Is this popular?
VAIL: Absolutely. Once lab customers see how these middleware applications can monitor work processes, they bring other types of issues to us. They want middleware applications that can trigger notifications based on all types of different events. Often light poles are used as visual notification within the laboratory.
“Middleware is the informatics solution that allows hospitals of almost any bed size to take their existing laboratory facility and add the software functions necessary to compete in the outreach marketplace.”
EDITOR: Greg, given the middleware solutions you’ve described as already in use in laboratories, it seems that this management option is robust and ready for “prime time.”
VAIL: That’s definitely true. Middleware is simple. It is typically very robust. It can easily be reconfigured to meet the changing business needs of the laboratory, often with no additional investment. We place a great deal of emphasis on putting control of this reconfiguration in the laboratory’s hands, not ours or that of a separate IT department.
EDITOR: Now that we understand how laboratories today are using middleware solutions, I’d like to circle back to ask you how middleware is being used in hospital laboratory outreach programs.
VAIL: There’s lots of exciting things happening in this area of laboratory operations. When a hospital wants to launch an outreach program and make it grow, that entire business line fits the manufacturing paradigm. Hospital inpatient testing is mostly performed between 7 a.m. and 5 p.m. Outreach specimens typically come in after 5 p.m. and allow the laboratory to use its asset base for more hours each day.
EDITOR: That fits the manufacturing paradigm of using the same factory and equipment two or three shifts per day.
VAIL: Exactly, and this additional utilization of fixed overhead, equipment, and computer systems helps drive down the average cost for all testing done in the laboratory, including the inpatient work. Middleware is the informatics solution that allows hospitals of almost any bed size to take their existing laboratory facility and add the software functions necessary to compete in the outreach marketplace.
EDITOR: I’d like to shift gears again. How are big healthcare IT vendors reacting to the use of middleware by many of their customers?
VAIL: Let me answer that this way. In the healthcare IT marketplace, many of the largest IT vendors are emphasizing software solutions and enhancements to HIS and similar products. This is consistent with the interests and needs of hospitals and health systems to develop a fully-integrated EMR as soon as possible and their interest to provide enterprise-wide solutions. But, as a consequence, the development of traditional LIS products is lagging. That is why growing numbers of laboratories are turning to middleware as a way to gain the functions they need to keep their lab competitive.
EDITOR: Inherent in that answer is your belief that the market for laboratory middleware solutions will be dynamic and fast-growing. That is based on growing interest by lab customers.
VAIL: I would agree. As we have done in the past, over the next few years 100% of what we develop will be in direct response to a customer’s request. I say this because we have so many requests now—and these customer requests are the source of many of our innovations. This development strategy ensures that our software meets the real-life business needs of the laboratory.
EDITOR: That makes Data Innovations rather unique. You are building self-contained software applications—the middleware we’ve been discussing—to meet the specific requests of laboratory customers. Unlike the traditional LIS, with its myriad lines of code, I would assume that you can bring these middleware solutions to market rather quickly.
VAIL: That’s correct. These are truly customer-driven products. Because of the add-on nature of the incremental modules we add to core product, we are able to add or rework one area without affecting another, making it even easier for labs to integrate into their operational environment.
EDITOR: I am curious about what you’re ready to introduce next.
VAIL: Our newest add-on feature is our Maintenance Manager module. It will be available in version 8.05, set for release in early 2006. It will allow the laboratory to go paperless on its maintenance. This includes preventive and unscheduled maintenance for everything from instruments to fire extinguishers and even temperature readings on refrigerators. It includes troubleshooting help with supporting documents and full logs to aid
with inspections.
EDITOR: Given all the paper in laboratories, this has to be a good thing.
VAIL: Paperless maintenance is a great example of a useful middleware solution. The goal of middleware should be to allow med techs to be as productive as they can be. It frees them up to concentrate their technical skills on improving patient care.
EDITOR: Does this type of middleware application free lab staff, both at the bench and in management, to shift to higher-value activities?
“Paperless maintenance is a great example of a useful middleware solution. The goal of middleware should be to allow med techs to be as productive as they can be. It frees them up to concentrate their technical skills on improving patient care.”
VAIL: Yes, middleware is something that takes the handcuffs off the laboratory and allows it to function as a business—that just happens to be in a hospital. Now they have the tools to be “business competitive.”
EDITOR: Using middleware to become “business competitive” is certainly an underappreciated benefit. Also, the fact that middleware is an affordable way for even laboratories from smaller hospitals to support a competitive outreach lab testing program may eventually change the competitive marketplace. Middleware is already spurring change in laboratory operations. Greg, thanks for an enlightening discussion today.
VAIL: Robert, it’s my pleasure. I appreciate the opportunity.
