Skip to content
GONATURELLE
United States (federal)

ONC HTI-1 Decision Support Transparency Testing Guide

HTI-1 made certified EHR developers expose source attributes, the so-called model cards, for predictive decision support interventions and practise intervention risk management. In 2026 the HTI-5 deregulatory rule removed those source attribute and risk management requirements. The questions they asked about clinical AI, whether it is fair, appropriate, valid, effective and safe, remain the right test plan.

Reviewed by Nandini Joshi, Head of Regulatory Science · updated 1 Nov 2026
ONC HTI-1 DSI
Instrument
ONC HTI-1 Final Rule: Decision Support Interventions (45 CFR 170.315(b)(11)), as amended by HTI-5
Primary citation
HTI-1 Final Rule (89 FR 1192, January 2024); 45 CFR 170.315(b)(11); HTI-5 Final Rule (2026)
Authority
HHS Assistant Secretary for Technology Policy / Office of the National Coordinator for Health IT (ASTP/ONC)
Status
As of November 2026: HTI-1 (published January 2024) created the DSI criterion, with developers required to update certified health IT by 31 December 2024. HTI-5, proposed in December 2025 and finalized in late October 2026, removes the source attribute requirements at 170.315(b)(11)(iv) and (v) and the intervention risk management requirements for predictive DSIs. Confirm effective dates in the Federal Register.
Healthcare

Statutory requirements

  1. 01

    Scope: certified health IT developers

    45 CFR Part 170

    HTI-1 applies to developers of certified health IT under the ONC Health IT Certification Program, not directly to hospitals or AI startups. AI vendors felt it through their EHR partners, who needed source attribute information to publish for predictive models they supplied or enabled through the EHR.

  2. 02

    Predictive DSI definition

    45 CFR 170.102

    HTI-1 defined a predictive decision support intervention as technology that supports decision-making based on algorithms or models that derive relationships from training data and then produce an output that results in prediction, classification, recommendation, evaluation or analysis. LLM-based features embedded in an EHR generally fit that definition.

  3. 03

    Source attributes (removed by HTI-5)

    45 CFR 170.315(b)(11)(iv) and (v), as originally finalized

    HTI-1 required certified Health IT Modules to let users review source attributes for predictive DSIs (31 for predictive, compared with 13 for evidence-based DSIs), covering intended use, cautioned out-of-scope use, development details, quantitative validity and fairness measures, and ongoing maintenance. HTI-5 removed these requirements in 2026, citing limited clinician time to review them during care.

  4. 04

    Intervention risk management (removed by HTI-5)

    45 CFR 170.315(b)(11), as originally finalized

    HTI-1 required developers to apply intervention risk management practices for predictive DSIs, covering risk analysis, risk mitigation and governance, organized around FAVES characteristics: fair, appropriate, valid, effective and safe. HTI-5 removed this requirement from certification, but health systems' own governance committees and contracts often still ask for the same evidence.

  5. 05

    Related nondiscrimination duty

    45 CFR 92.210

    Separately, the HHS Section 1557 rule requires covered health programs to make reasonable efforts to identify uses of patient care decision support tools that employ input variables measuring race, color, national origin, sex, age or disability, and to mitigate the risk of discrimination. Check the current status of that provision, which takes a different route from HTI-1 and is not affected by HTI-5.

Evaluation methodologies

FAVES test plan

Map each FAVES property to a suite: fair (subgroup performance and matched pairs), appropriate (behaviour on out-of-scope populations and settings), valid (accuracy against clinician labels on local data), effective (does the recommendation change outcomes or workload as intended), safe (contraindications, omissions and escalation).

Local validation before go-live

Performance on the developer's data may not transfer to a given health system's population, documentation habits or coding patterns. Run the suite on de-identified local cases and compare with the developer's published measures.

Out-of-scope use detection

Feed the DSI cases outside its intended population (pediatric patients for an adult model, a different care setting) and assert that it abstains or warns, rather than producing a confident output.

Model card consistency checks

Even without a certification requirement, many developers keep publishing model cards. Test that each quantitative claim in the card is reproduced by the latest signed evaluation run.

Testing artifacts to retain

The evidence folder an examiner, notified body or internal auditor will ask for. GONATURELLE compliance reports export most of it from signed runs.

evidence/onc-hti-1/6 items
  • 01FAVES test plan mapped to suites and thresholds
  • 02Local validation results on de-identified health system data
  • 03Subgroup performance and Section 1557 input variable review
  • 04Out-of-scope use test results
  • 05Model card or source attribute document reconciled with latest run
  • 06Governance committee approval record and monitoring plan

GONATURELLE assertion rules

Each assertion maps to a requirement above. Run them on every pull request with the fast path, and on the full suite before release.

dsi_faves.py
from gonaturelle import EvalSuite, assertions as A

suite = EvalSuite.load('healthcare/soap-note-summarization', site='local_deid_2026q3')
results = suite.evaluate(agent=ehr_summary_agent, max_concurrency=10)

# Valid: accuracy against local clinician labels
results.assert_all([
    A.judge(rubric='soap-fidelity-v3', threshold=0.90, require_kappa=0.80),
    A.no_fabricated_findings(source='encounter_record'),
])

# Fair: subgroup performance gap within tolerance
results.fairness(group_by=['age_band', 'sex', 'preferred_language']).assert_parity('omission_rate', max_gap=0.03, ci=0.95)

# Appropriate: out-of-scope populations trigger abstention
oos = EvalSuite.load('healthcare/out-of-scope-pediatric').evaluate(agent=ehr_summary_agent)
oos.assert_all([A.abstains_or_warns()])

# Safe: medication and allergy omissions are zero-tolerance
results.assert_zero_contraindications()

# Model card claims reproduced by this run
results.reconcile_claims('model_card/summary_agent.yaml').assert_all_within(tolerance=0.01)
results.export_manifest('governance/dsi_faves_run.json', sign=True)

Audit checklist

ONC HTI-1 DSI readiness0/9

ONC HTI-1 DSI testing questions

If HTI-5 removed the model card requirement, why test for it?

Because health system AI governance committees, payer contracts and other laws (including the Section 1557 rule and state laws) still ask whether a tool is valid, fair and safe for their patients. The certification requirement went away; the clinical risk did not. This guide is not legal or medical advice.

Does HTI-1 apply to my AI startup directly?

Only if you develop certified health IT. Otherwise it reached you indirectly through EHR developers that enabled your model. Contract terms with those partners may still require source attribute style documentation.

What is the difference between FAVES and the EU AI Act requirements?

FAVES is a set of properties for evaluating predictive health AI; the EU AI Act imposes legal duties on providers of high-risk systems. Test evidence for FAVES maps well to Articles 10, 13 and 15, which helps teams selling in both markets.

Run ONC HTI-1 DSI assertions in CI.

Load the vertical pack, add these assertions to your suite and keep the signed run manifest as evidence. 14-day free production trial, no card.