Framework · HHS Section 1557
Which decision support tools use protected-class inputs, from traffic.
Since 1 May 2025, 45 CFR 92.210 has required covered entities to make reasonable efforts to identify patient care decision support tools that use race, color, national origin, sex, age, or disability as inputs, and to mitigate the risk of discrimination from each one. Meilynx substantiates the identification duty with the live tool inventory and evidences the mitigation duty by attestation. It never performs bias testing and never asserts that any tool is nondiscriminatory.
No discrimination, identify, mitigate.
Section 92.210 has three parts. The identification duty is ongoing, and the source attributes ONC HTI-1 makes available are its developer-side input.
- No discrimination on the basis of race, color, national origin, sex, age, or disability through the use of patient care decision support tools (92.210(a)).
- An ongoing duty to identify tools in the entity's health programs that use input variables measuring a protected class (92.210(b)).
- Reasonable efforts to mitigate the risk of discrimination from each identified tool (92.210(c)): testing, monitoring, clinician review, vendor engagement.
- A notice of nondiscrimination and grievance procedures that reach AI-assisted care (92.8).
Runtime expectations, to runtime evidence.
A specific Meilynx control for each expectation the proxy can substantiate, and the artifact it produces. Everything else is attested in the package, and the package says which is which.
45 CFR 92.210 → Meilynx controls (AI-traffic slice)
| Requirement | How Meilynx maps | Examination artifact |
|---|---|---|
Identify the decision support tools in use HHS §1557 · 92.210(b) · HTI-1 · 170.315(b)(11)(iii) | The inventory of AI decision support tools is derived from live traffic and enforced by runtime model allow-listing. Whether a tool uses protected-class inputs is a determination you record per tool, with the source attributes as input. | Decision support tool inventory, generated from traffic |
Keep identifying as tools change HHS §1557 · 92.210(b) | Prompt-drift and tool-grant-drift detection flag when a proxy-routed tool's configuration changes, so the identification determination is revisited rather than assumed. | Drift findings against approved baselines |
Show clinician review as a mitigation measure HHS §1557 · 92.210(c) | Approval gates and their review record are supporting evidence that a clinician stood between the tool's output and the care decision. The review is a human act, and this control never auto-verifies. | Approval-grant lifecycle and clinician-review attestation |
Keep a record of decision support use HHS §1557 · 92.210(a) | Each interaction with a proxy-routed tool is sealed into a hash-chained record: what the tool was asked and what it returned, available when a discrimination inquiry arrives. | Hash-chained interaction record |
Evidence mitigation, policy, and notice HHS §1557 · 92.210(c) · 92.8 | Bias and outcome testing, the mitigation plan per tool, the nondiscrimination policy, and the notice are your acts. The package carries them as structured attestations and says so on every row. | Mitigation, policy, and notice attestations |
Identify the decision support tools in use
HHS §1557 · 92.210(b) · HTI-1 · 170.315(b)(11)(iii)
Maps to · The inventory of AI decision support tools is derived from live traffic and enforced by runtime model allow-listing. Whether a tool uses protected-class inputs is a determination you record per tool, with the source attributes as input.
Examination artifact · Decision support tool inventory, generated from traffic
Keep identifying as tools change
HHS §1557 · 92.210(b)
Maps to · Prompt-drift and tool-grant-drift detection flag when a proxy-routed tool's configuration changes, so the identification determination is revisited rather than assumed.
Examination artifact · Drift findings against approved baselines
Show clinician review as a mitigation measure
HHS §1557 · 92.210(c)
Maps to · Approval gates and their review record are supporting evidence that a clinician stood between the tool's output and the care decision. The review is a human act, and this control never auto-verifies.
Examination artifact · Approval-grant lifecycle and clinician-review attestation
Keep a record of decision support use
HHS §1557 · 92.210(a)
Maps to · Each interaction with a proxy-routed tool is sealed into a hash-chained record: what the tool was asked and what it returned, available when a discrimination inquiry arrives.
Examination artifact · Hash-chained interaction record
Evidence mitigation, policy, and notice
HHS §1557 · 92.210(c) · 92.8
Maps to · Bias and outcome testing, the mitigation plan per tool, the nondiscrimination policy, and the notice are your acts. The package carries them as structured attestations and says so on every row.
Examination artifact · Mitigation, policy, and notice attestations
What you hand an OCR reviewer.
A decision support package with a crosswalk over 92.210(a), (b), (c), and 92.8: each duty mapped to the section that answers it and the evidence scope it carries.
In the package
- Decision support tool inventory with the per-tool protected-class input determination.
- Mitigation evidence: testing performed by whom, metrics, next review, all attested.
- Clinician-review record and change-monitoring findings.
- A 92.210 crosswalk: duty, where addressed, evidence scope.
- Obligation timeline: 92.210 in force since 1 May 2025; 92.8 notice; HTI-1 pointer.
HHS §1557 and the proxy.
Does Meilynx test our tools for bias?
No. Bias and outcome testing is performed by your organization or your vendors. The package records who performed it, what was measured, and when it is next due. It never asserts that a tool is nondiscriminatory.
Which tools count as patient care decision support tools?
The rule's definition covers automated and non-automated tools used in clinical decision-making. Which of your observed AI tools meet it is your determination; the inventory shows what actually ran, so the determination starts from a complete list.
How does this relate to HTI-1?
HTI-1 requires certified health IT developers to make source attributes available, including whether race, ethnicity, sex, age, or disability are used. Those attributes are the developer-side input to your 92.210(b) determination. The ONC HTI-1 preset evidences that they are on file.
Build the evidence.
See exactly what an examiner receives
Download a sample examination package: model inventory, control coverage, a governance policy snapshot, and a SHA-256 integrity hash.