What's actually changing
For years, the default mode of payer interaction has been a person at a screen. Staff log into ten or more payer portals a day, each with its own layout, login flow, and quirks, to check eligibility, look up claim status, submit an authorization or referral, file an appeal, or pull a remit. The work gets done, but it's slow, inconsistent, and almost impossible to scale cleanly.
Where teams have tried to scale, the answer has usually been RPA. Bots logging into the same portals, clicking the same buttons, scraping the same screens — because for most of the last decade, that was the only option. The APIs either didn't exist or returned so little useful data that they weren't worth integrating against. RPA over portal UIs was the realistic automation path.
That's starting to shift. The same transactions are increasingly available through APIs that connect directly to a provider's core systems, and the responses are richer than they used to be. Clearinghouses and connectivity vendors are expanding their API offerings, EHR vendors are wiring more of this into native workflows, and payers, prodded by regulation, are standing up endpoints they didn't expose before.
HFMA recently described this as a multimodal model, where AI agents orchestrate payer-bound work across multiple modalities, including EDI, API, portal, and voice, routing each request through the fastest available channel and reserving calls as a final fallback. That ordering matters. APIs and EDI go first. Portal work — whether performed by humans or RPA bots — and phone calls become the exception, not the default.
Why now: the regulatory push
The shift isn't just market-driven. CMS is forcing the issue.
The CMS Interoperability and Prior Authorization Final Rule (CMS-0057-F), released in January 2024, requires impacted payers, including Medicare Advantage organizations, state Medicaid and CHIP programs, Medicaid managed care plans, and Qualified Health Plan issuers on the federal exchanges, to stand up four interoperability APIs: Patient Access, Provider Access, Payer-to-Payer, and Prior Authorization. Impacted payers have until at least January 1, 2027 to meet the API development and enhancement requirements. CMS has since proposed extending similar requirements to drug prior authorizations under CMS-0062-P.
Adoption is moving. Becker's reported on a Workgroup for Electronic Data Interchange survey from earlier this year showing that as of February, only 10% of payers had not started work on the API requirements, down from 42% at the beginning of 2025. The same survey found that two-thirds of providers said it was very or extremely important for the majority of their contracted payers to support the prior authorization API.
That last point matters. Providers aren't just waiting passively for compliance dates. They're already weighing API support when they evaluate payer relationships.
The operational case is about consistency, not speed
The obvious benefit is speed. APIs are faster than humans clicking through portals — and faster, and more consistent, than RPAs doing the same work. But speed isn't really why this shift matters. Consistency is.
Human portal work introduces variability at every step. Which fields did the rep check? Did they capture the reference number? Did they look at the right plan tier? Two staff members running the same eligibility check on the same patient can produce two different outputs depending on what they noticed. That variability shows up downstream as denials, missed follow-ups, and accounts that get worked twice because no one had a clean record of the first pass.
RPA over portal UIs solves part of that, but introduces its own problems. Bots are difficult to maintain at scale. Process times stretch out as transaction volume grows and the bot has to navigate every screen, every modal, every login timeout for every account. And the ceiling on stability is set by the portal itself — when a payer ships a UI change, or when traffic congestion makes the portal sluggish or unstable, results diminish quickly. The bot didn't get worse; the surface it depends on did.
APIs return structured data the same way every time. The transaction either succeeded or it didn't, and the response is parseable. There's no UI to scrape, no login session to keep alive, no layout change to break the workflow when the payer redesigns. That changes a few things at once.
Workflows become more predictable, which makes capacity planning, staffing, and QA easier. Audit visibility improves because every transaction leaves a structured trail. And automation gets dramatically more stable. Bots that mimic clicks in payer portals break the moment a payer ships a UI change, which means a steady tax of maintenance work just to keep the automation running. Direct API integrations don't carry that tax.
This is where the automation strategy actually changes. Instead of building bots that imitate humans inside someone else's UI, organizations can trigger transactions natively from their own systems. That's a different architecture, a different skill set, and often a different vendor conversation. For teams that have invested heavily in RPA over the last few years, some of that investment will hold up. Some of it won't.
What RCM leaders are doing
Here's what teams moving fastest on this are doing.
Start with an honest inventory. Map where portal work still lives — both staff hours and RPA runtime — by payer, by transaction type, by volume. You can't reduce dependency on something you haven't measured, and most organizations underestimate how much of their daily payer work still runs through portal UIs.
Prioritize the high-volume transactions first. Eligibility, claim status, authorizations and referrals, and appeals are usually where the biggest wins sit, because the volume is high and the workflows are repetitive enough to benefit from a stable channel.
Reassess existing automation, and revisit the API question even if you've looked before. Many teams investigated payer APIs a few years ago, came up dry on availability or response quality, and defaulted to RPA. Both sides of that equation have moved. APIs that didn't exist now do. Endpoints that returned thin data now return enough to act on. Re-engage with your clearinghouse, EHR vendor, and key payers and check what's actually available today — the answer is often different than it was 18 months ago.
When the API path is real, portal-scraping bots and screen-based RPA built over the last few years should be evaluated against it. Some will need to be retired, not just upgraded. The maintenance math changes when a more durable channel exists.
Bring API support into payer conversations. Make it a factor in scorecards and contract discussions. The Becker's data on provider expectations is a useful anchor here. Payers are paying attention to what providers prioritize.
Get the operational and technical sides aligned earlier than feels comfortable. This isn't just an IT project. It changes who does what work, how performance gets measured, and what your team needs to hire for.
The unglamorous foundation
AI is going to keep getting the headlines, and rightly so — the capabilities are impressive. But most of the durable operational gains in RCM over the next 24 months are going to come from the less visible work of cleaning up the channels underneath the AI layer.
Teams that move portal work to APIs now — whether that work is being done by humans or by existing RPAs — will have a cleaner foundation when AI agents are doing more of the orchestration. The ones that don't will end up automating around problems they could have removed.
It's a quieter shift than the AI story. It's also the one that's already changing how the work gets done.
If APIs aren't on your automation roadmap yet, they should be. Tarpon Health helps health systems fold API-based transactions into their everyday automation programs alongside existing RPA and staff workflows. For a deeper look at how to think about ROI and prioritization, let us know where you need help and we'll help you take the next step.
