A Request for Proposal is one of the most important documents a healthcare organisation will produce in any given procurement cycle. A well-written RFP attracts qualified vendors, sets clear expectations, provides a defensible basis for selection, and creates the foundation for a strong contract. A poorly written RFP produces vague proposals that are impossible to compare, invites responses from vendors who are not a genuine fit, and leads to protracted negotiations over things that should have been specified up front.
This guide walks through how to write a healthcare IT RFP that does its job.
RFP vs RFI vs RFQ: Using the Right Instrument
The three procurement instruments serve different purposes and are often confused.
A Request for Information (RFI) is used early in the process, before requirements are fully defined. It asks the market to describe what solutions exist, what capabilities vendors have, and what approaches are available. RFIs are non-binding and do not invite pricing. They are useful for market scanning and for shaping requirements before an RFP is written.
A Request for Proposal (RFP) invites vendors to propose a specific solution to a defined problem, with pricing and a commitment to key terms. It is the main procurement instrument for complex system selection. Responses to an RFP are evaluable against each other and form the basis for vendor selection.
A Request for Quotation (RFQ) is used when the specification is fully defined and the only variable is price. RFQs are appropriate for commodity purchases — hardware, standard software licenses — not for complex system selection where vendor capability, approach, and fit matter as much as price.
Using an RFP when you need an RFI leads to premature commitment and limits your ability to shape requirements based on market input. Using an RFI when you need an RFP wastes time. Know which instrument serves your current stage of the process.
What to Include in a Healthcare IT RFP
1. Organisational Background
Open with a brief description of your organisation: type of facility, patient population served, bed count or visit volumes, geographical scope, and existing IT environment. This context helps vendors assess their own fit and tailor their proposals accordingly. Vendors who respond without reading this section reveal something important about how they handle client requirements.
2. Current State Summary
Describe the systems currently in place that are relevant to this procurement. What are you replacing or supplementing? What are the known pain points? What integrations currently exist that a new system must accommodate? This section prevents proposals based on assumptions that are wrong about your starting point.
3. Scope and Objectives
Define clearly what the procurement covers and what it does not. Scope creep in proposals — vendors proposing additional modules, services, or related products not requested — makes evaluation harder. Being explicit about what is in scope and what is out of scope keeps proposals focused and comparable.
State the objectives the procurement is intended to achieve. These should be outcome-focused: "reduce medication administration errors at point of care" is more useful than "implement a medication administration system."
4. Functional Requirements
Functional requirements are the core of the document. They describe what the system must do, expressed in terms of user actions and clinical workflows. Use a numbered list so vendors can respond requirement by requirement.
Classify each requirement as:
- Mandatory: The system must meet this requirement. Vendors who cannot meet mandatory requirements should be disqualified.
- Preferred: Meeting this requirement will be scored positively but is not a disqualifier.
- Future: The organisation expects to need this capability in the future; vendor should indicate roadmap.
Functional requirements should be written from the user's perspective. Poor example: "Must support clinical documentation." Better example: "A nurse must be able to complete a post-operative assessment using a structured form at the bedside on a tablet, with the form auto-populating the patient's demographics and current medications from the patient record."
5. Technical Requirements
Technical requirements cover architecture and integration:
- Hosting model: cloud-hosted SaaS, on-premise, or hybrid
- Integration interfaces: which existing systems must the new system connect to (EHR, laboratory, imaging, billing), and what integration standards are required (HL7 FHIR R4, HL7 v2, DICOM, REST APIs)
- Security requirements: encryption standards, access control, audit logging, penetration testing cadence
- Performance requirements: response time expectations, concurrent user volumes, uptime requirements
- Browser and device compatibility: which platforms must be supported
6. Compliance and Regulatory Requirements
In the United States, this section should specify HIPAA compliance requirements and the obligation to sign a BAA. Internationally, specify applicable data protection regulations, national eHealth standards, or sector-specific requirements. For clinical applications, specify any relevant medical device software standards (IEC 62304, FDA SaMD guidance) that may apply.
If your organisation is subject to specific audit or accreditation standards (Joint Commission, NABH, ISO 27001), specify any requirements these create for vendors.
7. Implementation and Support Requirements
Describe your expectations for implementation: timeline, methodology, training approach, go-live support, and post-go-live hyper-care. Ask vendors to provide a proposed implementation plan and to identify what they require from your organisation (staff time, infrastructure, data access) to deliver it.
Specify support requirements: support hours, response time commitments for different incident priorities, escalation paths, and release management processes.
8. Pricing and Commercial Terms
Ask for a complete breakdown of costs, including:
- Software licensing (per user, per module, subscription, perpetual)
- Implementation and professional services
- Training
- Annual maintenance and support
- Estimated infrastructure costs (if on-premise)
- Costs for additional users or modules
Ask vendors to identify any costs that are not included in their proposal that might reasonably arise during implementation or ongoing operation. This question separates transparent vendors from those who quote low and charge heavily for extras.
9. Evaluation Criteria and Weighting
Publish your evaluation criteria and their weightings. This is counterintuitive to some procurement teams, but transparency about evaluation criteria actually improves proposal quality — vendors who know what matters most provide more targeted, useful responses. It also makes your evaluation defensible if challenged.
10. Submission Requirements and Timeline
Specify the format of required response (section by section, matching your RFP structure), the deadline, the submission method, and the key dates in the evaluation process. Include a deadline for vendor questions and commit to circulating answers to all bidders.
What Vendors Look For
Experienced vendors evaluate RFPs as much as you evaluate their proposals. They look for signs that the buying organisation is serious, well-organised, and likely to be a productive client. Clear requirements, realistic timelines, and published evaluation criteria signal a mature procurement process. Vague requirements, unrealistic timelines, and missing information signal an organisation that will be difficult to work with — and experienced vendors may decline to respond, leaving you with proposals only from vendors who are less selective.
Common RFP Mistakes
- Requirements so vague that any system technically meets them
- Mandatory requirements that are actually preferences, reducing their discriminatory value
- No published evaluation criteria, making the process appear arbitrary
- Timeline too short for vendors to produce a quality response (less than three weeks for a significant system is rarely adequate)
- No opportunity for vendor questions, resulting in proposals based on incorrect assumptions
- Failing to circulate vendor questions and answers to all bidders, creating information asymmetry
Evaluating Responses
Score responses against your published criteria before discussing them as a committee. If each evaluator scores independently and then the committee compares scores, you surface genuine disagreements that reflect different stakeholder priorities — which is valuable information for the decision-making process.
Document the basis for your decision. In the event of a challenge from an unsuccessful vendor, or in the event of a future audit, you need a paper trail that shows your evaluation was conducted fairly and in accordance with your stated criteria.
FZ Consulting LLP helps healthcare organisations develop RFPs, manage vendor evaluations, and make confident procurement decisions. Contact us to discuss your next procurement.