When a clinical algorithm produces an inequitable result, attention often moves upstream to the developer. Development choices matter, but the organization that puts the tool into patient care has its own duty. In the United States, 45 CFR 92.210 makes that point explicit for entities covered by Section 1557 of the Affordable Care Act.
The regulation prohibits discrimination through the use of patient care decision-support tools. The protected bases are race, color, national origin, sex, age, or disability. It also creates an ongoing duty to make reasonable efforts to identify uses that employ variables or factors measuring those protected bases and to make reasonable efforts to mitigate the resulting discrimination risk.
Coverage, interpretation, and enforcement can change the analysis. So can litigation, other laws, and facts. The operational lesson is nonetheless durable: buying a tool, accepting a regulator's clearance, or asking a clinician to review output does not transfer your civil-rights responsibilities to somebody else.
What Section 1557 covers#
Section 1557 prohibits discrimination in certain health programs and activities. The protected bases incorporated into the regulation are race, color, and national origin. They also include sex, age, and disability. Whether your organization or a given activity is covered requires legal analysis of the statute and the implementing rule.
The 2024 final rule took effect July 5, 2024. Paragraphs 92.210(b) and (c) had a delayed applicability date within 300 days, which placed their compliance date on May 1, 2025. By July 2026, this is an operational duty, not a future planning item.
The rule calls the relevant technology a “patient care decision support tool.” The definition is deliberately broader than AI or machine learning. It includes automated and nonautomated tools that support clinical decision-making. Those can include medical devices, clinical guidelines, and formulas. They can include equations, flowcharts, calculators, and predictive systems. The scope includes tools that make an autonomous decision and tools that assist or augment a human, so an organization cannot avoid the provision merely by describing an output as advisory.
The three parts of 45 CFR 92.210#
Paragraph (a) is the general prohibition, and a covered entity must not discriminate on a protected basis through its use of a patient care decision-support tool in its health programs or activities.
Paragraph (b) creates an ongoing identification duty. The covered entity must make reasonable efforts to identify uses of patient care decision-support tools that employ input variables or factors measuring race, color, national origin, sex, age, or disability.
Paragraph (c) creates the mitigation duty. For each tool identified under paragraph (b), the covered entity must make reasonable efforts to mitigate the risk of discrimination resulting from the tool's use.
These clauses should be read together. An inventory alone does not mitigate risk. A mitigation policy without a reliable way to identify tools does not satisfy the ongoing structure. The general prohibition also remains broader than a mechanical list of inputs because discrimination can arise through workflow, proxies, or implementation.
What counts as use#
The regulation focuses on a covered entity's use in clinical decision-making affecting patient care. Examples can include estimating kidney function, assigning clinical risk, and prioritizing care management. They can include supporting diagnosis, recommending treatment, allocating a scarce intervention, or deciding urgency.
The preamble explains that the provision does not apply to tools used for activities unrelated to clinical decision-making affecting patient care. It names administrative and billing work, automated coding, and fraud control. It names scheduling, facilities, and inventory. It names supply chains, financial investment, employment, and staffing when those activities are unrelated to clinical care decisions.
The phrase “when unrelated” matters. A scheduling system that only books an agreed appointment may fall outside this provision, while a system that uses clinical characteristics to decide which patient receives scarce specialist access may require a closer analysis. Labels such as administrative or operational do not settle function.
Organizations should document the actual workflow. What input enters? What output appears? Who sees it? Which decision can change? Which patient group is affected? A product description may be narrower than what you actually do with it, and a local customization may move the tool beyond the vendor's intended conditions.
Protected variables are not automatically forbidden#
The rule does not say that every protected characteristic must be removed from every clinical calculation. Age, sex, and disability can be clinically relevant in particular evidence-based contexts. A tool designed to address a health disparity can also be lawful if its use does not constitute prohibited discrimination.
The preamble gives age as an example. Because age is common in clinical tools and may have a valid medical purpose, a reasonable mitigation may include showing that age is clinically indicated and aligns with evidence-based practice without resulting in discrimination.
Race deserves careful scrutiny because it is a social and political classification, not a simple biological variable, and can act as a proxy for unequal systems rather than innate difference. The removal of race coefficients from kidney function equations illustrates how a tool can be revised when the factor lacks a sound and equitable clinical role.
The right question is not merely “does the tool use a protected field?” It is: what does the factor measure, why is it present, what evidence supports that use, how does it affect decisions, and does the resulting process discriminate?
Proxy discrimination still matters#
A model can produce disparate effects without receiving a field labeled race or disability. Geography, prior spending, and insurance history can correlate with protected characteristics and with structural barriers. So can language, utilization, missed visits, and device data.
The 2019 Science study of a widely used population-health algorithm showed the danger of a proxy target. The algorithm used health spending as a measure of need, and because Black patients with comparable illness had incurred less spending, the tool assigned lower risk and reduced access to added care.
Section 92.210(b) does not require covered entities to identify every tool containing any indirect proxy among the limitless possible correlations. The broader nondiscrimination obligation, however, is not made safe by deleting explicit fields. Outcome monitoring and review of model purpose remain important, and a governance program should distinguish direct protected inputs, known proxies, target variables that may encode unequal access, and implementation choices that can amplify disparity.
What “reasonable efforts” means#
The rule does not impose one audit formula. In the preamble, the HHS Office for Civil Rights identifies factors it may consider when evaluating reasonable identification efforts.
These include the covered entity's size and resources; whether the tool is used as intended or has been adapted; information received from the developer; and whether the organization has a methodology for evaluating tools. That methodology may include asking the developer, reviewing literature, using professional-association information, and analyzing comments or complaints.
Reasonableness is therefore proportional and evidence-based, but it is not permission to do nothing. A large system with data science, legal, equity, and clinical safety teams can be expected to do more than a small practice with limited resources. Every covered entity still needs a process appropriate to its capacity. And the duty is ongoing: a one-time procurement questionnaire may become stale after a model update, a new use, a population change, or a complaint.
What the rule does not require#
The preamble says covered entities are not required to obtain training datasets or all source-attribute information from developers. This recognizes that such information may be unavailable. It does not stop you from requesting it, or from making access a contract condition when that is feasible.
The rule does not require a particular fairness metric. Equal sensitivity, equal false-positive rates, calibration, demographic parity, and equal allocation answer different questions and can conflict. Metric selection should match the clinical decision and legal concern.
The rule also does not prescribe one mitigation. OCR evaluates efforts case by case. Possible actions include replacing a biased equation, changing an input or threshold, and limiting intended use. They include adding review, improving access, and retraining staff. They include monitoring outcomes or discontinuing a tool.
OCR declined to impose strict liability. That does not create a safe harbor for good intentions. It means the inquiry considers conduct, knowledge, reasonableness, mitigation, and facts rather than assigning automatic liability for every unfavorable result.
Why vendor status does not settle the user's duty#
A developer may or may not be a covered entity under Section 1557. If it is covered, it has its own obligations. The user's liability does not depend on whether the developer is also liable.
FDA authorization, when required, answers questions under medical-device law. It does not establish that every local use complies with civil-rights law. Likewise, deployment within certified health information technology may provide useful transparency without proving nondiscrimination.
The federal health IT certification framework for Decision Support Interventions includes source-attribute transparency for predictive interventions and risk-management information for certified modules. These requirements can help a purchaser obtain evidence. They are distinct from Section 1557 and do not cover every tool or organization. So contract language should require enough information to assess risk, notification of material changes, cooperation with incidents and complaints, and access to relevant performance records; a representation that a product is unbiased is too vague to audit.
Build a useful inventory#
Start with your clinical workflows, not only the AI budget. Search electronic health records, imaging systems, and laboratory rules. Search order sets, payer interfaces, and spreadsheets. Search mobile applications and paper protocols. Interview clinical and operational teams about tools that rank, score, recommend, exclude, or prioritize.
For each use, record the product and version, owner, and developer. Record intended purpose, local purpose, and affected population. Record inputs, output, and decision influenced. Record regulatory status, protected variables, customization, evidence, and monitoring.
Assign a risk tier based on consequence, autonomy, scale, reversibility, and affected population; a calculator that supports an easily reviewed low-consequence decision differs from an automated allocation system used across thousands of patients. Then reconcile the inventory after upgrades, contract renewals, new interfaces, and service-line changes, and give staff a simple channel for reporting a tool that is not on the list.
Evaluate local use#
Review whether the validation matches your local population, prevalence, and setting. Check equipment, data definitions, and workflow. A tool can be technically accurate while being used for the wrong purpose or at the wrong threshold.
Examine performance and outcomes across relevant protected groups where lawful and feasible. Use confidence intervals and sample sizes. A small subgroup estimate may be too uncertain to reassure you. Also examine who lacks data and whose cases are excluded from evaluation.
Test workflow factors: whether clinicians see the basis and limits, whether overrides are possible, whether time pressure creates overreliance, and whether patients have a route to question decisions. Monitor allocation and access, not only prediction accuracy.
Document clinical justifications for protected variables. Record residual uncertainty and why the chosen mitigation is proportionate. Legal, clinical, and data perspectives may all be needed. So may disability-access, privacy, and affected-community perspectives.
Monitor, respond, and preserve evidence#
Monitoring should include material errors, overrides, and subgroup performance. It should include allocation outcomes, complaints, appeal results, delayed care, and drift. Set thresholds that trigger investigation, restriction, or suspension.
Complaint channels must be accessible to people with disabilities and limited English proficiency. Frontline staff should know how to preserve the relevant output, input, version, and decision trail without altering the medical record improperly.
When a problem is found, mitigation can include immediate patient correction, wider case review, and workflow change. It can include vendor escalation, updated training, revalidation, notification, or retirement. Record why the response was selected and how effectiveness will be checked. The HHS Office for Civil Rights enforcement process includes complaint investigations and compliance reviews, and the 2024 preamble states that OCR will examine Section 92.210 complaints case by case, including the identification and mitigation efforts taken.
Coordinate the full legal map#
Section 92.210 is one part of the legal environment. Title VI, Section 504, and the Age Discrimination Act may apply. So may HIPAA, state privacy and civil-rights laws, and consumer-protection rules. So may medical-device law, malpractice duties, contract terms, and sector-specific rules.
Litigation or later rulemaking can change interpretation. Organizations should maintain a current legal register, assign counsel to material questions, and distinguish a best practice from a binding requirement.
Do not let legal uncertainty stop basic safety work. Knowing which tools you use, why, with which inputs, and with what effects supports patient care. It supports quality, procurement, cybersecurity, and civil-rights compliance at the same time.
References#
- Current text of 45 CFR 92.210
- HHS 2024 Section 1557 final rule and preamble
- HHS Office for Civil Rights Section 1557 information
- ASTP Decision Support Interventions certification companion guide
- NIST Artificial Intelligence Risk Management Framework 1.0
- Science study of racial bias in a population health algorithm
- HHS Office for Civil Rights compliance and enforcement process
Questions and answers
What does 45 CFR 92.210 prohibit?
It prohibits a covered entity from discriminating on the basis of race, color, national origin, sex, age, or disability through its use of patient care decision-support tools in covered health programs or activities.
Does the rule apply only to artificial intelligence?
No. It covers automated and nonautomated tools used for clinical decision-making, including calculators, equations, guidelines, flowcharts, medical devices, and AI systems that act autonomously or assist people.
Must a covered entity obtain the developer's training dataset?
No. The preamble says the regulation does not require obtaining developer datasets. Available source information, published evidence, complaints, local evaluation, and vendor questions can still form part of reasonable efforts.
Is every use of age, sex, disability, or race in a clinical tool unlawful?
No. The issue is prohibited discrimination; a protected characteristic may have a clinically justified and evidence-based use, but the covered entity still must assess and mitigate relevant risk under the rule.
Does following the rule guarantee legal compliance in every jurisdiction?
No. Other federal and state laws, regulations, contracts, professional duties, and case law may apply. This article is general information, and organizations need current legal advice for their facts.