Anne Paxton

When he began advising laboratories on how to select information systems, consultant Gary Braley was mystified by the number of laboratory reports that seemed to vanish into thin air. "The lab would say, 'We sent the report from the lab to the nurses and docs, and they didn't get it. They said they didn't get it, and we know we sent it.'" This was repeated to him so often, "I totally expected, the first time I started taking tours of labs, to find the hallways littered with reports," he said.

As it turned out, many of the reports were still in the laboratory or at the nurses' station. "But the systems were so screwed up, nobody knew where they were," explained Braley. As president of Braley Consulting Services Inc., Minneapolis, Braley tries to help laboratories avert that kind of systems failure when they are preparing to buy and install a new laboratory information system.

"It's hard to believe LISs have been around for over 30 years and we're still trying to figure out how to buy them and how to avoid disasters when we install systems," Braley said in a presentation at the June 1999 conference of the Clinical Laboratory Management Association, Dallas. Braley is currently working with a fairly small hospital, where there are few complications and a six-month selection process is planned, and an 11-hospital system that will take 10 months to choose an LIS. But laboratories of all sizes tend to make similar mistakes in selecting an LIS, he finds, and avoiding these is the key to successfully completing the increasingly complex implementation process.

One of the earliest mistakes occurs when developing budgets for an LIS, Braley says. "People tend to confuse system cost with project cost." Laboratory managers often tell him they budgeted for an LIS six months back and are ready to purchase one. "The question I always ask is where they got the number for the budget. And they say, 'Well, we talked to three or four vendors and got quotes of half a million to two million dollars and that's what we told the CFO.'"

But the chief financial officer and the vendors usually view budget quotes differently, Braley pointed

out. "The CFO is talking about total project cost, which often includes staffing, installation, travel, and support, and all of those things. And the company that gives you the budgetary quote isn't including those," he explained. "It's talking about the purchase price of the product from their company."

Time and again, he has seen the purchase price end up in the budget instead of the total project cost. Although he has never calculated the ratio of total system cost to purchase price, Braley said, "It has got to be a factor of two to one–particularly when you're talking about support costs over the lifetime of the system."

For a more accurate budget, he recommended preparing, well before budget time, a matrix that outlines all conceivable costs. Braley suggested contacting other sites to learn what unanticipated costs they incurred–whether from upgrades, cabling, travel, or other needs. In his experience, "If you get ready to sign a contract and install a system, and somebody asks what the cost will be, you'll overlook about half. You just plain won't think of it."

He also recommended projecting costs for at least five years to avoid being caught off-guard. "Some people say nobody knows what's going to happen in five years, and that's true, but for our planning, we have to think at least that far ahead, particularly when it comes to upgrading," Braley said. He has found that if the laboratory does a thorough cost justification, then when it needs new software and other enhancements in a few years, "It will help an awful lot if you can tell people that we said this three years ago and it's not a surprise item."

All aspects of the project should be included–travel, overtime, items people might not consider to be project cost, with special emphasis on staffing, he added. "What I'm hearing now from some vendors is, 'Oh, by the way, you can't just get by with your current LIS staff. You're going to need an Oracle database administrator, or you're going to need a network expert or something.' And when you walk in and say you'll need even half the cost of a database administrator, that will blow almost any budget out of the water."

People still think that computers are going to decrease staffing, not increase it, he noted. "In fact, if you want to run good complex information systems, they take very good support from either lab people or information systems people," Braley asserted. " You don't get the benefits of computers without a lot of effort, and a lot of that translates into expertise–which you may need to hire. And the more complex and newer the system, the more sophisticated that expertise has to become."

Even if you have no idea what potential staffing costs could be, "Any number you write down is better than leaving it out," he said. "A number can be pulled right out of the air if you want, but that's better than not thinking of anything."

All LIS projects should plan for upgrades about every three years, Braley believes. "If you buy an LIS, you should not plan on it lasting seven or eight years without spending some money on it, for one important reason. If you buy enough capacity now to handle a big workload for seven or eight years, then you just paid a whole lot for unnecessary disk storage," he said, because whatever you have to buy will be cheaper three or four years from now.

"So I usually tell vendors we want the initial configuration to handle our workload without purging any patient data for at least four years," Braley explained. "That means if we made a mistake, we'll get by for at least three years." At that point, the laboratory will have a line item for upgrades, which could include more disks, more terminals, or higher speed processors.

Never underestimate costs, Braley advised. "If you think the number is between 50 and 100, then use 100. You'll only get in trouble if you lowball it," he said. Although successful LIS companies generally have to be honest, "It's the salespeople's job to give you the lowest possible number," he noted. "Your job is not to go along with all the lowball estimates." Rather, laboratories should use the middle or high numbers for budgeting.

Price quotes can be deceiving, Braley pointed out. "If you go out to a vendor and say, 'We need a budgetary quote, tell us what you think an LIS will take for a 700-bed hospital,' you're probably going to get some very poor budgetary quotes." Companies that are run by engineers, for example," tend to throw everything but the kitchen sink into their proposals, all the software options and more terminals than you'll ever need, and so forth," he said. At the other extreme, "you have companies that are run by marketing and sales types, who believe the way to get business is to sell on the low end and upgrade later on."

Consequently, companies with similar technologies could propose prices that vary significantly, he said. "The worst thing you can do is assume that there's a real difference in the end price of those products and throw out one because it's way too high. In fact, it's probably high because it offers everything you can imagine, and it was a company run by technical people who didn't want to leave anything out."

To get more accurate budgetary quotes, he advises clients to assemble basic information so all the vendors, even at the budgetary stage, will be forming bids based on the same information. That means listing, for example, the number of terminals, the number of beds, the hospital's ratio of inpatient to outpatient work, and the total billable procedures. These figures can be approximate, but they allow the vendors to bid on systems of the same size.

"When you get done," Braley said, "if you've got a good budgetary quote process, you can take this range and say it's in there someplace; let's either pick a number in the middle or one slightly higher than the middle."

Overly optimistic scheduling can be a major pitfall in LIS planning, according to Braley. For example, a frequent mistake is to promise an installation by the end of the year but fail to take into account that the end of the year for most businesses is Nov. 15. "This isn't a financial thing; it has nothing to do with quarters," he explained. "But how many businesses do special project work between Thanksgiving and New Year's? It isn't a very productive time."

Most people, he finds, choose the right computer system, but they end up finishing far behind schedule. Part of the time people meet their deadlines, but they have not done their homework, leading them to pick a bad computer and rush installation. Another possibility–that they do an amazing job, buy the right computer, and finish by the end of the year–is the most remote. "How often have you seen people do a record-setting job on something as complicated as putting in an LIS?" Braley asked. "My estimate would be two percent of the time. It's like winning the lottery."

"As a manager, your job isn't just to buy a computer system, but to manage well, which means meeting your schedule," he said, adding that managers should develop a realistic project plan, not take an installation schedule from the vendor. "Don't copy one from somebody else, and don't take one your information system department said you should use, or one you read in a book, or heard in a lecture today."

When Braley asked a vendor why a system installation was running a couple of months late, the vendor said because Christmas and New Year's came at the end of the year." So I said, 'You mean the event that has happened every Dec. 25 for 2,000 years? You didn't put it in your plan?'"

Vacations, Memorial Day, Labor Day, the Fourth of July–all have to be factored in as well. One of Braley's current projects, for example, wisely blocked off the entire week of the CLMA conference where he spoke. "I'm tied up; the five project people are here; and all the vendors they want to deal with are here," he commented. "So that's a dead week in the project."

"Ninety-some percent of computer projects are late," he added." Are they late just because we're dumb and can't install things on time? No, most of them are late because the schedules were wrong in the first place, because we agreed to do it in five and a half months and it couldn't be done then." Braley recommended adding a week or two of cushion at several points in the process.

Leaving a cushion means being prepared for the unplanned events that are inevitable, such as a member of the project team breaking a leg, a staff member taking emergency leave, or a surprise laboratory inspection." Those unexpected things happen, and you don't want a single unplanned event to throw your schedule off," he emphasized." Don't set yourself up to fail with an unrealistic schedule." And don't back down, he added." I've seen enough good and bad LIS installations to know it's a hard job and you'd better start off with a reasonable plan."

Replacing an existing LIS, unfortunately, is harder than the initial installation, Braley said. "The system we bought 10 years ago had one or two sets of normal ranges. Now we've got 80 depending on test location, testing site, gender, species, and so on. Evaluation is more difficult, and support is more difficult," he asserted. The reorganization of hospitals and vendors has added to the complexity. " People who used to be competitors are now our allies, and former vendors are now our partners. All of these things change how an LIS will operate–and you never even thought of these things 10 years ago," Braley commented.

"In the good old days, when you went out and blew $500,000 on an LIS and it didn't work very well, it could be replaced," he said." But I'd sure hate to have my neck on the line if that happened today and I didn't have a really good reason why we bought the one we did and a real consensus in the organization that it was the right decision." It used to be easy to justify purchasing an LIS. " You could show people filing cabinets full of paper and say, 'Look we can get rid of all this paper.' Well, you got rid of, maybe, most of the paper, and you're electronic now. We're already doing remote reporting of physicians; that's not a benefit we can gain. We already streamlined the operation. So a new LIS can do a little bit more–but not a lot."

Obsolescence is different in laboratory systems than in other kinds of projects, Braley said. "Traditionally, computer vendors sold business systems with the idea that every five years you'd have to get a new one because the hardware becomes obsolete and so does the software." However, the average laboratory system probably lasts closer to 10 years, maybe even 15. Some are replaced earlier, but unless radical changes occur, most laboratories will have their system for 10 years, according to Braley.

Agreements with vendors also include periodic software upgrades, with the idea being that, in five years, you'll have the same software as somebody buying a new system. Although hardware sometimes needs to be replaced, Braley believes most people with a six- or seven-year-old LIS have

Moreover, changing LISs is a bigger task than most people anticipate." Even though we think we already have a computer and now we're computer people, the flow of information, the client/server technology, and the different way of interfacing instruments mean you'll make bigger changes than you expect. In fact, it's a pretty horrendous task," Braley said. The change-over will require converting databases that didn't have to be changed the first time, and a short-age of qualified personnel may make it difficult for the laboratory to use the powerful new system.

No matter how incredible the tools and capabilities of the LIS, an institution may not have time to set up files to test those capabilities and train employees on them. "People are often so excited because they've heard what the vendors say a system will do, and they think it will be beautiful," explained Braley. "Then when I take them on a site visit, they walk in and see the reality. They ask the user, 'Why aren't you using that quality control system?' And they say, 'We didn't have time to set it up and test it yet. We bought it a year and a half ago and spent $25,000 on it, but we're not using it, and the staffing situation is worse today, and we've got more complex things to learn, and we might not be able to use them either.'"

Another frequent problem with replacing an LIS is that people haven't identified what went wrong the first time. "They say, 'We'll do it the same way as last time, although we had trouble last time and we're not changing anything this time.' But it's not likely to work just because this is the second time," stated Braley.

Shifting terminology can present an additional pitfall. "When I see people writing down their requirements for a new system," he said, "they may make a whole list of things that seem to be English but [that are] just the language of the LIS vendor that they've learned over the last 10 years." Every vendor has its own terminology, and changing an LIS will mean changing to a new LIS language.

Conversely, most specifications are written as corrections to a current system, and the individuals who write them assume all other factors will remain the same. "That's probably the biggest mistake with trying to write specifications for a replacement system," Braley said. "People say, 'I want this and this fixed,' assuming everything they like about their current system will be in the new system. They do not take time to say what they want to keep. But if you like 90 percent of what you have and want to improve 10 percent, but you lose 20 percent of what you had, did you come out ahead?" he asked.

Replacement offers less opportunity for phasing, according to Braley. "In the good old days, you could say, if we can get chemistry up and running, we'll take the summer off and then we'll try for hematology, then something else. But if you're replacing a system today, you pretty much have to do it in one sweep. You don't have the luxury of doing a partial replacement now and finishing later."

His solution: "Make everybody aware at the outset that installing a new LIS is a bigger deal than we thought, and it's a bigger deal than the first time. Plan just as carefully as the first time and learn from your mistakes. Don't do the things you did wrong in the past, the things other people did wrong–and don't assume you're good because you did it once before."

One of the leading trends in computing is "bloatware" –the result of computer companies building into their systems whiz-bang capabilities that few people will use. "How many of you have used 10 percent of the features in the Excel spreadsheet program?" Braley asked." LIS vendors are doing the same thing. If you don't have enough resources to use the features, then you're buying essentially a bloatware package, and you will not get your value out of it. That's a real problem. If you don't use it in the current system, why get a better, bigger system with three times as many features?

"What I'm saying is to look for solutions, not features," Braley advised. "Don't buy a system because it has a lot of stuff in it. Buy one that solves your problem. Second, calculate the real cost of your capability. Look at human resources and look at the downside. Don't think everything you buy is a great new feature. Reject those things you can't afford because of the ongoing cost."

For example, a laboratory may buy a system that will allow it to write rules for how to run the laboratory. "And then you find out that somebody down the street bought this system and they wrote 6,000 rules, and you say wow, that's pretty powerful, and I'd like to write my own 6,000 rules. But how long did that take, and how many people were assigned to rule writing?" It's important, he stressed, to find out not just what features are available, but how much effort will be required to make those features work.

"One of the complaints I hear over and over from labs when their system has problems is, 'Well they told us it would do something, but we didn't get it in the contract.' But if you have a contract and it says what the product is going to do, and you put the system in and it doesn't do it, all you have to do is hold the contract up to the company and say, 'This is what you told us.' Most of the time they'll fix it," Braley said.

Nevertheless, probably the biggest mistake laboratories make is not writing a good contract. "You have to think about contracting, implementation, and operation from day one as parts of the same package," Braley emphasized. "You can't turn contracting over to lawyers because lawyers don't know anything about labs. And if you, as a selector, are not part of the contracting team, and you don't get contracting people in early to help avoid getting things wrong up front, then you're in trouble.

"You'd also better be able to pick up the contract and read, in your terms, the specs that say what you've bought," he added, "because that's what the company will wave in front of you later when it comes time to do the installation."

Braley advised using the selection process to gather information for contracting. "When you go on a site visit and somebody says, 'The vendor short-changed us on something,' that doesn't necessarily mean you eliminate that vendor. But if you like the product, make sure that something is taken care of in the contract."

"We all know that 'success' is the goal of any project. Unfortunately, it is not always clear what success means in an LIS selection," Braley pointed out. In 1991, during the U.S. bombing of Iraq, he recalled sitting in a coffee shop where people were discussing with an Air Force major how successful the raids were. Somebody eventually asked, " What's a successful bombing raid?" The answer was surprising: The pilot saw a target and dropped the bomb.

"It wasn't whether the bomb hit the target, destroyed the target, or whether it was the right target," Braley commented. "So I thought, wouldn't it be incredible in health care if we had a success description like that? One that said, We saw a patient and we treated somebody today. It might have been the wrong treatment, performed on the wrong patient, or somebody died. But we saw somebody and treated them."

Most people would say success in installing an LIS means buying the right, or best, computer, he continued. "But is a project successful if it's over budget, even though the computer does what it's supposed to do? You might think so, but the CFO and your board might not." Alternatively, "What if the physicians of a major medical group were threatening to pull all their patients out of the hospital unless they got the blinking interface between the LIS and the hospital information system working?" In one case, where such a threat was made, the CEO and CIO did not think the implementation was a success because of the angry letter they received from the medical staff.

"Would it have been a success for the fellow who had a heart attack in the middle of an installation because it was going so badly?" he asked. "I don't think he would call it a success. What about someone who quits? Someone who's fired? Some patients who don't get good treatment because of a mix-up in patient records during an installation? What about someone who ends up with a lawsuit because of some computer problem?"

To forestall outcomes like these, Braley recommended thinking about "ultimate" success. "My definition of success has two parts: One, buying the right product, and two, delivering it in a way that meets users' expectations. The first part is easy; the second we fail on miserably over and over again," he said.

Expectations of functionality may have been spelled out in great detail in the request for proposal, but users frequently say, "Yes, it does what you said. But it's incredibly hard to run; it's slow; and it takes lots of key strokes." In other instances, Braley said, he goes to a site that's just been installed, asks how the system works, and hears, "It's great, but . . ." Then he finds out about the nightmare that happened during the last six months: "'We had people on overtime, we had people who couldn't take vacations, people who quit'–all kinds of horrible things that happened because the effort to make the LIS work wasn't what they expected."

Laboratory professionals should not ask an outsider to conduct their needs analysis, he maintained. "Only you and your staff [know] what you need. People come to me all the time and say, 'You're in this business, tell us what the best company is. It will save us a lot of time.'" But Braley declines. "I'm not the one who sells the system; I'm not the one whose name is on the contract; I'm not the programmer who's developing the system," he stated. "You may not know how to translate needs into the terminology for an RFP or format necessary to communicate with a vendor, but your staff knows the needs."

Needs are not born of an epiphany, nor can a consultant define them for the laboratory, he emphasized, although a consultant might help organize and interpret information. Similarly, the only source of expert information about a vendor's product is that vendor. "Don't ask your neighboring hospital or clinic about what a system does. They're not selling it to you; they may be wrong; they may not understand; or they may have missed the class where they were supposed to learn what it did," Braley said. "They may have taken the class three years ago and forgotten what it does, and they're not going to have their name on the contract that promises it to you."

Laboratory professionals who are reluctant to trust salespeople must recognize that the vendor is the best place to get information about what the LIS offers. But if you want to find out how easy or difficult it is to use that functionality, talk to the users, Braley said. "Don't go to the computer company and write an RFP question that says, 'Is it easy to merge patient records?' What company's going to say it's really hard? They will never answer those questions with anything but a yes, because ease of use is relative."

The vendor can explain what the system does; users can explain how it works; and outside consultants can show you the most efficient way to conduct a thorough investigation and make a sound decision. Braley doesn't believe those roles can be switched.

Laboratories also need to resist pressure from vendors to adopt a single-vendor solution, Braley believes. Many hospitals are going to buy their laboratory and hospital information systems from different companies. Even though systems integration is a tough job, laboratories can't avoid it, Braley said. "We have to be willing to say to a vendor, 'We are going to put in different products and you're going to be part of a network, or you're not going to be here.'"

Braley recommended dealing with this issue up front. "The big mistake we make is looking at an LIS project as an isolated thing, or looking at the pharmacy as an isolated thing. Then we put all the systems in and we wonder why they don't work very well together.

"If we get vendors in here who don't want to be part of this kind of a system, then we have to throw them out," he asserted. "And most reputable vendors today understand this is the situation. They know that in these networks that are coming together, the issues are too complex to expect that they get the whole thing."

Laboratory professionals must not assume that computers will automatically take care of residual problems that were never fixed in a manual system, he warned. Regarding lost laboratory records, for example, "If there was never anybody in the manual system who was in charge of this mystical space between lab and nursing station, where everything went wrong and we patched it, then when we put in computers, we still have nobody in the organization who's responsible for that space," he explained.

Finally, laboratory professionals should remember that they are not just selecting a computer, Braley said. They're also learning how to be good users, and if they avoid the most common mistakes in selecting and installing an LIS, they can keep a good system operating for many years. Along the way, he added, ironically, they can achieve an ancillary goal: "If you're lucky, you won't have to buy lab computers often enough to get very good at it."

Anne Paxton is a freelance writer in Seattle.