Time to shelve your RFP for an RFI—here's why

November 2007
Feature Story

Raymond D. Aller, MD
Hal Weiner
Dennis Winsten

A salesperson for a small vendor recently confided that when he used to complete requests for proposal on his own, he would interpret each question, then honestly assess whether his current software met that specification. In recent joint bids with some larger vendors, he was mortified to see their staffs twist each question to try to find a possible interpretation for which they could say yes.

That's one of a number of problems with RFPs—there's no objective measure by which most questions can be unequivocally answered yes or no.

At the root of the problem is that most RFPs are used to select a system, not a long-term business partner. It is much more important that the vendor you choose be responsive to your future business needs—which you cannot predict today—than that the company's product have every widget you listed in an RFP.

Further, RFP responses from vendors typically indicate, sometimes misleadingly, what the system can or will do instead of how it will do it. In reality, all major systems today have similar functionality. A traditional RFP will most likely not shed light on the differences between systems and will waste an enormous amount of time, effort, and expense on the part of the laboratory and the vendor.

And about those yes or no questions—the RFP shouldn't ask them. Rather, couch questions such that the responses can be answered as: 1) operational (If so, where?), 2) in beta test (If so, where?),3) under development (If so, available when? And will the date be guaranteed in the contract?), 4) custom development (If so, how much and when available per contract guarantee?), and 5) not available.

Recognizing the drawbacks of an RFP, we recommend a different approach to laboratory information systems selection. But before we do, let's be clear that the RFP process is not without merit. It can: XX involve large numbers of staff in a thought process about the future of their laboratory and what capabilities they'd like a lab system to provide. XX standardize the assessment, comparison, and summarization of system features across vendors. XX satisfy governmental, legal, and organizational requirements for use of a formal, auditable process.

Know what you need

A crucial step in system selection obviously is to define your requirements. Start by developing a "master requirements" document. This will prompt staff to discuss the desired future state of the laboratory. Bringing together many divergent points of view is particularly important when the organization has decided to consolidate multiple disparate laboratories or hospitals into one database. Focus on how a new system will help the laboratory run more efficiently and effectively. Be sure to include recent hires in this process as they may bring a fresh perspective.

Management and staff must be willing to commit a substantial amount of time and effort to creating this master list of functionality. But set a reasonable timetable for developing such a document and stick to it so you don't spend a year on this one step. Focus at least as much on process and cost improvement as on features.

Keep in mind that your present way of operating has been constrained by the capabilities of systems and people you have worked with in the past. You probably have approached tasks in the same manner for years—and this approach may have been designed to emulate even earlier approaches. As Mike McNeely, MD, president-elect of the Association for Pathology Informatics, comments, we run the risk of marching backward in time and only introducing innovation when we want to emulate features found in non-medical systems, such as e-mail, word processors, and Web sites.

It's critical to get end-users, not just the top brass, involved in decisionmaking from the beginning. If you don't involve them, you are inviting failure. Front-line users know better than does anyone else what they need. However, it's important that all decisionmakers recognize that some "wish-list" capabilities may not be present in any new system as initially implemented. Furthermore, staff must understand that the new system may lack features provided by the current system simply because the laboratory has spent numerous years molding its LIS to better fit its needs. But if ongoing attention is devoted after go-live, many of these previous and desired features can, over time, be embedded in the system through automated rules, special dictionary/table settings, and by working with the national users group to formulate and guide the vendor's future software releases.

On the other hand, it's vital to brainstorm ways that a new system should be dramatically better than your current system. Don't lower your expectations and accept cumbersome workarounds and inefficient interactions.

Be aware that it is more important to be able to communicate between systems than it is to choose pure, traditional, or fashionable hardware, operating systems, databases, or programming languages. This precedence of communication over internal architecture has been reinforced by the evolution of such national standards as the CDC's Public Health Information Network. Early versions of the PHIN standards expressed a preference for certain database types, functionality, strategies, and features. The most recently published version of the standards (version 2.0) abolishes the earlier strictures and focuses almost exclusively on the requirements of connectivity.

In some cases, decisionmakers external to the lab may dictate what new system you will get. If you don't find the proposed system to be suitable, use the functional specifications to document how the lab's needs will not be met using such a system. But avoid a pie-in-the-sky mentality. In the end, regardless of what you ask for, you can only buy what vendors are selling, or what you believe they will have in the future. Some organizations have spent over $100,000 to develop a list of features that no vendor can provide.

Divide and conquer

After you have defined your requirements for a new system, divide them into a three-part list. Give vendors only the first part. Use the second part as an evaluation checklist. Hold the third part in abeyance until contract negotiation, implementation, or post-go-live.

Part one: legal, organizational, and operational must-haves. You should be able to describe these in 10 or fewer pages. This is the portion that will be sent to prospective vendors as an RFQ (request for [price] quotation) or RFI (request for information).

The most important item in this list is the requirement that the vendor supply a complete list of sites and contact people at those sites—anything short of a complete list should disqualify the vendor. Don't let the vendor dictate whom you're going to talk to—that must be your choice. Keep in mind that vendors who offer a select list of references may have something to hide.

Devote a few pages to questions that will show the fundamental characteristics and broad capabilities of the vendor and software. For example, compliance with industry communication standards, such as HL7, LOINC, ELINCS, ONCHIT/AHIC, and PHIN, is a must, so ask such questions as, "Can your system transmit all results in HL7 version 2.5.1 fielded format?" Your umbrella organization may insist on certain characteristics—for instance, all servers must be painted red. In such a case, you may want to ask the appropriate decisionmakers to provide the exact wording for conveying this requirement. This could be, "All servers must have red cabinets. Pink, orange, and other shades are not acceptable."

You will never be able to ask about all details of functionality—a much better measure is to see a demonstration of the system performing your required work processes as defined in a scripted demo—so don't start down the path of enumerating every feature you desire. If you've exceeded 10 pages (unless it's mostly governmental boilerplate), you've written too much. Not only is an overly voluminous RFI or RFQ costly for the laboratory, it is enormously expensive for the vendor as well. Asking the vendor to devote an inordinate amount of time to a proposal may well discourage the vendor that would have been your best business partner (box, at right). One vendor recently told us that a particularly egregious RFP cost the company $250,000 to respond to—and a smaller one "just" $50,000. This money would have been much better spent enhancing the system or hiring additional support staff.

Part two: a checklist of the key elements of functionality you are seeking. List only that functionality that can be shown in a demonstration and verified through a corporate site visit. During both events, ask for a demonstration of the features on the list that are most important to you. But be conservative when requesting to see features in operation. System capabilities such as collecting basic demographic information and simple result inquiries are standard in all LISs, so you don't need to spend a great deal of time analyzing them. Again, include only what's most important to your lab and place the other items in the third part of the list. Brevity is paramount to this section—keep it focused.

Part three: functionality that may be useful but won't dictate which vendor you select. This includes highly specialized or unique features, such as having a particular standard report format or a demographic data element with a specific name. Laboratories that require a vendor to program and implement numerous features unique to the laboratory often end up using few, or none, of the specially crafted capabilities. Therefore, it's best to assess the "vanilla" version of a system. Once you've narrowed your selection, you can determine if the table/dictionary settings in the standard software can provide the bonus functionality and, if so, pursue that functionality during contract negotiation or implementation, or even after go-live.

Develop a dialog

After you receive a vendor's response to your list, call most or all of the vendor's installed sites. Ask: How does the vendor do in supporting your organization's business objectives? Is the company responsive when the software needs to be repaired? If starting from scratch, would your organization choose this vendor or system again?

If possible, talk to someone you know at the client site—he or she may be more willing to openly discuss vendor issues with you.

It is just as important to speak with colleagues at sites that installed the vendor's product during the past several months as it is to speak with employees at sites that have been using the product for a number of years. The recent installs will tell you how the vendor's method of installation and training is working now—and the older sites will shed light on whether the vendor is a reliable long-term business partner. Sure, the product worked fine when it was installed years ago—but did the vendor continue to work with the client to make sure the product evolved to meet the client's changing needs through the years? And was the client trained and coached as needed to take advantage of the new capabilities of the software as it evolved?

At the same time, go through the "seven Fs" with each potential vendor's responses to your request for information. These serve as a framework for considering which vendors will be viable candidates. The seven Fs are: 1) function (top level applications), 2) features (details of applications), 3) fit (compatibility with existing systems), 4) feel (ease of use), 5) followup (service and support reputation), 6) financials (budget constraints), and 7) future (vendor financial/management stability and market focus).

Even if you are considering purchasing a system from the same vendor you've had a satisfactory relationship with for years, follow the aforementioned steps. Never assume you know what you're getting just because, until now, you've had a satisfactory business relationship with your existing vendor. It may cost as much, or more, to implement your current vendor's new system as it would to implement one from another company. And your current vendor may no longer be offering the same package of features or functionality or the same level of customer support as in the past.

Only after you have narrowed down the field of vendors to a select few through an RFI or RFQ and through telephone reference checks should you begin requesting scripted demonstrations, scheduling a corporate visit (and perhaps on-site visits), and negotiating a contract.

For more information about how to manage LIS product demonstrations, on-site visits, and contract negotiations, see the CAP TODAY article, “Landing a New LIS,” May 2007.

Dr. Aller is director of automated disease surveillance and team lead for disaster preparedness Focus B, Los Angeles County Department of Public Health; Weiner is president, Weiner Consulting Services, LLC, Healthcare Information Systems Consulting, Florence, Ore.; and Winsten is president, Dennis Winsten & Associates, Health Systems Consultants, Tucson, Ariz.