HTI-2: What Was Finalised, What Was Withdrawn, and What It Means

Most people searching for HTI-2 are looking for the August 2024 proposed rule, which was a sprawling document covering patient engagement, information sharing, public health interoperability, electronic prior authorisation and much else. That is not what was finalised.

The HTI-2 final rule, published December 16, 2024 at 89 FR 101772 and effective January 15, 2025, finalises only the Trusted Exchange Framework and Common Agreement provisions. Specifically it creates a new part of the Code of Federal Regulations for TEFCA at 45 CFR Part 172, implementing section 3001(c)(9) of the Public Health Service Act as added by the Cures Act, adopts the TEFCA related definitions as proposed, and amends the information blocking regulations to include definitions tied to the TEFCA Manner Exception. ASTP/ONC has been explicit that it made no changes to the TEFCA Manner Exception itself at 45 CFR 171.403.

If you came here expecting the patient engagement or public health provisions, they are not in this rule. Some became HTI-3 and HTI-4. The rest were withdrawn. The next section maps it.

ASTP/ONC broke the proposal apart and finalised it in fragments across three vehicles, then withdrew the remainder. Here is the whole HTI series as it stands in 2026.

The pattern is worth naming because it will repeat. Health IT policy is increasingly finalised inside CMS payment rules rather than standalone ONC rulemakings, and it is increasingly deregulatory. If your compliance calendar only watches for rules with ONC on the masthead, you will miss things.

They regulate different objects. HTI-1 regulates what a certified product must disclose and do, including the algorithm transparency requirements that are the main reason a health system's AI committee cares about the HTI series at all. HTI-2 regulates the rules of a network, TEFCA, and the definitions that surround it.

Put concretely: HTI-1 is the rule that lets a clinical informatics lead demand 31 structured attributes about a sepsis model shipped inside their EHR. HTI-2 is the rule that formalises how a Qualified Health Information Network operates and what the associated information blocking definitions mean. Nothing in HTI-2 says anything about a model, a prediction or an AI agent.

That distinction matters at procurement. Vendors occasionally describe themselves as HTI compliant without saying which rule. There is no such thing as being compliant with the HTI series as a whole. Ask which criterion, in which rule, and whether the product is listed on the Certified Health IT Product List. If the answer is vague, it usually means the product is not certified to anything and does not need to be, which is a legitimate position that should simply be stated plainly.

Usually not directly, and occasionally a great deal. TEFCA is a nationwide framework for exchanging electronic health information between networks. Your agent almost certainly does not join it. What TEFCA affects is the quality and breadth of the record your agent reads from.

Two situations make it operationally relevant. The first is care coordination and referral workflows where an agent is assembling an external record before a visit. If your organisation participates in a Qualified Health Information Network, the agent sees more history, and the completeness of what it sees becomes a clinical safety question rather than an IT one. The second is any agent that responds to an external request for information. The HTI-2 final rule added information blocking definitions tied to the TEFCA Manner Exception, so how a request arrives can affect how you are permitted to respond to it.

Neither situation puts an obligation on the AI vendor. Both put one on you. If an agent is in the path of a data release decision, the information blocking analysis is yours, and it is not a decision to automate without a documented policy behind it. That is a governance question, and we treat it as one in the deployment roadmap.

Information blocking is a practice by an actor that is likely to interfere with the access, exchange or use of electronic health information, except as required by law or covered by an exception in 45 CFR Part 171. The Cures Act applies it to health care providers, health IT developers of certified health IT, and health information networks and exchanges. Exceptions are voluntary safe harbours: meeting one means the practice is not information blocking, and failing to meet one does not automatically mean it is, since practices are assessed case by case.

Three failure modes show up in real agent deployments.

• Delay dressed as workflow. An agent that queues a records request for human review, indefinitely, is a delay. Whether it is information blocking depends on the reason and whether an exception applies. Design a service level into the workflow and record it.
• Over-broad withholding. An agent applying a blanket rule to sensitive categories may be reaching further than the Privacy Exception at 45 CFR 171.202 supports. HTI-3 revised that exception and the Infeasibility Exception at 171.204, and added a Protecting Care Access Exception at 171.206 with a definition of reproductive health care at 171.102. If your suppression logic predates December 2024, it predates the current text.
• Silent failures. An agent that drops requests it cannot parse, without alerting anyone, produces interference nobody chose. Log every declined or unhandled request and review the log.

None of this is exotic. It is the ordinary discipline of writing down what the automation does and why, which is the same discipline HIPAA already asks for.

Set the TEFCA material aside and the practically useful part of this rulemaking cluster is the certification criteria your EHR has to support, because those are what your agent integrates against.

Standardised API for patient and population services, 45 CFR 170.315(g)(10). This is the FHIR based API criterion that most third party integrations depend on, and it was one of the fifteen criteria with a revised version due on January 1, 2026, softened by enforcement discretion to February 28, 2026. When a vendor tells you an integration is not yet available, the useful follow up is which version of (g)(10) their EHR is currently certified to.

Electronic prior authorisation criteria from HTI-4. Effective October 1, 2025, these are the first federal certification criteria covering electronic prior authorisation, along with related API criteria and standards adopted for HHS use to support exchange of clinical and administrative information with payers. They are the provider side counterpart to the payer side obligations in the CMS prior authorisation rule, and they matter a great deal to anyone building prior authorisation automation or denial management workflows.

USCDI version 3. It became the certification program baseline on January 1, 2026. If an agent depends on data elements that only exist in a later USCDI version, that is a gap to confirm rather than assume, and it is worth checking against your specific product on the Certified Health IT Product List rather than against the vendor's marketing page.

HTI-5 was published on December 29, 2025 at 90 FR 60970 as Health Data, Technology, and Interoperability: ASTP/ONC Deregulatory Actions To Unleash Prosperity, framed against Executive Order 14192 on deregulation and Executive Order 14267 on anti-competitive regulatory barriers. ASTP/ONC describes three aims: reduce burden by removing redundant certification requirements, revise definitions so that patient access to data is not blocked, and advance a foundation of AI-enabled interoperability through modernised standards and certification. It would also reset the program's regulatory scope to make room for future FHIR based API requirements.

The provision most relevant to AI programmes is the proposed reduction in scope of the decision support interventions criterion, which ASTP/ONC's own materials describe as removing the AI model card requirements. If finalised as proposed, the structured transparency that HTI-1 currently forces out of EHR vendors would become voluntary.

Our advice is unchanged by the uncertainty, which is rather the point. Write the model documentation you need into vendor contracts, keep your own inventory, and do not treat a certification criterion as a substitute for either. Organisations that did that are indifferent to the outcome. Organisations that relied on the criterion are exposed to it. The governance and compliance engagement exists precisely to move an organisation from the second position to the first.

There is no HTI-2 compliance deadline for a provider organisation. There is a short list of things worth confirming.

1. Stop planning against the 2024 proposal. Anything in the HTI-2 proposed rule that is not in HTI-2, HTI-3 or HTI-4 was withdrawn on December 29, 2025.
2. Confirm which (g)(10) version your EHR is certified to and whether the January 2026 update landed. Ask for the Certified Health IT Product List entry, not a verbal assurance.
3. Check whether your EHR is certified to the HTI-4 electronic prior authorisation criteria. If you are building payer facing automation, this determines what you can do natively and what needs a workaround.
4. Review your information blocking policies against the post-HTI-3 text. The Privacy and Infeasibility exceptions were revised and the Protecting Care Access Exception was added in December 2024.
5. Map every agent that sits in a release-of-information path and give each one an owner, a logged decline path and a service level.
6. Watch HTI-5. It was still pending as of early August 2026 and would change what your vendor has to disclose about its models.

Steps two to five are the ones that surface real problems, and they usually surface them in a hospital or group practice as a mismatch between what the workflow does and what the written policy says it does. If you would rather find that in an assessment than in an audit, that is what the AI readiness audit is for.