Landing a new LIS
| Landing a new LIS |
|
|
|
May 2007 Dennis Winsten At Lab InfoTech Summit 2007 in March, Dennis Winsten and Hal Weiner provided advice on how best to acquire a new lab information system. Winsten is the founder of Dennis Winsten & Associates, HealthCare System Consultants, Tucson, Ariz., and Weiner is president of Weiner Consulting Services, Florence, Ore. An abridged version of their remarks follows. We’re going to talk about considerations for evaluating and selecting a new laboratory information system. Do I really need a new system? How do I go about that process? Do I want to replace what I have? Is what I have good enough, so that all I need to do is surround it with additional capabilities? How do you go about finding out which candidates are the correct systems for you? Do you want to go best-of-breed, or do you want to have a single vendor? You need to get information about the systems. And this is a dynamic industry, as you well know. If you looked at a laboratory information system or company six months ago, you need to look at it again, because things change very rapidly. Get cost quotations for the system according to your requirements. Telephone reference checks are an economical way for you to talk to your peers about the system you’re considering. They will talk your ear off, I guarantee it. Especially if you call the users who aren’t on the list that was supplied to you by the vendor. Also, take a note from the rock opera “Tommy”: You need to see it and feel it and touch it, and this is where the on-site demonstrations come in. And it’s very helpful to go and visit a vendor’s headquarters. If they’re operating out of a tent, you might be a little bit concerned. Last but not least, make a decision. And try not to have it take four years. Also important is the synergy with the rest of the things in your institution. If there has been a corporate decision that thou shalt be a Microsoft shop, and you’re trying to buy a product that’s running on a Unix platform, you have a big problem. A lot of people say, “Oh, we don’t want to consider cost right now.” But cost always becomes an issue at some point. It’s interesting, in the many years that we’ve been doing this, the low-cost spread, to our knowledge, has never won. Sometimes the low-cost bidder gets immediately thrown out because it seems obvious that “these people don’t understand the problem.” Another thing is to look at value. What’s the return on investment? What is this system doing for you compared with the alternatives? You need to consider the support and maintenance costs. You’re entering a long-term relationship. Fifteen years ago, that meant five years. Today there are over 1,600 systems in large institutions that have been installed for over 10 years. The relationship you’re entering with that vendor is almost as important as the product. What’s its reputation for keeping its clients happy? What am I going to get over the next 10 years? Understand your vendor’s business strategy. Where are they going? What market are they after? If you are a mid-size reference laboratory, for example, and the vendor’s primary target market is large academic teaching hospitals, you are going to be a voice in the wilderness. Also, what do you need to do to install and keep the system running? If you can’t have a medical technologist who is fairly up on information technology components write the expert rules, and you have to hire three programmers to do that, that’s something you have to understand. Though vendors have different strengths and weaknesses, the aggregate—the area under the end of the curve in integral calculus—for most of the leading vendors is about the same. What’s different is how well they do certain things. Vendors like to think they’re really special, they’re really different. And that’s not true in aggregate, at least in our judgment. An RFI, or request for information, is a way to understand, “Does the vendor have the basic capabilities you need to meet your key business objectives?” Then there’s an RFQ, or sometimes it’s called an RPQ. That is a request for price quotation. Based on your requirements—the number of workstations you have, the number of interfaces you have, the workload volumes—what is it going to cost to license, install, and maintain the information system? And finally, an RFP, or request for proposal. It needs to ask differentiating questions. If you ask, “Do you accept patient demographic information?” what do you think the answer’s going to be? “Yes!” What have you learned? Nothing. Better to ask: “Does your system provide multianalyte graphical reports/displays on a true proportional time scale axis?” One thing often neglected in the request for proposal and very important is to consider, in advance, how you’re going to evaluate the responses received. There’s a rule of thumb that if you send out two inches of documents, you’ll get 20 inches of information back. If you send out a large RFP to 10 vendors and get back a multiple of that for each member of your evaluation team, people will have a really hard time getting through it all. Vendors have become very good at finding out a way to answer “yes” to everything. So it’s important to ensure that the questions you’re asking require them to provide examples. The vendors will answer, I believe, honestly, but they will try to answer the questions in the best light for what their system can do, and the answers and the questions can both be ambiguous. There have been many different approaches to acquiring. The traditional approach was: You send off an RFI, find out about the vendors you want to send to, then write this detailed RFP, send it off, get the questionnaire back, have on-site demonstrations, go out on site visits, and then select a vendor and go into contract negotiations. There are better ways to do this. In a semitraditional approach, you look at vendor Web sites, and you can use CAP TODAY’s surveys and other information without going into the expense of the detailed request for proposal. On that basis, you can do telephone reference checking. It’s a good idea to ask for the complete users list from your vendor. Vendors say, “We have 250 users.” You say, “Would you send us your complete users list?” and you get 20. And you say, “What happened to the other 230 users? Why aren’t they on the list?” Don’t accept the statement, “We have all these confidentiality agreements.” Demonstrations are extremely important. If you’re going to have two or three vendors come in, have them come in at the same time. I’ve had clients say, “Are you kidding? How am I going to manage that?” But after they’ve done it, kicking and screaming, they’re absolutely thrilled about the information they were able to obtain. They have an opportunity to go from one vendor to the other, see something at the first vendor, go to the second vendor and see if they have that as well. Also, if you spread it out over time, I guarantee people are going to forget what they saw. Site visits are useful as a validation tool if there’s a local site that might be worth visiting. It’s difficult to find a site that is similar to the way you operate your laboratory. As you know, laboratories are all the same…except for the differences. If you can find a site that’s very close to yours that’s using the same hardware and the same software, that’s useful. But it’s difficult to find a good match. After you go through this process, go to that vendor’s house and learn its corporate culture. Meet the people who are going to be installing and supporting your system. You’re getting married to this person for the next 10 years. A nontraditional approach is to ignore that thing about “Who am I going to send an RFI to?” If you’re in a particular segment of the market, there’s only going to be a small number of vendors who are really going to meet your needs. So if you prepare your requirements document that summarizes your needs and send that to a handful of pre-selected vendors, and then go through corporate visits and discussions of your requirements along with demonstrations and pricing processes—that could substantially improve the whole time frame. This process is a lot less costly for the vendor and for you. So there are a number of ways to do this. If you look at the outcomes of any of these alternatives, they’re statistically all about the same. In summary, you need to get current valid data and be able to compare those data among the vendors you’re looking at. Focus only on those key issues. Don’t allow yourself to be stuck on, “I really like the fact that this field is on the screen in this corner from this vendor.” That’s the way you lose control of the whole process. Getting the most from LIS demonstrations: First, look at your priorities and rank them in terms of functionality. You don’t want to give equal priority to “It’s a pretty-looking screen” and “I can get a bill out twice as fast as I can today.” You want to be sure that when you get a new system, the things that were good in your old one are not lost. Don’t let the vendor—sorry, vendors—just come in and do their whiz-bang demo. There are some people who can make you believe that the system can walk and talk and do everything for everybody, anytime. One of the ways to ensure you’ve got the vendors on an even playing field is to give them play scripts that represent the way you want the system to work in your environment. The vendors will say, “I can’t do it. I don’t have time.” Don’t believe it. They can do it. You don’t have to do a play script for everything. It would take forever. Pick out some transactional sequences that are particularly important in your operation. But also make time for the vendors to show their whiz-bang things. When you do a demo, see everything from beginning to end. We’ve been in situations where you ask a question and the vendor begins talking about how wonderful it is rather than showing it to you. You’ve got to see it. Is there a client who’s actually using what they’re showing you, or is it some demo they mocked up in the back room? And if you can, do some hands-on. When multiple vendors are on site at the same time, you have a chance to revisit these vendors, confirm things, and fill in the gaps. If you see a demonstration of one component from one vendor, and two hours later see the same demonstration from another vendor and see something they’re doing that’s totally different, go back and ask that first vendor, “Show me how you could do that same function.” You need to have someone record things. What did I like? What was strong? What was weak? Let’s talk about specifying and negotiating a win-win LIS contract. There are four key premises. One, the worst time to negotiate a contract is during contract negotiations. Your leverage is not that great if you’ve already said, “We want you.” Second premise: There are vendor standard contracts. Some people want to throw those away. You shouldn’t do that. They have value. They’re very often a good baseline to start with. Three, the contract has to cover the entire system. If you’re going to be buying hardware, software, implementation services, support, and database and database training, the contract should cover it all, not just a piece of software. And four, the contract has to be fair and protect the interests of both parties. There are three generic types of contracts. First, there’s the hardnosed contract. This is rigid and inflexible. It has mostly negative and punitive conditions. Then there’s another type: loosey-goosey. It’s “I’m kind of delivering something, and I’m not too sure what it is, and if it gets there, it may or may not work, but you’re still going to pay me anyway.” And it may be missing important elements. We always get a big kick out of the thing that says “We make no warranty, express or implied, for merchantability or fitness of purpose.” What are we buying here? There’s also the right-on contract. The right-on contract is not necessarily everything you want, but it includes the important provisions. It includes acceptance criteria. You may not agree with the criteria, but at least the contract has a section in there that covers acceptance. Rather than wait until the end of the process to start negotiating your contract, put all the things that you feel are important up front in the whole process. Put it in your request for quotation. Put it in your request for information. Because some of the things you want to see in the contract may be things that cost money. If, for instance, you say in a contract, “I don’t want the support dollars to start until 150 days after I go live,” that’s going to cost a vendor some money. They may agree to it, but it may have an impact on what the price would be. Whatever is in writing from that vendor saying how great the system is should be part of the contract. If they’re not willing to make that part of the contract, you’ve got a big red flag. And get a sample contract during the selection process. You may look at it and say, “What is this crap? I don’t want to go any further.” Have a negotiating team. Remember, the goal here is to sign the contract. You need to be flexible. They need to be flexible. Don’t be adversarial. You’re going to be married to these people for a long time. You learn a couple things during the negotiation process, too. If they treat you badly before you’re a client, what are they going to treat you like when you become one of their clients? One of the things vendors like to do is find some insider who’s got all the scoop. Tell all of the people in your organization: “Loose lips cost money.” We’re going to run through a contract checklist:
We think it’s a good idea, before you get your attorneys and their related costs involved, to go through the issues that are important from operational, functional, and performance standpoints. Because they’re probably not qualified to address those issues. Bring them in after you’ve resolved all those other things; then get the i’s dotted and the t’s crossed. Hopefully, when you’re all done, the contract can get locked in a drawer and never be looked at again.
|
