A complete EHR RFP guide and template
A successful EHR selection process depends on obtaining a quality pool of vendor applicants from which to select.
A bad pool of vendor applicants to select from will lead to a poor EHR experience. The selection process has traditionally been driven by a process which involves publishing an EHR RFP inviting vendors to compete for an EHR contract.
The process of putting out an effective RFP for EHR serves as the foundation for the selection process. Therefore, how practices use the RFP process, for selecting EHR factor greatly in obtaining quality candidates. In the long-term this can improve the chances of selecting an EHR that will create value for a practice.
A practice should aim for a focused RFP process for EHR systems that seeks to contact a limited pool of strongest candidates. In this article, a practice will learn how to conduct an effective RFP process by covering the following topics:
- Understanding key acronyms: RFIs vs RFPs vs RFQs
- Gathering your requirements for new EHR software
- How to prepare an effective RFP for EHR software (including customizable template)
- Evaluating RFP responses
- Next steps: respondinng to RFPs and the demo phase
After you assess and identify your practice’s EHR requirements during the requirements gathering process the next step involves beginning the selection process relying on the following three information gathering tools:
Request for Information (RFI)
The RFI will often be sent to several vendors while the RFP is distributed after the field of vendors has been preliminarily researched and narrowed down.
The RFI can help a potential client overcome a significant hurdle in any software selection process - getting vendors to answer your initial questions about their applications, services, and support. An RFI ‘breaks the ice’ with potential vendors by presenting your EHR requirements and signaling to them you are seriously engaged in the process of investing in new or replacement EHR technology.
"The RFI can help a potential client overcome a significant hurdle in any software selection process"
An RFI’s purpose rests in narrowing the field of potential vendors by presenting broad questions that capture broad information about vendors and thus weed out obvious non-contenders. It is important to understand that an RFI may contain specific questions about a software solution, however, more specific questions should reserved for the RFP phase. By simplifying your RFI document to capture information from vendors on company values, high-level application capabilities, and fit, not only will more responses come back, but you’ll also be able to save time in the process. should not contain an
Request for Proposals (RFP)
Using the information collected from the RFIs the preliminary research should be conducted on the vendors who responded to the RFI with the purpose of further reducing the list of potential candidates and beginning the process of sending out RFPs to potential vendors who made the cut.
One of the most effective ways to reduce the risk of error and make the process proceed smoothly is to create sample RFP templates that can be used by the selection committee. An RFP for healthcare information systems offers a standard framework that your practice can use to provide uniform and comprehensive RFPs to potential vendors. Although each RFP should be customized to fit a practice’s individual needs, it is important to make sure an RFP contains at a minimum the information provided on sample RFP template.
Further, an RFP for healthcare information system could be modified for use as an RFP healthcare consultant or other IT contractors who would be involved in the implementation process. In sum, a sample EHR proposal should be kept on file so that anyone procuring EHR-related services at your practice can use this material if the need arises.
Request for Quotes (RFQ)
Upon receiving the responses to the RFI and RFP, the vendor’s responses should be scored again with these updated responses to determine which product best aligns with your practice’s requirements. The scoring process should result in a shortlist of vendors which you are willing to engage with an RFQ, which would formally address questions of costs, terms, maintenance, and support.
"The scoring process should result in a shortlist of vendors which you are willing to engage with an RFQ"
Once responses to the RFQ have been received a practice should be ready to complete the final stages of the selection process by scheduling vendor demonstrations.
A quality RFP process cannot begin to be planned without first understanding the process of requirements gathering. EHR requirements gathering refers to the process of collecting the requirements an EHR must meet to meet a practice’s strategic goals.
The purpose of the requirements gathering process rests in providing a well-defined list of EHR features that best compliment a practice’s strategic goals. For example, a practice whose strategic goal is to reduce wait times would tailor their requirements gathering process to finding EHR products whose features could help reduce wait times, such as a practice management system. Without a well-executed requirements gathering process, the RFP process and by association the selection process will suffer and can result in a practice selecting an EHR that is not a good fit.
The value in an EHR RFP is found when you go into detail about your requirements, and in doing so, create differentials between your vendors of choice. As the RFP process is being conducted it is important to include the following information at a minimum:
- Project overview and timeline
- Other vendor qualifications
- Proposal evaluation criteria
Here’s a more detailed RFP template that you can customize to your own practice’s needs:
|Section||What to include|
|Project purpose||Tell the vendor why you want a new EHR and tie it to fundamental needs of your practice Include your practice’s background and specialty, your current EHR system and why it's no longer fit for purpose, and an executive summary of what you're looking to change|
|Baseline project limitations||Lay down timing and budgetary constraints which you cannot go beyond to help the vendor get a sense of the scale of your project and practice|
|Project timeline||create a list of selection steps for a new EHR and provide a timeframe for each step. This should be a comprehensive overview - start with the selection process and detail timeframe for steps up to go-live|
|Requirements||Essentially the specific products and services the vendor should deliver. Give each requirement a separate section in your RFP and detail its priority. You can also specify whether you need this out of the box, or through customization/integration.|
|(Suggested sections for requirements)||
Here are some examples of feature requirement sections to include in your RFP - customize this section to your own requirements
|System requirements||E.g deployment method, customization and integration needs, hardware requirements, compatible operating systems|
|Other vendor qualifications||Look outside the EHR and ask about what you want in a partner. This can include what their support looks like, the uptime of their cloud services, or company culture requirements|
|Proposal evaluation criteria||Provide the vendor with a deadline for responses and guidance as to how to respond to the RFP by providing guidelines or a template. Detail how you'll be evaluating responses.|
Once vendors have responded to your RFPs, a practice should consider constructing a method of ranking vendors' EHR project proposals on how closely they align with your practice’s EHR requirements.
A set of objective criteria that can provide a clear and objective system for to identify their needs and then measure how closely an EHR aligns with them.
Some considerations when evaluating EHR RFP responses may include:
- Budgetary constraints
- Is there a timeline the vendor must meet?
- How much vendor support will your practice require?
- Is data conversion or migration required?
- Can the EHR be customized to meet your practice’s specific needs?
A vendor scorecard that assigns a numerical value to each function on a scale of 1 to 5. with 1 representing the lowest priority and 5 representing the highest priority can be a useful tool for evaluating responses and creating a comprehensive evaluation tool.
Here's our EHR RFP response evaluation template - feel free modify this to your needs or create your own.
|Key feature requirement 1|
|Key feature requirement 2|
|Key feature requirement 3|
|Key technical requirement 1|
|Key technical requirement 2|
Once you've scored all of your RFP responses, invite your top three to five vendors to demo their product to you and your team.
Remember: the numerical scores are a useful guide to which vendors to invite back to demo rather than a definitive measure. There may be instances in which you rule high-scoring systems out due to incompatibility with baseline requirements, including:
- being so far out of your project budget that it's not worth considering
- vendor company not being established or stable enough
- vendor not offering the level of support you would like
Read more about EHR demos in our extended guide to mastering EHR demos and making the right selection decision.
What should we do with RFP responses once evaluation is complete?
For larger practices or other organizations, an RFP database can serve as a useful tool for reducing the time needed to find vendors. For example, a hospital may keep a hospital RFP database so that if a vendor is needed for a particular service or product, a potential client within the organization can refer to the RFP database and find potential candidates more quickly.
Featured white papers
EHR RFPs, RFIs and RFQs: what should you send when?
The difference between EHR RFPs, RFIs and RFQs and when you should use each of them
EHR requirements and key features: your complete guide
Our extended guide to EHR requirements - everything you need to know and more on the subject
Invest for MIPS success: the four S's of ophthalmology EHR
Find a suitably specialized EHR to work around your MIPS and value-based care needs