For years, the health IT community has celebrated the expansion of patient access to health information: FHIR-based Patient Access APIs, USCDI data standards, TEFCA. The policy architecture was built to give patients authorized, structured access to their clinical records.
It covers roughly a third of what patients actually need to do in a portal.
Scheduling, messaging, refill requests, billing inquiries, and insurance questions aren't fully addressable through the authorized API channels we've spent a decade building. Patients who want to manage their care across multiple health systems still face multiple logins, multiple interfaces, multiple sets of credentials, and a patchwork of functionality that varies by organization and EHR version. The clinical information is technically available, but acting on it is still the patient's problem.
Patients are solving this problem themselves. Not by waiting for the next rulemaking cycle, but by teaching an AI agent to handle it for them. Log in once, navigate the portal, pull the lab results, request the refill, send the message. The agent handles it. The patient moves on.
A recently released open-source tool demonstrates how far this has already progressed. It logs into patient portals using the patient's own credentials, handles two-factor authentication, and exposes dozens of tools for reading and writing patient data: messages, refills, appointments, billing, insurance. It's early and imperfect. It won't stay that way. And it's one example among many. Open-source agent frameworks capable of running these kinds of tools have grown from experimental projects to hundreds of thousands of users in a matter of months. The patient behavior they enable will scale with that adoption.
The tools patients are using to fill that gap work differently than the ones health systems have been governing.
One step past reading the record
The existing FHIR-based APIs that give patients authorized access to their records are read-only and limited to a defined set of clinical data elements. They operate through standardized, authenticated channels that health systems can monitor, govern, and audit. Patient portal agents work differently. They use the patient's own credentials to log into the portal interface directly, the same way the patient would. They write. They schedule. They message. They request refills. From the health system's side of the portal, the interaction looks identical to a patient doing it manually. There's no indication that a human is driving it, and unlike API-based access, there's no structured channel through which the health system can apply governance controls.
A pattern health systems have navigated before
This isn't the first time patient access to health information has gotten ahead of organizational readiness. Patient portals gave patients their lab results before clinicians called. OpenNotes gave patients access to visit documentation and changed how clinicians wrote their notes. Price transparency requirements changed financial conversations at the front desk. Each transition required health systems to think through workflows, training, communication, and documentation. The ones that started early handled it. The ones that didn't spent months reacting.
Patient agents follow the same pattern. Prior transitions changed what patients knew. This one changes what patients can do.
The blind spot in current AI governance frameworks
AI governance frameworks in health systems share a built-in assumption: the organization controls the AI tools in play. That assumption holds for tools the organization selects, deploys, and monitors. Patient agents sit outside it. So do most portal terms of service, which weren't written with delegated automation in mind.
The enforcement position most organizations already hold
The information blocking enforcement environment has created a chilling effect on portal terms of service enforcement. Health systems that have drafted automated-access restrictions often hesitate to enforce them, because defending an information blocking complaint, even one they would ultimately win, carries real legal cost. Many organizations have effectively ended up in a non-enforcement position, whether by deliberate choice after legal review or simply by not having addressed the question yet. Either way, the position itself can be defensible. The governance gap is rarely about the enforcement approach an organization chose. More often it's the failure to document that approach, brief security operations on what it means for their threat model, and build clinical workflows around it. Many organizations are carrying an enforcement position their boards haven't been told about, their security teams don't know how it shapes their threat model, and their clinical staff are navigating without any operational guidance.
The security exposure that follows from it
Patient credentials are currently sitting in third-party agent frameworks with zero organizational visibility. If one of those platforms is compromised tomorrow, your IR team cannot identify which patients are affected, cannot revoke sessions it doesn't know exist, and cannot determine which portal interactions over the past six months were human-initiated. That's a present-tense breach-scoping gap your SOC should already be threat-modeling. Security operations can't build incident response playbooks around a risk acceptance decision nobody told them was made, which is why your CISO needs to be briefed on your organization's enforcement approach before your board is.
You can't govern what you can't monitor, evaluate, or enforce. Extending a governance committee's remit to patient-deployed agents without building the accountability infrastructure to match is paper coverage. The liability framework for tools patients bring is structurally different from the framework that applies to tools the organization deploys.
The accessibility dimension your general counsel will flag
For a meaningful subset of your patient population, patient agents are also an accessibility solution. A patient with a mobility impairment who cannot easily navigate a multi-step portal interface, or a patient with limited English proficiency whose portal is not available in their language, may be using an agent precisely because your portal is not accessible enough for them to manage independently. Section 1557 of the Affordable Care Act and the ADA require covered healthcare entities to provide meaningful access to patients with disabilities and those with limited English proficiency. HHS digital accessibility requirements for patient portals and mobile apps set a May 11, 2026 compliance deadline for covered entities with 15 or more employees, requiring WCAG 2.1 Level AA conformance. If your organization restricts patient agent access without offering an equivalent accessible pathway, you have a plausible disparate impact question under Section 1557 and the ADA that your general counsel needs to have considered before that restriction is enforced. That legal question isn't settled. It belongs on your general counsel's desk before it becomes urgent.
