HTI-5 timeline: what the final rule means for health system AI teams

What changed: HTI-5 moved from proposed to final

Planning documents written before October 2026 often describe HTI-5 as a proposed rule with a pending comment period and an uncertain outcome. That framing is outdated. HHS and ASTP/ONC announced the proposed rule, titled ONC Deregulatory Actions to Unleash Prosperity, on June 9, 2026. The announcement framed it as carrying out Executive Order 14192 and supporting U.S. AI leadership, and it provided for a 60-day public comment period starting at Federal Register publication.

On October 26, 2026, HHS announced the final rule. It is described as streamlining the ONC Health IT Certification Program and reducing burden on health IT developers. The final rule overview and the table of removals and revisions carry the same October 26 date, and ASTP/ONC scheduled a final rule information session for October 29, 2026.

For an AI team, the practical consequence is that provisions you may have tracked as proposals are now either finalized or no longer in play. The comment-period milestone is closed. The work that remains is tracking effective dates and understanding how vendors will change their certified products.

HTI-5 milestones and adjacent dates to track

The dates below fall into separate tracks. Keep them separate in your plan, because they have different triggers and affect different criteria.

• January 9, 2024 and March 11, 2024: HTI-1 baseline: The HTI-1 Final Rule was published in the Federal Register on January 9, 2024, with an effective date updated to March 11, 2024. It remains the reference point for existing decision support intervention obligations.
• June 9, 2026: HTI-5 proposed rule announced: Public comment ran 60 days from Federal Register publication. This milestone is now historical.
• October 26, 2026: HTI-5 final rule announced: The overview and the removals and revisions table are dated this day. An information session followed on October 29, 2026.
• Final rule's effective date: Clinical decision support §170.315(a)(9) is removed. Decision support interventions §170.315(b)(11) and safety-enhanced design §170.315(g)(3) are revised.
• January 1, 2027: further removals: Family health history (a)(12), clinical quality measures filter (c)(4), patient health information capture (e)(3), automated numerator recording (g)(1) and automated measure calculation (g)(2).
• January 1, 2030: transitions of care: The revision to transitions of care §170.315(b)(1) takes effect.

Developer obligations, deployer consequences, and the HTI-1 interaction

The HTI-5 table covers ONC certification criteria under 45 CFR 170.315. Those are obligations of certified health IT developers. The final rule materials establish developer-facing certification changes and do not state a new duty for health system deployers. A health system therefore experiences HTI-5 mostly through what its EHR vendor chooses to build, keep, change or retire.

Two criteria matter most for AI teams. Removal of §170.315(a)(9) changes the baseline clinical decision support functionality in certified products. Revision of §170.315(b)(11), the decision support interventions criterion introduced under HTI-1 for predictive decision support, means the vendor-supplied transparency features your teams may rely on can change. Do not assume that source attribute and transparency information available today will look the same after the effective date. Confirm with each vendor what changes in its product and when.

This is also the main tradeoff to manage. Relying on a vendor's built-in decision support transparency is efficient while those features are stable. When the underlying certification criterion is revised, that dependency becomes a planning risk. Controls that sit on the deployer side, at the point where requests and outputs pass through, do not depend on which criteria HTI-5 retains. That is a design observation, not a regulatory requirement.

Map each milestone to a workstream

Sequence work by dependency rather than by date alone. The first two workstreams respond to HTI-5 directly. The last two should not wait on it.

• AI use inventory: List every AI-enabled tool and tag it by whether it relies on a criterion that HTI-5 removes or revises: (a)(9), (b)(11) or (g)(3). Complete this before the final rule's effective date.
• Vendor and certified health IT dependency review: Ask each EHR vendor how decision support and DSI features will change, whether DSI transparency information continues, and how its roadmap handles the January 1, 2027 removals and the 2030 transitions of care revision.
• Runtime policy enforcement: Define what each AI tool may do with PHI and which actions need human approval. Implement this independently of vendor certification status.
• Evidence retention: Record the policy in force, the action taken and a timestamp for each AI interaction, and agree retention periods with compliance. Treat this as a standing HIPAA-driven workstream, not an HTI-5 deliverable.

Governance: keep sources, dates and obligations separate

The status of HTI-5 changed from proposed to final inside a five-month window. A version log of regulatory sources protects against acting on stale guidance. Assign an owner for the final rule text, ASTP/ONC information session materials and any later ASTP/ONC guidance, and record when each was last reviewed. Write dates in internal documents with an explicit as-of statement, such as as of November 2026.

Keep HIPAA obligations on their own track. HTI-5 changes certification criteria for developers, and nothing in the final rule materials ties HIPAA Security Rule duties to HTI-5 milestones. The audit controls standard at 45 CFR 164.312(b) requires mechanisms that record and examine activity in systems that contain or use electronic PHI. Whether and how AI interactions fall within your audit control scope is a determination for your compliance and privacy teams, and it applies regardless of how the certification criteria change.

Finally, avoid language that implies any tool delivers HTI-5 or HIPAA compliance or certification. Describe controls and evidence as supporting readiness. Compliance determinations remain with the organization and its counsel.

Where runtime enforcement and audit-ready evidence fit

Teams that can answer one question for any AI interaction are better placed when vendor features shift: what policy applied, what action was taken, and who approved it. That requires enforcement and evidence capture in the execution path, not reconstruction after the fact.

Trussed is runtime control and evidence infrastructure for regulated enterprises, and it runs in production with healthcare organizations. It enforces policy in the execution path on individual interactions and tool calls: allow, redact, block, or escalate for human approval. That enforcement generates continuous audit-ready evidence mapped to HIPAA, including 164.312(b) audit controls. It can be self-managed in the customer cloud, with configurable retention and data residency.

This supports readiness. It is not a certification, and it does not guarantee HTI-5 or HIPAA compliance. It also does not address model provenance, lineage or end-to-end tracing of agentic workflows.