How to Use the Healthcare Controls Schema - AI Shared Responsibility

Experimental schema. This vertical is a proposed extension of the CoSAI Shared Responsibility Framework, developed independently to demonstrate the approach. It is not part of CoSAI SRF v1.0 and has not been endorsed by CoSAI, the FDA, or any regulator. Validate all content with your regulatory and compliance functions before use.

FDA's 2025 TPLC draft guidance and final PCCP guidance tell you what lifecycle controls a clinical AI system needs. ONC HTI-1 tells you what algorithmic transparency your certified health IT must provide. The EU AI Act tells you which systems are high-risk. None of them tell you how to wire these obligations together into a working accountability structure with named owners and auditable evidence.

This guide walks through five steps: classify the system, select the operating model, map accountable personas, set tier parameters, and collect FHIR evidence. Each step references the specific controls in the schema that apply. The result is a complete accountability map you can use in an FDA submission, an ONC transparency disclosure, or an EU AI Act technical documentation package.

Before assigning controls, determine the regulatory classification of the AI system. This drives which controls apply at full rigor and which at reduced rigor.

Classification	Criteria	Controls at full rigor
FDA Class III SaMD	High risk; drives or informs treatment decisions where failure could cause serious harm	All 40 controls; Class III tier parameters
FDA Class II SaMD	Moderate risk; provides diagnosis or treatment support but clinical review required	All 40 controls; Class II tier parameters
FDA Class I SaMD	Low risk; administrative, wellness, or non-clinical decision support	L1, L2, L4 controls at full rigor; L3 and L5 at reduced cadence
Non-device CDS	Displays, analyzes, or communicates information without autonomous recommendations	ONC HTI-1 transparency requirements (L3-DEV-002); HIPAA controls (L4); no FDA SaMD controls required

EU AI Act parallel. If the system will be used in the EU, classify it under the EU AI Act simultaneously. Clinical AI used for diagnosis, treatment decisions, patient monitoring, or triage is high-risk under Annex III. High-risk systems face the same obligation set as Class II/III SaMD for EU-facing deployments, with full compliance required from August 2026.

Controls to run first: SRF-L1-DEV-001 (risk classification policy) and SRF-L1-DEV-002 (system inventory) establish the foundation. Every other control assumes the system has a documented tier and registry entry.

The schema defines four operating models. Every control specifies which operating models it applies to. Selecting the model trims the set to what applies: On-Premise deployments drop 8 of the 40 controls, while Agent-Clinical deployments carry all 40.

Operating model	Description	Largest accountability surface
`SaMD-Cloud`	Cloud-hosted AI medical device accessed by healthcare organizations as a service	L5 model provider controls; FDA submission and PCCP obligations sit with the SaMD manufacturer
`EHR-Embedded`	AI integrated into an ONC-certified EHR or health IT product	L3 ONC HTI-1 transparency controls; ONC certification obligations sit with the health IT developer
`Agent-Clinical`	Agentic AI operating autonomously in clinical workflows (prior auth, care coordination, order entry)	L3 human-in-the-loop and scope enforcement; L4 SMART on FHIR authorization; carries the largest surface area under HIPAA minimum-necessary
`On-Premise`	AI deployed on hospital infrastructure; institution retains platform accountability	L4 platform controls shift to the health system; L5 model accountability shifts to the deploying institution if no manufacturer SaMD registration

Agent-Clinical deployments require all controls from SRF-L3-PMS-003 (agentic task boundary enforcement) and SRF-L4-DEV-001 (SMART on FHIR scoped authorization) to be active before go-live. These are the two most common gap controls for healthcare organizations deploying LLM-based clinical agents for the first time.

Each control names one accountable persona. Personas are role types, not job titles. Map each schema persona to the specific named individual or organizational role that holds accountability in your institution.

clinical-ai-governance

Clinical AI Governance

Typically: Chief Medical Officer, CMIO, or Clinical AI Review Board

L1 · 9 controls

clinical-data-steward

Clinical Data Steward

Typically: Chief Data Officer, Privacy Officer, or Clinical Data Governance Lead

L2 · 8 controls

clinical-application-developer

Clinical Application Developer

Typically: Digital Health Engineering Lead, Clinical Informatics Developer

L3 · 8 controls

health-platform-provider

Health Platform Provider

Typically: EHR Vendor (Epic, Oracle Cerner), Cloud Provider, or Health IT Infrastructure Team

L4 · 8 controls

model-provider

Model Provider

Typically: SaMD Manufacturer, AI Model Vendor, or Internal AI Research Team (if building in-house)

L5 · 7 controls

Shared accountability warning. When an operating model splits accountability across multiple parties (e.g., SaMD-Cloud with a cloud EHR), each persona mapping must identify the specific organization responsible. Leaving a persona unmapped is equivalent to leaving the control unowned.

Controls with param_type: tier-configurable define a metric and operator, but require your organization to set the parameter value based on FDA SaMD risk class. The table below provides reference starting points; your clinical governance body must approve final values.

Parameter	Class I (Low risk)	Class II (Moderate)	Class III (High risk)
`min_representation_fraction`	0.05 (5%)	0.10 (10%)	0.15 (15%)
`max_subgroup_performance_gap`	0.10 (10% drop)	0.05 (5% drop)	0.03 (3% drop)
`max_psi_score`	0.25	0.20	0.10
`min_data_completeness_rate`	0.80	0.90	0.95
`min_explanation_coverage_rate`	0.75	0.90	0.99
`max_clinician_override_rate`	0.60	0.40	0.25
`min_audit_completeness_rate`	0.95	0.99	0.999
`min_platform_availability_rate`	0.990	0.995	0.9995
`max_cve_critical_patch_days`	30 days	14 days	7 days

Zero-tolerance and verification controls carry fixed values. The 31 controls with param_type: zero-tolerance or verification are not configurable. PHI in non-production environments, safety-critical filter bypasses, unauthorized access events, and model artifact integrity failures are zero-tolerance regardless of SaMD class.

PCCP note: If you have an FDA-approved PCCP, the parameter values in your monitoring plan must match those approved in the PCCP. Changes to tier parameters that affect the monitoring plan may require a PCCP amendment or a new 510(k) submission.

Each control specifies the HL7 FHIR R4 resource and attribute that proves the control is operating. FHIR-native evidence replaces annual attestation paperwork with continuous, machine-readable audit records that regulators, notified bodies, and auditors can independently verify.

Primary FHIR resources used in this schema:

FHIR resource	Used for	Key layers
`AuditEvent`	AI inference events, override events, PHI access, security alerts (type codes 110110, 110113, 110114), authentication	L3, L4
`MeasureReport`	Performance metrics, demographic representation, subgroup analysis, drift monitoring, data quality scoring	L2, L5
`Provenance`	Training data lineage, model artifact signing, PCCP change records, context store integrity	L2, L4, L5
`Device`	Model card / SaMD registry, SOUP documentation, regulatory filing references	L1, L5
`DeviceMetric`	Guardrail operational status, runtime safety check metrics	L4
`DocumentReference`	Policy artifacts, validation reports, risk files, test reports, usability studies	L1, L3, L5
`AdverseEvent`	AI-related adverse events for MDR/FDA reporting	L1
`Observation`	Population drift metrics (PSI scores)	L2

Example: AuditEvent for an AI recommendation override (SRF-L3-PMS-001)

// FHIR R4 AuditEvent: clinician override of AI recommendation
{
  "resourceType": "AuditEvent",
  "type": {
    "system": "https://aisharedresponsibility.com/fhir/CodeSystem/srf-audit-event-type",
    "code": "ai-recommendation-override",
    "display": "AI Recommendation Override"
  },
  "recorded": "2026-06-12T14:32:00Z",
  "outcome": "0",
  "agent": [{
    "type": { "code": "humanuser" },
    "who": { "reference": "Practitioner/dr-jane-smith" },
    "requestor": true
  }],
  "entity": [{
    "what": { "reference": "Device/sepsis-alert-model-v2-1" },
    "role": { "code": "4", "display": "Domain Resource" },
    "detail": [{
      "type": "purposeOfOverride",
      "valueString": "Clinical presentation inconsistent with model inputs"
    }]
  }]
}
          

Using evidence for FDA submissions. The FDA TPLC guidance expects post-market performance data referenced in the marketing submission. FHIR MeasureReport resources, particularly for SRF-L5-PMS-001 (post-market performance monitoring plan) and SRF-L2-PMS-001 (input drift monitoring), are structured to export directly as performance evidence tables for 510(k) post-market studies or De Novo performance summaries.

Using evidence for ONC HTI-1 transparency disclosures. Controls SRF-L3-DEV-002 (explanation coverage) and SRF-L2-VV-002 (subgroup performance equivalence) produce the data required for ONC HTI-1 §170.315(b)(11) disclosures. FHIR MeasureReport resources stratified by demographic group satisfy the ONC transparency format requirement when exported and published alongside the certified health IT product.

Quick reference: controls by regulatory obligation

Regulatory obligation	Primary controls	Evidence resource
FDA TPLC: marketing submission	SRF-L5-DEV-001, SRF-L5-VV-001, SRF-L5-DEV-003, SRF-L1-PMS-001	Device, DocumentReference
FDA PCCP: algorithm change governance	SRF-L1-PMS-003, SRF-L5-PMS-001, SRF-L2-PMS-001	Provenance, MeasureReport
FDA MDR: adverse event reporting	SRF-L1-PMS-002	AdverseEvent
ONC HTI-1: algorithmic transparency	SRF-L3-DEV-002, SRF-L2-DEV-002, SRF-L2-VV-002, SRF-L1-HOR-003	AuditEvent, MeasureReport
HIPAA: PHI access control and audit	SRF-L2-DEV-003, SRF-L4-DEV-001, SRF-L4-DEV-002, SRF-L4-DEV-003, SRF-L4-PMS-001	AuditEvent
EU AI Act: high-risk system requirements	SRF-L3-DEV-001, SRF-L3-DEV-002, SRF-L2-VV-002, SRF-L5-DEV-001, SRF-L5-PMS-001	Device, MeasureReport, AuditEvent
IEC 62304: software lifecycle	SRF-L5-DEV-002, SRF-L5-VV-002, SRF-L4-PMS-003	Device, Provenance
ISO 14971: risk management	SRF-L5-DEV-003	DocumentReference
Agentic AI scope enforcement	SRF-L3-PMS-003, SRF-L4-DEV-001, SRF-L2-PMS-003	AuditEvent, Provenance