HTI-1 Applicability to Health Systems vs. Certified EHR Developers, Updated for the HTI-5 Final Rule

What changed since HTI-1: HTI-5 is now final

HTI-1 was published in the Federal Register on January 9, 2024 and took effect on March 11, 2024. It updated the ONC Health IT Certification Program, set transparency requirements for AI and other predictive algorithms that are part of certified health IT, and revised information blocking definitions and exceptions, including a new exception supporting exchange under TEFCA. It also adopts USCDI v3 as the Certification Program baseline on January 1, 2026.

HTI-5, titled ONC Deregulatory Actions to Unleash Prosperity, was proposed on June 9, 2026 and finalized on October 26, 2026. It is described as reducing administrative burden for health IT developers in the Certification Program, which is voluntary. In the final rule's criteria table, clinical decision support (§ 170.315(a)(9)) is removed and decision support interventions (§ 170.315(b)(11)) is revised, both effective on the final rule's effective date. Other changes follow later: removal of automated numerator recording and automated measure calculation on January 1, 2027, and a revision to transitions of care (§ 170.315(b)(1)) on January 1, 2030.

HTI-5 therefore amends HTI-1-era criteria. It is not a new set of duties aimed at health systems.

Obligations by regulated party

The table separates direct duties from indirect effects. A health system can hold more than one role, so it should be read per role rather than per organization.

• Certified health IT developers: direct: Certification Program criteria and updates, including HTI-1 transparency for AI and predictive algorithms that are part of certified health IT, and the HTI-5 removals and revisions. Also information blocking, under a 'know, or should know' standard. ONC can treat information blocking claims against these developers as possible Certification Program non-conformities. Civil monetary penalties of up to $1 million per violation are listed for them.
• Health systems and providers: direct: Information blocking as a provider actor. The standard is knowing that a practice is unreasonable and likely to interfere with access, exchange or use of EHI. HHS OIG can investigate claims against providers.
• Health systems: indirect: Developer-side requirements shape the certified capabilities a health system deploys, such as decision support interventions. The effect arrives through the product, not through a rule addressed to the provider.
• Health systems that offer certified health IT: A health system is treated as a developer of certified health IT only if it offers health IT with certified Health IT Modules. A provider that self-develops health IT not offered to others is excluded from that definition.
• HIEs and HINs: Covered by information blocking alongside providers and developers, with a 'know, or should know' standard and listed penalties of up to $1 million per violation.

Information blocking: the direct provider obligation

Information blocking is the clearest place where a health system is a regulated party in its own right. The Cures Act framework applies to healthcare providers, certified health IT developers and HIEs/HINs, but the knowledge standards differ. Developers and HIEs/HINs are held to 'know, or should know'. Providers are held to the narrower standard of knowing the practice is unreasonable and likely to interfere with access, exchange or use of EHI. Policies and training written for a health system should not borrow developer-style 'should know' language.

Enforcement paths also differ. ONC can review claims against certified developers as possible non-conformities in the Certification Program, while HHS OIG can investigate claims against all actor types, providers included.

The HTI-5 proposal also contained language that would make the definitions of 'access' and 'use' in § 171.102 include automated means, including autonomous AI systems. That language matters operationally. If an AI agent or tool call retrieves or exchanges EHI on the health system's behalf, the question of whether a practice interferes with access, exchange or use can arise in an automated setting as well as a human one.

The boundary: certified technology and decision support interventions

HTI-1's algorithm transparency requirements attach to AI and predictive algorithms that are part of certified health IT. They are Certification Program requirements, so the party that must meet them is the developer whose Health IT Module is certified. A health system benefits from that transparency and depends on it, but the requirement itself is not addressed to the provider.

Two practical points follow. First, Health IT Modules are not required to certify to every criterion, so whether a given update matters depends on what each deployed module is certified to. A system running several modules may see HTI-5 changes affect some and not others. Second, the (b)(11) revision means the decision support intervention capability a vendor ships may change. Health systems should ask vendors how the revision alters the capability and the transparency information that accompanies it.

The certification rules, as they apply to developers, do not turn into a direct duty on the health system to evaluate, configure or monitor predictive decision support. Where a health system chooses to review model attributes, restrict use cases or monitor performance, those are internal governance decisions, or arise under other law. Documenting them as organizational controls, rather than as HTI-1 or HTI-5 mandates, keeps the compliance record accurate.

Where AI use remains the health system's own responsibility

Certification criteria describe what certified health IT must do. They do not govern every AI tool a health system uses. Clinical documentation assistants, administrative automation, coding assistants and internal agents that call tools or query records may sit outside any certified module. For these, the health system decides what the AI may access, what PHI may leave the boundary, and what record exists afterward.

HIPAA is the relevant framework for that work. PHI handling rules apply to AI interactions as they do to any other system, and the audit controls standard at 164.312(b) calls for mechanisms that record and examine activity in systems that contain or use PHI. A developer's certified transparency disclosures do not satisfy those obligations for the health system's own deployments.

This is the narrow area where runtime policy enforcement is relevant. Trussed enforces policy in the execution path of individual AI interactions and tool calls, with allow, redact and block outcomes, and produces audit-ready evidence mapped to HIPAA. It runs in production with healthcare organizations. It is not a substitute for certification requirements and does not address them. Its relevance is the AI use that certification does not reach, where an auditor will ask what the AI was permitted to do and what it did.