TL;DR Healthcare runs on portals: payer sites, provider directories, scheduling systems, and clinical tools that were never built for programmatic access. Browser agents can do that work, but six problems show up on every serious build: brittle portals, session and login state, sensitive data handling, getting flagged as a bot, human-in-the-loop steps, and observability. Here is what each one looks like and how to design around it.

The systems a healthcare team needs to reach, a payer's eligibility portal, a provider directory, a scheduling tool, a patient record system, rarely expose a clean API to the outside world. So the work happens where a human would do it: in a browser, logging in, clicking through, reading a screen, and typing values back in. Browser agents automate exactly that. But healthcare raises the stakes on every part of it, and the same six challenges come up whether the team is automating eligibility checks, prior authorization, or record retrieval.

1. Portals change and break your selectors

Healthcare portals are updated on their own schedule, and a layout change that a person would not even notice can break an automation that depends on fixed selectors. A renamed button or a moved field is enough to stall a run that worked yesterday. The fix is to stop hard-coding the DOM. Agents that act on the intent of a page, find the eligibility results and read the member ID, survive a redesign that a brittle CSS selector does not.

With Stagehand you describe what to pull, not where it lives, and the agent resolves the selector at run time against the page as it is now.

const result = await stagehand.extract(
  "extract the eligibility status and member ID",
  z.object({
    status: z.string(),
    memberId: z.string(),
  })
);

When the portal moves the field, the instruction still holds. That is the difference between an automation you babysit and one that runs.

2. Login and session state are the real work

Getting past the login screen is where most healthcare agents actually spend their effort. Portals expire sessions aggressively, layer on multi-factor prompts, and log you out the moment a session looks unusual. An agent that re-authenticates from scratch on every run is slow and gets flagged as suspicious. The durable approach is to persist authenticated state, cookies and local storage, so the agent resumes an existing session instead of logging in cold each time. Treat the login as a one-time setup that a human can complete for the sensitive step, then let the agent carry that state forward.

3. You are handling PHI, so the boundary has to be deliberate

Everything an agent reads in a healthcare portal is potentially protected health information, and that changes how you build. You have to know where the data goes, what the model sees, and what gets logged. Keep sensitive values out of prompts wherever the task allows, pass them as variables rather than inlining them into instructions, and be deliberate about what your logs and recordings capture. The point is a clear, auditable boundary around PHI, not an agent that quietly copies member data into places you did not intend.

4. Portals treat automation as a threat

Many healthcare portals sit behind bot-protection systems, and a naive automation gets challenged or blocked before it reaches the page it needs. Running from a plain headless browser on a datacenter IP is the fastest way to get flagged. Agents need to present as a real browser with a consistent fingerprint and reach the site the way a legitimate user would. This is where verified access matters: the goal is not to evade anything, it is to give the agent an identity the portal recognizes as a real user completing real work, so a legitimate eligibility check is not mistaken for an attack.

5. Some steps should stay human

Not every step in a healthcare workflow should be fully automated, and pretending otherwise is how teams get into trouble. A consent screen, a clinical judgment call, or a final submission that commits a prior authorization is often a place to hand control back to a person. Design the agent to pause at those points, surface the state clearly, and let a human approve before continuing. A live view of the session makes this practical: an operator can watch the agent work, step in for the sensitive action, and hand control back.

6. When a run fails, you need to see exactly what happened

At scale, some runs will fail. In healthcare, a silent failure is a claim that never got checked or a record that never got pulled. You cannot debug what you cannot see. Every session needs a replay, logs, and enough context to answer what the agent saw and where it stopped. Observability is not a nice-to-have here; it is how you tell a portal outage apart from a broken selector apart from a login that expired, and how you prove to a compliance reviewer what the agent did.

How Browserbase helps

Browserbase gives healthcare teams the infrastructure to build agents that hold up against every one of these challenges: real browsers that survive portal redesigns, persistent contexts that carry login state across runs, verified access so legitimate work is not mistaken for a bot, live view and human-in-the-loop control for the steps that need a person, and full session replays and logs for debugging and audit. It is the layer that turns a fragile script into a healthcare automation you can run and trust. See how teams are automating the repetitive portal work so their staff can focus on patient care at browserbase.com/industry/healthcare.