Toolkit lets labs make the case for the right LIS, 8/13:1
In ancient Rome, the legions might gird for combat with a muscled cuirass, helmet, and greaves, and carry a pilum. But none of them ever had to confront a hospital system C-suite, with high-level executives whose titles start with “chief” deciding between a single, enterprisewide information system or a “best-of-breed” laboratory information system.
For that kind of engagement, the Association for Pathology Informatics (API) maintains, the clinical laboratory needs better equipment to protect its interests. And—although it looks nothing like a broadsword—API believes that its LIS functionality toolkit will fit the bill.
The toolkit can be used to assess the various LISs on the market. It’s an idea that stemmed from a strategic summit the API held in spring 2012 to address a nationwide trend: institutions’ acceptance of LISs offered to them by the vendors of their enterprisewide solutions as a component of those solutions, with Epic the poster child for the trend. But many laboratories are not always certain those embedded LISs can address their comprehensive and increasingly sophisticated IT needs.
“Over the last five or six years, the major EHR vendors like Cerner and, increasingly, Epic have been producing a whole suite of software including the LIS for hospitals, and these EHR vendors have very ready access to the executive suite,” says Bruce A. Friedman, MD, active emeritus professor of pathology, University of Michigan Medical School, and a developer of the toolkit.
Several other companies make electronic health record systems, including Siemens Healthcare, Allscripts, GE Healthcare IT, and Meditech. While Cerner and McKesson still hold the lead in the number of installed EHRs in the nation, Epic is catching up quickly. “The vast majority of all ‘buy’ decisions in hospitals with 500 beds or greater are to go with Epic,” Dr. Friedman says.
Following the strategic summit in 2012, with financial support from LIS vendors Soft Computer, McKesson, Sunquest, and Cerner, the API decided to develop an LIS functionality toolkit that might help laboratories convey to hospital executives the complex IT needs of the laboratory.
The toolkit consists of a 6,000-word white paper, plus three appendices: an 850-item list of simple functionality statements with which a laboratory can specify the complex set of tasks that an LIS should perform, each paired with a weighting measure from one to four to gauge importance for the labs; a set of scenarios that a hospital can use as scripted demos to elicit possible functionality gaps during live vendor demos; and a list of the various categories that need to be taken into consideration when calculating the total-cost-of-ownership (TCO) of any particular LIS. This TCO calculation is important, Dr. Friedman says, because if the workhorse LIS of a pathology department lacks certain functionalities, there can be substantial up-front capital and long-term maintenance costs to purchase, install, and incrementally operate the additional software modules needed to compensate for the identified functionality gaps.
In September, at the meeting of the American Society for Clinical Pathology, the API intends to announce the availability of the toolkit as a download from the API Web site. “Everything we’re doing with this project is to help hospitals make an intelligent LIS buy decision and get the optimal, highest possible total functionality of the system,” Dr. Friedman says.
CIOs were generally not involved in selecting and implementing laboratory information systems 20 years ago, says Andrew R. Splitz, another of the developers of the API’s toolkit. Splitz is president and CEO of S&P Consultants in Boston, perhaps best known for implementation and customized solutions on leading systems at individual sites. CIOs, he says, are “involved nowadays, because the systems are so expensive. But the driving force is money, not functionality. They don’t understand the complexities of the lab and the role of the LIS as the backbone that supports the mission of the labs.”
“So we see this giant problem coming down the road of computer systems being institutionalized and not having put that focus on the functionality of the clinical systems.” Complicating that phenomenon, Splitz notes, is that pathologists are trained in pathology, not business.
“We felt the functionality toolkit was the best way to provide pathologists with a mechanism, when walking into the C-suite, to present a well-documented business case for the LIS they prefer—to say, these are the missing functionalities if an inadequate LIS has been selected, and this is what’s going to happen if we don’t have them. Higher costs to add the necessary software or to perform the missing functions manually.”
Everyone is anxious about buying “vaporware,” he adds. “The systems we’ve had in the lab are very sound and functional, and you don’t want to purchase a system that lacks the functions you need or comes with a promise from the LIS vendor that they’re going to develop them in the next one to three years, because we need to have that support now.” If laboratories are forced to backslide five steps, Splitz says, most will need increased time at the bench to prevent declines in safety and functionality. “And that’s really not too much of an option when you cost out laboratory services.”
An institution might be told that a laboratory module is included in its EHR at no additional cost. “So if you bought a $100 million EHR license for the entire hospital and all the modules, the licensing fee for the laboratory module might be included. But the implementation costs are extremely expensive and won’t be covered by the EHR license.”
“You may be looking at $800,000 to $1.4 million to install the core laboratory system and then still have to address the purchase and installation cost of the additional systems and modules such as blood bank and outreach. So when you start adding all of these up, it’s not just one implementation, it’s like five or six implementations. What they have done in the lab is fractionate us and force us to install multiple systems.”
In the toolkit, the development group provides a worksheet to enable pathologists and institutions to assess the true cost of ownership of a whole system. The aim would be to “normalize” different offerings from LIS vendors so that an apples-to-apples comparison can be made. “The vendors all like to bundle items and come back with different categories and things they’ve included,” Splitz says, “so a TCO worksheet allows lab personnel to develop a summary comparison including all financials, licensing, and implementation costs.”
“As a CEO, I would be really attracted to the idea of an integrated super database that is associated with an enterprisewide solution,” Splitz says. But with this latter approach, as opposed to a best-of breed lab solution, lab professionals often pay a significant price.
With the 850-item functionality list, the laboratory can grade each item from a range of four—a must-have, such as providing an audit trail of canceled tests—to a one or two for functionalities that might be nice but are more optional, such as voice recognition capability. “That’s the first big piece of the toolkit,” Splitz says. “When functionality statements are included in a request-for-proposal, the vendor must respond to each of them. Lab professionals can grade the product according to the responses, which can be invaluable later after a contract is signed to say you told us the feature was in the current release.”
Dr. Friedman says the message is not that labs need to use all of these functionalities. “They can pick and choose. But we wanted to provide a comprehensive reference list,” he says. “Before, people were working on their own unique in-house lists. In addition, the future of the lab lies in genomics and proteomics, and those functionalities are still in a state of flux, so we consider this a dynamic list that will change as labs take on new functions.”
The functionality toolkit also discusses the development of scripted demos that consist of a series of scenarios to determine during live vendor demos whether a single system might meet the work process needs of a particular lab. Why do laboratories need their own scripts to help guide a vendor demo? “First of all,” says Mark Tuthill, MD, head of the pathology informatics division, Henry Ford Health System, Detroit, “you make sure you’re not stepping into rote presentations, potentially things that have been canned by the vendor who naturally wants to put their best face forward. The idea is to take scenarios more from the laboratory’s perspective and under its control versus the vendor’s.”
“So it’s more than just ‘check a box, yes we do this.’ Show me how you can update my microbiology culture, what reformatting is done on the EHR side. You want the vendor to do a demo they’re comfortable with, but then you want to be able to ask for certain types of specific scenarios too.”
For example, Splitz says, a children’s hospital might ask to see how the system is able to manage low-volume specimens. “You want to make sure the vendor, who has responded to an RFP and described which functions it did and didn’t have, can come in and use your scenarios to demonstrate how easy it is to go through particular steps.” Sometimes a product will technically be able to cover a particular functionality. An example, he says, would be a specific workflow that may be easy to perform in one system while it requires many steps or is extremely cumbersome in another. “Just because they say they can support the workflow doesn’t mean it provides an optimized solution.”
The C-suite often includes a CIO who is not a pathologist or pathology informaticist and may be heavily oriented toward a primary vendor solution, says Ulysses J. Balis, MD, professor of pathology and director, Division of Pathology Informatics, University of Michigan Health System.
“But executives may not see the drawbacks of selecting an enterprisewide system architecture that itself may be an amalgam of incomplete core functionality with third-party products, as contrasted with the best-of-breed LISs, which offer a seamless workflow, at least within the laboratory setting, and many more capabilities such as rules, self-configurable interfaces, and flexibility with both billing and external reference lab interfaces. These are things that are still on the drawing board for some companies,” he says.
A co-developer of the toolkit, he views it less as a weapon and more as an equalizer that can weigh realities against marketing pitches. “The toolkit is meant to remove a number of significant ‘pain points’ associated with the selection, purchase, and stewardship of LISs,” Dr. Balis says. “It simply enumerates functionalities and lets those using the tool make their own determinations as to the level of feature richness, by applying the questions at their discretion.”
“So it’s the idea of having a standardized roadmap. Clinical laboratory staff and pathologists who have not been through the LIS selection process—and that’s many, if not most—would have a way of being equalized by the collective wisdom of the people who are creating these questions.”
“We’re not looking for exotica,” Dr. Balis emphasizes. “These highlighted features really are present to a lesser or greater extent in all major products. The question is, how seamlessly are they implemented? How capable is the vendor application of communicating within and across internal LIS modules and finally across interfaces to disparate systems with other vendors or other EHR products? By going with a best-of-breed LIS package, there actually may be less overall burden of stewardship because in that case, one doesn’t have all these third-party middleware packages to run in addition to the complex LIS package itself.”
As an example of how scripted demos might help laboratories assess different systems’ capabilities, Dr. Balis cites the tracking of reagents in the molecular laboratory module. “Tracking lot numbers and reagent batches can be a complex task, recognizing things like master mixes, subcomponents, or primer mixes that go into a final master mix.”
“So let’s say you find after you’ve done a significant amount of testing that one reagent component of a master mix was defective, and that, of course, necessitates the clinical need for retesting in order to push out correct clinical results. Recognizing that not all the testing performed to date is defective, can one use the LIS database at the reagent level to generate a workload manifest of testing that needs to be redone?”
“And that’s a subtle but important distinction. Because if you are able to do that, you can minimize a lot of work and expense—and additionally there may not be enough sample left to do everything from the ground up. So this more nuanced scenario has to be quite carefully controlled if you are going to compare disparate systems.”
IT vendors do not demonstrate their products side by side and are typically brought in serially. Dr. Balis has found that having one vendor a week perform a demo, the typical pattern, is not as effective as having them showcase in rapid succession over days. “That way, participants from the departments have multiple vendors sufficiently fresh in their memories such that meaningful pairwise comparisons are possible.”
The field has gotten too complex for any one person to know all the questions to ask and how to frame the features of a contract, Dr. Balis believes. The LIS product guide that Raymond Aller, MD, has been editing for many years and is published in CAP TODAY has similar capabilities. “But the toolkit goes one step further, because it layers on top of the expected static facts an incremental matrix of weighting factors.”
What the developers have created, he says, is a value proposition about how important a feature is in the overall selection of the application or product. “The weighting factors will be changed, of course, based on local needs, but they are a good starting point based on the consensus of experts. And they give one a vehicle by which one can perform pairwise or multi-way comparisons between vendor products, and identify at least semi-quantitatively the superior product for the setting in which it will be deployed. Rather than simply providing a table of attributes of a system, we’re combining that now with a value proposition.”
The enterprisewide system is a relatively recent phenomenon that over the last two years, spurred by the Centers for Medicare and Medicaid Services’ emphasis on “meaningful use” and the HITECH Act, which provides federal subsidies for EHR implementation, “has really changed everything,” Dr. Balis says. “However, the enterprisewide solutions are competing against perhaps 40 years of evolution, knowledge, and expertise that rests with the contemporary generation of intermediate and larger LIS vendors who offer best-of-breed systems.”
Middleware products have been and continue to be employed as an integral component of overall configurations to meet functionality gaps in enterprisewide LIS offerings, Dr. Balis says. “But an assemblage of multiple middleware vendors with the core product increases its overall complexity to reach the same goals as a more sophisticated standalone LIS product might allow.”
A certain tension has generally existed between clinical practice and that of pathology/laboratory medicine when it comes to IT, Dr. Balis notes. “Typically the CIO and C-suite within the hospital/health enterprise come from the clinical practice world of internal medicine, surgery, or public health. So, not surprisingly, their central point of reference is the EHR.”
“From a clinical medical informaticist perspective, the LIS is often viewed with some level of suspicion as being either superfluous or unnecessary and a problem that can be mitigated by making it a natural extension of the EHR.”
But the LIS’ automation lines, the rules-based testing for autoverification, and data transformation for foreign systems—these are all activities that are different from those at the EHR level. “So there’s a false sense of simplicity and of thinking that the LIS can comfortably be swapped out in lieu of a central solution with no added burden of stewardship or complexity.”
The main concern is that this trend may represent too much of a swing toward an EHR-only solution, Dr. Balis says. “This could hurt the collective LIS market if we have very mature companies leaving the marketplace, leading to even fewer choices for sophisticated academic and community medical centers.”
At his own health institution, the University of Michigan, Epic is now serving as the EHR for outpatients, and by June 2014 that implementation will also include support for inpatients. “We have completely interfaced Epic to our LIS solution, which is made by SCC Soft Computer, and we just went live June 1 with very satisfactory results.”
It was a comparison document that his department put together five years ago that resulted in this configuration. “We were able to show the hospital IT leadership that the total cost of ownership would be much higher with an integrated EHR-based LIS solution. But of course five years ago that argument was considerably easier to make than now.”
At the University of Michigan, Dr. Balis says, he feels fortunate that the laboratory is an equal player at the enterprisewide IT level of leadership. “And that representation model is appropriate given the importance of lab results for the health enterprise at large. It doesn’t matter the size, whether it’s a community practice or academic setting.” For locales where pathology and the clinical laboratory do not enjoy that level of representation at the highest executive offices, he adds, “That should be an active goal.”
At Henry Ford Health System, the Epic installation is also underway systemwide, but the laboratory will not be included, says Dr. Tuthill. “We’re about one-third live and the process will be done in 2014.”
An enterprisewide solution does have advantages, he says. “One of the things it does is eliminate complexity because you’re eliminating interfaces by removing all the different department systems—the ER, surgical, OB/GYN, and so on—15 systems in our case.”
The laboratory and radiology departments at Henry Ford, however, are staying on their best-of-breed systems. “They looked at the complexity of our Sunquest Laboratory and Sunquest CoPath implementation and realized it would be difficult to handle those functionalities with an enterprisewide LIS solution.”
Dr. Tuthill doesn’t believe the Affordable Care Act is increasing pressure on labs to upgrade their informatics, but increasingly complex laboratory testing is. “I don’t think there’s a requirement for more sophistication than last year or the year before. It’s just that the drum continues to beat. At some point you have to look at a vendor replacement or upgrade process.”
“Henry Ford has been a Sunquest shop for 20 years, and has developed new aspects of its LIS in conjunction with Sunquest. But Sunquest on its own has just a very aggressive development process, so it’s constantly updating its LIS and building new modules, such as its molecular module which it just completed.”
The enterprisewide systems are probably adequate for core lab functions of clinical chemistry, hematology, and urinalysis, says Dr. Tuthill, a co-developer of the toolkit. “But is it able to do sophisticated functions such as special hematology, protein electrophoresis, molecular diagnostics, or genomics? Is your microbiology module able to talk to your chemistry module, which is sometimes necessary?”
Frequently, the functionality demands of the clinical laboratory are assigned a low priority, Dr. Tuthill believes. “It’s because the industry is just so swamped by all of this EHR deployment, and as a result, many of the best-of-breed companies are spending less time and effort on their legacy applications for the clinical lab. It’s really a bandwidth issue, some of it driven by meaningful use.”
“The toolkit is first of all a way to litmus-test your own current LIS and assess whether to upgrade from your current vendor. And secondarily the toolkit will allow you to assess a new LIS offering with apples-to-apples comparison. Finally, it allows a reasonable defense for a sophisticated lab to be able to easily present the gaps and deficiencies they may find in a solution being pushed on the laboratory through an enterprisewide system coming into their environment.”
Hal Weiner, president of Weiner Consulting Services in Florence, Ore., takes a somewhat different view of the need for the toolkit. (See “Concepts and consults,” above.) “In the industry, the driving force behind the move to enterprisewide systems has been the need to have an integrated electronic health record and a single source of data. The problem that comes about in doing that, from the standpoint of pathology informaticists, may be that the data may not be as accessible as if it were in a unique specialized best-of-breed laboratory database.”
There’s been a marked improvement in functionality from the enterprisewide solution vendors, Weiner says. “They may not currently have all the whiz bang functionality that best-of-breed vendors can offer, but that may or may not be important for the operation of a particular institution’s laboratory.”
Is the LIS functionality toolkit a quixotic, perhaps last-ditch effort to save laboratories’ LIS functionality from possibly inflexible enterprisewide solutions? Time will tell, in Weiner’s view. “In five years, those enterprisewide vendors may have the majority of the functionality that the current best-of-breed vendors have, and those best-of-breed vendors may just be meeting some specialty lab requirements. I wouldn’t say that best-of-breed has fallen from favor. But enterprisewide solutions are starting to deliver, or plan to deliver, systems with functionality that is close in capability to what best-of-breed vendors can offer.”
For his part, Dr. Balis stresses that the toolkit is not intended as a criticism of the enterprisewide solutions. But it’s important to quantitatively compare the current best-of-breed LIS approach versus an Epic system, for example, “on a fair, side-by-side basis,” he says.
The LIS functionality toolkit also isn’t the last word in how to select an LIS, Dr. Balis adds. “We simply hope it to be an additional tool that perhaps guides the inclusion of additional features or concerns in selecting an LIS, including those categories of often overlooked features and/or capabilities and operational requirements.”
“We’ve made our best effort to assemble a thorough list, and we hope that it will make people’s lives less frustrating in this area. But it’s by no means the last word in LIS selection,” Dr. Balis says. “And people should continue to exercise common sense and include their own experience and good judgment in the final selection process.”
Anne Paxton is a writer in Seattle.