AI Use Case Tiering in Healthcare: From Patient Impact to Runtime Controls and Audit Evidence

Why patient impact is the organizing variable

Health systems now run AI in clinical, revenue cycle, operations, administrative and research departments. Without a shared ranking method, a documentation assistant, a triage support tool and a patient-facing chatbot can end up under the same controls. The result is predictable: low-impact uses are over-controlled and slow to deploy, while high-impact uses are under-controlled.

NIST AI RMF 1.0 is voluntary, non-sector specific and use-case agnostic, so it does not hand a health system a tier scheme. The tier criteria and the control mapping are your own adaptation. That is a design task, and it is worth doing deliberately, because the tier becomes the input to everything downstream: which data the tool may touch, which actions it may take, who must approve, and what is retained.

A workable method scores each use case on five criteria. Direct influence on clinical decisions: does the output inform, recommend or trigger a care decision? Reversibility of harm: can an error be caught and corrected before it affects a patient? Degree of human review: does a qualified person review every output, a sample, or none? PHI exposure: what identifiable data enters the prompt, the context and the tool calls? Audience: is the tool staff-facing or patient-facing? The highest-scoring criterion should usually set the tier, rather than an average, so one severe factor is not diluted by four mild ones.

Representative use cases by tier

The assignments below are examples to calibrate your own scoring, not fixed classifications. The same tool can move up a tier when its scope changes, for example when a documentation assistant gains permission to write to the chart.

• Tier 1: Minimal: Examples: facilities and supply chain forecasting summaries, IT help desk assistants, internal policy search, literature summarization for research without PHI. Controls: allow, rate limit, block PHI from reaching the tool. Evidence: interaction record with the policy applied.
• Tier 2: Moderate: Examples: clinical documentation drafting reviewed by the clinician, revenue cycle coding suggestions, denial appeal drafts, scheduling optimization. Controls: allow with PHI redaction to what the task needs, read-only and scoped tool calls, human review before any write. Evidence: interaction record, redactions applied, tool calls, reviewer action.
• Tier 3: High: Examples: triage support, risk prediction alerts, discharge instruction generation, patient-facing chatbots. Controls: block out-of-scope content and unapproved tool calls, escalate for human approval before release or action, redact PHI by default. Evidence: full interaction and tool-call records, approval decisions, monitoring review.
• Tier 4: Critical: Examples: medication dosing recommendations, automated order entry, autonomous result communication. Controls: block autonomous execution, escalate every consequential action to a named approver. Evidence: everything in Tier 3, plus documented validation and a tested stop procedure.

Turning a tier into runtime policy

A tier that lives only in a policy document is reviewed after the fact, if at all. To be enforceable, each tier has to resolve into four decisions made at the moment of each interaction or tool call: allow, redact, block, or escalate for human approval. Rate limiting is a useful fifth control for lower tiers, where the main risk is volume or misuse rather than a single consequential action.

PHI handling is the first translation. Lower tiers may be configured to keep PHI out entirely. Middle tiers typically permit PHI but redact fields the task does not need before they reach a model. Higher tiers may permit identifiable data but only to approved destinations, with the redaction rule written down per use case.

Tool-call restrictions are the second. Most patient-impact risk in agentic and tool-using systems comes from what the system can do, not only what it can say. A Tier 2 assistant might be limited to read-only queries against a scoped record set. A Tier 3 system might be permitted to draft an order but not submit it. A Tier 4 system should not take the action at all without an approver.

Human approval is the third. Define which actions require it by tier, who is authorized to approve, and what happens if no one responds. The default on timeout should be no action.

Finally, keep a stop control that is independent of tier. The ONC SAFER guide says organizations should give clear written instructions and authority so anyone in IT can disable, stop or turn off AI-enabled systems 24 hours a day, seven days a week. It also says organizations that use AI-enabled systems share responsibility for their safety, so document which controls sit with the health system and which with the vendor.

Evidence by tier and the HIPAA audit-controls link

The HIPAA Security Rule's technical safeguards at 45 CFR 164.312 apply to covered entities and business associates, and they include the audit controls standard at 164.312(b). Confirm each AI vendor's HIPAA role before assigning evidence duties, because a vendor handling ePHI changes who must produce what. A proposed update to the Security Rule was published in the Federal Register in January 2025, and as of November 2026 the current eCFR text of 164.312 still lists the 2013 amendment as the most recent. Schedule periodic re-review so tier-to-evidence mappings track any change.

It helps to separate two kinds of evidence. The first is static documentation about the tool. ONC's HTI-1 proposal for predictive decision support described four source-attribute categories: intended use; development; evaluation of validity, fairness and effectiveness; and ongoing monitoring and use. That proposal is not a confirmed requirement you can rely on, but the categories make a sound intake template for each use case record, and they support the goal ONC stated of letting users judge whether a tool is fair, appropriate, valid, effective and safe.

The second is runtime evidence: what the use case was permitted to do, and what it did. These records are what an auditor reviewing audit controls will want, and they cannot be reconstructed from static documentation. Scale the depth by tier. Tier 1 needs a record that the interaction occurred and which policy applied. Tier 2 adds redactions and tool calls. Tier 3 and Tier 4 add approval requests, approver identity, the decision and the outcome, plus post-deployment monitoring review. Retention periods and formats should be set per tier by your compliance team.

Be precise about scope. Interaction-level and tool-call-level evidence shows what happened at each call. It does not by itself describe how a model was trained or reconstruct a multi-step workflow end to end. Those questions need their own documentation, and the evidence plan should say so.

How Trussed fits

Trussed enforces policy in the execution path across models, agents, tools, MCP servers, AI sites and coding assistants. It applies allow, redact, block, rate limit and escalate-for-human-approval decisions at the level of individual interactions and tool calls, so a tier can be enforced at runtime, not reviewed after the fact. That enforcement generates continuous audit-ready evidence, mapped to HIPAA and NIST among other frameworks.

Trussed runs in production with healthcare and pharma organizations, supports self-managed deployment in the customer cloud, and offers configurable retention and data residency. Its scope is interaction and tool-call enforcement. It does not provide model or dataset provenance, and it does not trace agentic workflows end to end, so those parts of your evidence plan need other sources.