The RFP Process for EHR Systems (Updated)Editor’s note: This update replaces the June 2007 practice brief “The RFP Process for EHR Systems.”
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:
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.
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:
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..
AHIMA e-HIM Work Group: Guidelines for EHR Documentation Practice. “Guidelines for EHR Documentation to Prevent Fraud.” Journal of AHIMA 78, no. 1 (Jan 2007): 65–68.
AHIMA. “ICD-10-CM/PCS.” Available online at www.ahima.org/icd10/default.aspx.
AHIMA. Meaningful Use White Paper Series. Available online at http://journal.ahima.org/category/arra/arra-white-papers/.
Amatayakul, Margret K. Electronic Health Records: A Practical Guide for Professionals and Organizations. 3rd ed. Chicago, IL: AHIMA, 2007.
Carpenter, Jennifer. “Practice Brief: Writing an Effective Request for Proposal (RFP).” July/August 1998. Available online in the AHIMA Body of Knowledge
Certification Commission for Health Information Technology. Available online at www.cchit.org.
Dougherty, Michelle. “Linking Anti-fraud and Legal EHR Functions.” Journal of AHIMA 78, no. 3 (Mar 2007): 60–61.
Hagland, Mark. “Leading from the Middle.” Journal of AHIMA 76, no. 5 (May 2005): 34–37.
McClendon, Kelly. “Purchasing Strategies for EHR Systems.” Journal of AHIMA 77, no. 5 (May 2006): 64A–D.
Mon, Donald T. “Model EHR: Status and Next Steps for an International Standard on EHR System Requirements.” Journal of AHIMA 81, no. 3 (Mar 2010): 34–37.
National Institute of Standards and Technology (NIST) Health IT Standards and Testing Meaningful Use Test Methods Overview. Available online at http://healthcare.nist.gov/use_testing/index.html.
Office of the National Coordinator for Health Information Technology. “Standards and Certification.” Available online at http://healthit.hhs.gov/portal/server.pt?open=512&objID=1153&parentname=CommunityPage&parentid=13&mode=2&in_hi_userid=10741&cached=true.
Quinsey, Carol Ann. “Foundational Concepts of the Legal EHR.” Journal of AHIMA 78, no. 1 (Jan 2007): 56–57.
Quinsey, Carol Ann. “Using HL7 Standards to Evaluate an EHR.” Journal of AHIMA 77, no. 4 (Apr 2006): 64A–C.
Swanfeldt, Melissa. “Is It Legal? 10 Questions about Legal Functionality to Include in Your RFP.” Journal of AHIMA 77, no. 5 (May 2006): 60.
June Bronnert, RHIA, CCS, CCS-P
AcknowledgmentsJill Clark, MBA, RHIA
Angela Dinh, MHA, RHIA, CHPS
Colleen Goethals, MS, RHIA, FAHIMA
Julie Hatch, RHIT, CCS
Joy Kuhl, MBA, CPF
Mary Stanfill, MBI, RHIA, CCS, CCS-P, FAHIMA
Allison Viola, MBA, RHIA
Diana Warner, MS, RHIA, CHPS
Lydia Washington, MS, RHIA, CPHIMS
Lou Ann Wiedemann, MS, RHIA, CPEHR
Prepared by (original)AHIMA e-HIM Work Group members:
Denise Dunyak, MS, RHIA
Karen Fabrizio, RHIA
Susan Fenton, PhD, RHIA
Bill French, MBA, RHIA, CPHQ, CPHIT
Crystal Kallem, RHIA, CPHQ
Jennifer Meinkoth, MBA, RHIA, CHP
Dawn Osborne, MHS, RHIA
Carolyn Valo, MS, RHIT, FAHIMA
Adriana Van der Graaf, MBA, RHIA, CHP, CCS
Yeva Zeltov, RHIA
Acknowledgments (original)Liz Allan, RHIA
Lisa Garven, RHIA, CPC
Teresa M. Hall, MHA, RHIT, CPC, CAC
Roger Hettinger, CPC, CMC, CCS-P
Lynn Kuehn, MS, RHIA, CCS-P, FAHIMA
Stephen R. Levinson, MD
Mary Ellen Mahoney, MS, RHIA
Donald T. Mon, PhD
Harry Rhodes, MBA, RHIA, CHPS
Michelle Wieczorek, RN, RHIT, CPHQ, CPUR
Margaret Williams, AM