Administrative Tasks Healthcare AI Agents Can Automate Without Custom Integrations
Screen-reading AI agents can handle prior authorizations, claims.

Computer-use AI agents can automate healthcare administrative workflows without custom API integrations by reading screens, clicking, typing, and navigating existing EHRs, payer portals, and fax systems. Their value comes from connecting the steps of prior authorization, claims, scheduling, and other administrative work. Because agents still make errors, their end-to-end reach needs clear rules for human review and ways to measure how well each workflow runs.
Why administrative work resists the automation tools practices have tried so far
HealthAdminBench puts what the U.S. spends each year on healthcare administrative work at above $1 trillion. Much of that work crosses systems never designed to exchange information with each other. Staff move between legacy EHRs, payer portals, and fax systems, interpreting documents and transferring information as they go. The friction sits within and between systems. Automating one screen leaves the next handoff untouched.
Tools that depend on an API cannot reach systems without API support, while traditional robotic process automation uses scripts that can break when layouts change or unstructured information needs to be read and understood. These conditions are common in healthcare administration. Staff may therefore still have to do part of an authorization request by hand even when one stage has been automated.
API access is improving, but it will not remove this mixed environment. The Da Vinci Project’s FHIR specifications, including CRD, DTR, and PAS, move prior authorization toward API-native submission. But covered payers do not have to support FHIR Prior Authorization Support until January 1, 2027. Practices will still face portal, API, and fax submission for the foreseeable future. A different approach to automation must work through those channels, read different kinds of documents, and find its way through interfaces that change.
How can AI agents navigate EHRs and payer portals without API setup?
Computer-use agents work through the interface that staff already use. The screen supplies their input, and mouse clicks and keystrokes supply their output. They read what is displayed, locate the relevant controls, enter information, and navigate to the next step. No custom connector is required for each system. The EHR and payer portal need no modification.
HealthAdminBench, a 2026 benchmark from Kinetic Systems developed in collaboration with Stanford Hospital domain experts, reflects this operating environment. It tests agents across an EHR, two payer portals, and a fax system, covering 135 expert-defined tasks. These are the gated interfaces through which administrative work already passes.
Agentic coordination extends screen operation across a workflow. Dynamic task decomposition, persistent memory, and multi-agent collaboration allow work to move from the EHR to a portal and then to fax without requiring a human handoff at every transition. Using an existing staff login, an agent can reach software that has no API access, including older EHR versions and legacy portals. Unlike a fixed script, its visual reasoning can reinterpret a changed layout. That makes it more resilient to interface changes, though not immune to failure.
What end-to-end prior authorization looks like when an agent runs the full workflow
Allegheny Health Network partnered with Humata to automate prior authorization from clinical data extraction through submission and status tracking. MUSC Health expanded its agentic AI deployment and now completes a meaningful share of authorizations with zero manual involvement. Its processing time per case fell from roughly half an hour to about a minute. These deployments address more than form completion. They connect the work required before and after submission.
In a full prior authorization workflow, an agent identifies the requirement in the EHR, logs into Availity or a direct payer portal, and gathers the required clinical data. It submits the request, monitors status over hours or days, and routes the decision back into the chart. Where a portal is inaccessible, a voice agent can call the payer, navigate phone menus, wait on hold, and speak with a representative.
Decision deadlines add urgency to that coordination. Rules already in place in 2026 give impacted payers 72 hours to decide urgent requests and 7 calendar days to decide standard requests, and require them to give a specific reason for each denial. Tracking the response is therefore part of completing the authorization.
How agents handle the full claims lifecycle, from pre-bill error detection to denial appeals
One health system said it had cut the time for claims appeals from several weeks of manual nurse review to days. An agent reads denial letters, assembles corrected documentation, and routes the result for nurse approval. The nurse retains responsibility for sign-off. The agent handles the research and assembly work that previously prolonged the process.
That example shows the value of connecting tasks, but appeals begin after a claim has already failed. Earlier in the lifecycle, an agent can use structured EHR data and unstructured notes together to find gaps in documentation, missing medical-necessity support, and coding-evidence mismatches. Correcting those problems before submission is more efficient than reconstructing the evidence after a denial.
The scope of automation determines how much work remains manual. A practice that automates eligibility verification alone still needs staff to review claims, classify denials, and assemble appeals. Revenue losses from denials, undercoding, delayed follow-ups, and manual processing make even partial improvement valuable. Broader lifecycle coverage addresses more sources of loss, provided that review remains in place where errors could reach the payer.
Scheduling, referral intake, and cancellation recovery as connected agent workflows
Following a visit, an agent can create referral orders in the EHR, draft the prior-authorization letter, and submit it to the payer portal pending physician approval. That follow-through connects a referral being ordered with the administrative work needed to act on it.
Scheduling continues the same chain. An agent can match patients to available slots based on preferences and care needs, send reminders, verify insurance eligibility in real time, and pre-fill intake forms from existing EHR data. Voice AI can support scheduling interactions, but it is one modality within this broader capability. The workflow also requires updating the systems that hold the appointment and patient information.
A cancellation creates another handoff that agents can handle. The agent detects the opening, identifies eligible waitlisted patients, reaches out, confirms rescheduling, and updates the schedule. Staff no longer need to monitor the calendar manually for every gap. Once an unfilled provider slot has passed, its revenue is lost, so filling openings quickly links patient access to provider utilization across locations.
Durable medical equipment ordering and other payer portal tasks agents handle across systems
HealthAdminBench includes Durable Medical Equipment order processing as a task category with Prior Authorization and Appeals and Denials Management. DME is therefore already a benchmarked administrative workflow. Its inclusion also broadens the discussion beyond authorizations and claims.
DME order processing requires coverage verification, order submission, clinical documentation attachment, approval tracking, and updates to the patient record. The steps are much like those in prior authorization, though the request is for equipment. An agent logs in, locates the patient, completes structured fields, attaches documents, submits the request, and monitors its progress. It does not need a new integration for each workflow type.
The same portal interaction layer reaches other repetitive tasks. These include eligibility verification with multiple payers before appointments, checks on benefits coordination, and follow-ups to check the status of pending requests. Each requires information to be found or entered through an existing interface. The architectural advantage is that one approach can reach all these workflows, rather than requiring a separate connection for every portal task. Reach, however, is not the same as reliable completion.
Where current computer-use agents succeed at subtasks but still fall short on full-task completion
HealthAdminBench found that its best-performing configuration, Claude Opus 4.6 CUA, achieved only 36.3% full-task success. The higher rate of subtask success showed that agents could get many steps right and still fail to finish the whole task. Document handling and cross-system data transfer were key failure points.
This distinction qualifies the entire workflow catalog. An agent may be able to navigate a portal or fill fields without reliably completing the transfer that connects those actions to a finished request. Successful clicks do not establish successful administration.
The deployment implication is to define human review and recovery before assigning work. An incorrectly assembled appeal can be caught at nurse review, and a coding error can be caught during pre-bill review. Those checkpoints give incomplete or incorrect work a route to correction. Practices should select workflows with such recovery paths rather than allow uncaught errors to reach patients or payers.
How to deploy agents on existing systems without disrupting staff workflows or requiring IT overhaul
A practice should begin with one high-volume, well-defined workflow, such as prior authorization or eligibility verification, whose output can be reviewed against a known standard. This keeps the first test small enough to review before taking on related work. The agent operates through an existing staff login and the familiar interface. The practice’s technology stack stays as it is.
That avoids a custom integration project, talks over an API contract, or changes to the EHR, but the practice still needs to prepare for how the work will change. Staff responsibilities need deliberate redesign. As agents take over repetitive transactions, more staff attention can move toward exceptions, quality review, and governance. Change management is therefore part of deployment even when software replacement is not.
For multi-location groups, PE portfolios, and enterprise health systems, interface-based operation also changes the scope of rollout. An agent that can work across the systems involved in a workflow does not require every site to use the same platform. This creates a path to portfolio-level automation without first standardizing every EHR. Expansion should still follow reviewed results from the initial workflow, rather than assume that access to another system establishes reliable performance within it.
HIPAA compliance and PHI security requirements that apply to any agent handling administrative workflows
Any agent that handles protected health information must meet the HIPAA requirements for systems that handle ePHI. There is no exemption for AI-based administration. Compliance architecture must be verified before deployment, regardless of whether the agent connects through an API or operates through a screen.
A concrete exposure arises when staff enter patient details into a public generative AI tool without a BAA and appropriate security controls. Deploying through a compliant, credentialed system avoids that particular route of exposure. Screen-based access does not, by itself, establish compliance. HealthAdminBench’s gated access, sensitive data handling, and limited documentation reflect the constrained environment in which agents must operate.
Practices should also plan for tightening requirements. The proposed HIPAA Security Rule update would eliminate the “addressable” safeguard distinction and require annual risk assessments explicitly including AI systems. Its originally targeted May 2026 finalization has been delayed, with OMB targeting July 2027 for final action. State requirements add another layer, including Texas TRAIGA, California’s AB 489, and Colorado’s AI Act, SB 26-189, effective January 1, 2027. Practices must therefore meet state as well as federal rules on disclosure and governance.
Measuring agent value against workflow-specific outcomes rather than generic efficiency claims
Practices should agree on which workflow outcomes to measure before they deploy agents. Prior authorization calls for approval rate and days to decision, while claims automation calls for denial rate and days in accounts receivable. Scheduling requires provider utilization and cancellation recovery rate. These measures test whether the administrative objective was achieved. Generic claims about hours saved do not.
Allegheny’s deployment with Humata reported a 96% first-pass approval rate, giving administrators a workflow-specific result. That specificity supports a meaningful evaluation of performance. The benchmark’s gap between subtask and full-task success shows why saving time alone is not enough. Faster individual steps can coexist with unfinished requests and untracked exceptions.
For enterprise operators, measurement also needs to span locations. Authorization approval rates for all sites combined, denial rates by site, and utilization across locations can show whether automation gets consistent results across different systems. Those results provide the basis for expansion or correction. An agent deployed against a defined first-pass approval target can be held accountable for that outcome, while one described only as helping with authorizations invites anecdotal evaluation. The purchasing criterion is completed, reviewed administrative work (not simply the ability to operate the software).


