HTI-5 vs HTI-1: What the Final Rule Changes for Decision Support Intervention Transparency

Where HTI-5 stands relative to HTI-1

HTI-1 introduced the decision support intervention (DSI) criterion at 45 CFR 170.315(b)(11). It required a Health IT Module to let a limited set of identified users access plain language descriptions of source attributes for evidence-based and predictive DSIs that the developer supplies as part of the module. For each such predictive DSI, intervention risk management practices also had to be applied.

The December 2025 HTI-5 proposal set out a broad deregulatory agenda. Of the 60 criteria then in effect, it proposed 34 removals and 7 revisions. The final rule, published October 28, 2026, finalized 14 removals and 7 revisions. The final rule table lists § 170.315(b)(11) as "Revise" and § 170.315(a)(9), Clinical decision support, as "Remove", both effective on the final rule's effective date.

Some older guidance pages still describe HTI-5 in conditional language, as a proposal that "would" make changes. The final rule supersedes that wording, so any internal analysis that treats HTI-5 as pending should be updated.

Requirement-by-requirement comparison

The table separates what the final rule explicitly addresses from what it leaves alone. The calendar effective date should be confirmed in the final rule text before any retirement of controls is scheduled.

• (b)(11)(iv) Source attribute support: HTI-1: module must support source attributes for evidence-based and predictive DSIs. HTI-5: removed.
• (b)(11)(v) Source attribute access and modification: HTI-1: users can access, and authorized users can author or revise, source attribute information. HTI-5: removed.
• (b)(11)(ii)(C) Electronic feedback data: HTI-1: users provide feedback on evidence-based DSIs, exportable in a computable format. HTI-5: ONC did not propose removing it.
• (b)(11)(vi) Intervention risk management: HTI-1: practices applied to each developer-supplied predictive DSI. The December 2025 proposal included its removal. The final rule's explicit removal language describes (iv) and (v).
• (b)(11) overall criterion: HTI-1: DSI criterion with source attribute and risk management components. HTI-5: revised, effective on the final rule's effective date.
• (a)(9) Clinical decision support: HTI-5 final rule table: removed, effective on the final rule's effective date.

Who was responsible, and what shifts

HTI-1 placed its DSI requirements on the Health IT Module and its certified developer, covering DSIs supplied by the developer as part of that module. Developers were not necessarily responsible for the content of every source attribute. They had to support the capability for users to author or revise source attribute information, and they were not responsible for the accuracy or use of information their users modified.

With (iv) and (v) removed, that certified capability disappears. ONC stated that it is not persuaded of the value of the transparency requirements in (b)(11), and that it does not believe removing source attribute access for evidence-based and predictive DSIs will significantly impair the ability to evaluate DSI tools. An organization deploying AI-enabled decision support may reach a different conclusion about its own risk. If so, that position should be documented, along with how the organization intends to obtain the information it needs.

In practice, this makes contract and procurement terms the likely route to equivalent information from developers. Whether a developer continues to provide source attribute or model documentation voluntarily, and on what terms, becomes a commercial and governance question rather than a certification one.

Operational implications for compliance and implementation teams

Start with an inventory of the (b)(11) capabilities in each certified module, including user-facing source attribute screens and the processes built around them. Mark (iv) and (v) as removed, and align retirement timing to the final rule's effective date.

Keep the (b)(11)(ii)(C) feedback and export workflow. That capability lets users provide electronic feedback on evidence-based DSIs and makes the data available for export in a computable format. The minimum data elements are the intervention, the action taken, user feedback where applicable, the user, the date and the location. ONC describes the capability as supporting transparency by enabling providers to share, export and report on DSI performance in real-world settings. As written, it applies to evidence-based DSIs.

Separate regulatory retention from voluntary retention. HTI-5 reduces what the certification criteria require. It does not change what contracts, clinical governance or internal policy may still call for. Records that exist only because a certified screen produced them should be reviewed deliberately, not discarded by default.

Finally, treat any model-level documentation your organization keeps after removal as its own artifact. It will no longer be a certified module output, so ownership, update cadence and review need to be assigned internally.

What runtime enforcement evidence can and cannot contribute

Trussed enforces policy in the execution path of AI systems, across models, agents, tools and MCP servers. Each interaction or tool call can be allowed, redacted or blocked, and enforcement generates audit-ready evidence of what the AI system was permitted to do and what it did. The scope is individual interactions and tool calls, and the evidence is mapped to frameworks including HIPAA and NIST.

That evidence is useful where a compliance team must show how an AI-enabled intervention behaved in production. It is closest in spirit to the interaction-level fields in the retained feedback requirement: what happened, who was involved, when and where. The feedback fields are a floor for data elements, not a mapping to enforcement records, and the two should not be treated as equivalent.

Runtime enforcement evidence does not replace source attribute disclosure or model-level documentation. It does not describe a model's performance, training data or intended use, and it makes no claims about model provenance or lineage. Those remain with the developer and with the organization's own documentation. Runtime evidence and model documentation answer different questions, and a complete record for AI-enabled decision support needs both.