When Your Patient's Agent Calls

Part 1 and Part 2 worked through what patient-deployed agents do to a health system: the security exposure, the nursing inbox at 6:30 AM, and the enforcement position most organizations are holding without having decided to. Part 3 takes up the question sitting underneath all of it.

When a patient's agent logs into the portal and acts, by what authority is it acting?

None of the operational answers from Parts 1 and 2 resolve that. The vendor side of the industry is busy answering its own version of the question. The push right now is to give AI agents a verifiable identity, so an agent arrives as a recognized actor with permissions the system of record can see, rather than as anonymous traffic it can't tell apart from a scraper. That same conversation is now running through health IT. The progress is real. It also makes the silence on the patient's own agent easier to notice.

The vendor answer doesn't reach the patient's own agent

Most of the agent-identity work happening right now is about vendor agents. A business partner builds an integration, the integration authenticates as itself, and the provider approves it with permissions that are scoped and revocable. Three-legged OAuth, the model a growing number of post-acute and acute platforms now require, does exactly this. The system of record can see which agent is acting and shut one off without cutting off anyone's patient.

I touched one corner of this in Part 2, and it's worth scoping carefully, because the ruling gets stretched further than it reaches. The Fourth Circuit's PointClickCare decision found that using technical controls to block automated access likely counted as information blocking. That case was narrow. It involved a health information network pulling data through certified health IT pathways, not a patient's agent on portal credentials, and it doesn't transfer cleanly to the patient case. Read it as a general instruction that health systems must permit patient agents and you've read in more than the court held. What it did do is push vendor-side practice toward identifying and permitting automated access rather than walling it off, since giving each integration its own identity is how you permit access and still keep control of it. None of that settles what a health system owes a patient's own agent.

That works because vendor agents are a bounded, contracted population. There are a few hundred of them, and each one signed something. A patient's own agent is none of that. No contract, no marketplace, no identity issued by anyone, and built to look exactly like the patient. The vendor answer is real, and it stops at the edge of the patient's own agent.

Power of attorney is the wrong frame

The first instinct, when you try to place a patient's agent in a legal category, is power of attorney. A patient authorizes something to act for them, so it feels like a delegation of authority.

It doesn't fit. A health care power of attorney is a documented legal instrument, executed under state law, that names a person to make health care decisions when the patient can't. It has a known principal, a named agent, a signature, and a revocation process. A patient running an agent on their own portal login has none of that paperwork, and the patient may be present and competent the whole time. Power of attorney describes someone acting in the patient's place. A patient's agent is the patient acting, through software.

Personal representative doesn't fit either

HIPAA has its own version of this idea, the personal representative. Under 45 CFR 164.502(g), a covered entity has to treat a personal representative as the individual for access to records and for exercising the individual's rights. It's a strong status, and it's worth understanding why a patient's agent doesn't qualify for it.

The status comes from state law, not from HIPAA. A person is a personal representative only if, under applicable state law, they have authority to make health care decisions for the individual, usually through a power of attorney, a guardianship, or parental rights. HIPAA defers entirely to the state on who holds that authority. No state makes software a decision-maker. There's no instrument that confers personal-representative status on an autonomous agent, so the status isn't available to it.

There's a more basic reason it doesn't fit. A personal representative is a third party who steps into the patient's shoes. A patient's own agent isn't a third party at all. It's the patient, using a tool, exercising the patient's own rights.

The more honest anchor is the right of access

If a patient's agent isn't a representative, the next question is what it is. The closest fit I can tell in existing law isn't the personal-representative rule. It's the individual right of access under 45 CFR 164.524, the patient's own right to reach their own records.

That reframes the question in a way that's more useful to a board. The issue isn't whether to recognize some new kind of representative. It's whether a patient's existing right of access extends to access the patient carries out through software they direct, and at what point a patient using a tool becomes an agent acting on its own that the system of record can treat differently. That line isn't drawn yet, in regulation or in case law. Posing it honestly is more useful than reaching for a category that doesn't fit.

Three agents, three different answers

The word "agent" is carrying three different situations, and a board that wants to govern this well needs to tell them apart.

1. The first is the patient's own agent, the case Parts 1 and 2 were about. It's closest to an extension of the patient's own right of access, with no representation involved. This is the one with no settled legal home.
2. The second is an agent deployed by an actual personal representative, a POA-holder or guardian using software to do what they're already authorized to do. Here 164.502(g) genuinely applies, to the human, and the agent inherits that person's scoped authority. The legal authority is clear. The technical attribution still isn't.
3. The third is a vendor's agent, the marketplace-integration case. This one runs on contract and API terms, with no patient-rights question in it at all. It's also the one the industry is closest to solving, through the identity work described above.

The risk in the current conversation is that the third case gets solved, gets most of the attention, and gets mistaken for progress on the first. Identity for vendor agents tells you nothing about the authority of a patient's own agent. They're different problems wearing the same word.

What this leaves on a board's desk

Part 2 laid out the operational moves available now. Part 3 adds one that sits earlier than any of them. Before an organization decides how to handle patient agents, it helps to be clear about which of the three it's actually deciding about, because the legal footing under each is different. A policy written as though all three are the same problem will be wrong about at least two of them.

None of this is settled, and a board can't settle it. Courts and regulators will draw the line on whether a patient's right of access reaches the software a patient directs. What an organization can decide now is how it will act while that line is still being drawn, and to do that deliberately rather than by default.

The vendor world is giving its own agents identity and calling it governance. For a patient's own agent, the more honest position is that the authority question is still open. Naming it clearly, and deciding how you'll operate until it's answered, is the work in front of healthcare leaders now.

This article describes how existing rules map to an emerging situation. It isn't legal advice, and the questions it raises belong with your counsel.