PHI: What AI Can Touch — and What It Can’t | HIPAA AI EHR

Five things your EHR’s AI assistant is quietly reading right now — and what HIPAA actually says about each.

Every AI vendor selling into healthcare says the same thing: HIPAA-ready. It’s on the homepage, the sales deck, the security questionnaire. And it’s usually true, in the narrow sense that the vendor has signed the right paperwork and encrypted the right database.

But “HIPAA-ready” describes the vendor. It says nothing about what happens once that tool is wired into your EHR, reading real patient data, in real time, across real workflows. That’s a separate question — and it’s the one most health systems haven’t answered yet.

Here are five places AI is already touching PHI inside a typical hospital, what’s actually permitted at each one, and where the gap between “compliant product” and “compliant deployment” tends to open up.

1. The Ambient Scribe Is Recording the Whole Room

Ambient AI scribes listen to the patient encounter and draft the note. That’s the value proposition — less typing, more eye contact. It also means the microphone is on for everything said in the room: the patient’s symptoms, but also the name of the family member who drove them in, the medication they admit to skipping, the offhand comment about a second opinion at another hospital.

HIPAA permits this as treatment documentation. What it doesn’t waive is consent and disclosure. In January 2026, a patient sued Sharp HealthCare alleging an ambient AI scribe recorded his visit without his knowledge. In April 2026, Sutter Health and MemorialCare were named in a similar class action — the complaint alleges the AI system auto-inserted consent language into the record claiming patients had agreed to recording when they hadn’t.

The technology wasn’t the problem. The workflow around it — who discloses what, when, and how that’s documented — was. A 2026 JAMA study found 79% of physicians offered ambient tools declined to use them, and many are quietly going back to dictating notes after the patient leaves the room.

2. The FHIR Agent Pulls More Than It Was Asked For

An AI agent built on FHIR can query a patient’s record the way a human user would — pull medications, problem list, recent labs, scheduling. That’s the whole point of FHIR: structured, queryable access across systems.

The catch is scope. A prior-authorization agent that needs to confirm a single diagnosis code for a single claim can technically query the entire longitudinal record — including unrelated conditions, behavioral health notes, or substance use history that carries extra protection under 42 CFR Part 2. HIPAA’s minimum necessary standard says the agent should only see what it needs for the task. Most FHIR scopes, as configured out of the box, don’t enforce that distinction.

3. Scheduling Data Carries More PHI Than It Looks Like

A scheduling assistant seems low-risk — it’s just calendars. But a scheduling record often includes the reason for visit, the referring provider, an emergency contact, sometimes a note like “patient’s daughter will accompany — discuss prognosis privately first.” All of that is PHI, and it’s often the least access-controlled data in the EHR because nobody thinks of the scheduling module as a privacy surface.

An AI tool that automates appointment reminders, no-show prediction, or rebooking is processing this data continuously. If that tool sits outside the BAA covering the core EHR — a separate scheduling SaaS, a marketing automation platform — the PHI may be leaving the covered entity’s compliance boundary without anyone flagging it as a PHI export.

4. Billing Codes — and Whatever Gets Typed Into the Free-Text Field Next to Them

Billing and coding AI is one of the most mature use cases: suggesting ICD-10 codes, flagging documentation gaps, predicting denials before submission. The structured fields — codes, modifiers, amounts — are exactly what these tools are built to read, and that’s well within HIPAA’s payment and operations carve-outs.

The risk sits in the free-text fields next to them. Billing staff routinely paste clinical notes, appeal letters, or claim correspondence into “comments” fields that were never designed to hold PHI — and those fields often aren’t excluded from what an AI coding assistant ingests. A Social Security number, a patient’s full name and diagnosis in a denial appeal, or a payer’s internal case notes can end up inside a model’s context window simply because nobody scoped the free-text fields out.

5. The Prompt Itself — Where Does It Go?

This is the one most healthcare AI conversations skip entirely. Every time a clinician, biller, or AI agent sends a prompt that includes patient information, that prompt — and the model’s response — is PHI in transit and at rest, wherever it lands.

Two questions determine whether that’s a problem:

• Is the model vendor covered by a BAA? Without one, sending PHI to a third-party model is a HIPAA violation regardless of how secure the vendor’s infrastructure is.
• Is the prompt logged, and for how long? 45 CFR 164.312(b) requires an audit trail for PHI access — but “audit trail” and “indefinite retention of every prompt containing patient data” are not the same thing. The minimum necessary standard applies to logs too.

---

The Pattern Across All Five

None of these are stories about AI doing something HIPAA prohibits. In every case, the underlying access is permitted — treatment, payment, or healthcare operations cover most of it. What’s missing is the layer that decides how much, for how long, and with what disclosure — the layer that sits between “the model is allowed to see this” and “the model only sees what it needs, for as long as it needs it, and the patient knows.”

That’s not a model problem. It’s an integration and governance problem, and it’s the same one we wrote about when Claude for Healthcare launched in January 2026.

Anthropic’s Claude for Healthcare shipped with HIPAA-ready infrastructure, FHIR agent skills, and direct connectors to the CMS Coverage Database, ICD-10 codes, and the National Provider Identifier registry — built for exactly the workflows above: prior auth, coding, claims, chart review. Elation Health’s early deployment cut chart review time by 61%.

That’s a real capability shift. It’s also, by design, a platform — not a configuration. The FHIR scopes still need to be defined. The free-text fields still need to be audited. The consent workflow for an ambient tool still needs to exist before the tool is switched on. “HIPAA-ready” describes what the model is allowed to do. What it actually does inside your EHR depends on the integration layer your team — or a technical partner — builds around it. That’s also the lens we used when we mapped what it takes to connect an AI agent to an EHR via FHIR.

That’s the layer Itirra builds: the part between a HIPAA-ready model and a compliant deployment.

---

FAQ

#HealthcareIT #HIPAA #AIinHealthcare #EHRIntegration #RCM