Binding law — in force
Apply risk analysis, risk mitigation and governance to every Predictive DSI a certified Health IT Module supplies (45 CFR 170.315(b)(11)(vi))
Intervention risk management practices must be applied to each Predictive Decision Support Intervention the health IT developer supplies as part of its Health IT Module: analysis of potential risks and adverse impacts for validity, reliability, robustness, fairness, intelligibility, safety, security and privacy; practices to mitigate the risks identified; and policies and implemented controls for governance, including how data are acquired, managed and used (45 CFR 170.315(b)(11)(vi)(A)-(C)). The records are kept by the developer outside the code. Report a missing risk-management record as not verifiable from code.
Trust and provenance not reviewed by a lawyer · audit-grade · source verified 4 Oct 2026 · release 2026.10.05
- Lane
- Binding law — in force In force: applies since 1 Jan 2025
- Official source
- 45 CFR 170.315(b)(11)(vi) · captured 4 Oct 2026 · anchor hash (SHA-256)
458cb10d16f5…· 4 more anchors in the data release - Verification
- Quoted text found word for word in the captured official document (4 Oct 2026). Source last verified 4 Oct 2026: checked against the captured official document; not in the weekly watcher's list; checked against the captured document.
- Data release
- Data release 2026.10.05, data as of 4 Oct 2026, schema 0.3.10.
- Legal review
- Not reviewed by a lawyer. TwinEthos derived this rule from the official text it cites: treat it as research to check against that text; it is not legal advice. No TwinEthos rule has been legally reviewed yet. Open questions for counsel on this rule: 1.
- Audit standard
- Audit-grade: meets all 9 checks of the TwinEthos audit standard that apply to it. The audit standard is TwinEthos's own quality bar for provenance, dates, applicability, detectors, fixtures, remediation and licences; it is not a legal review.
- Detectors
1 detector (missing artifact), experimental: written from the rule's text and not yet measured for precision on real code, so treat a hit as a lead to verify. Code cannot show this item: the evidence is a kept record or process.
Who it applies to
- Duty falls on: developer
- Sectors: healthcare
- Health IT developers presenting a Health IT Module for certification to 45 CFR 170.315(b)(11), for each Predictive DSI they supply as part of the module, in the United States. HTI-1 is in force from 2024-02-08; (b)(11) is required for the Base EHR definition from 2025-01-01.
- Not covered:
- Health IT that is not presented for certification to 170.315(b)(11) under the ONC Health IT Certification Program (the criterion is a certification requirement, not a general duty)
- Whether it applies depends on facts outside the code; a person has to decide.
The guard to add
Organizational artifact to keep (not verifiable from code); the guard is the record, its owner and its upkeep.
Keep an AI risk register that identifies, analyses, evaluates, treats, and monitors each AI system's risks through its life cycle, including after deployment.
A written AI risk methodology (AI-specific risk sources such as data drift, bias, misuse, opacity, and third-party model changes; likelihood and impact criteria; risk acceptance thresholds) folded into the organization's existing risk process, plus a per-system register entry with owner, analysis, evaluation against tolerance, chosen treatment, residual risk, and the monitoring signal that would show the risk changing. The system owner keeps it, with the risk function, and updates it at design review, before release, and when monitoring or incidents show a change. Link register entries to the evals and production monitors that implement each treatment.
Where it goes: 12 repository artifacts, 13 tests and evals, 10 logs and telemetry.
What this provision adds:
- Analyse each Predictive DSI for validity, reliability, robustness, fairness, intelligibility, safety, security and privacy; mitigate what the analysis finds; and govern how its data are acquired, managed and used.
Example (AI risk register (repo record)), before:
# risk-register.yaml
- system: loan-assistant
risk: model might be biasedAfter:
# risk-register.yaml
- system: loan-assistant
id: R-07
source: training data under-represents applicants over 65
analysis: {likelihood: medium, impact: high}
evaluation: above tolerance
treatment: reweighting + subgroup error-rate eval (evals/subgroups.py)
residual: low
owner: credit-ml-lead
monitoring: dashboard approval-rate-by-age, alert at >5 point gap
last_reviewed: 2026-09-15Control: AI system managed without a documented AI-specific risk-management process. The same guard addresses 3 items with binding law in 2 jurisdictions. Engineering guidance, not legal advice.
Standards that recommend the same control
- AI-specific risk management should follow a documented identify-analyse-evaluate-treat-monitor process (ISO/IEC 23894) (ISO/IEC 23894:2023 (AI risk mgmt) · ISO/IEC 23894:2023 (AI risk management process; Annexes A/B/C))
Rule id us-onc-hti1-dsi.predictive-dsi-intervention-risk-management · review status: primary source derived