Applying One AI Policy Set to Both Clinical AI and Revenue Cycle AI

Why separate policy sets break down

Clinical AI, such as documentation assistants and decision support, and revenue cycle AI, such as coding, claims, prior authorization and denial management, usually have different owners, tools and policy documents. Both handle PHI. The Security Rule's Subpart C applies to covered entities and business associates with respect to ePHI, and that duty does not change with the use case.

Separate programs produce predictable problems. PHI redaction rules drift between teams. Audit work is done twice. Evidence is shaped differently in each domain, so showing an auditor a consistent account of AI activity becomes a manual reconciliation exercise. A single policy set fixes this only if it can express legitimate differences between the domains and if it is enforced where the AI actually acts, rather than described in a document that is reviewed later.

Structure: a shared baseline with domain scoping

NIST AI RMF 1.0 offers a useful model. GOVERN applies to all stages of an organization's AI risk management processes, while MAP, MEASURE and MANAGE can be applied to specific AI systems and lifecycle stages. Mapping that onto policy gives two layers.

The baseline layer holds what must be true of every AI workload: how PHI is detected and handled, who or what may access which systems, and what evidence each decision must produce. One accountable owner maintains it across clinical and revenue cycle teams.

The domain layer holds the parameters that legitimately differ. Treat these as inputs to one policy, not as grounds for a second program. The table below shows examples of how a policy author might scope them. The specific values are illustrative and should come from your own risk analysis.

• Data classes: Baseline: PHI is identified and handled the same way everywhere. Clinical scope may permit chart content for a treating-context task. Revenue cycle scope may permit claim and coverage fields and block clinical narrative not needed for the task.
• Tool permissions: Baseline: deny by default, allow by task and role. Clinical scope allowlists clinical record and reference tools. Revenue cycle scope allowlists claims, coding and payer-facing tools.
• Escalation triggers: Baseline: any out-of-scope action is escalated or blocked. Clinical scope may require clinician approval before content reaches the record. Revenue cycle scope may require approval before submission or appeal actions.
• Approval thresholds: Baseline: defined per use case and documented. Higher-risk workflows sit on top of the baseline with stricter thresholds.
• Rate limits: Baseline: limits apply to every agent and tool. Revenue cycle scope may set different volume limits for high-throughput batch work.

Evidence: showing what the AI was allowed to do and what it did

Auditors need two things: the rule that applied and the action taken. For each enforcement decision, record the policy that was evaluated, the identity and policy context of the caller, the result of validation, and the outcome. A NIST presentation on runtime execution governance for agentic AI lists similar evidence mechanics: schema validation, policy evaluation, IAM and policy context, and checks against defined invariants. Use these as a starting checklist for your own record design.

This evidence supports audit controls under 45 CFR 164.312(b), and the shared baseline means one evidence format serves both domains. A single format also lets governance teams answer the same question about a documentation assistant and a claims agent in the same way.

Risk analysis is the other thread. A January 2025 Federal Register document on the Security Rule states that regulated entities must conduct repeated risk analyses that account for changes in technology or operations. It also states that HHS would expect a risk analysis as AI evolves, and it quotes NCVHS on analyzing AI throughout the system's life cycle. As of November 2026, confirm the current legal status of that document before treating any part of it as an obligation. Either way, the design implication is stable: tie enforcement records to the use-case inventory so each re-analysis has data to work from.

On the NIST AI RMF side, baseline policy and its evidence map to GOVERN, while per-domain scoping and measured enforcement outcomes support MAP, MEASURE and MANAGE for each system.

Tradeoffs and where Trussed fits

A shared baseline concentrates responsibility. One owner and one policy set mean a mistake in the baseline affects both domains, so change control and testing of policy edits matter more, not less. Domain scopes also need discipline: every deviation from the baseline should have a documented risk rationale, because HHS's strategy emphasizes transparent, risk-proportionate controls and an auditor will ask why clinical and revenue cycle rules differ. Specific approval thresholds are a judgment for your risk analysis, not something a framework supplies.

Trussed enforces policy in the execution path across models, agents, tools and MCP servers, with outcomes of allow, redact, block, rate limit and escalate for human approval on individual interactions and tool calls. Policy is enforced at runtime, not reviewed after the fact, and the enforcement generates audit-ready evidence mapped to HIPAA and NIST. It runs as a self-managed deployment in the customer cloud with configurable retention and data residency, applies one policy plane across 100+ models, and runs in production with healthcare organizations.