EHR Vendor AI Features After HTI-5: Certification Is Narrower, So Verification Is Yours

What HTI-5 changed

HHS/ONC released the HTI-5 final rule on October 26, 2026, and it was published in the Federal Register on October 28, 2026. It is a deregulatory rule that streamlines the ONC Health IT Certification Program. It retains 39 certification criteria without change, including those adopted in HTI-4. Its table of revisions lists decision support interventions, §170.315(b)(11), as revised and clinical decision support, §170.315(a)(9), as removed. Both take effect on the final rule's effective date. Other removals take effect January 1, 2027, and one revision takes effect January 1, 2030.

The revision matters because the 2024 HTI-1 rule set the transparency expectations many health systems have relied on. HTI-1 required source attribute access and predictive DSI risk management practices for developer-supplied DSIs. The December 2025 proposal would have removed the source attribute requirements in (b)(11)(iv) and (v), the predictive DSI risk management requirements in (b)(11)(vi), and the AI model card requirements. Compliance teams should read the final (b)(11) text in the October 28 notice before treating any vendor disclosure as a certification requirement. Until they have done so, the safer assumption is that these disclosures may now be a contractual matter rather than a regulatory one.

Responsibility map: vendor side and health system side

The table separates what certification and vendor disclosures can reasonably provide from what remains with the deploying organization. The vendor column describes the general scope of (b)(11) as ONC has described it. Confirm the details against the final rule.

• Scope of certification: Vendor: (b)(11) attaches to DSIs the developer supplies in its Health IT Module. Health system: identify which AI features are developer-supplied and which are other-party DSIs reaching clinicians through the EHR, since developers are not accountable for source attributes on DSIs they do not supply.
• Transparency documents: Vendor: may provide source or risk information, depending on the final rule and the contract. Health system: treat these as useful but non-dispositive, and secure them contractually.
• Feedback data: Vendor: (b)(11) supports a feedback data capability, exportable in computable format to a limited set of identified users. Health system: this is an export mechanism, not runtime logging of PHI access or AI outputs.
• HIPAA compliance: Vendor: certification to privacy and security criteria is not a guarantee of compliance or an affirmative defense. Health system: remains responsible under the Privacy, Security and Breach Notification Rules.
• Local behavior: Vendor: certification does not require evidence of behavior in your environment. Health system: must establish what PHI is touched, who invokes features and what outputs are delivered.

Where certification stops and HIPAA obligations continue

ONC states in the HTI-5 final rule that adopting certified health IT does not guarantee HIPAA compliance. It is not an affirmative defense, it has not been identified as a mitigating factor for civil money penalties, and it does not exempt a regulated entity from the Privacy, Security or Breach Notification Rules. A vendor's certification status therefore cannot stand in for the health system's own controls.

The most direct pressure point is audit controls under 45 CFR 164.312(b). The standard requires mechanisms that record and examine activity in information systems that contain or use ePHI. The regulated entity uses its risk analysis and organizational factors to decide what is reasonable and appropriate. HITECH makes business associates directly subject to Security Rule requirements, but that does not remove the covered entity's own determinations. A January 2025 proposal to strengthen the Security Rule observed that OCR enforcement experience suggests audit controls compliance could improve with more specificity. For AI features, this means the risk analysis should name them explicitly. Ambient documentation, summarization and predictive tools each create PHI flows and outputs that existing EHR audit logs may not describe in enough detail.

ONC's SAFER guidance adds a governance frame. Developers, EHR vendors and healthcare organizations share responsibility for AI safety in proportion to their ability and resources, and the health system should document its own share.

Questions to put to vendors at procurement and renewal

Because certification now supplies less, the contract carries more of the load. Ask which AI features are developer-supplied predictive DSIs under (b)(11) and which are other-party supplied, and what source and risk management information the vendor provides for each after the HTI-5 revisions. Ask which source attribute, model card or risk management disclosures it will keep providing contractually, whether or not certification still requires them, and how it will notify you of changes.

Then move to behavior in your environment. What PHI does each feature access or transmit? What logs can you export showing which users and workflows invoked it and what output was delivered? Can you configure users, purposes and workflows, and require human approval steps? How is feedback data and any other AI-related audit evidence made available in exportable, computable form? Ask for written answers and attach them to the agreement. Vendor answers that rely only on a certification attestation should be treated as incomplete, because the attestation does not describe runtime behavior.

Runtime enforcement and audit-ready evidence

Even a strong contract produces documents, not records of what happened on a given Tuesday. Evidence of PHI handling, invocation and delivered output has to come from controls on the health system's side. One design option is to enforce policy in the execution path, so each AI interaction or tool call is allowed, redacted, blocked or escalated for human approval before it proceeds, and the decision is recorded as it is made. Enforced at runtime, not reviewed after the fact, the policy decision and its evidence come from the same event.

Trussed provides this kind of policy enforcement in the execution path, with audit-ready evidence mapped to HIPAA, including 164.312(b) audit controls. It runs in production with healthcare organizations, can be self-managed in the customer cloud, and offers configurable retention and data residency. Its scope is individual interactions and tool calls. It does not replace vendor certification or contractual disclosures, and it does not address model provenance or lineage. Features that run entirely inside a vendor's product may not expose a path you can enforce in, which is why the configurable controls and exportable evidence requested above remain part of the contract.