HTI-5 AI Transparency Requirements: What Changed for Health System AI Teams

What HTI-5 actually changed

HTI-5 is the ONC deregulatory rule for the Health IT Certification Program, which HHS describes as voluntary. HHS finalized it on October 26, 2026, and it reduces certification compliance costs for health IT developers. It supersedes the HTI-5 proposed rule.

For AI, the change runs opposite to what many teams expected. The final rule revises the decision support intervention criterion at 170.315(b)(11) and removes the AI model card requirements along with the predictive DSI risk management requirements. It also removes the clinical decision support criterion at 170.315(a)(9) and the security tags criteria at 170.315(b)(7) and (b)(8). Those changes take effect on the rule's effective date. Other removals, including family health history, CQM filter, and several application access and measure calculation criteria, take effect January 1, 2027. The transitions of care revision at (b)(1) takes effect January 1, 2030.

The rule also makes conforming edits to the Conditions and Maintenance of Certification, scales back Real World Testing, and reduces Insights reporting, while keeping the FHIR bulk data access measure. The stated direction is a foundation of FHIR-based APIs for AI-enabled interoperability. Nothing in this material creates runtime PHI handling, per-interaction logging, or tool-call logging requirements.

Common assumptions versus what the rule does

The table separates four assumptions that appear in internal planning documents from what HTI-5 does as of November 2026.

• HTI-5 requires AI transparency artifacts: It removes the model card requirements from the DSI criterion. Model documentation is no longer a certification-level baseline.
• HTI-5 sets AI logging duties for health systems: It changes certification criteria for health IT products and describes burden reduction for developers. It creates no tool-call or per-interaction logging duty.
• HTI-5 defines how AI should handle PHI: It does not. PHI handling for AI remains a matter of your existing HIPAA obligations and internal policy.
• Removal means transparency commitments end: Removal of a federal certification requirement does not retire contractual or internal commitments that referenced model cards or predictive DSI risk management.

How this relates to HIPAA audit controls

The HIPAA Security Rule technical safeguards at 45 CFR 164.312, including the audit controls standard at 164.312(b), are separate from HTI-5. HTI-5 neither replaces them nor addresses them. Teams should map each technical safeguard to AI workflows by reading the current regulatory text directly, then decide what each safeguard means when a model, agent, or coding assistant touches PHI.

That mapping is where most programs have a gap. Model documentation describes a system in general. Conventional logs record that something happened. Neither shows, for a single interaction, what the AI was permitted to do, what PHI it handled, and what action was taken. No regulation reviewed here defines the evidence an auditor would expect for an AI interaction or tool call, so the evidence model is a design choice. Make it deliberately, and make it strong enough to answer those three questions.

Separate the control from the evidence

Logging is a source of evidence, not the control itself. A control decides whether an action proceeds. Evidence records the decision. Reviewing logs after the fact can show that PHI reached a model, but it cannot prevent that. Enforcing policy at runtime changes the sequence: the decision happens before the call proceeds, and the record is a by-product of the decision rather than a reconstruction.

The practical unit is the individual model call or tool call. At that level, a useful record states the policy version applied, the action taken, what was redacted or blocked, and the identity of any human approver. A system that can only report aggregate activity, or that depends on someone reassembling events from separate application logs, will struggle to answer a specific question about a specific interaction.

Where Trussed fits

Trussed enforces policy in the execution path across models, agents, tools, MCP servers, AI sites, and coding assistants, at the level of individual interactions and tool calls. Actions include allow, redact, block, rate limit, and escalate for human approval. Policy is enforced at runtime, not reviewed after the fact, and that enforcement generates audit-ready evidence mapped to HIPAA among other frameworks.

Trussed deploys self-managed in the customer cloud, with configurable retention and data residency. It runs in production with healthcare and pharma organizations and holds SOC 2 Type II, HIPAA, and ISO 27001 attestations, among others. It is not a substitute for the regulatory mapping work described above, which remains your responsibility.