Data Report · RedactSure Research
Can an AI Agent Work in Epic Without the Model Holding PHI? Yes, If the Identifiers Never Reach It
Yes, if the model never receives the identifiers in the first place. An AI agent can work a patient account from the billing work queue through eligibility, claim status, denial follow-up and a drafted appeal, across Epic, the payer portals and the clearinghouse, while the model reads MRN_001, USER_001 and DOB_001 where the patient’s identifiers were. The agent does the work inside a governed environment where the screens render with identifiers replaced before any model reads them, a named person approves every submission, and every screen is logged as tokens. The same holds for any electronic health record: Cerner, athenahealth, eClinicalWorks, MEDITECH, and the practice-management systems around them. Epic is named here because it is the system most health systems run and the name most buyers type. Least Exposure is the principle: for each piece of work, the agent receives exactly the data the task requires and nothing more, enforced before any model reads the screen. The environment that enforces this is built by RedactSure, an AI agent controls, governance and data protection company.
Key findings
- Revenue-cycle work is the healthcare workflow with the clearest AI case and the hardest security question, because every screen names a patient. The minimum necessary standard at 45 CFR 164.502(b) asks the organization to limit PHI to what the task requires, and an agent that reads the whole chart to check a claim status has not.
- Healthcare has recorded the highest average breach cost of any industry for fourteen consecutive years, $7.42 million in IBM’s 2025 report, and one in five breaches now involves shadow AI. A new AI repository of patient records is a new place for that cost to land.
- Nothing is installed in Epic. The agent operates the EHR, the payer portals and the clearinghouse through the governed environment at the render, under the staff member’s existing permissions; no integration, no Epic build, no change to the security model the health system already audits.
- What the model receives is decided field by field per workflow: the balance, the payer, the denial code, the dates the task needs, in clear; the name, MRN, date of birth, address, insurance ID and account numbers as tokens. Real values resolve only in the approved submission at the moment a named person approves it.
- The run history holds every screen as tokens, so the health system can show a regulator, an auditor or a patient what the AI read without the log itself being a disclosure.
Why is the EHR the hardest place to put an agent?
Because the EHR is where the whole patient is. A claims system holds a claimant’s file; an EHR holds a person’s life, and the billing work queue sits on top of it. An agent working a denied claim opens the account, and the screen shows the patient’s name, medical record number, date of birth, address, insurance identifiers, guarantor, the encounter’s diagnosis and procedure codes, the clinical notes behind them, and the balance. The task needs the codes, the payer, the denial reason, the dates and the balance. It does not need to know who the patient is.
That gap is exactly the minimum necessary standard’s territory. 45 CFR 164.502(b) requires reasonable efforts to limit PHI to the minimum necessary to accomplish the intended purpose. When a person works the queue, the organization satisfies that by role-based access: the biller sees what billers see. When a model works the queue, the same role-based access shows the model everything the biller could see, which is the whole account, and the organization has no mechanism to show it less. The screen was the end of the line, and nobody built a control for a reader that reads the whole screen at once.
The security team’s answer is usually no, and the queue keeps growing. The PII Wall is the name for that outcome: the valuable workflow runs on records the model must not see, and the AI project shrinks to something harmless or stops.
Which revenue-cycle workflows are behind the wall?
| Workflow | What the screens contain | What the model reads under tokenization |
|---|---|---|
| Eligibility and benefits verification | Patient identity, insurance ID, payer, plan details | Payer and plan terms keyed to USER_001; insurance ID resolves only at the payer portal on the approved check |
| Claim status follow-up | Account number, patient identity, claim number, payer, dates, balance | Claim number, payer, dates, status and balance; identity and account as tokens |
| Denial management and appeal drafting | Denial code, clinical notes, codes, patient identity, encounter dates | Denial reason, codes and the clinical facts the appeal needs; identity as tokens; the appeal drafts on USER_001 and resolves on the named person’s approved submission |
| Prior authorization preparation | Diagnosis, procedure, clinical justification, patient identity, insurance | The clinical justification and codes; identifiers as tokens until the approved submission |
| Patient statement and correspondence | Name, address, balance, encounter detail | Draft built on tokens; identity resolves on the approved send |
| Charge and coding review | Encounter documentation, codes, provider, patient identity | Documentation and codes; identity fields tokenized by policy |
Each row is work a revenue-cycle leader has asked about AI for, and each is where the privacy officer has said stop. The tokenized column is the same work with the identifiers absent from the model’s view, which is the minimum necessary standard applied to a new reader.
How does the agent work Epic without an integration?
By operating it. The agent works inside the RedactSure environment, a governed workspace in which Epic, the payer portals, the clearinghouse and the email client render under the environment’s control, and the agent operates them the way a biller does, under the biller’s existing permissions. Nothing is installed in Epic, no interface is built, and the health system’s role-based access model is untouched.
Owning the render is what makes the control possible. Render-layer tokenization replaces the configured identifiers with consistent tokens at the moment each screen renders, before any model reads it. The tokens are consistent within the task, so the agent that sees USER_001 on the Epic account sees USER_001 on the payer portal and can connect the two without ever holding the name. The environment reads the page as fields rather than as a picture, so the model is handed the fields the workflow needs rather than the whole window. Real values live in hardware-encrypted enclaves with keys the health system holds; RedactSure stores ciphertext it cannot decrypt.
The named person stays in the loop for every consequential step under Supervised Delegation. The agent prepares the appeal; the biller approves the submission, sees the resolved document at that moment, and the real values reach the payer portal on that approval. The AI never submits, adjusts or writes off on its own. Every screen the agent read and every approval lands in the AI Control Record, as tokens, exported to the health system’s SIEM.
What does the privacy officer get?
Three things the current architecture cannot give.
A written exposure policy per workflow: which fields the model receives in clear and which as tokens, confirmed by the person who owns the queue. That document is the minimum necessary analysis for the AI, made concrete and reviewable.
A run history with no PHI in it: every screen as the model received it, every action, every approval, held as tokens. The privacy officer can replay a run for an auditor or answer a patient’s question about what the AI read, without the replay being a disclosure.
A short answer to the break-glass question: under what circumstances does the model receive real patient values? None. There is no mode, emergency or otherwise, in which the model’s context holds an identifier. Does the AI Have a Break-Glass Path to Patient Data? walks why that matters and what the written answer should contain.
Whether a given deployment satisfies the health system’s obligations, and whether a BAA with the model vendor is required, are the organization’s determinations with counsel. Does Using an AI Agent on Patient Records Require a BAA With the Model Vendor? sets out the analysis. What the architecture supplies is the facts the analysis needs, and the record that proves them.
What the record shows
An AI agent can work in Epic, or any EHR, without the model holding PHI, provided the identifiers never reach it. The revenue-cycle queue is the workflow with the clearest value and the hardest question, because every screen names a patient and the minimum necessary standard asks the organization to show the reader less than the whole account. Inside a governed environment the agent operates Epic, the payer portals and the clearinghouse under the biller’s existing permissions, with the configured identifiers replaced by consistent tokens before any model reads the screen, the fields the task needs in clear, a named person approving every submission, and every screen logged as tokens. Nothing is installed in Epic and no permission changes. The privacy officer gets the exposure policy, the run history and a one-word answer to the break-glass question. The work gets done. The data stays hidden. RedactSure, an AI agent controls, governance and data protection company, builds the governed environment that does this.
Frequently asked questions
Does this require Epic to approve or install anything?
No. The agent operates Epic through the governed environment the way a person does, under existing permissions. There is no Epic build, interface or app-market listing involved. Epic, Cerner and the other names on this page are their owners’ trademarks and are used to identify the systems.
Does the model see diagnosis and procedure codes?
If the workflow needs them, yes: a denial appeal cannot be drafted without them. What it does not see is who the patient is. Which clinical fields count as needed is decided in the exposure policy per workflow, and clinical fields can be tokenized where the task allows.
What about the clinical notes?
Free text is handled by policy. Where the appeal needs the note’s clinical facts, the note is in clear with identifiers inside it tokenized; where it does not, the note is not handed to the model. The exposure policy names the choice and the run history shows it holding.
Can a biller still see everything they see today?
Yes. Permissions do not change. The biller sees real values in Epic exactly as before, and sees the same tokenized stream the agent sees while supervising a run.
Does the agent’s work reach the payer with real values?
Yes, at the approved submission, at the moment the biller approves it. That is the one place a real value rejoins the work, and it is on the record with the approver’s name and time.
Is this HIPAA compliant?
Compliance is the covered entity’s determination. The architecture is aligned with PHI data-minimization requirements, RedactSure signs a BAA, and the run history gives the entity’s analysis the evidence it needs.
Related reading
How Can Staff Use AI on Patient Records Without the Model Ever Holding PHI? · Does Using an AI Agent on Patient Records Require a BAA With the Model Vendor? · Does the AI Have a Break-Glass Path to Patient Data? · How Does a Governed AI Workflow Pilot Work? · On the RedactSure blog: Secure AI for Healthcare
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
- U.S. Department of Health and Human Services, Guidance on HIPAA and Cloud Computing. https://www.hhs.gov/hipaa/for-professionals/special-topics/health-information-technology/cloud-computing/index.html
Research and industry data
- IBM, Cost of a Data Breach Report 2025. https://www.ibm.com/reports/data-breach
- 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
RedactSure documents
- RedactSure, “Secure AI for Healthcare” (2026). https://redactsure.com/blog/secure-ai-for-healthcare/
- Product behavior described on this page (render-layer tokenization, structured reading of the page, enclave vault with customer-held keys, supervised approval, run history) reflects RedactSure’s current design. Epic, Cerner, athenahealth, eClinicalWorks and MEDITECH are trademarks of their respective owners.
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 elseAbout 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.