Two automation curves are moving in opposite directions inside American healthcare. On one side, payers are wiring artificial intelligence into their review pipelines fast: 65% of private payers say they plan to fold AI into prior authorization within the next three to five years [1]. On the other side, the practices submitting those requests are still doing the work by hand. The average physician runs 39 prior authorization requests every week, and physicians and their staff spend roughly 13 hours on them, nearly two full business days [2].
That gap is not a story about effort. Provider revenue teams are not lazy, and they are not short on motivation to speed things up. The problem is infrastructure. Prior authorization workflows live inside payer portals, and most of those portals were never built to be automated from the outside. Where a clean API exists, submission can be programmatic. Where it does not, someone logs in and clicks.
Optexity closes that portal gap by turning the exact web workflow a human would perform into a deterministic, API-callable automation. This piece is written for the developer or revenue-cycle engineer who has to actually build the integration, and it goes deeper than the standard "AI reads the chart and files the request" explanation. The interesting question is not whether automation helps. It is which layer of the stack each payer actually exposes, and what you do about the layer that has no API at all.
Why Prior Authorization Is Still a Manual Process in 2026
Prior authorization is the pre-approval step a provider must clear before a payer will cover certain treatments, drugs, or procedures. It sounds like a formality. In aggregate, it is one of the heaviest administrative loads in the system.
- Prior authorization accounts for an estimated $35 billion of US healthcare administrative spending [1].
- Physicians complete an average of 39 prior authorization requests per physician per week [2].
- Physicians and their staff spend about 13 hours every week completing those requests, close to two business days.
- 93% of physicians reported prior authorization burden as high or extremely high, according to a 2021 AMA survey [3].
- Roughly 40% of prescriptions delayed by the manual prior authorization process end up abandoned [4].
The automation gap between the two sides of the transaction is measurable. Only 17% of provider organizations have prior authorization processes that are more than 50% automated, compared with 27% of private payers. Payers are also further along in intent, planning AI adoption at 65% against 11% for providers. When one party automates denials faster than the other can automate submissions, the slower party absorbs the cost.
The asymmetry compounds over time. As payers deploy AI-assisted review, the complexity of the submissions they demand increases: more documentation, more specificity, faster turnaround windows. A provider team still doing the work manually in that environment faces a growing structural disadvantage as the payer side accelerates.
The root cause is fragmentation. Each payer runs its own portal, with its own login flow, its own form fields, and its own submission rules. The major commercial portals, from Aetna to UnitedHealthcare to Cigna to Humana, share no common interface, and clearinghouses like Availity plus regional plans such as Ambetter and Peachstate each run their own systems on top of that. For most practices, manually navigating each portal is not a sign of inefficiency. It is the only path that exists. We cover the mechanics of this in more depth in the prior authorization and eligibility verification guide.
The Three-Layer Problem: Why Standard Automation Falls Short
Most teams that set out to automate prior authorization reach for one of three tools, and each one covers a different slice of the problem while leaving the rest exposed. Understanding where each layer stops is the whole game. The table below maps what each approach handles and where it breaks down in practice.
The FHIR layer looks like the clean answer, and for covered payers it eventually will help. The catch is scope. CMS mandates FHIR-based prior authorization APIs, but only for impacted payer types, and only on compliance dates beginning January 2027. Commercial employer-sponsored plans sit outside that mandate entirely.
Aggregators run into a subtler failure. They speak the standard transaction set well, but prior authorization is where the standard set runs out. Clinical attachments, payer-specific forms, and appeals all live in the portal UI, not in a tidy X12 message. Aggregators also tend to serve data that was true at last sync rather than what the portal shows right now, which matters when a status flips between polls. Static RPA, meanwhile, can technically reach into the portal, but it treats a living web page as if it were a fixed target. Payers redesign their portals, and the scripts snap. The reason these portals lack clean APIs in the first place is structural, which we unpack in why legacy healthcare systems don't have APIs.
The stale data problem with aggregators deserves a more specific explanation. Aggregator platforms typically pull and cache payer data on a scheduled basis, often once or twice per day. If a payer updates a prior authorization status to "approved" at 10 AM and your practice queries the aggregator at 11 AM, you may still see "pending" in the response because the aggregator has not re-synced. For practices monitoring a high-volume queue, that lag means manual verification is still required for any time-sensitive decision. Browser automation avoids this by reading the payer portal directly at query time, returning the state the portal actually shows at that moment.
What Prior Authorization Automation Actually Requires
End-to-end prior authorization automation is not one task. It is a chain of five, and most tools automate only the first one or two before handing the rest back to a human.
- EHR data extraction. Pull the structured and unstructured clinical data the request needs from the source EHR. That covers platforms like eClinicalWorks and drchrono, along with AthenaOne, AdvancedMD, or PracticeSuite depending on the practice setup.
- Authenticated payer portal access. Log in and hold a session across payer portals. That spans Availity and Aetna on the clearinghouse side, plus the major commercial payers: UnitedHealthcare and Cigna (and Humana). The automation handles two-factor authentication and persistent sessions that survive between steps.
- Submission routing. Send the request by the right channel for each payer: a FHIR API where one exists, an EDI X12 278 transaction where that is supported, or a portal-driven submission where neither is available.
- Status monitoring and follow-up. Poll each payer's dashboard for decisions and pending states, and act on them without a person watching the queue.
- Denial and appeal handling. Route denials into the appeal workflow, which almost always lives inside the portal rather than in any API.
Infor's technology overview frames prior authorization automation as a stack of integration engines, RPA, and healthcare standards working together rather than a single component [5], and that framing holds up in practice. The step that trips most builds is the jump from step three to step five. Submission through an API is the easy part. Attachments, portal-specific forms, and appeals are where the work actually piles up, and where a plain API integration quietly stops short. The Availity automation guide walks through what that looks like on a single high-volume portal.
Step two deserves particular attention. Payer portals vary significantly in their authentication requirements. Some require SMS-based two-factor authentication that must be completed on each new session. Others use time-based one-time passwords tied to an authenticator app. A small number use certificate-based authentication for high-volume submitters. Any automation that cannot handle these authentication flows will fail at login before it reaches the submission form, which means the automation gap effectively starts at step two for a significant share of portals.
How Browser Automation Handles What APIs Cannot
The portion of prior authorization that resists APIs is not exotic. It is the everyday portal work: uploading a clinical attachment, filling a payer-specific form field that has no standard equivalent, filing an appeal, and polling a payer's own dashboard for a status that only appears there. These tasks are defined by the UI, so they have to be automated at the UI.
Browser automation approaches this by recording the workflow once through a browser extension, then converting that recording into a deterministic automation you can call from an API. The automation navigates the same portal a human would, so it reaches the same attachment uploads, form fields, and appeal screens, and because it is deterministic and self-healing rather than a one-off script, it holds up when a portal changes rather than snapping. At Optexity, that automation runs against the specific portals practices actually touch: Availity and Aetna, UnitedHealthcare and Cigna, plus commercial plans like Humana and regional ones like Ambetter (and Peachstate, Modemed). On the EHR side, it sources data from eClinicalWorks and drchrono, along with AthenaOne and AdvancedMD (plus PracticeSuite and Optimantra).
Healthcare adds requirements a general-purpose scraper does not carry. Portal logins often require two-factor authentication, sessions need to persist across a multi-step submission, high-volume practices need concurrent requests running in parallel, and the whole thing has to sit inside a HIPAA-aligned posture. Optexity's stated compliance posture covers HIPAA and SOC 2. Because a deterministic automation replays a known workflow instead of asking a language model to reason through every click, it skips the per-step LLM calls that make agent-style approaches slow and expensive, which meaningfully cuts per-run cost and latency. For the specific case of the largest commercial payers, the Big Four payer portals guide goes portal by portal.
The self-healing property matters in practice because payer portals do change. Aetna has updated its prior authorization submission flow multiple times in the past two years. Availity has rolled out interface changes tied to its own product roadmap. UnitedHealthcare has shifted form field layouts as it has expanded its portal capabilities. A static RPA script that breaks on any of these changes creates exactly the kind of maintenance backlog that offsets whatever time the automation was supposed to save. A self-healing automation detects the change and re-anchors its navigation rather than failing silently or throwing an error that nobody catches until a denial stack builds up.
The other variable that separates portal-capable automation from API integration is data type. FHIR and EDI transactions carry structured data fields. A clinical attachment is a PDF or image file. A payer-specific prior authorization form for a specialty drug may include fields for clinical notes, lab values, and physician attestations that have no EDI equivalent and no FHIR mapping. Browser automation handles these because it operates at the browser layer, where any content type the portal accepts can be passed through. That is the fundamental reason it covers ground the other layers cannot.
The CMS-0057-F Mandate: What It Changes and What It Doesn't
CMS-0057-F is the rule most often cited as the thing that will finally fix prior authorization, and it does change real requirements. It mandates FHIR-based prior authorization APIs for impacted payers, with API compliance dates beginning January 2027. Operational requirements covering decision timeframes, denial reason disclosures, and public reporting took effect January 2026. Most impacted payers must return decisions within 72 hours for urgent requests and seven calendar days for standard requests (QHP issuers on the Federally Facilitated Exchanges are excluded from this timeframe requirement). Public reporting of prior authorization metrics, including volume and turnaround, began phasing in from 2026.
The word doing the heavy lifting is "impacted."
So even in a fully compliant post-2027 world, a meaningful share of prior authorization volume still lands on payers the mandate never touched. A practice with a heavy commercial book will keep submitting through portals for those plans regardless of what any FHIR API offers for the covered ones. That is the durable reason browser automation stays relevant after the mandate arrives: the mandate closes the API gap for one set of payers and leaves it wide open for the rest.
The public reporting requirement that begins phasing in from 2026 is worth noting separately. Impacted payers must publish data on prior authorization volume, approval and denial rates, and turnaround times. For provider organizations, that data will for the first time make payer-level performance comparable. Practices that have been absorbing high denial rates from a specific payer without a clear benchmark will have a public reference point. The reporting requirement does not change portal infrastructure, but it creates a pressure surface that may accelerate payer investment in improving their own submission processes.
Getting Started: A Developer's Implementation Path
You do not automate every payer at once. You automate the ones that hurt most, confirm the approach, and expand. A workable sequence looks like this.
- Map prior authorization volume by payer. List which portals you touch, at what volume, and for which transaction types.
- Audit API coverage. For each payer, note whether a usable FHIR API or X12 278 path exists, or whether the workflow is portal-only.
- Wire the API-capable payers first. Implement the FHIR prior authorization API or EDI X12 278 where the payer supports it.
- Bridge the portal-only payers with browser automation. Record the workflow once and convert it into an API-callable endpoint for the payers that expose no usable API.
- Sequence by pain. Start with the payer that combines the highest volume with the highest denial rate, where automation returns the most hours per unit of effort.
- Measure the delta. Track approval rate, turnaround time, and staff hours freed so the next payer's business case writes itself.
The speed of that first build matters more than teams expect, because it decides whether the project keeps momentum. Confido Health deployed their first automation in under 20 minutes, which is the kind of early win that gets a second payer greenlit. When you are ready to try it against your own highest-volume portal, you can start free: Get Started For Free.
A few practical notes on sequencing. The payer that causes the most manual work is not always the one with the highest volume. A payer with a high denial rate, a slow portal, and a complex appeal form can consume more staff time than a high-volume payer with a straightforward submission flow. Looking at both dimensions together, volume and denial-plus-appeals burden, gives a better prioritization signal than volume alone.
On the measurement side, approval rate and turnaround time are the metrics that surface the business case most clearly. Staff hours freed is harder to attribute precisely because time savings often disperse across the team rather than showing up as a single person removed from the queue. Tracking time-to-decision at the payer level gives a cleaner signal and feeds directly into the next payer's ROI calculation.
FAQs
Which payer portals can browser automation cover? Any portal a person can operate in a browser. That includes major commercial payers such as Aetna, UnitedHealthcare and Cigna, plus Humana, clearinghouses like Availity, and regional plans such as Ambetter and Peachstate or Modemed. Coverage is not limited to payers that publish an API, which is the point of the approach.
How does it handle two-factor authentication? The automation supports 2FA and persistent sessions, so it can complete a login challenge and then hold that session across a multi-step submission rather than dropping out after the first screen.
Is it HIPAA compliant? Optexity's stated compliance posture covers HIPAA and SOC 2. That posture matters because prior authorization workflows move protected health information between the EHR and the payer.
How fast can a team get a first automation running? It varies by workflow complexity, but as one data point, Confido Health deployed their first automation in under 20 minutes by recording the workflow and converting it into a callable endpoint.
How is this different from legacy RPA? Traditional RPA scripts are brittle and break when a payer redesigns its portal. A deterministic, self-healing automation replays a known workflow and adapts to interface changes instead of snapping on the next UI update.
How is this different from FHIR APIs and aggregators? FHIR APIs only exist for impacted payers under CMS-0057-F, and aggregators cover standard HIPAA transactions but not attachments, payer-specific forms, or appeals. Browser automation handles the portal-only work that both leave uncovered.
Can it run many requests at once? Yes. Concurrent requests let a high-volume practice run multiple prior authorizations in parallel rather than processing them one at a time.
Why does aggregator data feel out of date? Aggregators frequently return data from their last sync rather than a live read of the portal, so a status that changed since the last pull can show up stale. Browser automation reads the portal directly, so it reflects the current state.
Does automation still matter after the 2027 CMS mandate? Yes. CMS-0057-F covers only impacted payer types. Commercial employer plans and many regional payers stay out of scope, so portal-based submission remains necessary for a large share of volume.
How much does it cost? Pricing runs from a free tier up through paid plans and enterprise. Current details live on the Optexity pricing page.
What EHR systems does it support? The automation connects to eClinicalWorks and drchrono, as well as AthenaOne and AdvancedMD, with support for PracticeSuite and Optimantra as well. The source EHR supplies the clinical data that the automation then routes to the appropriate payer portal. If your EHR has a portal or export interface a person can use, it can generally be automated.
What happens when a payer changes its portal interface? The automation is self-healing, so it detects interface changes and re-anchors its navigation rather than breaking outright. This is the key difference from legacy RPA scripts, which require manual intervention each time a portal updates. The self-healing approach means maintenance burden does not compound as you add more portals to the automation layer.
Can it handle the full appeal workflow, beyond initial submission? Yes. Appeals almost always live inside the payer portal rather than in any API surface, which makes them a natural fit for browser automation. The appeal workflow is recorded the same way as the initial submission workflow, converting it into a callable automation that routes denials into the appeal process without requiring a person to log in and click through the portal manually.
Closing
The honest read on prior authorization automation is that no single layer solves it. FHIR APIs will help for the payers CMS compels, aggregators cover the standard transaction set, and neither reaches the attachment uploads, payer-specific forms, and appeals that make up the hard middle of the work. That is the portal layer, and it is exactly the layer browser automation was built to reach.
The practical move is to treat the three layers as complementary rather than competing: use the API where a payer gives you one, and automate the portal where it does not. That combination is what gets a revenue team from 39 manual requests a week toward a queue that mostly runs itself.
The regulatory calendar makes the window for building this infrastructure clearer than it has ever been. CMS-0057-F creates pressure on covered payers to deliver FHIR APIs by January 2027. Provider organizations that build the API integration layer now, and pair it with portal automation for the payers outside the mandate, will be positioned ahead of the compliance deadline rather than scrambling to catch up. The practices still clicking through Aetna's portal manually in late 2027 will not have a regulation to blame. They will have an infrastructure decision that was deferred too long.
References
[1] JAMA Health Forum / NIH PubMed Central. "Perceptions of prior authorization burden and solutions." 2024. https://pmc.ncbi.nlm.nih.gov/articles/PMC11425057/
[2] American Journal of Managed Care (AJMC). "AMA Survey Highlights Growing Burden of Prior Authorization on Physicians, Patients." 2025. https://www.ajmc.com/view/ama-survey-highlights-growing-burden-of-prior-authorization-on-physicians-patients
[3] Medical Economics. "Physicians warn that AI will undermine judgment, increase prior authorization denials." 2025. https://www.medicaleconomics.com/view/physicians-warn-that-ai-will-undermine-judgement-increase-prior-authorization-denials
[4] Surescripts. "Powering Prior Authorization Transformation." 2025. https://surescripts.com/insights/powering-prior-authorization-transformation
[5] Infor. "Prior Authorization Automation in Healthcare." https://www.infor.com/products/cloverleaf/prior-authorization-automation
