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
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
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
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
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,