Lab Soft News

Home Town Newspaper Covers Data Innovations

Data innovations (DI) is a significant player in the lab software space. I have posted previous notes about the company. DI provides to the lab industry a comprehensive set of interfaces between LISs and analyzers. It also sells lab middleware, both under its own label as well as in the form of products sold by major in-vitro diagnostics (IVD) companies under their own labels. A recent article about the company by its home town newspaper, the Burlington Free Press, provides useful information (see: Data Innovations expands). Below is an excerpt from it with boldface emphasis mine:

Data Innovations' products, known as middleware, and services provide the link between a lab's analyzers and its information system. They interface with analyzers and with equipment for automation....Nearly 1,000 instruments, automation systems, and information systems are supported by Data Innovations' middleware....Data Innovations' products traditionally were designed for the reseller market and are sold to suppliers of analyzing instruments and to suppliers of laboratory information systems. Customers include McKesson, Roche Diagnostics, GE Healthcare and Ortho Clinical Diagnostics and many others. In March, GE Healthcare headquarters announced that it would provide Data Innovations products, along with GE services, to customers for instrument interfaces, replacing GE-developed modules. When Data Innovations acquired P.G.P. of Brussels, Belgium, in 2007, it added a related component that serves more than 1,200 direct customers....Forty employees in South Burlington staff departments of sales and marketing; software development, customer service; quality assurance regulatory and documentation; implementation consulting services; training; finance; human resources and a production department that builds and ships the company's systems...."Within the last few years, we have been developing and growing the [I]mplementation [C]onsulting [S]ervices. The ICS consultants combine their knowledge of our software and services with their knowledge of advanced laboratory workflow to make our customers' processes more efficient and therefore more profitable," [a company spokesperson] said.

This article contains three of the magical words in today's lab software industry: middleware, workflow, and consulting. I have made many references to middleware in previous notes. You can generally define this category of software as a product that is interposed between the LIS and a lab analyzer that serves as an interface but can also offer additional functionality. Hence the middleware label. For example, some middleware now serves as a rules engine that can process test results coming from the lab instrument.

In part because of the growing popularity of Lean/Six Sigma, the term workflow has taken on additional weight in the eyes of lab managers. An understanding of workflow implies the knowledge and ability to increase the efficiency of a lab and reduce costs. For example, the term appears consistently in press releases from Siemens Medical Diagnostics describing the value that the company brings to the table for customers.

Finally, a brief discussion about the role of lab software companies as consultants to lab managers. A number of LIS vendors and IVD manufacturers have attempted to recast one of their business units as lab consultants. One such example is Ortho Clinical Diagnostics' ValuMetrix Consulting Service. Some LIS vendors have had difficulty carving out a niche as paid consultants to their lab clients, partly because of the monthly support fees that the clients pay to such vendors for software support. It has been difficult for the vendors to differentiate between these paid-for software support services and consulting services that lie outside of these recurring payments. I suspect that the focus of Data Innovation's ICS unit will be, in part, the development and deployment of lab rules. I have posted a number of previous notes about such rules in the past. It may be relatively easy for the company to offer remunerative consultation services in this area, particularly when it is easy to demonstrate the payoff of rules deployment calibrated in staff reductions. Autoverification rules in particular hold such a promise.

A Brief History of Automated Rules in the Clinical Laboratory

Stimulated by a lobby conversation that I had at the APIII conference in Pittsburgh, I began to reflect on the history of automated rules in the clinical laboratories. About five years ago, I had conversations with the developers of Lab Wizard, a rules engine that had achieved success in Australia. It was developed and marketed by Pacific Knowledge Systems (PKS). At that time, PKS was trying to sell its software in the U.S. without a great deal of success and despite its  high quality.

The primary intended use for Lab Wizard at that time, and its major application in Australia, was the automated generation of interpretive reports for patients based on their abnormal test results. There was not much enthusiasm among lab professionals in the U. S. for interpretive reporting. partly because of the perception that clinicians did need or want help in interpreting test results. There was also a concern that computer-generated interpretations could not be billed for and thus represented an additional cost in a commoditized business. In Australia and by way of contrast, such interpretive reporting was viewed as an important component of a lab report and a quality measure.

There have been major shifts in the lab business in the intervening years, one of which is the growing enthusiasm for lab middleware, about which I have posted multiple previous notes. One of the most common features of many middleware products is the inclusion of a rules engine. Autoverification is the most popular rule being deployed in U.S. labs today whereby test test results are released without human review if they are normal or similar to a patient's previous results. The major impetus behind the interest in this type of rule is the need to reduce labor inputs in the lab, spurred on by a shortage of medical technologists and the aging medical technologist  population. There is a similar driving force behind Lean/Six Sigma projects.

So, the moral to this story is that Lab Wizard was probably being offered to lab managers in the U.S. prematurely. Enthusiasm has now peaked for in the U.S. for rules, so PKS is taking another run at both labs and the IVD companies selling middleware. My friends are telling me that their efforts are now being rewarded with much greater success.

Some Unsolicited Advice for Vista Equity Partners About the Misys LIS Purchase

I covered the Misys LIS purchase in a previous note primarily to report the breaking news (see: Misys Sells Diagnostic Systems Business to Private Equity Firm). Here are some additional links to news about the recent Misys LIS purchase by Vista for $381M. I have no connection to Vista Equity Partners nor any knowledge about the firm's goals for the LIS that they have purchased. However, I thought that I would offer some unsolicited opinions to them about various aspects of lab software and the clinical lab culture:

• In my opinion, Misys allowed their LIS to languish due to inadequate investment in R&D while some of their competitors forged ahead. However, most of the existing client base were able to hunker down on their "classic LIS" product and never bolted. This installed customer base is a very valuable asset but these labs will not stay in the fold forever as their software functionality needs continue to escalate.
• The lab software industry has become highly fragmented recently with the emergence of strong competitors in the areas of middleware and web-enabled lab outreach software (also called lab portal or web portal software). In fact, many of the current Misys customers have been able to add functionality to their core Misys systems by supplementing them with these other software products.
• Selling software to lab professionals can be a challenge. The name of this game is functionality. This is also a  moving target, given the emergence of molecular diagnostics and the lab outreach market. Save the "power lunch" money for hospital CEOs and CIOs. For the lab crowd, your LIS sales staff will need to endure hours of scripted demos at lab sites designed to ferret out all of the weaknesses of your system. Some healthcare IT vendors may be able to foist an inadequate LIS on a hospital lab but only as part of an EMR package that is marketed solely to the hospital executives.
• You will also be selling into a hospital lab market that is capital-starved. Hence the great appeal of middleware and lab outreach software that can add functionality to a system with a smaller price tag. Many of the C-level hospital executives are often saving their loose change for an EMR or a PACS.
• As if this weren't enough, two very large corporations, GE and Siemens, are raising the ante in the lab/LIS world by promoting a new "doctrine" of in-vivo/in-vitro diagnostics (IV2D). Think of this as a major health delivery model shift with the center of gravity moving toward a diagnostic-centric model for healthcare. Some onlookers are even promoting the idea of an integrated "department of diagnostic medicine" created by the convergence of pathology, lab medicine, and radiology. If and when you invest in enhancements to the LIS that you have just purchased, keep in mind that the LIS and RIS worlds may be converging and integrated functionality of these systems may be highly valued in the future.

Local Lab Control of Middleware

In response to my recent post entitled Lab Software ROI and Middleware (link here), Dr. Curt Hanson, a hematopathologist at Mayo Clinic, commented in the following way (boldface emphasis mine):

Middleware (using an Orchard product) has been a critical part of our Heme lab for several years. We were able to show a significant decrease in personnel due to the use of the rules-based process. We have continued to expand its role in the lab and now we are at the point of worrying about over-dependence on a single product! We have moved from just looking at delta checks, quantitative and qualitative flags, to setting rules for specific medical practices, setting review criteria for individual patients that have unique medical issues (e.g., blasts or lymphoma cells that can be easily missed on the off-shifts; DIC f/u's, etc.), deriving productivity and work flow data that can be used from a management perspective, and standardizing the lab heme practices that are located at a variety of remote sites around the medical center. We are now exploring how we can use middleware to enhance our lab's patient safety initiatives. There are a lot of opportunities in this area. The classic LIS vendors have not been able to offer the degree of creativity and flexibility that the middleware product has allowed us. The ability to drive the software at a local lab level has been critical to its success as opposed to the necessary hierarchical controls that sometime exist for large central LIS systems.

Curt makes two very important points that I want to highlight. First, it's important to view a lab rules engine as a decision-making tool. If the rules running on it are well conceived and executed, they function as a proxy for some decision-making by a medical technologist or pathologist. It is understood, of course, that the talents of the lab personnel stand behind the rules and monitor them on a daily basis.

Rules therefore are used to manage routinized tasks, freeing up the medical technologists and pathologists for more creative work. Also, as Curt emphasizes, a talented lab team will push the capabilities of rules as they become more comfortable with their capabilities, extending them into a set of ever expanding tasks.

Curt's second point is also worth emphasizing. He refers to the "necessary hierarchical controls that sometime exist for large central LIS systems." From where I have always sat within the departmental LIS group, the personnel and the LIS itself seem very flexible and accommodating when compared to the central IT group of my hospital or other comparable facilities. For a pathologist embedded in an individual lab, however, the LIS may be seen rigid and hierarchical. Part of the appeal of middleware with its rules engine is that the locus of control for this software migrates to those labs creating and deploying their own rules.

Lab Software ROI and Middleware

I am in the early stages of developing the program for Lab InfoTech Summit 2007 that will take place on March 5-7, 2007, at the Venetian Hotel in Las Vegas. Two workshops will be offered at the conference. The first will focus on the return-on-investment (ROI) of lab software, including middleware, and the second will discuss lab rules development and deployment. I have posted a number of previous notes about lab middleware and rules (links here, here, here, here, and here). CAP Today also had a recent article about middleware (link here).

Although middleware can be defined in many ways, one major component of most of the software packages is a "rules engine" that allows users to integrate rules into various lab processes. One popular use for lab rules is autoverification whereby test results are released to physicians without technologist intervention if they meet predefined criteria such as an acceptable delta check against a previous result(s).

I have never been enthusiastic about the idea of calculating the ROI for LISs in order to justify the purchase of a system. I always felt that the complexity and breadth of the various applications included in a "classic" LIS made such a calculation contrived and artificial. Moreover, the value of some of the most critical LIS functions may be very difficult to quantify as part of the overall ROI calculation.

However, the very focused nature of middleware, and particularly the availability of a rules engine, makes this type of software more amenable to ROI calculations. There are a number of articles in the literature that discuss personnel savings and other efficiencies resulting from the initiation of autoverification. Here is a link to one of them and below is an excerpt from the article summarizing the impressive net gains from the process:

Before implementation of autoverification, 14 FTEs were required for result-review–related functions (8 for chemistry and 6 for urinalysis). Six months after implementation, the laboratory had assigned 8.5 FTEs for performance of these duties (4.5 for chemistry and 4 for urinalysis). Thus, autoverification has led to personnel savings of 5.5 FTEs, or a reduction of ~40% in personnel assigned to result-review function....After implementation, the combined TAT for all routine orders was reduced by 22% ...because delays attributable to manual result review were eliminated. The laboratory’s annualized total workload has increased by 4%, whereas STAT orders have gradually decreased since the implementation of autoverification.

Cerner Exclusive Distributor for Correlagen's GeneExplorer

Correlagen Diagnostics has announced the availability of GeneExplorer, an automated platform that enables hospital-based clinical labs to perform genetic testing with limited user intervention. Protedyne's Radius is the robotic device supporting the platform. GeneExplorer is a compact analyzer capable of processing a variety of clinical samples using modular attachments.

Cerner Corporation will be the exclusive distributor of GeneExplorer that is integrated with Millennium Helix, Cerner's molecular diagnostic software package. Here is the link to the press release, here is the link to the Correlagen home page, here is the home page for Protedyne, and here is the Cerner page with additional information about Helix.

David Margulies, M.D., president and chief executive officer at Correlagen said, "Correlagen's reference lab services are currently marketed via our distribution partners or directly to providers. The new Cerner distribution channel increases the breadth of our services to medical centers that have the capacity to perform diagnostic sequencing in-house to both improve turn around time and reduce cost. Integration with the Cerner Millennium platform creates unique opportunities to correlate sequence information with patient phenotypes, the essential activity that enables discovery."

This announcement is very interesting on a number of counts:

• Correlagen's previous business model has been that of a reference lab so GeneExplorer seems to be its first venture as the manufacturer of a diagnostic sequencing platform. Partnering with both Protedyne for the robotic device and Cerner with its Helix software strikes me as a well-thought-out strategy for entering the IVD market.
• David Margulies was formerly an executive with Cerner, so turning to his former company to create this marketing alliance is a natural fit.
• IVD companies decades ago owned reference labs but all of them have exited from this side of the clinical lab business. I wonder if this new announcement is an omen that this business model is coming back into favor. See my previous note here about PerkinElmer entering the neonatal testing business.
• I am also stuck by the symmetry of Cerner moving "downstream" as a distributor of an analytic instrument integrated with its LIS software in contrast to the strategy of the IVD manufacturers moving "upstream" and competing with vendors like Cerner with their middleware products.

The Appeal of Lab "Middleware"

I received a comment to my note of March 29 from "LIS Vendor" that I have copied below. My note was entitled "Measuring the ROI of Middleware Solutions" and you can link to it here.

There are very good LISs on the market that provide the very features you mention here. I'm not sure why you have a fascination with middleware. It can and often does become a critical point of failure. Trying to prop up an old or poorly designed LIS with middleware is like trying to keep that old car running with rubber bands and duct tape.

The comment raises the question about why I comment frequently about middleware in Lab Soft News and I agree that I have a special interest in the topic. You can read some of my recent notes about middleware here and here.

I will provide below a bulleted list of why lab middleware appeals to me but first I want to raise a definitional issue. Middleware and LISs are both types of software designed to support clinical lab functions. Middleware provides modular solutions that are frequently not provided by the broader LISs or that are superior to the LIS alternatives. If this were not so, there would be no market for the products and they would disappear from the market. Middleware, in my judgment, does not serve to "prop up" an installed LIS but rather to extend its usable life and also continue the monthly maintenance fees for the LIS vendor. Having dealt with this point, I will now proceed to present my bulleted list of reasons why middleware interests me so much:

• The middleware market has drawn the major IVD companies into the lab software market. I look upon this as a very favorable trend because the lab business is their only business. Although companies like Cerner, Misys, and Meditech started in the LIS world, this segment of the market is no longer their total focus. I prefer having my LIS vendor focused in this single area.
• As noted above, middleware allows the lab purchaser the opportunity, at a lesser cost, to buy a focused "solution" that one's current LIS vendor can't or won't supply. This cost issue grows increasingly important as the capital costs for lab software undergoing increasing scrutiny by hospital executives.
• The middleware product line has brought into the lab software market a host of new products, producing a more dynamic and competitive market. Middleware purchases come with an additional price, however, and that price is the challenge of integrating a number of heterogeneous software components into an interoperating lab-based network. This integration challenge has produced a new market opportunity -- I hope that the LI'S vendors who are unhappy about the increasing sales of middleware will see this as an opportunity to develop and sell this new type of product.

::  Update on 4/3/2006

William Shipley of Schuyler House added a comment on 4/3/2006 that is worthy of note. Read the whole thing. Here is a portion of his comment:

The introduction of the IVD vendors is not new, and is, in my opinion, doomed to the same fate as their previous ventures.  The problem is that they are in the business of selling instruments and, thus, will attempt to utilize their software to lock in a laboratory to their instrumentation.  Support for competitor’s instruments, while critical for full functionality, is not in their main interest.

It is absolutely correct that various IVD vendors have entered the lab software market before with only limited success. It is also correct to say that their core business is selling analyzers and reagents. I have heard IVD vendors in the past say that they are in the information management business as opposed to the information creation business, but not necessarily understanding all of the implications of total lab information management. One of the litmus tests for the IVD vendors entering the middleware market will be whether their middleware products will be able to interact with information from their competitor's analyzers.

Measuring the ROI of Middleware Solutions

I have written a number of previous notes on lab middleware. You can review some of the most relevant here and here and here. Middleware is lab software that is installed and integrated with the LIS to provide functionality not provided by the LIS. In essence, it provides new lab capabilities at a relatively modest incremental cost. The individual middleware modules are sometimes referred to as supplemental lab application modules (SLAMs).

Although rules (algorithms) can be deployed on LISs and have been used for decades in lab computing, there has been an accelerated interest in rules lately for the following reasons: (1) middleware products can provide access to a rules engine for the first time in some labs; (2) personnel shortages are causing lab managers to explore ways to increase the efficiency of lab operations through the use of rules; and (3) lab managers are seeking ways to trim the fat from lab budgets because of cost constraints and rules can help them achieve this end.

Because SLAMs provide very focused solutions and because C-level executives are scrutinizing capital requests from lab managers for new software purchases, there is also a renewed interest in quantifying the return on investment (ROI) after middleware products have been purchased and installed. I hasten to emphasize here the criticality of obtaining baseline measurements about the efficiency of various lab operations, and most specifically the "problem" that the SLAM is designed to correct, before the SLAM is installed.

Here are three examples of middleware solutions that lend themselves to relatively easy measurement: (1) automated specimen archival retrieval; (2) results autoverification; and (3) positive patient identification. Although a number of metrics could be used to assess each of these, the most obvious would be: (1) mean time to retrieve a specimen for test add-ons by lab; (2) decreased test turnaround time (TAT) by lab by shift; and (3) a reduction in specimen identification errors however defined by the lab.

This discussion brings to mind one of the features of my new car -- the ability to display current miles-per-gallon performance while en-route.  Middleware could similarly calculate lab management and quality measures on-the-fly, allowing for experimentation by lab managers to improve some specific performance measure. For example, one could change staffing on a particular lab shift and look for improvements in TAT. There is a very satisfying feel about using a software tool to measure its own value.

IVD and Lab Software Vendor Collaboration

For several decades, what I will call the product overlap zone between the IVD and lab software companies has consisted primarily of instrument interfaces. There is now much more product overlap in this manufacturing space with the IVDs developing so-called middleware, often through third parties, and Cerner, as one example, developing a bar-coded drug administration system for use in patient care units.

Additional evidence for this overlap is that Lab InfoTech Summit, and its precursor meeting that was referred to as AIMCL, has never hosted an IVD company as an exhibitor in 23 years.  For the conference next March, four IVDs (Abbott, Beckman Coulter, Roche, and Sysmex) will be participating in this lab software conference as vendors. One of the major drivers for this shift has been the inclusion of a middleware workshop at the conference that is being advertised as an industry dialogue.

I believe that the time is now appropriate to initiate a dialogue between the IVD and the lab software companies to develop what I will refer to here as a "lab plug-and-play-methodology" (LPPM) that will facilitate interoperability between LISs/middleware on the lab software side and devices on the IVD side. We will define a device as an analytic instrument of any size ranging from a glucometer to a total lab automation (TLA) line.  Such an LPPM would be designed to eliminate the need for LIS-device interfaces and facilitate rapid device and inexpensive deployment of the devices.  I am avoiding the use of the term "standards" in this discussion in favor of the more neutral term of LPPM to avoid any preconceived notions of how this dialogue should be structured.

I believe that any discussion pertaining to a LPPM will require a convening organization to get the ball rolling and help develop a work plan. I also think that the convener should be a non-profit organization with some intellectual stake in a successful outcome to the discussions. Examples of such an organization would include CAP, AACC, ASCP, CLMA, API, or even the Pathology Education Consortium (PEC), the sponsors of this blog. The key question at hand is whether the business plans of the major IVDs and lab software companies would allow them to actively and collaboratively support the development of an LPPM.

Two Trends to Counter Lab Testing Commoditization

I foresee two trends for the clinical labs that should provide some relief to the commoditization of lab testing which has been a race to the bottom of the price curve for the industry. The first is the high level of interest in emerging cancer biomarkers. No less an authority than the Wall Street Journal in its year-end assessment of hot spots (December 31, 2005) included cancer biomarkers in its short list of critical areas to watch during the new year. You may want link to this previous note on biomarkers.

The second major trend to watch in the clinical lab industry is the "finishing" of test results after they are have been created in the various laboratories. For the purposes of this discussion, I will refer to this finishing process as the organization, integration, and consultation (OIC) of test results. Some of these three OIC processes will be managed by middleware rules or by rules running on the LIS which has been discussed previously here.  Refer to the middleware & lab rules category in the right hand column for references to other blog notes.

Organization refers to the arrangement of test results for a patient in a structure that facilitates the clinicians' understanding of them, sometimes by lab or sometimes on the basis of a patient's underlying disease. Integration means placing results into a context such as associating one result to another (e.g., an abnormal converts to normal) or connecting results to a patient's diagnosis. Consultation refers to a sophisticated synthesis and analysis of test results by a lab medicine expert for complicated patients.

Here are some of the major reasons why lab-based OIC will achieve increased importance during this new year and subsequent years:

• The complexity of lab testing will increase because of the growing popularity of newly developed biomarkers, initially to monitor patients with a history of malignant neoplasms but eventually as standard tests in wellness screening.
• Clinicians are increasingly challenged by their patient loads and anxious to improve their clinical efficiency; OIC support from lab medicine experts will be enthusiastically endorsed by them.
• Payers of healthcare services will begin to view OIC processes as an enhancement of lab quality control and also a means to make better use of lab test results, some of which may be misinterpreted or overlooked by harried clinicians.