The RFP Process for EHR
Systems (Updated)

Implementing an electronic
health record (EHR) requires substantial time and money for healthcare
providers of all sizes and types. Product selection is a time-intensive
step that requires appropriate attention. Organizations must dedicate
sufficient time and resources to evaluate their goals, information needs,
functional requirements, and pending regulatory requirements in advance
of reviewing available EHR products and services. This advanced planning
will start the organization down the road to a successful vendor selection
process.

This practice brief guides
organizations through the selection process, assisting providers as
they issue requests for information or requests for proposal for EHRs
or component systems. It is to be used in conjunction with the accompanying
RFI/RFP Template.

RFI versus RFP: What’s
the Difference?

A request for information (RFI)
is often used to solicit information from vendors about their products
and services. It is a fact-finding process, often used as the first
step in narrowing down the field of vendors when considering future
purchases.1

Most vendors have marketing
materials that can provide in-depth information regarding their products.
For some organizations, this packet of materials, along with a profile
of the company, its history and services, standard agreements, and a
cover letter, may be a sufficient response to an RFI. In other instances,
an RFI may include more information focused on the specific areas of
organizational need as it relates to product functionality.

The RFI is a valuable tool
in assessing how existing products and services within an organization
measure up to current vendor product offerings. Technology changes rapidly,
and managers need to know if there are more efficient and cost-effective
solutions that meet their organizations’ needs. Sending an RFI
to vendors is an effective way to stay current and an excellent starting
point for the more formal selection process.

Unlike an RFI, a request for
proposal (RFP) is a formal request sent to a vendor or group of vendors
for specific responses as to how their company, products, and
services can meet the organization’s unique requirements. It generally
includes a complete summary of related costs (hardware, software) and
services (support, training, implementation, and consulting).

An RFP can become the basis
for a contract, which forms a legal obligation between two parties.
In this case, the two parties are the vendor and the solicitor.2 For this reason, both the vendor and
the solicitor should carefully consider the phrasing of the questions
and corresponding responses. For instance, in seeking an EHR, the solicitor
should request specific information about how the product will support
the functionality needed by the healthcare organization.

This additional attention to
detail usually necessitates a significant resource and time commitment
and frequently involves legal counsel. Organizations should consider
forming a selection committee consisting of key stakeholders and end
users as a first step in preparing the RFP.

Identifying Prospective
Vendors

An important initial step in
the selection process is identifying and including all appropriate vendors.
It can be costly to learn later that one or more key vendors were missed.
To prevent this situation, there are a variety of resources to help
identify the vendors that should be included in the initial list for
the RFI or RFP process, including:

Lists of certified
EHR products

Published EHR software
vendor guides

Peer-to-peer reviews
or suggestions

Internet searches,
including vendor Web sites

Professional organizations
and user groups

Likewise, it does not make
sense to invest time and resources in preparing an RFP for vendors that
do not identify themselves as having the needed products and services.
If an organization clearly states its objectives in the RFI, it should
be clear which vendors are appropriate for an RFP.

Not all vendors will be interested
in submitting a response to an RFI or RFP because of costs or suitability.
As a first step, organizations can ask prospective vendors to indicate
their intent to participate in the response process. Typically, this
can be done quickly through an e-mail or letter of intent to bid. In
this step, the organization may also include its requirements for completion
and delivery of the proposal, including format requirements and the
contact within the soliciting organization for clarification regarding
the submitted documents.

Developing and Disseminating
an RFP

One of the very first steps
in preparing an RFP is identifying and selecting a proposal committee
composed of key stakeholders. This committee should be as inclusive
as possible and include, at a minimum, a physician champion and representatives
from the departments that will be using or be affected by the EHR system—for
example, health information management (HIM), information technology
(IT), clinical staff (e.g., nursing, radiology, etc.), medical staff,
compliance, privacy and security officer, legal counsel, accounting,
and purchasing.

The next step, once the team
is assembled, is preparing a description of the organization’s priorities
and functional and technical requirements. These will be identified
from a current and future state workflow analysis that should have been
performed before RFP development. Consideration should be given to the
scope of the project by identifying any specific needs such as possible
master patient index cleanup, data conversions from existing systems,
modifications to current hardware and software and interfaces, regulatory
requirements affecting system changes (e.g., ICD-10-CM/PCS, meaningful
use incentive requirements, MDS 3.0, RUGs IV), customizations done in-house,
and any expected nonstandard use of the system. The identified priorities
and functional requirements will become the line items to be included
in the RFP.

The scope document can also
be used as a sign-off document for the involved departments to ensure
that demonstrated products are evaluated based on the functionality
requested in the RFP, not the additional features or add-on modules
that may be presented at the time of demonstration. In addition, the
team should gather basic data about the organization that the vendor
will need, such as facility size, current infrastructure and technology,
estimated budget, timelines, strategic goals, contact information, and
other pertinent data.

The Value of
HIM Involvement in the RFP Process

An EHR project is often initiated
and managed as an IT project. Although technology is an important component,
it frequently represents the least challenging element of the implementation.
Ensuring HIM workflow and external regulatory and compliance requirements
are adequately addressed in the EHR cannot be completed without strong
HIM leadership. The AHIMA
Body of Knowledge
contains a wealth of resources aimed at guiding professionals and organizations
through the EHR selection and implementation process.

Because of their knowledge
of accreditation and regulatory content requirements, privacy and security
functionality, and principles for a legal record, HIM professionals’
involvement in the RFP development process and the evaluation of vendor
responses is invaluable. Any clinical application that will be part
of the organization’s official health record must include HIM in the
assessment to evaluate records management and evidentiary support functionality
and ensure the application meets the business and legal needs of the
organization.

RFP Proposal Formats

A simple letter of inquiry
is not a sufficient or practical method for requesting a proposal. Typically,
an RFP is prepared in one of two formats or a combination: a checklist
or a short answer response format.

In the checklist response format,
a table is usually provided with a column designated for the question
or requested feature. Adjoining columns may have titles such as Yes/No,
Available/Not Available, Included/Add-on, and Future Feature/Not a Future
Feature. Responses may have a numerical value associated with them (for
example, a yes response may rank higher than a no response). The vendor
responds to the question or feature by indicating whether the feature
or service is available and if it is included in the price of the bid.

The checklist response format
provides a way for the vendor to quickly respond and for the solicitor
to quickly determine whether or not the requested features are available
in the bid. A limitation of this format is that it might not provide
enough space for vendor clarification of the selected option associated
with the functional requirement. This limitation can be overcome through
the use of the narrative, short answer format.

The narrative response format
is written in paragraphs, providing vendors with greater opportunity
to explain in detail the products and services offered and how those
products and services will best meet the needs of the organization.
One inherent problem with this format is that it limits the reviewer’s
ability to conduct a side-by-side comparison of multiple vendor responses.
In addition, narrative responses may result in vague or cryptic responses,
potentially hindering the solicitor’s abilities to draw conclusions
from the functional system requirements.

To help ensure the optimal
amount of important information is gathered while minimizing the amount
of reading and reviewing, organizations often develop an RFI in a checklist
response format to screen for critical functionality. Based on the RFI
results, a list of prospective vendors can generally be narrowed to
a select few. After this step, organizations send RFPs to a smaller
list of vendors and use the short answer response format, incorporating
and expanding knowledge gained through the RFI process.

Another option is to combine
both the checklist and narrative formats into a single RFP. A checklist
section accommodates questions that can be answered easily with a yes/no
response, leaving more detailed responses for the narrative section.

Regardless of the format used,
responses to the RFI or RFP often include a cover letter, an executive
summary, marketing collateral, and other supporting documentation that
may be helpful during the decision-making process. Organizations can
also request that the proposal include these items along with the responses
to the proposal format.

EHR Functional Requirement
Specifications

Compiling a complete list of
EHR functional requirements can be challenging. In addition to conducting
a complete workflow analysis that identifies requirements specific to
the organization, the proposal committee should leverage the Health Level Seven
(HL7) EHR System Functional Model (EHR-S FM)
and Records Management and Evidentiary Support Functional Profile to
identify industry-recognized EHR requirements. The functional model
is based on two axes: functions and care settings. The functional axis
is a hierarchy of the essential, desirable, and optional EHR functions
across all care settings, with functions organized into care setting
and infrastructure categories.

Several care domains have developed
accompanying profiles that define how to use each function and identify
the functions specific to that domain, such as Child Health, Behavioral
Health, and Long-Term Care profiles. A comprehensive list of functional
profiles is available in the HL7
Functional Profile Registry,
sponsored by the National Institute of Standards and Technology.

Health IT Certification

The Health Information Technology
for Economic and Clinical Health (HITECH) Act, enacted on February 17,
2009, amended the Public Health Service Act (PHSA), providing the Office
of the National Coordinator for Health Information Technology (ONC)
with the authority to establish a certification program for the voluntary
certification of health IT. The act specifies that the ‘‘National
Coordinator, in consultation with the Director of the National Institute
of Standards and Technology, shall keep or recognize a program or programs
for the voluntary certification of health information technology as
being in compliance with applicable certification criteria adopted under
this subtitle’’ (i.e., certification criteria adopted by the HHS
secretary under section 3004 of the PHSA). The certification program(s)
must also ‘‘include, as appropriate, testing of the technology in
accordance with section 13201(b) of the [HITECH] Act.’’3

With the multitude of vendors
to consider, a good way to limit your list is to narrow your pool of
vendors to those whose EHRs have been certified by an authorized certification
body. Monitor ONC’s Standards
and Certification Web site
for additional information on the new health IT certification program,
certification criteria, and recognized certification authorities.

Certification status provides
purchasers with an assurance that the product is able to address critical
components of meaningful use. However, certification criteria should
be assessed in combination with key functional requirements to ensure
your organization’s critical goals and objectives are addressed.

Importance of the RFP Process

Carefully preparing an RFP
by clearly articulating the organization’s needs and evaluating vendor
responses can eliminate significant cost and risk to the organization.
Organizations following the proper steps during the proposal process
may reap the following benefits:

Conserve time and
resources by avoiding poorly phrased questions that result in unclear
or vague responses

Serve as an objective
source for documentation supporting the inclusion or exclusion of vendors,
if necessary

Vendor Selection

After a workable listing of
facility background data and vendor requirements is completed, the next
step is narrowing the vendor pool. Some healthcare consortia offer purchasing
agreements or have vendors they prefer based on performance. A search
of professional journals and organizations can provide additional information.
In researching vendors, factors other than software functionality must
be considered. Key considerations include:

Financial stability,
reputation, and history (e.g., longevity)

Ability to provide
a list of current customers and references

Percentage of research
and development reinvested into the company

Life cycle state
or maturity of EHR system products (i.e., the occurrence of software
obsolescence)

Frequency of software
product updates

Customer support
availability

Certification status

All of these factors can aid
in selecting vendors with staying power. The proposal committee may
identify additional factors as well.

Once a set of vendors is identified,
the RFI/RFP template can be used as a starting point for developing a customized proposal
request. A finalized RFP can be assembled by taking the basic sections
outlined in the RFP template and incorporating the facility data and
requirements previously gathered. After the team has signed off on the
final draft, the RFP is ready for submission to the vendors identified.

Before submitting the RFP,
determine the name and contact information of the person within the
company to whom the RFP should be sent. A cover letter should establish
expectations such as a response deadline, response format, the name
and contact information of one person to whom all questions concerning
the RFP should be directed and to whom the RFP should be returned, and
any other specifics that require emphasis. Any questions and responses
should be shared with all prospective vendors in accordance to the established
RFP timeline. If the deadline is extended for one vendor, the organization
should consider granting the same extension to all vendors. Granting
deadline extensions can be problematic, so the proposal committee should
establish a policy for extensions before disseminating the RFPs. If
a vendor fails to respond to the RFP, that vendor should no longer be
considered.

One person on the selection
team should be assigned to lead the compilation of vendor responses
so they can be reviewed and compared side by side. The lead may compile
the vendor responses on his or her own or divide the work among several
team members by using a standard evaluation tool. The evaluation tool
should include a column for comments to document positive or negative
notes related to each line item. Any functional requirements not met
should be highlighted so they are obvious at review. The team may also
consider incorporating weighted scoring of requirements that are critical
to the organization’s goals and priorities.

Organizations should contact
references provided by the vendor in the RFP response and make notes
in the comments column. When all data are collected, the selection committee
should meet to review the entire report and document all responses.
Important high-level concepts to be considered include use of technical
standards that support interoperability, ICD-10-CM/PCS and Version 5010
readiness, vendor stability, certification status, and how well the
RFP requirements are addressed. Look at overall cost as well, including
hidden support fees, implementation fees, and any costs associated with
data conversion.

The RFP is a tool to rank and
evaluate vendors, but it may not be adequate for final vendor selection.
The committee should evaluate the proposals to narrow the list of vendors.
The selected group of vendors should then be invited for presentations
and demonstrations to provide additional learning and evaluation opportunities
about their products. Before final vendor selection, their installed
sites should be visited to view the product in use and assess overall
user satisfaction..