Skip to content
CCompareHealthcareAPI

Framework · RFP question set

The RFP question set that separates documentation from marketing

Questions written so that a vague answer is visibly a vague answer. Reuse them with attribution.

Written by Compare Healthcare API Editorial DeskReviewed by Technical ReviewLast reviewed Rubric v1.0

Short answer

What should you ask an AI scribe or speech API vendor in an RFP?

Ask questions whose answers are artefacts, not adjectives: show the request and response payload for a multi-problem encounter; state the default retention window and whether zero-retention is available; provide the BAA and name the plan it is available on; list subprocessors including inference providers; state whether our PHI trains your models, in contract language; document the EHR write paths you support and the scopes they need; and give per-minute pricing including minimums. Vendors who answer these in writing are the shortlist.

Cite as: AI scribe and speech API RFP question set, Compare Healthcare API, last reviewed 2026-09-01.

Key findings

  • The best RFP questions request an artefact — a payload, a report, a clause — because artefacts cannot be answered with enthusiasm.
  • Ask for the failure cases explicitly; how a system behaves on missing information tells you more than any accuracy claim.
  • Pricing questions belong at the end, after capability, so a low price cannot mask a costly integration.
  • Any question a vendor answers with 'on the roadmap' should be re-asked as 'what is supported in production today, in documentation'.
  • Send the same set to every vendor unmodified; comparability is the entire value of a question set.

API and integration

These questions predict integration cost more reliably than any demo.

  • Provide public documentation URLs for authentication, endpoints, error semantics, rate limits and versioning policy.
  • Show a complete request and response payload for a realistic multi-problem encounter.
  • Can an engineer obtain sandbox credentials today without a sales conversation? What is the path?
  • What SDKs are officially supported, and what is your deprecation policy for breaking changes?
  • Is output addressable by section and field, and is transcript provenance included per section?
  • What are your published uptime commitments, and where is your status history visible?

Clinical output quality

The aim here is to establish evaluation practice, not to extract a number you cannot reproduce.

  • How do you evaluate note quality, on what corpus, and reviewed by whom with what clinical qualification?
  • What does the system do when a required template field has no supporting content in the conversation?
  • How are speaker attribution errors detected and surfaced to the clinician?
  • How do you prevent fabricated content, and how are suspected fabrications reported and investigated?
  • What is your process and notification policy when the underlying model changes?
  • Which specialties have production customers today, and can we speak to one in ours?

Interoperability

Answers here should name resources and scopes, not standards in the abstract.

  • Which FHIR resources do you emit, and at which version?
  • For each supported EHR, what is the documented note write path and what scopes does it require?
  • Do you support SMART on FHIR launch, and is your app registered with the relevant developer programmes?
  • What does per-customer enablement require, and who performs it?
  • How do you handle customers whose EHR has no documented note write path?

Compliance and security

Every one of these should return a document or a contract clause.

  • Provide your BAA and state the plan level at which it is available.
  • What is default retention for audio and transcripts, and can it be set to zero?
  • Provide your current SOC 2 Type II report or HITRUST certification.
  • List all subprocessors, including model inference providers, and their locations.
  • Confirm in contract language that customer PHI is not used to train or fine-tune models.
  • Describe access controls, audit logging, breach notification timelines and data destruction at termination.

Commercial terms

Ask last, ask precisely, and ask about the shape of the curve rather than the headline rate.

  • Provide per-minute or per-encounter pricing, minimums, and overage behaviour.
  • Are white-label and resale rights included, and is vendor attribution required anywhere in the chart or UI?
  • What are volume tier boundaries, and how does price change at ten times our current volume?
  • What are the termination terms, and how is our data exported — in what structure?
  • What support commitments and escalation paths apply to production incidents?

Frequently asked questions

Can I reuse this RFP question set?
Yes, with attribution to this site and a link. It is organised by the same seven criteria used in our rankings, so vendor responses map directly onto a weighted score. Evaluation framework.
What is the single most revealing question?
'What does the system do when a required template field has no supporting content in the conversation?' Vendors built for clinical use answer it precisely; others answer it with reassurance. Output contracts.
How should we score the responses?
Map each answer to its criterion, score 0-10 per criterion, apply your weights, and record the evidence. The vendor selector does the arithmetic and produces a shareable report with your weighting attached. Vendor selector.

Evidence & sources

Every factual claim on this page traces to one of the primary references below. Each entry records what it supports and its evidence tier, so documentation can be told apart from judgement.

  1. [1]Business Associate Contracts — sample provisions

    U.S. Department of Health & Human Services · Regulation · Tier A — primary documentation

    Supports: The contractual clauses a documentation vendor's BAA must contain.

  2. [2]SOC 2 — trust services criteria

    AICPA · Standard · Tier A — primary documentation

    Supports: What a SOC 2 Type II report does and does not attest to during a vendor security review.

  3. [3]HITRUST CSF

    HITRUST Alliance · Standard · Tier A — primary documentation

    Supports: The certification many health systems require of documentation vendors handling PHI at scale.

  4. [4]AI Risk Management Framework (AI RMF 1.0)

    NIST · Standard · Tier A — primary documentation

    Supports: A defensible structure for governing an AI documentation feature you ship to clinicians.

  5. [5]FHIR DocumentReference resource

    HL7 International · Standard · Tier A — primary documentation

    Supports: The canonical target resource for writing a generated clinical note back to a chart.

  6. [6]SMART App Launch framework

    SMART Health IT / HL7 · Standard · Tier A — primary documentation

    Supports: The launch and authorisation pattern for embedding a documentation app inside an EHR.

  7. [7]Epic on FHIR developer documentation

    Epic Systems · Vendor documentation · Tier A — primary documentation

    Supports: What an integrator can and cannot write back to an Epic chart, and under which app programme.

Source tiers are defined on the methodology page. Outbound links are unaffiliated and carry no commercial relationship.

Continue