How to Automate Healthcare Prior Authorization on Insurance Portals (March 2026)

When your team logs into 30+ different payer portals each week, every interface change breaks your automation. Building separate scripts for UnitedHealthcare, Cigna, Aetna, and Humana means managing dozens of workflows that need constant maintenance when portals update. Prior authorization software solves this by using LLMs to interpret portal layouts visually, so your authorizations keep running across every payer without breaking when UIs change or new MFA requirements appear.

TLDR:

• Prior authorization takes 13 hours per week per physician across 39 requests, with 93% reporting care delays.
• Payer portals require manual login, form filling, and status checks across 10-40+ different sites with no APIs.
• CMS mandates FHIR APIs by 2027, but prescription drugs are excluded and complex cases remain portal-based.
• AI browser automation handles multi-payer workflows by reading portals visually, self-healing when UIs change.
• Skyvern automates prior auth submissions across any payer portal with HIPAA-capable deployment and audit trails.

Understanding the Healthcare Prior Authorization Burden

Prior authorization consumes substantial clinical staff time. Physicians complete an average of 39 prior authorizations per week, spending 13 hours on the process. 93% of physicians reported that prior authorization delays patient access to necessary care. The root cause is portal-based workflows. Healthcare teams log into separate payer portals for UnitedHealthcare, Aetna, Cigna, Humana, and dozens of BCBS plans. Each portal has its own authentication flow, form layout, documentation requirements, and submission process. Some require CoverMyMeds integration. Others use proprietary payer portals. A few still accept faxed forms.

Staff spend their days working through portals and uploading clinical documentation, and manually checking approval status. High-volume practices handle 50 to 200+ prior auth requests daily. The process doesn't scale without adding headcount.

The portal burden stems from systemic fragmentation.

Why Insurance Portals Are the Automation Bottleneck

Payer portals exist because standardized APIs don't. UnitedHealthcare Optum, Cigna, Aetna, Humana, and regional BCBS plans each built proprietary web interfaces for prior authorization submission, none designed for automation. But, the fragmentation runs deep. Every payer uses different forms, fields, and documentation requirements. UHC might ask for CPT code first, then diagnosis. Cigna reverses the order. Aetna requires drug name entry from a searchable database. Humana uses free text. And then, authentication adds more friction. Some portals require TOTP-based MFA. Others send SMS codes. Session timeouts vary from 5 to 30 minutes. CAPTCHAs appear randomly. Finally, UIs change without notice. A payer updates their portal layout, and any script relying on CSS selectors or XPaths breaks immediately. This is why traditional RPA and Selenium-based automation fails. The maintenance cost exceeds the value.

Regulatory pressure is building to tackle this bottleneck.

The 2026 CMS Interoperability Mandate and What It Changes

The CMS Interoperability and Prior Authorization Final Rule requires impacted payers to implement FHIR-based Prior Authorization APIs by January 2027. Under the rule, payers must send authorization decisions within 72 hours for expedited requests and seven calendar days for standard requests. They're also required to provide denial reasons and report metrics on authorization volume and approval rates.

The mandate creates urgency but doesn't eliminate portal work. Prescription drugs are excluded from the rule. Not all payers fall under the mandate. API adoption will be gradual, and many authorization workflows will remain portal-based during the multi-year transition. And, even after full implementation, APIs won't cover every scenario. Complex cases requiring clinical documentation uploads, supplemental forms, or appeals still route through web portals. The mandate accelerates electronic submission, but browser automation remains necessary for the workflows APIs can't reach.

Understanding current approaches reveals why partial solutions fall short.

Manual vs Electronic Prior Authorization Workflows

Manual prior authorization requires staff to call, fax, or log into payer portals to submit requests. Manual requests take 24 minutes on average when conducted via telephone, fax, and email. Portal-based requests drop to 16 minutes but still require human attention for every step: login, form completion, file uploads, and submission confirmation.

Electronic prior authorization (ePA), though, integrates with EHR systems to pre-fill request forms from patient records. The goal is straight-through submission without leaving the EHR. In practice, only 31% of authorization tasks use fully electronic methods. The remaining 69% still involve manual work.

Why do ePA falls short? Complex cases requiring supplemental clinical documentation can't auto-submit. Status checks require logging back into payer portals. Non-formulary drug requests, appeals, and peer-to-peer review scheduling all route back to manual portal workflows. EHR integrations cover simple scenarios but break down when clinical context matters.

Full browser automation picks up where ePA stops. It handles the portal workflows that partial integrations can't reach.

How AI Browser Automation Works for Prior Authorization

AI browser automation interprets payer portals through visual understanding instead of hardcoded selectors. LLMs analyze live pages, identify form fields by their labels and context, and decide which actions to take. When Cigna's prior authorization form requests prescribing physician NPI, the system recognizes it regardless of input type.

This approach handles UI changes without breaking. When payers redesign portal layouts, the automation adapts by interpreting meaning instead of relying on XPath coordinates.

Comparing Automation Approaches for Prior Authorization

Healthcare teams assessing automation solutions need clear criteria to assess which approach handles the unique challenges of multi-payer prior authorization workflows. The eight-dimension framework below shows how different automation categories perform across the capabilities that matter most: self-healing when UIs change, ability to work across multiple payer portals without site-specific code, and production readiness for complex healthcare workflows.

The workflow mirrors human interaction: login with credentials, handle MFA prompts, fill multi-page forms by matching clinical data to fields, upload supporting documents, and check approval status. Session management runs in parallel across dozens of payer portals simultaneously, handling different timeout rules per site. Human-in-the-loop review flags ambiguous clinical questions requiring staff judgment before proceeding.

Building an Automated Prior Authorization Workflow

Automated prior authorization starts with intake. Pull patient data, prescriber information, medication or procedure details, and diagnosis codes from your EHR or practice management system via API or scheduled export. Structure this data as JSON with required fields mapped to common payer requirements: NPI, date of service, CPT/HCPCS codes, ICD-10 diagnosis, prescription details, and supporting clinical notes.

Developers can integrate prior auth automation into existing practice management systems through the Python SDK. Initialize a client with Skyvern() and use client.run_task() to submit authorization requests programmatically:

from skyvern import Skyvern
import asyncio

skyvern = Skyvern(api_key="YOUR_API_KEY")

async def submit_prior_auth():
    task = await skyvern.run_task(
        url="https://portal.payername.com/auth",
        navigation_goal="Submit prior authorization request with provided patient and clinical data. COMPLETE when authorization is submitted and confirmation number is displayed.",
        navigation_payload={
            "patient_name": "John Smith",
            "dob": "1975-03-15",
            "member_id": "ABC123456789",
            "prescriber_npi": "1234567890",
            "procedure_code": "99213",
            "diagnosis_code": "E11.9",
            "clinical_notes": "Patient requires procedure due to..."
        },
        data_extraction_goal="Extract the authorization number and approval status",
        extraction_schema={
            "type": "object",
            "properties": {
                "authorization_number": {"type": "string"},
                "status": {"type": "string"},
                "approval_date": {"type": "string"}
            }
        }
    )
    
    print(f"Status: {task.status}")
    print(f"Extracted data: {task.extracted_data}")

asyncio.run(submit_prior_auth())

This approach allows practice management systems to trigger authorization workflows directly from their existing interfaces, passing patient data as structured JSON and receiving authorization results via webhook or by polling task.status and task.extracted_data.

Next comes portal routing logic. Each authorization routes to the correct payer portal based on patient insurance information. Store payer-specific credentials securely, handle MFA tokens, and map your structured data to each portal's unique form fields. Submit requests in parallel across multiple payers, uploading clinical documentation as PDFs where required.

Status monitoring runs on schedule. Check each payer portal for authorization decisions, extract approval numbers or denial reasons, and return results to your case management system via webhook. Flag denials or requests requiring peer-to-peer review for clinical staff. Maintain full audit trails with screenshots, submission timestamps, and confirmation documents for compliance records.

Human-in-the-loop review sits before final submission. Clinical staff approve authorization details, verify documentation completeness, and confirm that selected clinical justification matches the case before the system submits to the payer portal.

Managing Multi-Payer Portal Complexity at Scale

High-volume practices interact with 10 to 40+ different payer portals every day. UnitedHealthcare, Aetna, Cigna, and Humana each operate separate portals. Regional BCBS plans, state Medicaid variations, and Medicare Advantage carriers push that number higher.

Per-portal scripting creates maintenance problems. Building separate automations for each payer means managing 40+ scripts that break independently when interfaces change. Documentation requirements shift by plan type: Medicare Advantage requests need clinical justification that differs from commercial plans. DME authorizations require supplier information that pharmacy auths skip.

Parallel execution fixes throughput bottlenecks. Run authorizations across all payers at once instead of one at a time. Steel Server coordinates browser instances and routes requests, managing the infrastructure layer that provides for parallel execution and session persistence across multiple concurrent workflows. Credential management needs secure storage per portal with MFA token handling. Payer-specific documentation mapping sends the correct files to each portal's upload fields.

Assessing Prior Authorization Automation Platforms

Healthcare teams assessing automation solutions for prior authorization need to assess how different platforms handle the unique challenges of multi-payer workflows. Below are three common solutions and why their approaches fall short for high-volume authorization environments where portals change frequently and authentication complexity is the norm.

Browse AI

Browse AI markets itself as a no-code platform that allows users to train "robots" to extract data and automate tasks on websites through point-and-click configuration. For prior authorization, this translates to building separate robots for UnitedHealthcare, Cigna, Aetna, Humana, and every BCBS plan your practice works with.

The per-site robot approach creates immediate scaling problems. A practice working with 40 payer portals needs 40 separate robots, each requiring individual configuration, training, and maintenance. When UnitedHealthcare updates their portal layout, only that robot breaks. When Cigna changes their form fields, you retrain the Cigna robot. Multiply this across dozens of payers, and maintenance becomes a full-time job.

Browse AI's limitations for prior authorization include robots that break when websites change their layout or structure, requiring manual retraining each time a payer updates portal design; limited ability to handle multi-step workflows with conditional logic beyond simple navigation patterns; no native 2FA or authentication handling for the login-gated payer portals that dominate authorization workflows; inability to adapt to portals it has never seen before without new training, making it impractical for workflows touching dozens of different sites; and the requirement for separate robot configuration per website, meaning teams managing multi-payer workflows must build, maintain, and monitor individual robots for every single portal.

The bottom line: Browse AI works for monitoring a handful of stable websites for data changes but falls short when workflows demand authentication complexity, cross-site consistency, or the ability to work on portals the system has never encountered before. Insurance agencies working with 40 carrier portals would need 40 separate robots, each requiring maintenance when its target site changes.

Stagehand

Stagehand takes a hybrid approach as an open-source TypeScript library that wraps Playwright to add AI-assisted actions while maintaining programmatic browser control. Unlike platforms with built-in AI capabilities, Stagehand requires users to bring their own API keys for AI providers, making its AI functionality limited by nature.

For prior authorization workflows, Stagehand's hybrid model means you can use natural language for simple interactions like "click the submit button" while writing traditional Playwright code for complex multi-step authorization flows. This flexibility appeals to TypeScript teams who want some AI assistance without fully committing to a pure AI approach.

The library integrates with Browserbase's cloud infrastructure for managed execution, supports multiple AI model providers including OpenAI and Anthropic, and includes debugging tools like DOM snapshots and action traces. Stagehand works with existing Playwright test infrastructure, allowing teams to incrementally adopt AI assistance without rewriting entire workflows.

Yet Stagehand's limitations mirror traditional tools for prior authorization use cases. The platform still requires TypeScript or JavaScript development skills for implementation and customization, depends on site-specific code and selector maintenance that breaks when payer portals change their structure, provides AI assistance for individual actions but not end-to-end workflow intelligence, and leaves teams responsible for maintaining the underlying automation architecture. The hybrid model reduces but doesn't eliminate maintenance overhead. Teams still spend time updating selectors and fixing broken workflows when Cigna redesigns their portal or UnitedHealthcare adds new MFA requirements.

In addition, Stagehand lacks native 2FA or CAPTCHA solving capabilities that prior authorization workflows frequently require, has no AI-powered adaptability to handle completely unseen payer portals without configuration, and operates with a smaller community compared to existing frameworks, which can impact support availability.

The bottom line: Stagehand works for TypeScript teams with engineering resources who want to reduce selector maintenance frequency, but it doesn't fundamentally solve the maintenance problem that pure AI approaches eliminate. Organizations considering Stagehand should have TypeScript expertise in-house, be prepared to manage their own AI provider relationships, and understand that while AI assistance helps, workflows still break when payer portals change.

Director

Director positions itself as an AI-powered browser automation tool designed to simplify workflow creation through natural language instructions. The platform appeals to teams seeking a balance between ease of use and automation capability, offering a visual workflow builder that translates natural language descriptions into browser actions.

For prior authorization, Director's approach means you can describe what you want in plain language: "Log into the UnitedHealthcare portal, navigate to prior auth submission, fill out the form with patient data, and submit." The platform translates this into executable browser actions.

Director's strength lies in its approachable interface that lowers the barrier to entry for non-technical users who want to create simple automations without writing code. Director offers tiered pricing starting with a Free plan that includes 1 concurrent browser and 1 browser hour included. The Developer plan is $20/month with 25 concurrent browsers and 100 browser hours. The Startup plan is $99/month with 100 concurrent browsers and 500 browser hours.

Yet Director's AI-powered adaptability is fundamentally limited for prior authorization workflows. It does not provide runtime adaptability to handle payer portal changes dynamically. Once a workflow is created, it remains static and brittle against UI changes, requiring manual updates when UnitedHealthcare, Cigna, or Aetna portals evolve their structure.

This limitation places Director in the same category as traditional automation tools that break when websites change, despite the AI-assisted workflow creation. The platform helps you build automations more easily but doesn't solve the ongoing maintenance problem that occurs when payer portals update layouts, add new required fields, or change authentication flows.

The bottom line: Director reduces upfront workflow creation time through AI assistance but leaves teams facing the same ongoing maintenance burden as Selenium or Playwright once payer portals change, making it unsuitable for multi-payer authorization workflows that require long-term reliability without continuous manual intervention.

Automating Healthcare Prior Authorization with Skyvern

Skyvern automates prior authorization by treating each payer portal as a browser-based workflow that LLMs can interpret. Pass in authorization data as JSON (patient info, diagnosis codes, CPT/HCPCS, prescriber NPI, clinical documentation) via API, and Skyvern executes the full submission workflow across any payer portal without portal-specific code.

The system logs into UHC Optum, Cigna, Aetna, or any other payer site, solves CAPTCHAs, handles MFA prompts, fills multi-page authorization forms by matching your data to each portal's unique field labels, uploads supporting clinical documents, and submits the request. Status checks run on schedule, extracting approval numbers or denial reasons and returning structured results via webhook for integration with your practice management system.

Human-in-the-loop review flags complex cases requiring clinical judgment before final submission. Every run produces a complete audit trail with screenshots and video replay for compliance documentation. HIPAA capability comes through self-hosted or VPC deployment. Because Skyvern reads portals visually instead of relying on hardcoded selectors, it works across every payer without breaking when UIs change.

Most teams can deploy their first automated workflow in 2-3 hours. Complex multi-step processes like policy renewals or compliance reporting take 1-2 weeks to fully optimize and test across all systems.

Steel pricing tiers provide flexible options for different scales: the Free tier includes $10 in credits per month (100 browser hours), Start tier is $29/month (290 browser hours, 2.9 GB proxy bandwidth, 7.2K CAPTCHA solves), Developers tier is $99/month (1,238 browser hours, 12 GB proxy bandwidth, 28K CAPTCHA solves), and Startups tier is $499/month (9,980 browser hours, 166 GB proxy bandwidth, 166K CAPTCHA solves). This usage-based model scales with authorization volume and avoids the per-user licensing fees and minimum seat commitments that make enterprise RPA platforms expensive for mid-market healthcare practices.

Final Thoughts on Fixing Prior Authorization Bottlenecks

The portal problem doesn't fix itself, and partial ePA integrations only cover 31% of your authorization work. Automated prior authorization software picks up where EHR integrations stop, handling the complex cases and multi-payer workflows that still require human attention today. You can automate those remaining workflows now and get hours back for your clinical team.

FAQ

How long does prior authorization take with browser automation?

Automated portal submissions complete in 2-5 minutes per authorization compared to 16-24 minutes manually. The system processes multiple payer portals simultaneously, so practices can submit 50+ authorizations across different insurers in the time it would take staff to complete 2-3 manually.

What happens when a payer portal changes its layout?

LLM-based automation reads portals by meaning instead of hardcoded page structure, so it adapts automatically when payers update their interfaces. Staff won't need to fix broken scripts or reconfigure automation workflows after UI changes.

Can automation handle complex cases requiring clinical documentation?

Yes, the system uploads supporting clinical documents like physician notes, lab results, and imaging reports to each payer's portal during submission. Human-in-the-loop review flags cases with ambiguous clinical criteria for staff approval before the authorization submits, so clinical staff maintain control over complex decisions while automation handles the portal work.

How accurate is AI-powered automation compared to manual portal entry?

AI-powered web scraping delivers 30-40% faster data extraction times and achieves accuracy rates of up to 99.5% when handling dynamic, JavaScript-heavy websites compared to traditional methods. For prior authorization, this translates to fewer submission errors that trigger denials and rework. The system validates data before submission and flags inconsistencies for staff review, reducing the manual error rate that occurs when teams rush through 39+ authorizations per week across different portal interfaces.

Does this work with Medicare Advantage and Medicaid plans?

The automation works across any payer portal including UnitedHealthcare, Cigna, Aetna, Humana, BCBS variations, Medicare Advantage carriers, and state-specific Medicaid plans. Each portal's unique authentication, form layout, and documentation requirements are handled without building payer-specific integrations.