Standardizing PHI Handling Rules for AI Across Health System Departments

Why PHI standardization is an enforcement problem

Clinical operations, revenue cycle, research and IT usually adopt AI on separate timelines. Each team writes its own PHI rules for prompts, outputs and tool calls, and each interprets them differently. The result is a set of policies that read consistently on paper but are applied unevenly, and often not applied at the point where PHI reaches an AI system.

The regulatory text points toward technical enforcement. The Security Rule general requirements (164.306) call for ensuring the confidentiality, integrity and availability of all ePHI an entity creates, receives, maintains or transmits. The access control standard (164.312(a)(1)) limits access to persons or software programs that have been granted access rights. That wording supports treating agents, tools and coding assistants as access-controlled actors, not only human users. The audit controls standard (164.312(b)) requires hardware, software and/or procedural mechanisms that record and examine activity in systems that contain or use ePHI.

The standard is mechanism-neutral, so runtime enforcement is one way to meet it, not a mandate. The January 2025 HHS proposed rule on Security Rule changes is worth reading as a signal of direction. It states that ePHI in AI training data, prediction models and algorithm data is protected by the HIPAA Rules, and that OCR is concerned some entities treat technical policies as written policy only. It is a proposal, so treat its specific requirements as not confirmed in force as of November 2026.

Build the baseline: inventory, classes and rule categories

Start with an inventory of every AI model, agent, tool, MCP server and coding assistant that could touch ePHI, and fold it into the existing risk analysis. The proposed rule describes assessing risks before adopting new technologies, and that is a sound practice regardless of its final status. The inventory determines which policy tiers you need and which departments use which systems.

Then define the rule categories once, at the system level, so that no department writes its own version. Each category below should have a default that applies everywhere unless an approved exception says otherwise.

• PHI data classes: Name the classes your organization recognizes, such as direct identifiers, clinical content, claims and billing data, and non-PHI, and tie each to a tier.
• Permitted AI systems per class: State which models, agents and assistants may receive each class, including whether external or vendor-hosted systems are allowed at all.
• Redaction requirements: Specify which identifiers must be removed from prompts, outputs and tool-call parameters before they leave a boundary.
• Tool-call restrictions: List which tools and MCP servers an agent may call with each class, and which operations (read, write, export) are permitted.
• Human approval triggers: Define the conditions that require a named person to approve an action before it proceeds.
• Retention and evidence: Set how long interaction records are kept, where they reside, and which fields every record must contain.

Translate each rule into a runtime action

A rule is enforceable only when it maps to an action taken on a specific interaction. Five actions cover most of what a PHI standard needs, and each tier in the baseline should resolve to one of them. Policy is evaluated on the individual prompt, output or tool call, which is where PHI actually moves.

• Allow: The actor, data class and destination match the baseline. The interaction proceeds and its record is written.
• Redact: PHI is detected and removed or masked before the prompt, output or tool-call parameter continues. Use this when the task does not need the identifiers.
• Block: The class, tool or destination is not permitted. The interaction stops and the denial is recorded.
• Rate limit: Volume or frequency of PHI-bearing calls is capped per actor, which constrains bulk extraction through an agent or assistant.
• Escalate for human approval: The interaction pauses until an authorized reviewer approves or denies it. The decision becomes part of the record.

Where department-level exceptions belong

Exceptions belong in an overlay on the baseline, not in separate department policies. The baseline stays owned by security and compliance. A department requests a variation for a specific data class, system or action, and the variation is expressed in the same policy language and enforced by the same mechanism.

Each exception should carry an owner, a defined scope, a rationale tied to the risk analysis, and a review date. Typical examples show the pattern. Research may need a broader data class but with stricter limits on where outputs can go and an approval step for exports. Revenue cycle may need claim identifiers, but only in calls to approved billing tools. Clinical operations may allow clinical free text to reach a model but require redaction of direct identifiers first. IT may block PHI from coding assistants entirely and require test data instead.

This structure makes exceptions visible. An auditor or CISO can list every deviation from the baseline, see who approved it, and compare it with what the interactions under that exception actually did.

Evaluating runtime enforcement for your environment

Enforcing in the execution path and reviewing after the fact solve different problems. Review after the fact can reveal what happened, but only once PHI has already reached a model or tool. In-path enforcement can stop, redact or pause the interaction first. It also adds latency, becomes a dependency for availability, and can produce false positives that need tuning. Weigh those costs against your risk analysis rather than assuming either approach fits every workload.

When assessing any approach, ask five questions. Does the enforcement point sit in the path for prompts, outputs and tool calls? Does it cover every department's models, agents, MCP servers and coding assistants? Can one baseline carry documented departmental exceptions? Does each interaction record show both what was permitted and what occurred? Can it be deployed in your own cloud, with retention and residency you control?

Trussed enforces policy in the execution path across models, agents, tools, MCP servers, AI sites and coding assistants, with allow, redact, block, rate limit and escalate for human approval, scoped to individual interactions and tool calls. Enforcement generates audit-ready evidence mapped to HIPAA. It is deployed self-managed in the customer cloud, with configurable retention and data residency, and it runs in production with healthcare and pharma organizations, with 100+ models under one policy plane.