HIPAA AI Evidence Binder for Health Systems: What to Keep Per Requirement, and Where HTI-5 Fits

What changed with HTI-5, and why it matters for the binder

Many health system binders treat HTI-5 as a source of AI evidence obligations. That premise is outdated. HTI-5 is a deregulatory rule. ONC describes the final rule, announced in late October 2026, as removing and revising certification requirements to reduce compliance costs for health IT developers. The earlier proposed rule would have removed 34 of the 60 certification criteria and revised seven. One proposed revision would have narrowed the decision support intervention (DSI) criterion to fully remove the AI model card requirements.

The practical consequence is about who holds the obligation. The DSI requirements are placed on certified Health IT Modules and their developers. For a health system, HTI-5 evidence is mostly the documentation its certified-product vendors supply, plus its own record of which AI tools fall under the Predictive DSI definition at 45 CFR 170.102: technology that uses algorithms or models derived from training data to produce a prediction, classification, recommendation, evaluation, or analysis. Do not build the binder around model card requirements. Build it around what each AI system was permitted to do and what it did.

On the HIPAA side, HHS stated in its January 2025 Security Rule proposal that ePHI in AI training data, prediction models, and algorithm data held by a regulated entity for covered functions is protected by the HIPAA Rules. That proposal has not been shown to be final, so treat it as a signal of enforcement direction rather than a current requirement.

Requirement-to-artifact map

Each row names the artifact, the source system, and a suggested owner. Ownership is an organizational decision, so assign it explicitly and record it in the binder.

• Audit controls, 164.312(b): Artifact: per-interaction records showing the AI system, user, date, location, action, tool calls, and how PHI was handled. Source: runtime enforcement in the execution path. Owner: security. Keep exportable in a computable format.
• Access control and minimum necessary: Artifact: the policy each AI system ran under, its change history, and enforcement decisions showing what PHI was allowed, redacted, or blocked. Source: runtime enforcement plus identity systems. Owner: security, with compliance review.
• Risk analysis and AI scoping: Artifact: an inventory entry per AI system recording whether it touches ePHI, whether it meets the Predictive DSI definition, and whether it ships in a certified module. Source: periodic assessment. Owner: compliance.
• Vendor and HTI-5 documentation: Artifact: agreements, attestations, and developer-supplied source attribute descriptions for certified modules. Source: procurement and vendor. Owner: compliance with clinical informatics. These describe the product, not your runtime behavior.
• Human oversight: Artifact: records of actions escalated for human approval, with the approver, decision, and time. Source: runtime enforcement. Owner: clinical informatics for clinical use cases, compliance for administrative ones.
• Policies and documentation retention: Artifact: versioned policies, review dates, and the as-of date of each regulatory statement. Source: document management. Owner: compliance. The proposed 164.316(b)(1), if finalized, would require retention for six years from creation or from when last in effect, whichever is later.

What runtime enforcement can evidence, and what it cannot

Runtime records answer a narrow question well: what did this system do, for this user, at this time? An enforcement decision to allow, redact, or block, recorded at the level of an individual interaction or tool call, is stronger evidence than a log assembled later from scattered systems. A human approval escalation shows that a control operated, not only that one existed.

Those records cannot show that your risk analysis was sound, that a vendor contract contains the right terms, or that a policy was approved by the right people. They also cannot show how a vendor's certified module was built or what its developer documented. Keep those artifacts in separate sections of the binder, labeled by source type, so a reviewer can see which claims rest on observed behavior and which rest on documents.

The fields in ONC's feedback-loop description for certified modules are a useful reference for record design: the intervention, action taken, user feedback where applicable, user, date, and location. They are not a HIPAA audit-log specification, and the Security Rule does not adopt them. They do make a reasonable baseline for attributing each record to a specific system, person, and moment.

Retention, integrity, and ownership decisions

These choices determine whether evidence is durable. Most are policy decisions rather than regulatory text, so document the reasoning for each.

• Set retention to the longer of organizational policy and the documentation period in the current 164.316 text, and consider the proposed six-year language if it is finalized.
• Record the as-of date beside every regulatory statement in the binder, and track the Security Rule proposal and HTI-5 implementation as monitored items.
• Store runtime records where the AI system's operators cannot edit them, and restrict who can read interaction records that may contain PHI.
• Keep records exportable in a computable format so an auditor request does not require manual reconstruction.
• Assign each artifact a named owner in compliance, security, or clinical informatics, plus a review cadence.
• Retain the scoping decision for each AI system as its own artifact, including PHI touched, Predictive DSI status, and certified-module status.

Where runtime evidence generation fits

Trussed enforces policy in the execution path across models, agents, tools, MCP servers, and coding assistants, with decisions to allow, redact, block, rate limit, or escalate for human approval at the level of individual interactions and tool calls. The enforcement generates continuous audit-ready evidence mapped to HIPAA, including PHI handling and the 164.312(b) audit controls. Because that evidence is produced when policy is enforced at runtime, not reviewed after the fact, it fills the runtime rows of the binder above.

Trussed deploys self-managed in the customer cloud, with configurable retention and data residency, so retention can follow the periods your compliance team sets. It runs in production with healthcare organizations. It does not replace the risk analyses, vendor agreements, or policies that make up the rest of the binder, and it makes no claim about regulatory outcomes.