5.3 Vendor Selection, RFP Process & System Evaluation

5.3 Vendor Selection, RFP Process & System Evaluation

COTS Software Procurement in Healthcare

Healthcare organizations rarely develop complex enterprise software in-house. Instead, they procure Commercial Off-The-Shelf (COTS) solutions from commercial health IT vendors. Procuring an enterprise Electronic Health Record (EHR), Picture Archiving and Communication System (PACS), or Enterprise Resource Planning (ERP) platform is a multi-million-dollar investment that impacts clinical operations for decades.

Selecting an improper vendor solution can result in catastrophic financial losses, severe clinical productivity declines, and compromised patient safety. Consequently, health IT procurement follows a rigid, highly objective procurement lifecycle designed to minimize risk and ensure optimal organizational alignment.

---

Information Requests: RFI vs. RFP vs. RFQ

Procurement begins by issuing formal request documents to vendor markets. Candidates must understand the clear distinctions between these procurement instruments:

1. Request for Information (RFI)

An RFI is an exploratory document issued early in procurement when an organization seeks broad market intelligence. It allows the health system to identify available vendor solutions, emerging technology approaches, and general company profiles. RFIs do not request binding pricing and are used to narrow down a broad vendor market (10–15 vendors) to a qualified shortlist (3–5 vendors).

2. Request for Proposal (RFP)

An RFP is a formal, comprehensive document sent to shortlisted vendors after requirements gathering is complete. The RFP contains hundreds of specific functional, non-functional, clinical, technical, and regulatory requirements. Vendors must provide detailed, binding responses explaining how their product fulfills each requirement, alongside implementation schedules, technical architecture diagrams, and total pricing models.

3. Request for Quote (RFQ)

An RFQ is used when procuring standardized, highly commoditized goods or services where functional requirements are identical across vendors and price is the sole deciding factor. In health IT, RFQs are used for hardware purchases (e.g., procuring 500 identical barcode scanners or desktop monitors) rather than complex software applications.

---

RFI vs. RFP vs. RFQ Comparison Matrix

---

Developing and Structuring the RFP

A health IT RFP must be meticulously structured to ensure vendor responses can be objectively compared. Key components include:

1. Organizational Profile: Hospital bed count, annual patient volume, clinical specialties, current IT infrastructure, and strategic goals.
2. Scope of Work (SOW): Specific modules requested (e.g., Inpatient EHR, CPOE, Pharmacy, Emergency Dept, Revenue Cycle).
3. Functional & Clinical Requirements Matrix: Detailed spreadsheet listing hundreds of system requirements where vendors score compliance (e.g., Out-of-the-box, Configurable, Custom Code Required, Not Supported).
4. Technical & Security Requirements: Infrastructure requirements, database architecture, disaster recovery capabilities, and HIPAA/SOC2 compliance attestations.
5. Vendor Profile & Financial Stability: Corporate background, annual revenue, ongoing litigation history, and R&D investment levels.
6. Cost & Commercial Terms: Detailed breakdown of software licensing, SaaS subscriptions, implementation consulting, interface build fees, and annual maintenance costs.

---

Objective Vendor Evaluation & Weighted Scoring Grids

To prevent subjective bias and vendor favoritism, evaluation committees use a Weighted Vendor Scoring Matrix. Each evaluation category is assigned a percentage weight based on organizational priorities. Committee members score vendor proposals on a standardized scale (e.g., 1 to 5).

Sample Weighted Vendor Evaluation Matrix

---

Advanced Vendor Evaluation Techniques

Scripted Product Demonstrations

Vendors routinely deliver polished, generic "canned" sales demonstrations that showcase their software's best features while obscuring workflow flaws. Evaluation teams must mandate Scripted Demonstrations.

The health system provides vendors with standardized, complex clinical scenarios in advance. For example: "Demonstrate an ED physician ordering an IV antibiotic for an elderly patient with renal impairment, showing automated GFR dose adjustment alerts, nursing administration documentation, and pharmacy verification." Scripted demos level the playing field and test how software handles real-world organizational workflows.

Reference Validation & Site Visits

• Vendor-Provided References: Contacting customer sites provided by the vendor. While useful, these sites are typically highly favored brand advocates.
• Blind References: Contacting peer hospitals not listed on the vendor's reference sheet to uncover candid feedback regarding implementation delays, unpatched software bugs, and poor customer support.
• Site Visits: Sending a small multidisciplinary team to observe the vendor's software in active production at a peer health system. Site visits allow clinicians to evaluate screen load speeds and user satisfaction firsthand.

---

Contracting, SLAs, and Total Cost of Ownership (TCO)

Service Level Agreements (SLAs)

An SLA is a legally binding contract addendum defining mandatory vendor performance standards and financial remedies for non-performance. Key health IT SLA metrics include:

• System Uptime/Availability: Enforcing 99.99% operational uptime (allowing less than 52.6 minutes of unplanned downtime per year).
• Mean Time to Resolution (MTTR): Mandating that Severity 1 ("System Down") incidents receive vendor response within 15 minutes and resolution within 2 hours.
• System Latency: Specifying that clinical screen load times must not exceed 1.5 seconds during peak operations.
• Financial Penalties: Liquidated damages or fee credits (e.g., 5% monthly fee credit for every 0.1% drop in uptime below SLA threshold).

Total Cost of Ownership (TCO) Financial Modeling

TCO calculates the true cost of acquiring, operating, and maintaining a system over its complete lifecycle (typically 5 to 7 years). Evaluating initial license fees alone is a catastrophic mistake.

TCO = Initial Capital Expenses (CapEx) + 5-7 Years of Operational Expenses (OpEx)

TCO Cost Component Breakdown

1. Software Costs: Upfront license fees or monthly SaaS subscription fees.
2. Implementation & Consulting: Vendor professional services, interface build costs, and system integration fees.
3. Hardware & Infrastructure: Network upgrades, storage expansion, servers, clinical workstations, and barcode readers.
4. Staff Backfill & Training Costs: Overtime or temporary staffing costs to cover shifts while regular nurses and physicians attend mandatory software training.
5. Ongoing Annual Maintenance: Annual software maintenance fees (typically 18%–22% of initial software license costs for on-premise systems) or escalating cloud hosting fees.