What Is HTI-1 and How Does It Regulate AI Used in Clinical Decision Support?

TL;DR

• HTI-1 is ONC's (now ASTP's) 2023 final rule, "Health Data, Technology, and Interoperability: Certification Program Updates, Algorithm Transparency, and Information Sharing." It adds transparency requirements for AI-driven clinical decision support, formally called "predictive decision support interventions" (predictive DSIs).
• The rule replaces the old CDS certification criterion, 170.315(a)(9), with 170.315(b)(11), "Decision Support Intervention." Certified health IT developers must now publish "source attributes" describing how a predictive tool was built, trained, validated, and monitored.
• Deterministic, rule-based alerts (drug-drug interaction checks, fixed dosing reminders) generally sit outside the predictive DSI definition. Models that generate risk scores, predictions, or classifications are the target.
• Whether ambient scribes and AI documentation tools are covered depends on whether any part of their output functions as an inference or recommendation, not pure transcription. This is the area where we've seen the most vendor confusion in practice.
• Compliance obligations fall on certified health IT developers, but clinics feel it downstream through in-product disclosure links and vendor attestations.
• Practical move for IT administrators: inventory every AI-driven feature in your EHR stack now, using a specific three-question test (below), rather than waiting for a vendor notice.

What Is HTI-1?

HTI-1 is ONC's final rule, published in December 2023, updating the ONC Health IT Certification Program. The part drawing the most attention from health IT teams is its algorithm transparency framework.

Before HTI-1, certified EHRs met a generic CDS certification criterion, 170.315(a)(9), covering things like configurable alerts and links to reference information. It said nothing about how an underlying algorithm was built or validated. As machine learning models spread through EHR features, ONC's stated rationale was that clinicians and administrators had no reliable way to know what a given predictive tool was trained on or how it performed across different patient populations.

HTI-1 replaces that criterion with 170.315(b)(11). This introduces the predictive DSI concept and requires certified developers to make a defined set of disclosures, called source attributes, available to users and the public. ONC's rule preamble frames the underlying goal as letting users judge whether a tool is valid, reliable, and fit for a specific clinical use, not simply whether it exists.

One naming note: ONC became the Assistant Secretary for Technology Policy (ASTP) in 2024, so current guidance appears under both names. The substance of the requirement hasn't changed.

Which AI Tools Does HTI-1 Actually Regulate?

A predictive DSI is technology that derives relationships from training data and produces an output, such as a prediction, classification, recommendation, evaluation, or analysis, meant to inform a clinical decision.

Three categories tend to fall inside scope: risk stratification and prediction models (sepsis risk, readmission risk, deterioration indices, no-show prediction), machine-learning-based diagnostic support (pattern-flagging across labs, imaging, or clinical text), and any CDS feature where the logic was learned from data rather than explicitly coded.

What generally falls outside: deterministic alerts driven by a hard-coded interaction table, fixed-threshold reminders (an A1c-due alert triggered by a calendar rule), and reference lookups that link a code to a guideline without generating a prediction.

A three-question test we use with clients evaluating a specific feature:

1. Does the output involve a probability, classification, or recommendation that goes beyond what was directly entered?
2. Was the underlying logic learned from data, rather than authored by a human as a fixed rule?
3. Is the output intended to inform a clinical decision, not just document one that already happened?

If the answer to all three is yes, treat the feature as a predictive DSI until your vendor tells you otherwise in writing. If the answer to any is clearly no, it's very likely outside scope, even if marketing copy calls it "AI-powered."

The edge case that trips up most teams isn't the obvious risk score. It's a feature that started as a documented convenience (auto-suggesting a next appointment, flagging a coding gap) and quietly picked up predictive behavior in a later release without anyone re-running the DSI test.

What Are Source Attributes and What Must Vendors Disclose?

Source attributes are the categories of information certified developers must document for every predictive DSI, grouped roughly into six areas under 170.315(b)(11): developer information (including funding sources and conflicts of interest), intervention details (intended use and population), training data description, development process (variables used, exclusions), validation and performance (ideally broken out by demographic subgroup, since aggregate performance can mask subgroup underperformance), and ongoing maintenance (monitoring cadence, retraining triggers).

Developers must publish this both publicly (typically a web page) and inside the product, reachable at the point of use.

In practice, disclosure quality varies enormously. Published evaluations of AI-based clinical decision support, including analyses that have appeared in JAMA, consistently flag the same pattern outside HTI-1 specifically: subgroup performance data, when published at all, is often too coarse, or based on too small a sample, to say anything meaningful about how a model performs for patients outside the majority training population. A source attribute page that says "trained on a large, diverse dataset" without numbers is not meeting the intent of the rule, even if it technically exists.

Does HTI-1 Apply to AI-Assisted Documentation Tools Like Ambient Scribes?

It depends on what the tool does with its output, and this is the area we get the most direct questions about.

Pure transcription and structuring, converting speech to a formatted note without generating a prediction or recommendation, generally does not meet the predictive DSI definition. It's a documentation aid, not a decision support intervention.

The line blurs the moment a scribe starts:

• Suggesting a diagnosis or problem-list entry inferred from the conversation, rather than transcribing what was said.
• Flagging a probable condition the clinician didn't state explicitly.
• Suggesting an E/M billing level based on inferred complexity rather than documented elements alone.
• Auto-populating orders or a differential based on inferred patterns.

Once any part of the output is an inference intended to inform a decision, that feature looks like a predictive DSI, even bundled inside a scribe. This is the gap we see most often in vendor compliance work: teams treat the scribe as a single product with a single disclosure, when the rule cares about the specific feature producing the specific output. A vendor that publishes one blanket "our AI is trained responsibly" statement for an entire scribe product, while quietly shipping a diagnosis-suggestion feature inside it, has not done the compliance work for that feature.

When evaluating any ambient documentation tool, ask directly: does any part of this output function as a prediction or recommendation, and if so, where is the source attribute disclosure for that specific feature? A vendor that can't answer with specifics hasn't finished the work.

What's the Compliance Timeline for Developers and Providers?

Certified developers carry most of the direct compliance burden. HTI-1 set an original target for certified developers to meet 170.315(b)(11), including source attribute disclosures, by the end of 2024, with providers expected to be able to rely on those disclosures starting in early 2025. ASTP has continued issuing clarifying FAQs on HealthIT.gov and, in places, enforcement discretion as vendors work through implementation, so exact sub-requirement dates have shifted since the rule finalized.

Rather than anchoring to a specific date from any single source, including this one, check your EHR vendor's own compliance attestation and ASTP's current published guidance directly. What matters operationally is less the exact date and more the fact that this obligation flows through your certified EHR vendor, not something your clinic independently attests to. Your job is to confirm your vendor has a specific answer, not a generic one, for each AI feature you actually use.

How Should IT Administrators Prepare Their Organization?

Start with an inventory, not a legal review. List every feature in your EHR and any bolt-on tools that generates a prediction, risk score, flag, or recommendation, and separate that from features that are purely rule-based or purely transcription-based.

A recurring failure mode worth naming: third-party AI tools integrated into a certified EHR via API sometimes don't get carried into the platform's top-level source attribute disclosures at all. The certified developer's compliance obligation is real, but the disclosure can end up buried, incomplete, or absent for the bolt-on piece specifically. If your EHR integrates outside AI tools, ask separately about each one; don't assume the platform-level disclosure covers it.

For endocrinology and primary care specifically, look closely at:

• CGM trend interpretation tools that flag patterns or predict glycemic events. The ADA's Standards of Care has increasingly addressed decision-support tools in diabetes technology (its diabetes technology sections have expanded in recent editions), though it does not yet mandate anything as specific as HTI-1's source attributes, which makes vendor self-disclosure the only real check right now.

-