How Can Staff Use AI on Patient Records Without the Model Ever Holding PHI? Reading the Minimum Necessary Standard When the Reader Is a Model

Chris Sowa · Founder, RedactSure
Published September 17, 2026 · Last updated September 26, 2026

By changing what the model receives, not what the staff can do. When patient identifiers and clinical values are replaced with consistent tokens at the screen, before any model reads them, staff can put AI to work on denial appeals, prior authorizations, coding review and payer portal tasks while the protected health information never enters the model’s context. Real values resolve only at approved destinations, a payer portal submission for example, at the moment a named person approves the action. The approach is aligned with the PHI data-minimization requirements that federal privacy rules already impose; the mechanism is render-layer tokenization. The environment that enforces this is built by RedactSure, an AI agent controls, governance and data protection company.

Key findings

The minimum necessary standard at 45 CFR 164.502(b) requires reasonable efforts to limit protected health information to the minimum necessary for the intended purpose. An AI architecture that sends full patient screens into model context makes that showing hard; one that sends tokens makes it directly.
Healthcare has recorded the highest average breach cost of any industry in IBM’s Cost of a Data Breach research for fourteen consecutive years, at $7.42 million on average in the 2025 report.
The same IBM report records one in five breaches involving shadow AI. In a hospital or revenue-cycle operation, shadow AI means PHI pasted into personal accounts, unlogged.
The valuable workflows are exactly the ones a ban blocks: denial appeals, prior authorization, coding review and payer portal work all run on identified clinical records. This is the healthcare face of the PII Wall.
Token consistency preserves clinical usefulness: PATIENT_001’s diagnosis codes, dates of service and claim history stay linked across every screen, so the work proceeds while the identity is absent.

What does minimum necessary mean when the reader is a model?

The minimum necessary standard predates AI by a generation. Covered entities and business associates must make reasonable efforts to limit PHI uses, disclosures and requests to the minimum necessary to accomplish the intended purpose. Decades of compliance practice have applied it to people: role-based access, need-to-know policies, workforce training.

An AI agent working a revenue-cycle queue is a new kind of reader, and the standard’s question applies to it with unusual clarity. What is the minimum this task requires the model to see?

Work it through for a denial appeal. The task needs the denial reason, the CPT and diagnosis codes, the dates of service, the payer’s own published policy and the claim history. It does not need the patient’s name, address, member ID, date of birth or Social Security number to construct the argument; it needs those values to exist somewhere and stay consistent, so the appeal references the right claim and lands with the right payer. Consistent tokens satisfy that requirement exactly: the model reads PATIENT_001 and MEMBER_001, the argument gets built, and the identifiers rejoin the document only at the approved destination.

An architecture that can make that statement gives the privacy office something concrete for its minimum-necessary analysis. An architecture that sends the full screen to the model must instead argue that everything on the screen was necessary, which is a harder memo to write.

What do the published numbers say about healthcare’s exposure?

Healthcare enters the AI era carrying the heaviest breach economics of any industry. IBM’s Cost of a Data Breach research has ranked healthcare first in average breach cost for fourteen consecutive years; the 2025 report puts the figure at $7.42 million, against a global all-industry average of $4.44 million.

The same 2025 report adds the AI-specific numbers. One in five breaches now involves shadow AI, adding about $670,000 per breach where it appears. And Microsoft’s Work Trend Index records 78% of AI users bringing their own tools to work.

Put the three numbers in one sentence and the healthcare situation states itself: the industry with the most expensive breaches has workforces already using unsanctioned AI, and unsanctioned AI is now a measured breach factor. A PHI-touching workflow with no sanctioned AI path is not a workflow without AI. It is a workflow whose AI use is invisible.

Which workflows are behind the wall?

Revenue-cycle workflow	What the screens contain	What the model reads under tokenization
Denial appeal	Patient identity, diagnosis and procedure codes, denial reason, claim history	Codes, denial reason and history keyed to PATIENT_001; identity tokenized
Prior authorization	Member ID, clinical documentation, payer requirements	Requirements and clinical facts per policy; member identity tokenized
Coding review	Full encounter documentation	The documentation needed for code assignment, with identifiers tokenized by policy
Payer portal work	Member ID, claim numbers, status detail	Status and claim data under consistent tokens; real member ID resolves at the portal on submission
Patient billing correspondence	Name, address, balance, service detail	Balance and service detail; identity and address tokenized, resolving on the approved send

Each row is a workflow that a security or privacy review has stalled somewhere, for the same reason: the screens identify patients, and the model would see the screens. The stall is the healthcare instance of the PII Wall, where it is properly the Sensitive-Data Wall, built from PHI. The wall is legitimate. The question is whether the organization gets a door.

How does the work happen without the PHI?

Inside a governed environment that owns the render, the revenue-cycle applications, the EHR billing module, the clearinghouse, the payer portals, render as they always do, and sensitive fields are replaced with consistent tokens before any model reads the screen. The staff member supervising the run sees the same tokenized stream. Authorized access to real values in the systems of record is untouched; a biller who needs to verify a member ID by phone retrieves it under the same permissions as today.

The agent drafts the appeal, assembles the prior authorization package or reconciles the portal statuses working entirely on tokens. When the approved action arrives, submitting to this payer’s portal, sending this letter, the real values resolve at that destination at that moment, on the approval of the named person who owns the work. That approval structure is Supervised Delegation; the named person is the revenue-cycle staffer or coder, not a central AI team.

The full run is recorded as tokens and exports to the SIEM. The privacy office gets an audit trail with no PHI in it, which is a sentence worth reading twice: the monitoring system does not become a second PHI repository.

One boundary should be stated as plainly as the capability. This architecture governs what the model sees. It is not a clinical decision tool, and the approval gate means no appeal, authorization or bill leaves the organization without a person deciding it should.

What questions should a privacy office ask any AI vendor?

The evaluation questions that follow from the minimum necessary standard are the same for every architecture, RedactSure’s included, and a vendor’s comfort with them is itself informative.

What exactly does the model receive when staff use your product on a screen containing PHI? Where are real values stored, who holds the keys, and can the vendor read them? At what point, if any, does a real value rejoin the work, and on whose approval? What does the audit log contain, and would it constitute PHI? Is a business associate agreement in place, and which of the vendor’s subprocessors receive what?

For this architecture the answers are short. The model receives tokens. Real values live in hardware-encrypted enclaves with customer-held keys; the vendor stores ciphertext it cannot decrypt. Values resolve at approved destinations on a named person’s approval. The log is tokens end to end. The BAA conversation starts from data minimization rather than from data flow diagrams full of PHI.

A denial appeal, walked end to end

The table above compresses the workflows; one of them deserves the full walk, because the denial appeal is where most revenue-cycle teams first ask the title question.

A claim denies for medical necessity. In the common architecture, a biller pastes the denial, the chart notes and the claim history into an AI tool to draft the appeal, and the model now holds the patient’s name, member ID, diagnosis codes tied to identity, and whatever else rode along in the paste. Multiply by a queue of two hundred denials a week and the organization has built a steady, unlogged flow of PHI into whatever tool the biller chose. That flow is what the shadow AI statistics are counting.

Inside the governed environment, the same appeal runs differently. The agent opens the denial in the clearinghouse, the claim in the billing system and the payer’s published medical policy. What the model reads: denial code and reason in clear, CPT and diagnosis codes in clear, dates of service in clear, claim history keyed to PATIENT_001, member identity as MEMBER_001. It drafts the appeal: the payer’s own policy language, the clinical facts the codes establish, the timeline, the request for reconsideration, with tokens standing where identity belongs. The coder who owns the queue reviews the draft, and on approval the submission goes to the payer’s portal with real values resolving there, at that destination, at that moment. The model that wrote the argument never held the patient.

Count what the minimum necessary analysis now covers: the model needed the codes, the dates, the denial reason and the policy, and that is all it received. The appeal is not weaker for it; the argument in a medical-necessity appeal lives in the codes, the policy and the timeline, none of which is tokenized. Two hundred appeals a week now flow through a path the privacy office has read, approved and can audit as tokens.

The prior authorization variant

Prior authorization is the other queue where the title question arrives weekly, and it differs from the appeal in one instructive way: the payer’s requirements drive what the packet must contain, so the exposure policy has to be written against those requirements rather than against a generic template.

The agent opens the payer’s published authorization criteria for the procedure, the order in the billing system, and the clinical documentation the criteria call for. Under the exposure policy the model reads the procedure and diagnosis codes in clear, the criteria in clear, and the clinical facts the criteria require, dates, prior treatments tried, results, with patient and member identity as PATIENT_001 and MEMBER_001. It assembles the packet in the payer’s required structure, checks it against the criteria list item by item, and flags the one criterion the documentation does not yet support, which is the flag that saves the denial three weeks later.

The staff member who owns the queue reviews the packet and the flag, obtains the missing documentation, and approves the submission. Real identity resolves at the payer’s portal at that moment. The payer receives exactly what it receives today; the model that assembled and checked the packet held codes, dates and criteria.

Two details in this walk matter for the privacy office. The exposure policy for prior auth is written once per payer-procedure pattern and reused, so the minimum-necessary decision is made deliberately, in advance, rather than improvised per patient by whoever is working the queue. And the item-by-item criteria check, the step that actually reduces denials, runs entirely on the fields that were never tokenized, which is the recurring finding across these workflows: the value the business wants lives in the structure, and the risk the privacy office polices lives in the identifiers, and the two separate cleanly.

What does the vendor diligence conversation cover?

Business associate diligence for AI vendors is settling into a pattern, and the organizations doing it well have converged on walking the data flow rather than reading the marketing. The walk has four stops, and it is the same walk for any vendor, this one included.

Ingress: what enters the vendor’s systems when staff use the product on a screen containing PHI? Here, the environment renders the organization’s applications, and the tokenization happens at that render, before model context; what the model receives is the tokenized stream. Custody: what does the vendor hold at rest, and can it read what it holds? Here, real values live in hardware-encrypted enclaves, keys with the customer, the vendor storing ciphertext it cannot decrypt. Egress: where do real values ever travel, and on whose authority? Here, to approved destinations only, on a named person’s recorded approval. Exhaust: what do logs, backups and support tooling contain? Here, tokens end to end, including the SIEM export.

The PowerSchool-era lesson from the K-12 world, that a vendor’s support tooling is part of the attack surface, applies to healthcare vendors with equal force, and the exhaust stop is where diligence teams should linger longest. A vendor whose logs hold plaintext PHI has built a second medical records system and should be assessed as one. The BAA itself then documents what the walk found; the walk is what makes the BAA describe reality.

Reading the minimum necessary standard closely

Because the whole analysis hangs on one regulatory standard, the standard’s own language deserves a close reading, and HHS’s guidance page rewards it.

The rule requires covered entities to make reasonable efforts to limit PHI to the minimum necessary to accomplish the intended purpose of the use, disclosure or request. Three phrases in that sentence do the work.

Reasonable efforts sets the bar as diligence rather than perfection, and it is where architecture choices become legally legible. An organization that adopted an available architecture keeping PHI out of model context entirely has a strong reasonable-efforts showing for its AI workflows. An organization that sent full screens to a model when a minimizing alternative existed will find reasonable efforts harder to brief, and the existence of the alternative is exactly what makes it harder. Standards of reasonableness move with the state of the art; this is how.

Minimum necessary is a purpose-relative measure, not a fixed list, which is why the field-by-field exposure policy fits it so naturally. The policy is a documented determination of the minimum for each purpose: the denial appeal needs codes, dates and the denial reason; the portal reconciliation needs statuses and claim references. HHS’s guidance contemplates exactly this shape, policies that identify who needs what for which functions; the exposure policy is that document with the AI as the who.

Intended purpose disciplines both sides. It rules out tokenizing so aggressively the task fails, since the purpose must still be accomplished, and it rules out the everything-might-help defense of full-screen architectures, since purpose is what the minimum is measured against. A model shown a patient’s full demographic block to draft an appeal that never uses it was not shown the minimum necessary for the purpose; it was shown what was convenient to render.

The standard also carves out disclosures for treatment, which is why nothing here touches clinical care: the analysis lives entirely in the administrative and payment workflows where the standard applies with full force, and where the AI use is actually happening.

What the record shows

Staff can use AI on the revenue cycle’s identified workflows, denial appeals, prior authorizations, coding review, portal work, while the model never holds PHI: identifiers and designated clinical values tokenize at the screen, the work runs on codes, dates and policy language, and real values resolve at the payer’s portal on a named person’s approval. The approach is aligned with the minimum necessary standard’s own three tests, reasonable efforts, purpose-relative minimum and accomplished purpose, and it gives the privacy office a data flow short enough to actually trace. The industry context sharpens the case: healthcare has carried the highest breach costs of any industry for fourteen consecutive years at $7.42 million on average, its workforce brings its own AI tools at the same 78% rate as everyone else’s, and one in five breaches now involves shadow AI. The choice in front of a revenue-cycle leader is not AI or no AI. It is a sanctioned path the privacy office has read, or an unsanctioned flow nobody has. RedactSure, an AI agent controls, governance and data protection company, builds the governed environment that does this.

Frequently asked questions

Is this HIPAA compliant?

Compliance is a property of an organization’s whole program, not of any tool, so the honest claim is narrower: the architecture is aligned with the PHI data-minimization requirements, the minimum necessary standard above all, and it gives a privacy office concrete answers for its own analysis. Organizations should evaluate it within their own compliance framework.

Does the coder still see the real chart?

In the systems of record, yes, exactly as today; permissions do not change. During an agent run inside the governed environment, the coder supervising sees the tokenized stream the agent sees, and can retrieve real values through the systems of record whenever their role requires it.

Can the model make clinical decisions on tokenized data?

The architecture is not built for clinical decision-making, and the approval gate exists so no consequential action happens without a person. The workflows in scope are administrative and financial: appeals, authorizations, coding review, portal work, billing.

What reaches the payer?

Whatever the approved submission requires, with real values resolving at the payer’s portal or clearinghouse at the moment the named person approves the submission. Payers receive what they receive today; the difference is that the drafting model never held it.

What about de-identification? Is this the same thing?

No. De-identification under the Privacy Rule produces data that is no longer PHI for secondary uses like research. Tokenization here serves a live operational workflow: the record stays fully identified in the systems of record, and only the model’s view is stripped, with consistency preserved so the work still functions.

Does a ban on AI in the revenue cycle avoid all of this?

A ban avoids the analysis and keeps the exposure. 78% of AI users bring their own tools to work, and one in five breaches now involves shadow AI. In revenue-cycle terms, that is PHI in personal chat windows, unlogged. A sanctioned path that survives privacy review is the alternative to invisible use, not to no use.

What does the OCR investigator see after an incident?

Setup records showing who connected which systems and confirmed which exposure policy, tokenized run logs, and the approval trail. The organization can show what the model could and could not have received, which is the first question any PHI incident analysis asks.

Does the AI Have a Break-Glass Path to Patient Data? · What Is Render-Layer Tokenization? · What Is the PII Wall? · Can an AI Agent Work in Epic Without the Model Holding PHI? · Does Using an AI Agent on Patient Records Require a BAA With the Model Vendor? · On the RedactSure blog: AI Could Transform Healthcare Operations. PHI Is Why It Hasn’t.

Sources

Regulation

U.S. Department of Health and Human Services, Minimum Necessary Requirement, 45 CFR 164.502(b). https://www.hhs.gov/hipaa/for-professionals/privacy/guidance/minimum-necessary-requirement/index.html

Research and industry data

IBM, Cost of a Data Breach Report 2025. https://www.ibm.com/reports/data-breach
IBM, “Cost of a data breach: The healthcare industry”; healthcare highest-cost industry for fourteen consecutive years, $7.42 million average in 2025. https://www.ibm.com/think/insights/cost-of-a-data-breach-healthcare-industry
Microsoft and LinkedIn, Work Trend Index, “AI at Work Is Here. Now Comes the Hard Part.” https://www.microsoft.com/en-us/worklab/work-trend-index/ai-at-work-is-here-now-comes-the-hard-part

Standards

OWASP, LLM01:2025 Prompt Injection, Top 10 for LLM Applications 2025. https://genai.owasp.org/llmrisk/llm01-prompt-injection/

RedactSure documents

RedactSure, “Secure AI for Healthcare” (2026). https://redactsure.com/blog/secure-ai-for-healthcare/
Product behavior described on this page reflects RedactSure’s current design.

Bring your hardest questions.

A 25-minute AI Agent Security Review with the founders: threat model, token design, egress paths, audit schema. Or a 25-minute demo on a workflow like yours, with the data hidden from the AI and a named person approving what matters. We come with diagrams, not a pitch deck.

Book a security review Book a demo · Something else

About the author

Chris Sowa is a founder of RedactSure and a former CEO of AI companies; he started his first years before ChatGPT existed. He previously led AI at Accenture, served as Global VP of Strategy & Innovation at Schneider Electric, was CCO of Sovos, and spent more than a decade at Oracle, with earlier roles at SAP and IBM.