11.3 Proposals, RFPs, RFIs, SLAs, SOWs, and NDAs
Key Takeaways
- An RFI scans the market without award intent. An RFP solicits a scored solution with award intent. An RFQ prices a specified item.
- A proposal (task A.9) must recommend an approach and include a benefits-realization plan—not just a product name or a go-live date.
- An SLA is measurable service levels, measurement method, exclusions, and remedies. An SOW is scope, deliverables, and acceptance. They are not interchangeable.
- An NDA protects confidential information during evaluation. It does not authorize PHI, replace a BAA, or create an SLA, SOW, or purchase.
- Extract lock-in and exit clauses from business documents: data formats, interface fees, termination, escrow, and data-return.
11.3 Proposals, RFPs, RFIs, SLAs, SOWs, and NDAs
Quick Answer: Task A.9 is writing a proposal that recommends an approach and a plan to realize benefits. Task A.10 is reading business documents so you can promote a change without getting locked in. RFI scans. RFP solicits a scored solution with award intent. RFQ prices a specified item. SLA is service levels and remedies. SOW is scope and acceptance. An NDA is confidentiality only—it is not a BAA, a purchase, or permission to use PHI.
This is the last analysis block before design (chapter 12) and selection (chapter 13). You have disparately sourced facts (11.1) and an aligned, multi-lens case (11.2). Now you must package a recommendation and extract risk from paper. Vendor contracts return in chapter 18; here the skill is interpretation during analysis.
A.9 — The proposal is not a product brochure
A CPHIMS proposal (internal business case or formal recommendation) has to do two official jobs: recommend approaches and solutions, and include plans for realizing benefits.
| Proposal element | What “good” looks like | What fails A.9 |
|---|---|---|
| Problem and A.5 facts | Grain, identity, match rate, residual | “Our data are messy” with no residual |
| Alternates (A.6) | Status quo plus at least one process and one application path | Single vendor name |
| Alignment (A.7) | Quoted strategic and operational objectives | “Supports innovation” |
| Multi-lens CBA (A.8) | Quality, access, economics, satisfaction, process | Payback-only appendix |
| Recommended approach | Named option, why others lost, residual risks | “We like Product X” |
| Benefits-realization plan | Benefit, baseline, target, owner, window, data source | Go-live date offered as the benefit |
| Resources and dependencies | EMPI, interfaces, training, operational owner | Silent on identity work |
| Decision requested | Approve, defer, or kill | “For awareness” with a purchase order attached |
Benefits realization is later validated (chapter 14). Analysis still has to plan it: who will measure 90-day new-patient wait, from which system, against which baseline, and what happens if the benefit does not appear. A vendor ROI paragraph is not that plan.
A.10 — What each document is for
Memorize purpose, not folklore. The handbook examples are RFPs, RFIs, SLAs, SOWs, and NDAs. Professional practice also uses RFQ, MSA, BAA, and best-and-final offers. Know the distinctions.
| Document | Job | When you use it | What CPHIMS must extract |
|---|---|---|---|
| RFI (Request for Information) | Market scan. Capability, architecture, viability. No award intent. | You do not yet know the solution shape | What the market can do; identity and interoperability patterns; what you still must specify |
| RFP (Request for Proposal) | Formal solicitation against stated requirements, with evaluation criteria and award intent | Requirements and scoring exist | Mandatory versus scored requirements, data ownership, interfaces, requested SLAs, exit, implementation method, how vendors are scored |
| RFQ (Request for Quote) | Price for a specified item or service | You already know the SKU, module, or staff-augmentation profile | Unit price, term, volume breaks, what is out of the quote |
| Proposal (vendor or internal) | Offered approach, price, and assumptions | Response to an RFP, or an internal A.9 package | Gaps versus requirements, assumptions that shift cost, benefits claims versus your 11.2 CBA |
| NDA (Non-Disclosure Agreement) | Confidentiality during evaluation or negotiation | Before you share non-public information | Mutual versus one-way, term, return/destroy, residuals, what it does not authorize |
| MSA (Master Services Agreement) | Umbrella legal terms | Before or with the first SOW | Liability, IP, insurance, audit, termination, order of precedence |
| SOW (Statement of Work) | What will be delivered, by whom, when, and how acceptance works | Each engagement under the MSA | Scope, deliverables, out-of-scope, assumptions, acceptance tests, change control, time-and-materials versus fixed fee |
| SLA (Service Level Agreement) | How well an ongoing service must perform, and remedies | Operations, hosting, support, HIE, cloud | Metrics, measurement method, exclusions, credits, exclusive-remedy language, security and incident times |
| BAA (Business Associate Agreement) | HIPAA: permitted PHI use, safeguards, breach duties | Before a vendor creates, receives, maintains, or transmits PHI | Permitted use, subcontractors, breach clock—not interchangeable with an NDA |
RFI versus RFP versus RFQ
Use an RFI when the board asks “what exists for remote monitoring?” You want architecture patterns, identity models, and a short list—not a price war. Using an RFP as your first document wastes vendor and staff time and locks you into requirements you have not earned from A.5–A.8.
Use an RFP when you can publish requirements, scoring, and an intent to award (or to award a place on a contract). Extract whether identity, data-return, interface standards, and SLA targets are mandatory. If they live only in a sales appendix, they will vanish at contracting.
Use an RFQ when the thing is specified: 200 identical tablets, a named EHR module already on the price file, or a defined FTE profile. An RFQ is the wrong tool for “help us choose a population-health strategy.”
SLA versus SOW
People swap these labels. Do not.
- The SOW answers: What work? Which deliverables? What is out of scope? Who accepts, and with what test? What happens when the clinic adds a seventh hospital mid-project?
- The SLA answers: What uptime, response, resolution, batch window, or matching rate will you run to? How is the metric measured (user transactions versus vendor ping)? What is excluded (unlimited “planned maintenance”)? What credit or other remedy applies—and is the credit the exclusive remedy?
A beautifully written SLA on a vague SOW still leaves you arguing about whether identity matching was in scope. A precise SOW with no SLA leaves you with a delivered system that is down every Monday.
NDA limits (high-yield)
An NDA is narrow. After it is signed you may share confidential business information under its terms. You may not:
- Disclose PHI because “they signed the NDA.” PHI needs a BAA (and a purpose, minimum necessary, and often a SOW).
- Treat the NDA as a purchase, a pilot, or an SLA.
- Assume a one-way NDA that only protects the vendor is acceptable when you are sending strategy documents the other way.
- Ignore term and return/destroy. Evaluation files should come back or be certified destroyed if you do not award.
Residual-knowledge clauses and over-broad restrictions in an NDA are negotiation items. They are not a reason to skip the NDA and email a full identifiable extract.
Vendor lock-in and SLA pitfalls
A.10 is how you promote a change—and how you avoid a change you cannot unwind.
Lock-in signals to extract from RFP responses, MSAs, and SOWs:
- Proprietary extracts only; no documented FHIR, HL7, or bulk data-return.
- Per-destination interface fees that make leaving mathematically silly.
- Source-code or data escrow missing for a system of record.
- Termination for convenience blocked, or a multi-year auto-renew with a 180-day notice that nobody will hit.
- “Only our cloud” with no exit runbook.
- Professional-services-only path to get your data out.
SLA pitfalls that show up on stems:
- 99.9% uptime excluding all planned maintenance, with no cap on the exclusion.
- Measurement from the vendor’s network, not from the clinic workflow.
- Credits that require written notice in five days or they expire.
- Credits as exclusive remedy even after a multi-day outage of an EHR-adjacent service.
- No recovery-time or recovery-point objective, no security-incident clock, no distinction between acknowledge and resolve.
- Batch windows that miss the claims-lag and operational-worklist split you learned in section 11.1.
If the RFP did not ask for data-return, SLA measurement method, and exit assistance, the analysis is incomplete—even if the demo was excellent.
Scenarios and exam traps
Scenario. Leadership wants “an RFP next week” for population health, but you have not profiled claims/EHR/device identity and have no scored requirements. Issue an RFI (or finish A.5–A.8). An RFP without requirements is a brochure contest.
Scenario. Procurement sends an RFQ for “a population-health system.” That is the wrong instrument. An RFQ prices a specified item. Strategy selection needs an RFI, then an RFP.
Scenario. A vendor says the signed NDA lets them load production PHI into a demo cloud this weekend. Stop. NDA ≠ BAA ≠ SOW. No PHI until the legal path for a business associate is in place and the purpose is defined.
Scenario. The SLA promises 99.95% uptime. Footnotes exclude maintenance, third-party networks, and “factors beyond our control,” and credits are exclusive remedy with a five-day claim window. Extract those limits in the analysis; do not read the headline percentage.
Scenario. The SOW lists “integration” as a bullet. Extract: which messages, which identity key, who owns the EMPI match residual, and what acceptance test proves a member-to-MRN bind. A bullet is not a deliverable.
Watch these traps:
- Using RFP, RFI, and RFQ as synonyms.
- Treating SLA and SOW as the same document.
- Believing an NDA authorizes PHI or replaces a BAA.
- Accepting vendor ROI language as the A.9 benefits-realization plan.
- Missing lock-in: formats, interface fees, exit, escrow.
- Reading the SLA headline uptime without exclusions and exclusive-remedy clauses.
The organization wants to learn what remote-monitoring products exist, how they bind devices to patients, and whether the market can support an EMPI. Requirements and scoring are not ready. Which document is the right first instrument?
What should a CPHIMS candidate extract as the difference between an SLA and an SOW?
A vendor says a signed NDA lets them load production PHI into a demo cloud this weekend and start implementation. What is the correct interpretation?