Automating Prior Authorization in Healthcare: Architecture and Cost

The Prior Authorization Problem

Prior authorization (PA) requires clinics to get insurance company approval before providing certain procedures, medications, or referrals. For high-volume practices, PA requests consume hours of staff time daily: logging into payer portals, submitting clinical documentation, checking status, and managing denials.

Much of that work is repetitive: the same codes, the same documentation types, the same follow-up. That makes it a good candidate for automation, as long as each payer is reached through a route it allows.

What Can Be Automated

• Status checks on submitted PA requests
• Eligibility pre-checks before submitting
• Assembling the documentation packet for standard procedures (orthopedic, imaging, DME, specialty pharmacy)
• Submission through the payer's API, the X12 278 or a portal that permits automation, after staff review
• Denial notification retrieval and routing to the right staff queue

What Cannot Be Automated

• Clinical judgment calls: whether to submit at all, what documentation to include
• Complex appeals requiring physician narrative letters
• Phone-based PA requests (some payers still require calls for specific codes)
• Portals whose terms prohibit automated access, unless the payer approves it in writing

One Connector Per Payer

Each payer accepts requests differently, so the system is organized as one connector per payer behind a shared request model. The route is chosen payer by payer, in this order of preference:

1. FHIR Prior Authorization API, where the payer offers one. CMS-0057-F requires impacted payers to offer these, generally from January 1, 2027.
2. X12 278 through your clearinghouse.
3. Portal automation, only where the payer's terms allow it or the payer has approved it in writing.
4. Manual, in the same work queue, for phone, fax and portals that do not permit automation.

Check the payer's terms before automating a portal. Several large payers do not allow it. Availity announced in April 2022 that it was ending bot access to Availity Essentials and offers API connections to approved partners instead. The terms of use for the UnitedHealthcare provider portal and Optum prohibit using software to access or scrape their online services, and the Evernorth terms bar robots, scripts and scraping unless Evernorth approves in writing. A bot that breaks a portal's terms puts the practice's portal account at risk. Terms change, so read the current version for each payer; we last read these on 2026-09-29. This is engineering context, not legal advice.

from enum import Enum
from typing import TypedDict

class Route(Enum):
    FHIR_API = "fhir_api"
    X12_278 = "x12_278"
    PORTAL = "portal"  # set only once the payer's terms or written approval are on file
    MANUAL = "manual"

class PARequest(TypedDict):
    member_id: str
    procedure_code: str
    diagnosis_codes: list[str]
    requesting_provider_npi: str
    documentation_path: str

async def submit_prior_auth(request: PARequest, payer_id: str) -> str:
    route = PAYER_ROUTES.get(payer_id, Route.MANUAL)

    if route is Route.FHIR_API:
        return await submit_fhir_pas(request, payer_id)
    if route is Route.X12_278:
        return await submit_278(request, payer_id)
    if route is Route.PORTAL:
        return await submit_through_portal(request, payer_id)
    return await queue_for_staff(request, payer_id)

A payer with no recorded route falls through to the staff queue, so a missing entry never turns into an unapproved bot run.

Where a portal connector is permitted, role-based selectors (get_by_label, get_by_role) survive portal redesigns better than CSS ID selectors. See the eligibility verification automation guide for why this distinction matters.

HIPAA Requirements

PA connectors handle PHI: member IDs, procedure codes, diagnosis codes, and clinical documentation files. The pipeline must satisfy HIPAA technical safeguards:

• Payer credentials stored in AWS Secrets Manager (never in code or environment variables)
• Documentation files encrypted in transit and at rest (KMS-encrypted S3)
• Audit log of every submission, status check, and outcome

The same Lambda + Secrets Manager + encrypted S3 pattern used in the dental RPA billing reference architecture applies here.

Denial Analytics

When every PA result is stored as structured data, you can analyze denial patterns by payer, procedure code, and provider, turning a reactive task into a proactive workflow optimization signal. This layer integrates directly with custom Practice Management software.

The RPA Billing Automation service covers prior authorization, eligibility verification and claim status, using the route each payer allows.