HTI-5 and Decision Support Intervention Source Attributes: What Was Removed and What Health Systems Should Keep

What the HTI-5 final rule changes

HTI-1 introduced the decision support intervention (DSI) criterion in 45 CFR 170.315(b)(11), effective March 11, 2024. Its source attribute provisions required certified Health IT Modules to support categories of technical performance and quality information for both evidence-based and predictive DSIs. ONC described these attributes as supporting model cards for predictive DSIs. They work like nutrition labels, covering how an algorithm was trained, its intended use and limitations, and how it performs across patient groups.

The HTI-5 final rule reduces the scope of that criterion. It fully removes the model card requirements in (b)(11)(iv), source attribute support, and (b)(11)(v), source attribute access and modification. The final rule table lists (b)(11) as "Revise" and lists the legacy clinical decision support criterion in 170.315(a)(9) as "Remove". Both take effect on the effective date of the final rule.

The stated rationale is reduced burden and support for innovation. ONC materials note that developers report limited clinician time and technical capacity to use source attributes during care. The wider rule finalized removal of 14 certification criteria and revision of seven, narrower than the proposal, which would have removed 34 of the 60 criteria then in effect.

What was removed, revised and left alone

The distinction matters because teams often map one control set to the whole criterion. Treat each paragraph separately.

• (b)(11)(iv) source attribute support: Removed. Certified modules are no longer required to support source attribute fields for evidence-based and predictive DSIs.
• (b)(11)(v) source attribute access and modification: Removed. The requirement for identified users to access, record and change source attributes no longer applies.
• (b)(11) as a criterion: Revised, not deleted. Do not retire DSI procedures on the assumption that the criterion is gone.
• (a)(9) clinical decision support: Removed. Keep its mapping separate from (b)(11) when updating certification-dependent procedures.
• HTI-1 source attribute provisions: In effect from March 11, 2024, and superseded by HTI-5 as to (b)(11)(iv) and (v).

Developer obligations versus health system responsibilities

Certification criteria apply to certified health IT. The Health IT Certification Program is voluntary, and the obligations in (b)(11) are framed around certified health IT developers and their modules. Before HTI-5, modules had to support source attribute fields, but developers were not necessarily responsible for the content of each attribute. Developers also carried an ongoing Maintenance of Certification duty under 45 CFR 170.402(b)(4) to review and update source attribute information and related summary information. With (iv) and (v) removed, the certification requirement that drove those fields no longer applies.

For health systems, the practical consequence is an inference rather than a rule: if certified modules no longer have to provide source attribute fields, you cannot assume the EHR will hold or maintain model-card-style records. Whatever you want to keep about an AI-enabled tool may need to live in an internal system of record.

Two scoping questions follow. First, which of your AI-enabled tools are certified DSIs, and which are non-certified or internally built tools that (b)(11) never covered? Controls for the second group were never a certification matter, so HTI-5 does not change them. Second, which obligations on your tools come from outside the certification program, such as HIPAA? Those are not created by the certification criteria, and HTI-5 does not amend them.

What to keep, and why

A deregulatory change removes a requirement on developers. It does not answer the questions a clinical governance committee, an auditor or an incident review will still ask about a tool in use. Where did the tool come from? What is it intended to do, and what are its known limits? How does it perform across the patient populations you serve? Who can use it, and what happened when they did? Source attributes were one way to answer these. Once vendors are no longer required to supply them, the answers become your responsibility to collect or to request contractually.

The risk management side of the criterion deserves the same treatment. HTI-5 removes the source attribute paragraphs, and the intervention risk management practices are not among them. More importantly, a practice of identifying, assessing and monitoring risk for AI-enabled tools is operational hygiene whichever rule first prompted it.

There is a real tradeoff. Records maintained only to mirror a vendor's field layout, or only to satisfy a certification mapping, carry maintenance cost and little value. Retire those deliberately. Keep records that support intended-use decisions, performance review and access oversight, and assign each an owner. These are internal governance choices, and you can size them to the risk of each tool.

Where runtime enforcement fits

Source and intended-use records describe what a tool is meant to do. They do not show what it did. HIPAA audit controls under 164.312(b) apply regardless of any certification criterion, so health systems need evidence of actual activity on AI-enabled tools, not only documentation of design. That evidence is more reliable when it is produced by the control itself rather than assembled after the fact.

Trussed enforces policy in the execution path for AI interactions and tool calls across models, agents, tools and MCP servers. Policy is enforced at runtime, not reviewed after the fact: each interaction is allowed, redacted or blocked, and that enforcement generates audit-ready evidence mapped to HIPAA. Trussed runs in production with healthcare and pharma organizations. It is not a certification mechanism, and nothing here is a claim about HTI-5 certification. It addresses the layer that stays in force whichever way certification requirements move: a record of what your AI was allowed to do and what it did.