Checklist

    HTI-5 Readiness Checklist for Health System AI Platform Teams: What the Final Rule Changes

    As of November 2026, HTI-5 is a finalized deregulatory rule that streamlines the ONC Health IT Certification Program for developers. It removes the clinical decision support criterion (a)(9) and revises the decision support interventions criterion (b)(11). For a health system AI platform team, readiness means two things: identifying which of your AI systems are certified health IT supplied by a developer, and maintaining HIPAA audit-control evidence for every AI system that handles PHI. The checklist below is organized by control area.

    The checklist by control area

      What HTI-5 changed, and what it did not

      The HTI-5 proposed rule was released on December 22, 2025, and ONC published the final rule overview in October 2026. The rule is described as reducing burden on health IT developers by streamlining the certification program. It also resets the program's regulatory scope as a foundation for future FHIR-based API requirements.

      The changes most relevant to AI teams are in the decision support criteria. The clinical decision support criterion (§ 170.315(a)(9)) is removed, and the decision support interventions criterion (§ 170.315(b)(11)) and safety-enhanced design criterion (§ 170.315(g)(3)) are revised. All three take effect on the final rule's effective date. Separate removals take effect on January 1, 2027: family health history (a)(12), CQM filter (c)(4), patient health information capture (e)(3), automated numerator recording (g)(1) and automated measure calculation (g)(2). The transitions of care (b)(1) revision takes effect on January 1, 2030. ONC also made conforming edits to the Assurances, Application Programming Interfaces and Attestations requirements at §§ 170.402, 170.404 and 170.406.

      HTI-5 is a certification program rule aimed at developers. It should not be read as a new AI mandate on health system platforms. Whether and how it reaches a specific vendor product is a question for your vendor and your counsel.

      Who holds which obligation

      The most common scoping error is assuming a developer obligation belongs to the provider. Separate the actors before working through any control area.

      • Certified health IT developers: Certification criteria, including the removed and revised decision support criteria, and the Conditions and Maintenance of Certification requirements. These sit with the developer of the certified product.
      • Covered entities and business associates: The HIPAA Security Rule technical safeguards at 45 CFR 164.312, including audit controls. This applies to your organization, or to the business associates acting for it, whether or not a product is certified.
      • Your AI platform team: Evidence that internally built and operated AI systems that touch PHI are controlled and auditable. This follows from your HIPAA position and internal policy, not from a new HTI-5 requirement.

      Where runtime enforcement produces audit-ready evidence

      Pre-deployment review documents intent. It does not show what a system did on a given Tuesday with a given patient record in context. Audit controls under 164.312 call for records of activity in systems that handle PHI, so the question for AI is whether you can show, per interaction, what policy applied and what happened.

      Enforcing policy inside the execution path addresses this directly. When each interaction or tool call is evaluated at runtime and resolved as allow, redact, block, rate limit or escalate for human approval, the decision itself becomes the record. Evidence is then a by-product of enforcement, not something reconstructed later from separate systems.

      Trussed works this way. It enforces policy in the execution path across models, agents, tools, MCP servers, AI sites and coding assistants, and generates continuous audit-ready evidence mapped to HIPAA, among other frameworks. It can be self-managed in your own cloud, with configurable retention and data residency, and it runs in production with healthcare organizations. Its scope is individual interactions and tool calls. It does not provide model provenance or end-to-end tracing of agentic workflows, so those questions need other controls in your estate.

      Planning dates and an optional testing item

      Plan against the dates that are fixed: the January 1, 2027 removals and the January 1, 2030 transitions of care revision. Date the (a)(9) removal and the (b)(11) and (g)(3) revisions from the final rule's effective date, and ask each developer how those changes affect the products you license.

      Separately, the January 2025 HIPAA Security Rule proposal would emphasize technical controls, defined as mechanisms implemented and executed primarily by the system, and would require reviewing and testing them at least every six months or on operational change. As of November 2026 it should be treated as a proposal, not current law. If you want to be ready for it, add an optional seventh check: periodically test that runtime policies block, redact and escalate as intended, and keep the test results alongside the evidence from item 5.

      A practical order of work is to complete the inventory first, since it determines which obligations apply. Then confirm that policies are enforceable, and then confirm that you can produce an evidence export on request.

      Checklist control areas

      AI inventory and scope

      Which systems are certified health IT and which are internal.

      Policy definition

      Rules written so they can be enforced, not only documented.

      PHI handling at runtime

      Allow, redact or block at the point of each interaction.

      Human approval

      Escalation for consequential actions.

      Evidence and retention

      Records that answer an audit control request.

      Data residency

      Where evidence and processing live.

      Check your AI estate against the list

      Talk through your inventory, PHI handling and evidence requirements with a Trussed expert, and see how runtime enforcement produces audit-ready evidence.

      Talk to an Expert
      Next step

      How does your AI governance program compare?

      See where your program has gaps in less than 2 minutes.