Data Report · RedactSure Research
Chris Sowa · Founder, RedactSure
Published
Last updated
How Do Hospitals Use AI Agents Without Exposing Patient Data?
Hospitals start agents on administrative screens, posting payments, checking eligibility and booking visits, and keep clinical reading inside the EHR vendor's own tools under a business associate agreement. Ask what the model receives on each screen and who approved the action, because every account screen names a patient.
A patient account screen in a hospital billing office shows a name, a date of birth, a guarantor, a balance and the claim history behind them, and that is the screen an agent is asked to work first. The tasks a hospital can hand over without a clinical judgment carry the clearest case: eligibility checks, scheduling, payment posting and denials follow-up. Each of them runs on a page that names a person.
The vendor pages show the shape of the work. Epic's billing interfaces post charges and payments against guarantor accounts, and its card integration returns a verified payment to the system that posted it. The break-glass rule on a flagged record asks for a reason and a password and writes an audit entry. None of those pages says what a model reads when it works the same screen, and that is the part a hospital has to settle before it hands over a queue.
Clinical reading has stayed inside the EHR vendor's own tools, under a business associate agreement, because the record is the vendor's product and the agreement is the instrument that governs it. Administrative work moved first because the volume is high, the rules are written down and the result is a posting rather than a note in the chart. The difference between the two is what the model receives, and the administrative tasks are the ones a hospital can change without touching the clinical record.
Key findings
- For a hospital agent to work a patient account without learning who the patient is, the values on the rendered screen would have to be replaced with consistent tokens before any model reads it, so the run posts against ACCT_001 and the real name resolves only at the payment destination (What Is Render-Layer Tokenization?).
- It would also require a named person approving each posting, adjustment and record change, and an audit record of the read, which the break-glass control in Epic creates for the person who opens a flagged record and not for an agent that reads one (University of Iowa Health Care, Break-the-Glass, 2026).
- The pages reviewed describe the posting work and the access gate and do not describe a step that replaces a value on the rendered screen before a model reads it, so the control sits outside the interfaces the EHR vendor documents (Epic Systems, 2026).
- Epic's interface catalog says Incoming Financial Transactions "can receive charge and credit transactions for hospital accounts for Epic's Hospital Billing application, and post or void charges on guarantor accounts for Epic's Professional Billing application," an interface description that does not say what a model reads on the posting screen (Epic Systems, 2026).
- The payment-posting catalog lists "Posting Guarantor Payments (SBO030)", "Posting Insurance Payments (RHB030)", "Posting Adjustments (RHB032)" and "Working Remittance Workqueues (RPB031)", and says the resources "describe back-end payment posting workspaces and workflows," so the task is a workspace rather than an API (University of Iowa Health Care, Payment Posting, 2026).
- A measured study of web agents found they "are prone to inadvertent use of unnecessary sensitive information," which on a patient account means the name and the balance arrive with the claim status the task needed (Zharmagambetov et al., 2025).
Which hospital tasks does an agent work from a rendered screen?
The first three tasks a hospital gives an agent tend to be the ones where the screen is the whole job. An eligibility check opens the payer portal, enters the member and the date of service, and reads the coverage response. A scheduling task opens the template, finds a slot and books the visit against the order. A posting task opens the remittance workqueue, matches the payment to the claim and posts it.
The worked record is that set of three, a hospital's first three agent tasks, and each one is a rendered page. The eligibility response draws the plan, the member and the patient. The scheduling template draws the patient and the visit. The posting batch draws the claim, the guarantor and the amount. A task can be administrative and still name a patient on every line.
The order is administrative first and clinical last for a reason. The administrative work is repetitive and measured in batches, and the payment-posting catalog says its resources "describe back-end payment posting workspaces and workflows," listing module titles, formats and run times rather than fields (University of Iowa Health Care, Payment Posting, 2026). The clinical work is a note, an order or a diagnosis, where the reading is the judgment and the chart is the record.
Jim Sinkoff, Deputy CEO and CFO, Sun River Health, said on a HAL podcast that the administrative logic does not carry over: "That's not the case in the clinical environment. The clinical environment is much more rigid." (Who Owns the Data When AI Touches Patient Records? A Health System CFO on AI Governance).
An agent that works the three tasks needs the claim, the amount and the status. It does not need to know who was treated, and the page supplies that anyway (Can an AI Agent Work in Epic Without Holding PHI?).
What does a patient account screen carry that the task does not need?
The payment-posting catalog shows the shape of the work in its module list, "Posting Guarantor Payments (SBO030)", "Posting Insurance Payments (RHB030)", "Posting Adjustments (RHB032)" and "Working Remittance Workqueues (RPB031)", and it gives no field detail (University of Iowa Health Care, Payment Posting, 2026). Each row in a batch belongs to a patient, and a remittance page has the same property, where the claim number and the amount are the keys and the name rides along (Can an AI Agent Post Remittances Without Reading Patient Names?).
A model reading that page receives every field it draws. The AgentDAM evaluation found that web agents "are prone to inadvertent use of unnecessary sensitive information," which describes the failure: the task needs the claim, and the page supplies the name, the date of birth and the balance beside it (Zharmagambetov et al., 2025).
The hospital's own controls are built for a person at the screen. For a flagged patient the break-glass rule reads, "the user must enter a reason and their password," and the page adds that "An audit trail stores details of the event when a user chooses to break the glass" (University of Iowa Health Care, Break-the-Glass, 2026). A reason and a password identify a person and record the decision. An agent that reads the same record has neither, and the pages reviewed do not describe a reason field or an audit entry for a model's read.
The access control decides whether a person may open the record, and nothing in it decides which values the page draws once it opens. The page the agent reads is a rendered page, not the database behind it, which is why the browser that renders it is part of the surface to review (What Is the Difference Between a Headless Browser and a Protected Browser for AI Agents?).
What do the vendors themselves say?
Epic documents the interfaces and the gate. The card path is explicit: "The gateway then sends the verified payment information back to the Epic system to post the payment," across "the patient portal and patient kiosk software as well as in over-the-phone and billing-office use cases"; for collections, "Epic can generate a flat file extract to collections agencies containing information about charges assigned to the agency," and Epic can receive flat file imports with updates to those charges (Epic Systems, 2026), an interface description that does not say what a screen shows a model that works it.
The University of Iowa's Epic training catalog is the customer-side view, listing the posting modules and saying the resources "describe back-end payment posting workspaces and workflows," with no field detail, posting rules or error handling on the page (University of Iowa Health Care, Payment Posting, 2026). The break-glass page covers the gate: "the user must enter a reason and their password," "An audit trail stores details of the event when a user chooses to break the glass," and "ONLY Compliance and Hospital Operations Managers (HOMs) can set the Confidential patient flag from the Flags activity" (University of Iowa Health Care, Break-the-Glass, 2026). The MyChart page covers the portal, where adolescent proxy messages "will be routed to a general pediatric or pediatric specialty pool," "Confidential messaging allows the patient and clinician to select which proxy users are able to view the message," and "HIM approved Patient Proxies are given access to view a patient's chart through MyChart via Proxy Access" (University of Iowa Health Care, MyChart, 2026).
| Dimension | Epic, per its documentation | What a buyer should verify |
|---|---|---|
| Payment interface | Incoming Financial Transactions can "post or void charges on guarantor accounts" | Whether the agent posts through the interface or reads the screen |
| Card payment | "The gateway then sends the verified payment information back to the Epic system" | What the page shows the model when a card payment posts |
| Posting work | "back-end payment posting workspaces and workflows" | Which fields the agent reads on those screens |
| Access gate | "the user must enter a reason and their password" | Whether an agent can open a flagged record, and what is recorded |
| Portal messages | Adolescent proxy messages go to "a general pediatric or pediatric specialty pool" | Which proxy the agent runs under, and what the message body carries |
| Audit | "An audit trail stores details of the event" | Whether the record covers a model's read |
A step between the page rendering and a model reading it is not described in the pages reviewed. That absence is the finding.
Does a business associate agreement change what a model receives?
No. An agreement governs how a vendor handles patient data and what it promises the hospital; it does not describe what the vendor's model receives from a screen.
HHS guidance lists "claims processing or administration, data analysis, billing, and practice management" among the activities that make a vendor a business associate, and it requires "satisfactory assurances, in the form of a contract or other written arrangement" before a covered entity discloses patient data to that vendor (HHS Office for Civil Rights, 2026). A company whose agent reads denials and posts payments for a hospital falls inside that list, because the test is the data handled rather than the technology.
The same page settles who is disclosing: "A provider that submits a claim to a health plan and a health plan that assesses and pays the claim are each acting on its own behalf as a covered entity," and the conduit exception is limited to entities that "only provide transmission services for PHI" (HHS Office for Civil Rights, 2026). A vendor that reads a patient account on a regular basis to work the queue is doing more than transmitting, and the page adds that entities which access patient data to perform a service for a covered entity are not conduits.
What the agreement adds is accountability: who may use the data, which safeguards apply, how a breach is reported. What it cannot add is a sentence about the rendering step, because a contract can require safeguards without saying what a screen draws. A hospital can hold a signed agreement with its EHR vendor and still be unable to say whether the vendor's agent read a name from a patient account (Does an AI Model Vendor Need a BAA for Patient Records?). The exposure is not rare: about 1 in 3 large healthcare breaches came through a vendor, a business associate under HIPAA, in each year from 2023 to 2026, counting only breaches of 500 or more people and relying on a flag the reporting entity fills in (How Many Healthcare Breach Victims Were Exposed Through a Vendor?).
What should a hospital ask for in writing before an agent reads a screen?
Ask what the model receives from a rendered screen first, because that answer does not change when a role, a setting or a confirmation is added. Then ask who approves each posting, adjustment and record change, and what record of the read survives the run.
Harvard's guidance lists seven risk categories for AI systems and asks teams to "Require human approval for high-impact, sensitive, irreversible, or externally visible actions whenever feasible" and to "Maintain the ability to promptly revoke access, disable the connector, or stop the system when it behaves unexpectedly" (Harvard University, 2026).
The screen question is the one vendors answer least often, and a filter on the way into the model is not the same control as a page that draws without the value. The strongest published result for a firewall at the agent-tool interface reports a "simple, modular, and model-agnostic defense operating at the agent-tool interface" that "achieves perfect security with high utility across all four public benchmarks" (Bhagwatkar et al., 2026). The same paper concludes that "existing agentic security benchmarks are easily saturated by a simple approach," so a benchmark win is a statement about the benchmark (Bhagwatkar et al., 2026).
Nasr and co-authors bypassed 12 published defenses against jailbreaks and prompt injections with an "attack success rate above 90% for most," many of which had reported near-zero rates (Nasr et al., 2025).
The written ask has four parts: which values the page may draw, who approves the action, where the record exports, and what the vendor will show in a test on one workflow with no real patient data (How Do You Pilot an AI Agent on Real Customer Data Without Creating a Breach?).
What does a governed environment change?
A governed environment acts where the page is rendered. Values chosen by policy, the patient's name, the date of birth, the guarantor and the account number among them, are replaced with consistent tokens before any model reads the screen, so the agent works ACCT_001 and PT_001 for the whole run. Real values resolve only at the approved destination, at the moment of an approved action, and for this record that destination is the posting or the payer submission a named person releases.
Every screen the model read as tokens, every action and every approval with a name is written to a record the hospital can export to its own monitoring, which is the artifact that answers for an agent what the break-glass audit entry answers for a person (What Is Render-Layer Tokenization?).
Substitution does not cost the work its accuracy. Replacing identifiers with consistent pseudonyms and restoring them after the model has done its work reduces semantic utility errors by a factor of five compared with baseline techniques, which places the loss on inconsistent redaction rather than on substitution itself (Does Masking Data on Screen Break Browser Agents?).
The scope has to be stated with the same care. A governed browser environment covers the rendered page the agent works. It does not cover the batch file a hospital imports into its billing system, the interface that posts the charge, or the EHR database behind the page. One condition decides the question: the name on the page must be a token before the model reads the page, and then the posting runs and the model finishes the task without ever holding the name.
What the record shows
What the model receives on the rendered patient account is what the run keeps, so the page rather than the ledger entry decides what the agent knows. The administrative tasks a hospital starts with need the claim and the amount, the vendor pages document the work and the access gate without documenting a step that keeps the name off the model's side, and the agreement governs custody rather than the reading. That is the finding, and it points at the screen. A hospital can check it on one workflow: pick a posting batch the hospital already runs, render it with the patient's name and date of birth replaced by tokens, and run the agent. Then compare three things, the page the model received, the posting it proposed and the name on the approval. If the approval names a person and the page holds a token, the hospital has a control it can test again after every release. If the page holds the name, the exposure happened before anyone approved anything.
Methodology and limitations
This page rests on public documentation: an EHR vendor's interface catalog, a health system's Epic training pages for payment posting, break-glass and MyChart, HHS guidance on business associates, university guidance on generative AI systems, and three research papers on prompt injection and web-agent privacy. Public documentation read in full gives a sound view of where each product applies its control. The pages were read between October 16, 2026 and October 22, 2026.
No product named here was tested for this page, and "not described in the pages reviewed" means the pages listed in Sources. Vendor features change, so the page carries its date. The products on this page are described from their documentation, RedactSure included, and the example describes a record type, a set of agent tasks on patient accounts, and not an organization. RedactSure is deploying now with enterprise and government customers. Whether an agent's reading meets a contractual or regulatory requirement belongs to counsel, assessors and the hospital's own compliance officers, and nothing here replaces a pilot of one workflow on the hospital's own screens.
Frequently asked questions
How do hospitals use AI agents without exposing patient data?
On administrative screens first, with the identifiers handled before the model reads them. Eligibility, scheduling, payment posting and denials are the tasks a hospital hands over, and each one runs on a page that names a patient. The vendor pages document the work and the access gate; they do not describe a step that keeps the name off the model's side. A hospital that starts with those tasks, a tokenized page, a named approver and an exported record has a pattern it can repeat when clinical work follows.
What does the model receive when an agent opens a patient account?
Every field the page draws. The account page carries the name, the date of birth, the guarantor, the balance and the claim history, and a posting batch carries a row for each patient in it. The task needs the claim and the amount, and the identity arrives with them. Unless policy-chosen values are replaced before the model reads the screen, the name and the date of birth enter the context and stay there for the rest of the run.
Does a business associate agreement change what the model reads?
No. The agreement makes the vendor a business associate and sets out how it handles patient data. Federal guidance requires "satisfactory assurances, in the form of a contract or other written arrangement" before a covered entity discloses patient data to a business associate. It does not describe what the model receives from a screen, and a contract can require safeguards without naming a rendering step. A signed agreement can leave a hospital unable to say whether the agent read the name.
Who approves a payment an agent posts?
A named person on the hospital's staff, before the payment is released, with the approval tied to the run rather than to the session. The break-glass control shows the shape of a person-level gate: a reason, a password and an audit entry. That gate is built for a person who opens a record, and the pages reviewed do not describe its equivalent for an agent. The approval should name the person, the batch and the amount.
What record shows what the agent saw on a screen?
One that pairs the screen the model read with the action and the approver. A posting batch leaves a trail of amounts, and that trail records the money rather than the reading. The record a reviewer needs carries the tokens the model saw, the posting it proposed, the name of the person who released it and the time, exported to the hospital's own monitoring rather than kept in a vendor dashboard.
Can an agent work denials without reading patient identities?
Only if the identifiers are replaced before the model reads the page. A denial carries the claim number, the member identifier, the date of birth and the diagnosis, and the appeal needs the claim and the reason rather than the identity. Substitution keeps the claim consistent across the run, so the agent can find the same claim again while the name stays out of its context. Without that step, the agent reads the identity with the denial.
How RedactSure Keeps Patient Names Off the Screens an Agent Reads
An agent reading a patient account holds the name, date of birth and balance for the whole run, and the gates above govern the person, not the model. The AgentDAM evaluation found web agents "are prone to inadvertent use of unnecessary sensitive information" (Zharmagambetov et al., 2025).
The environment that enforces this is built by RedactSure, an AI agent controls, governance and data protection company.
Before, the page shows the name, the date of birth and the guarantor beside the claim; inside the governed environment it draws ACCT_001 and PT_001, and the real values resolve only at the posting a named person approves.
RedactSure is deploying now with enterprise and government customers.
Everyone else controls where data can go. RedactSure controls what the AI can see.
See it on your own workflow
A patient account screen is the record a compliance office asks about first. Bring one posting task and see, with test values, what the model reads on the screen it works and who approved the posting. Book a demo