Clinical AI Observatory
Clinical AI Vendor Evaluation Checklist Reviewed 2026-10-24
BLUF: Before deploying any clinical AI vendor, verify four pillars: (1) regulatory clearance matching the exact use case, (2) transparent model cards with demographic performance data, (3) integration testability via FHIR/SMART-on-FHIR sandbox, and (4) post-deployment monitoring commitments. A vendor that cannot produce documentation for all four should be treated as high-risk.
Risk Tiers
| Vendor Maturity | Evidence Required | Minimum Bar | Recommended Bar |
|---|---|---|---|
| Tier 1: FDA-cleared medical device | 510(k) or de novo + MDR CE marking + post-market surveillance plan | 510(k) number verified on FDA database | + model card + integration PoC + monitoring SLA |
| Tier 2: FDA-registered SaMD (Class II) | Clinical validation ≥ 2 peer-reviewed studies | + prospective multi-site study + monitoring SLA | |
| Tier 3: Unclassified AI tool | Data use agreement + security posture + validation against local cohort | Local validation study (IRR ≥ 0.85) | + IRB-approved validation + monitoring commitment |
Pillar 1: Regulatory Clearance
□ FDA 510(k) / de novo / PMA clearance obtained
Verify the clearance number on the FDA 510(k) database (https://www.accessdata.fda.gov/cdrh/510k/). Confirm the cleared indication matches your intended use exactly — many vendors clear a narrower indication than their marketing claims.
□ EU MDR 2017/745 CE marking
For EU deployments: verify the CE marking certificate number and the notified body. Check that the AI component is explicitly covered under the device classification.
□ ISO 13485 Quality Management
Vendor should hold ISO 13485 certification. Request the certificate and verify its validity period.
□ Post-market surveillance (PMS) plan
Vendor must commit to ongoing safety monitoring, incident reporting, and periodic safety update reports (PSURs).
Pillar 2: Model Cards & Data Provenance
□ Model card with demographic performance breakdown
Performance must be reported by: race/ethnicity, age bands, sex, BMI categories, and comorbidity burden. Look for performance gaps >15% between demographic groups — these indicate bias risk.
□ Training data composition disclosed
Vendor must disclose: total N, data sources, collection period, geographic distribution, and exclusion criteria. Red flag: "proprietary dataset" with no composition details.
□ Data provenance and consent documentation
All training data must have documented patient consent or be fully de-identified per HIPAA safe harbor. Request IRB approval references.
□ Known limitations and failure modes documented
Vendor must document: edge cases where performance degrades, contraindicated use cases, and known false-positive patterns.
Pillar 3: Integration Testability
□ FHIR API compatibility verified
Test with a FHIR sandbox (e.g., Microsoft FHIR Server, IBM FHIR Server). Verify the vendor can consume and produce standard FHIR R4/R5 resources: Patient, Observation, DiagnosticReport, Media, etc.
□ SMART-on-FHIR app launch tested
If the vendor provides an embedded app, test the OAuth2 launch sequence against the EHR's SMART launch endpoint. Verify scope requests are minimal (least-privilege).
□ CDS Hooks integration tested
Test at least one hook (e.g., patient-view) with realistic FHIR context. Verify the card response includes: summary, indicator, and actionable link.
□ Performance SLA verified
Pillar 4: Post-Deployment Monitoring
□ Model drift detection committed
Vendor must commit to monitoring for distributional shift in input data and performance degradation over time. Request the detection methodology and alerting thresholds.
□ Version control and rollback capability
Each model version must be versioned (semver) with documented changes. Rollback capability must be testable in staging.
□ Audit trail integration
Vendor must generate FHIR AuditEvent resources for all AI decisions. Verify these can be ingested into your existing audit infrastructure.
□ Incident response SLA
Security and safety incidents must have: 4-hour critical response, 24-hour high response, 72-hour standard response. Request the contact escalation matrix.
Scoring Rubric
| Pillar | Critical (5 pts) | Important (3 pts) | Nice-to-have (1 pt) | Total |
|---|---|---|---|---|
| Regulatory | 3/3 met | 1/1 met | 0/1 met | 4/5 |
| Model Cards | 3/3 met | 1/1 met | 0/1 met | 4/5 |
| Integration | 3/3 met | 1/1 met | 0/1 met | 4/5 |
| Monitoring | 2/3 met | 2/2 met | 1/1 met | 5/5 |
| Total | 11/15 | 5/5 | 1/3 | 17/23 |
Threshold: ≥18/23 to proceed to PoC. Below threshold → reject or require remediation. Adjust weights per institutional risk appetite.
JEV Decision Branch: Vendor Risk Gate
# JEV v12.336 — Vendor Risk Evaluation Node
# confidence_gate: 0.85
# persona: maria_santos (Regulatory Advisor)
node: vendor_risk_gate
prompt: "Evaluate vendor [name] against the four-pillar checklist. Does it meet the 18/23 threshold for PoC?"
gates:
- regulatory_clearance verified
- model_card has_demographics
- integration_poc viable
- monitoring_sla documented
fast_path: score ≥ 18 AND no critical gaps → proceed to PoC
slow_path: score < 18 OR critical gap → escalate to Silicon CRM for stakeholder review
Reviewer & Review Metadata
| Metadata | Value |
|---|---|
| Reviewer Name | Maria L. Santos |
| Credentials | JD, FDA Regulatory Affairs, MPH, Certified Clinical Research Professional |
| Review Date | 2026-10-24 |
| Re-review By | 2028-04-24 |
| Review Cycle | 24 months |
| Confidence Score | 0.93 (System-1 JEV gate) |
| Sources Verified | FDA 510(k) database, EU MDR, HL7 FHIR R4 docs |
View this note in the Obsidian-provenance vault: /evidence/vendors/checklist-vendor-evaluation.md