Computer-Use Agents vs RPA vs API Integrations in Healthcare

Administrative waste eats up 25 to 30 percent of total healthcare spending in the US, something in the neighborhood of a trillion dollars a year. Physicians still spend 49.2 percent of office hours on EHR work and desk tasks, against just 27 percent on direct patient care, logging more than five hours a day on documentation alone. Automation keeps missing the mark here because healthcare workflows never live in one system, and the three main approaches to fixing that (RPA, API integration, and computer-use agents) each make a different bet about what kind of environment they're working in. Picking the wrong one for a given workflow means paying for it in maintenance costs or, worse, missed deadlines on time-sensitive claims.

A single prior authorization might touch an EHR, a payer portal, a fax machine, and a third-party scheduling tool, none of which were built to talk to each other. Payer portals in particular are often built to slow humans down rather than expose data cleanly, and many were never given APIs. Kore.ai puts the first-submission claim denial rate around 15 percent, often for avoidable reasons, sometimes even on claims that were pre-approved. That fragmentation is what drives billing costs up, and it's also what makes the choice between automation approaches matter so much: treat them as interchangeable and you'll end up rebuilding the same broken workflow three times before finding the one that holds.

What each automation approach assumes about how systems work

RPA assumes the world holds still: interfaces don't change, steps stay predictable, and a script written today still works next quarter. It mimics what a human does, clicking, typing, tabbing through fields, without interpreting anything on the screen. It just executes.

API integration assumes something different: that the systems on both ends agree to expose structured data through a defined contract, so machines can talk to machines without a human touching a screen. Done right, this bypasses the interface completely and holds up far better when a system changes its look, since no interface is being watched. But it only works if the other system agrees to cooperate, and a lot of healthcare software simply doesn't.

Computer-use agents assume the opposite of RPA: that systems are messy, inconsistent, and might never offer an API. Instead of scripting fixed steps, a CUA looks at the screen, reasons about what it's seeing, decides what to do next, and adjusts when something unexpected shows up, the way a new hire would feel their way through unfamiliar software.

These are three different answers to three different questions about where reliability comes from, not three competing solutions to the same problem. Healthcare, as an operating environment, manages to violate all three assumptions more or less at once. Interfaces change without notice, systems refuse to expose data, and workflows demand judgment calls no script anticipated. Most mature deployments end up blending all three, and the wrong move is treating this as a bake-off with one winner. What matters is which one anchors a given workflow, and which ones patch the gaps around it.

RPA in healthcare: where it reliably breaks

RPA is genuinely good at the boring, high-volume stuff: claim submission to a stable portal, eligibility checks, payment posting, typing known values into known EHR fields. When the environment holds still and the steps never vary, RPA runs at scale without complaint.

The market reflects that. GlobeNewswire pegs global RPA revenue at $35.3 billion in 2026, on a path toward $247 billion by 2035, numbers that point to real enterprise adoption rather than a passing trend. One vendor is widely regarded as the category leader and reportedly serves 75 percent of the top 100 health systems in the country; at ViVE 2026 it introduced agentic tools aimed at medical records summarization, denial prevention, and prior authorization, the last built alongside the healthcare AI firm Genzeon. Another vendor holds a recognized security certification for HIPAA compliance and runs deep in enterprise healthcare, offering an orchestration tool to route work intelligently.

None of that changes the underlying fragility. The moment a payer portal redesigns its layout, adds a new security step, or throws an error the bot has never seen, RPA just stops, and someone has to send an engineer in to fix it. Ventus.ai found that at scale, across 50-plus payer portals and 100-plus locations, AI agents hold above 95 percent uptime while RPA runs 60 to 70 percent, with constant upkeep in between. Aetherix Systems puts the useful life of portal-scraping RPA for prior authorization at roughly 12 to 18 months before an interface change forces a rebuild. That maintenance tax rarely appears in the initial business case. It tends to surprise administrators later, once the invoices for "just one more fix" start piling up.

RPA's core assumption, that interfaces hold still, is about the most violated assumption in all of healthcare IT. Anyone who has watched a bot choke on a portal's new verification step knows the interface didn't hold still for it, which is the job, not a rare edge case. API integration starts from the opposite premise: that systems will cooperate at the data layer instead.

API integration in healthcare: the reliability gain and the access problem

Where RPA works the edges of a system, clicking through screens and forms, API integration works higher up, moving structured data directly between systems. Nirmitee.io states the advantage directly: talking to a system through its API, rather than scraping its screen, makes automation far more resilient to interface changes, since no interface needs to be watched.

FHIR (Fast Healthcare Interoperability Resources) is what makes this workable at industry scale. FHIR-based APIs, especially the CRD, DTR, and PAS standards, let automation tools pull clinical data and check payer coverage rules directly, which matters enormously for something like prior authorization. MUSC Health is one cited example: after expanding its use of FHIR-based agentic AI, the health system reduced manual touchpoints on prior authorizations meaningfully, cutting turnaround from days down to hours.

None of this works unless the other side plays along, and that's the catch that makes API integration far less universal than its advocates suggest. Plenty of healthcare systems, independent payer portals, legacy billing platforms, older EHR instances, third-party referral tools, offer no API whatsoever, and some were arguably built that way on purpose. Even where an API does exist, getting access often means months of vendor negotiation and custom development, plus ongoing upkeep as the endpoint contract shifts underneath you. API integration is genuinely strong wherever the ecosystem is willing to cooperate. It just can't reach the parts of the workflow that refuse to.

That gap, the part of the multi-system workflow that neither RPA nor an API can touch, is exactly where computer-use agents were built to work.

How computer-use agents operate on healthcare systems

Mechanically, a CUA reads the state of a screen and reasons about what it sees. The HealthAdminBench paper on arxiv.org evaluates agents operating across realistic GUI environments. That's the raw input. What the agent does with it is the interesting part.

RPA runs a fixed script: if step three fails, the bot stalls out or throws an error. A CUA works from a goal instead. It reads the current screen, decides on an action, carries it out, checks whether that action actually worked, and adjusts, including when an MFA prompt, a bot-verification challenge, or some error it's never seen before pops up. In practice, that means the agent can walk into a payer portal it has never seen and feel its way through it the way a new front-desk hire would. It can keep working after the portal changes its layout overnight, with no rebuild required. And it can move across several systems in one continuous task, an EHR, then a payer portal, then a fax queue, without anyone stitching the steps together by hand.

Ventus.ai cites Smilist as one example of this at scale: AI agents there run more than 3,000 claim status checks a day, work that would otherwise tie up several full-time coordinators. Keragon breaks the underlying architecture into four pieces. Planning means deciding what to do next. Action means carrying it out through the interface or other tools. Reflection means checking whether it worked. Memory means holding onto context so the same mistake doesn't repeat. Prior authorization, denial appeals, and referral scheduling demand multi-step reasoning across systems that share no common data layer, and this loop closes that gap.

Because a CUA operates the interface directly, it doesn't need an API to get started. It can run against anything a staff member can log into, with no vendor cooperation and no custom integration project required first.

What the benchmarks say about where CUA reliability stands

HealthAdminBench, presented in 2026 at an ICLR workshop, is the first peer-reviewed attempt to measure CUAs against realistic healthcare administrative work. It runs agents through four GUI environments (an EHR, two payer portals, and a fax system) across 135 expert-defined tasks covering prior authorization, appeals, and DME order processing, broken into 1,698 fine-grained, verifiable subtasks. The best performer, Claude Opus 4.6 operating as a CUA, hit a 36.3 percent end-to-end task success rate. That's not a passing grade by any normal standard, and it shouldn't be read as one.

A companion benchmark, MedCUA-Bench, also from 2026, tested 23 agents across healthcare administrative tasks. The strongest closed-source model reached 54.2 percent strict success. On real OpenEMR tasks, every model tested stayed under 9 percent, and open-source agents averaged just 2.5 percent. The results point to persistent failures in accurately targeting the correct interface elements on cluttered clinical screens, rather than in higher-level reasoning or instruction-following.

What stands out across both benchmarks is the gap between subtask accuracy, which is often strong, and end-to-end success, which isn't. Agents tend to get most of a workflow right and then trip at one critical junction, a pattern where agents complete most of a workflow successfully before failing at one critical junction. These benchmarks test agents cold, with none of the workflow-specific tuning, prompt engineering, or human-in-the-loop checkpoints that a production deployment would layer on top. Given that Smilist runs 3,000-plus claim checks a day and MUSC Health has automated a significant share of prior authorizations with minimal manual intervention, production deployments with workflow-specific tuning and human-in-the-loop checkpoints operate under meaningfully different conditions than these benchmarks. The benchmarks test agents under cold, untuned conditions, and the fact that peer-reviewed benchmarks now exist for this domain says the field is finally measuring itself with some rigor. That is a sign of a maturing category, not a struggling one. Even so, any administrator evaluating a vendor should ask for workflow-specific completion rates instead of a generic CUA benchmark score. The benchmark environment and the production environment are genuinely different animals, and a vendor who only quotes the former is hiding something.

Most real deployments combine all three approaches rather than choosing one

By 2026, the pattern settling into place looks less like a competition and more like a division of labor, The pattern that emerges is a division of labor: AI agents take on judgment-heavy, unstructured decisions, while RPA or APIs handle the structured, stable transactions sitting right next to them in the same workflow. Anyone still shopping for a single tool to run the whole revenue cycle is asking the wrong question.

In revenue cycle work specifically, that split plays out cleanly. RPA handles claim submission to a portal endpoint that hasn't changed in years, fast and mechanical, no reasoning needed. API and FHIR connections cover eligibility checks and payment posting wherever the systems on both ends are willing to cooperate. CUAs take the unpredictable middle: navigating an unfamiliar payer portal, filling out a prior authorization form, assembling a denial appeal, all the places where neither a fixed script nor a clean API can reach.

The workflows that gain the most from CUAs are the ones that cross systems never designed to speak to one another, an EHR, an independent payer portal, a fax queue, and a scheduling tool, strung together in sequence. At real scale, multi-location groups, investor-backed portfolios, large health systems, the maintenance burden of running RPA across dozens of separate payer portals becomes the biggest line item in the automation budget. CUAs absorb that interface variability without needing a dedicated engineering fix for every single portal. Deloitte's healthcare AI survey found more than 80 percent of health systems now prioritizing agentic AI for clinical operations and revenue cycle management, a strong signal that this hybrid setup is becoming the default rather than the exception. None of that removes the need to weigh each approach on its own merits. If anything, it raises the stakes on knowing exactly where each one belongs in the stack.

The adoption gap between intent and production deployment

The appetite is obvious. Keragon reports that 61 percent of organizations are already building or have budgeted agentic AI initiatives, and an IBM survey found 86 percent of executives expecting AI agents to make process automation meaningfully more effective by 2027. Gartner tracked investment in AI for business transformation jumping from 15 percent in 2024 to 52 percent in 2025, a steep climb by any measure.

Production reality lags well behind that enthusiasm. A KLAS Research report found only a modest fraction of organizations had moved these initiatives past pilot stage into live, everyday use. That gap is visible across enterprise software generally: budgeting for a technology and actually running it reliably in production are two very different milestones, and most vendor pitches quietly skip over the distance between them. For a practice administrator, that gap is the real takeaway. The tools exist, the benchmarks are improving, and the hybrid architecture is taking shape. What's still catching up is the unglamorous work of implementation, workflow by workflow, portal by portal, until intent turns into something that runs quietly in the background every single day.