Most engineering teams building prior auth automation start the same way. Open Playwright, record a session on Availity or Cigna, write a script against the selectors, run it on a handful of test cases. It works. The demo goes well. You ship it.
Then production finds the edges.
This isn't a knock on Playwright. It's one of the best browser automation tools available. But payer portals weren't designed to be automated, and the ways they resist it are specific enough that knowing them in advance saves a lot of pain. Here's what teams consistently run into when they try to build and maintain this themselves.
Selectors That Change Under You
Angular and React payer portals regenerate element IDs on every render. The data-v-3f9a12c4 attribute your script targets in a test session may not exist in the next session. Unique identifiers tied to component state, build hashes, or session context are common on portals built with modern frontend frameworks. Cigna, Carelon, and CoverMyMeds all use dynamic rendering patterns that make hardcoded CSS selectors and XPaths brittle by design.
The failure mode here is subtle. Your script doesn't always throw an obvious error. It may target a stale selector, interact with the wrong element, and continue running. A wrong dropdown selection on a prior auth form doesn't just fill the wrong field. It can branch the form into a completely different clinical pathway, producing a submission that looks complete but triggers a first-pass denial. You won't know until the payer responds days later.
Stable selectors require semantic anchors: element text, ARIA labels, visible labels, structural position. But even these require maintenance as payers update their portal copy or restructure forms for new drug categories.
Session Timeouts During Complex Submissions
A full prior auth submission on Carelon or UHC often involves 20 or more form interactions. Portal sessions typically time out between 15 and 30 minutes. If your script hits a slow server response, gets rate limited on a drug code lookup, or encounters a validation error that requires a retry, you can exceed the timeout window mid-submission.
The consequence is worse than a clean failure. A timed-out session on a partially completed prior auth can leave the submission in an indeterminate state. Some portals save partial progress, some don't. You may not be able to safely resume or resubmit without first checking whether the original attempt was recorded. On live patient data, that check is not optional.
Concurrent sessions compound this. If multiple patients are being submitted simultaneously under the same provider credential, portals with single-session enforcement will terminate earlier sessions, or flag the account for unusual activity. Managing concurrency across a queue of pending prior auths requires coordination logic that goes well beyond what a simple script handles.
No Staging Environments
Payers do not provide sandbox environments for automation testing. There is no fake patient you can use to verify your integration against a real portal. Every test is a live submission, against real patient records, with real clinical and compliance implications.
This means bugs surface in production. A script that handled 50 submissions cleanly can break on submission 51 because the payer pushed a silent UI update to their portal. There is no changelog, no notification, no version bump. You find out because a submission fails, or worse, because it completes incorrectly.
The testing constraint also means you cannot safely iterate quickly. Every change to your automation requires careful manual walkthrough before deployment, which is expensive in engineering time and slows down the iteration cycle significantly.
Bot Detection
UHC uses Shape Security. Other major portals use Cloudflare, Akamai, or behavioral fingerprinting systems. A default headless Chromium session exposes navigator.webdriver = true, which is a known signal for every major anti-bot system. Even Playwright with stealth plugins is identifiable. Google Chrome for Testing, which Playwright uses by default, is a red flag for detection systems that maintain lists of known automation browser builds.
Beyond browser fingerprinting, behavioral detection looks at interaction patterns. Scripts that move at machine speed, interact with elements in a fixed order, and never produce natural mouse variance are distinguishable from human sessions. CAPTCHA challenges appear unpredictably, often mid-flow rather than at login, which means a script that clears the initial authentication can still get blocked several pages deep into a submission.
Bypassing this requires maintaining a realistic browser profile, managing request headers and timing, and staying ahead of detection system updates. That's not a one-time engineering project. It's ongoing maintenance, and payers invest actively in keeping their bot detection current.
Portal Proliferation
UHC has four different portal environments depending on plan type. Cigna routes certain drug categories through CoverMyMeds and handles others on its own portal. Aetna has different flows for behavioral health versus medical. Each portal variant has its own authentication, its own form structure, its own session behavior.
At the scale a health tech company actually needs, you're not maintaining one Playwright script. You're maintaining dozens, each covering a specific portal and plan configuration, each requiring updates when the portal changes. The long tail is long. A billing company serving a thousand clients, each contracted with 30 to 50 payers, faces a combinatorially large surface area of portal configurations, most of which are rarely tested and frequently broken.
When a payer adds a new clinical question for a new drug category, scripts that don't handle the new branch don't fail loudly. They may continue to completion, submitting a prior auth that's missing required clinical context, and the denial comes back a week later. Silent failures are the hardest to catch and the most expensive when they involve patient care timelines.
What Actually Works
The teams that ship reliable prior auth automation separate the build phase from the run phase.
In the build phase, an agent maps the portal by monitoring network and request traffic, not by targeting DOM selectors. Rather than scraping element attributes that change on every render, the agent intercepts the underlying API calls and form submission payloads the portal is making. This gives you a stable, structured picture of what data the payer actually requires and how it flows, independent of how the frontend renders it.
In the run phase, what executes is a deterministic script built from that network map, not an agent reasoning live on the page. This matters both for reliability and for compliance. Healthcare teams are rightly uncomfortable with a model making judgment calls about which dropdown to select when the patient's drug approval is on the line. Deterministic execution with structured patient data as input is auditable, repeatable, and doesn't produce the class of errors that come from a model misreading a form under time pressure.
The third piece is maintenance. Portal UIs change, but the underlying network requests change far less often. When a payer redesigns their frontend, the API calls behind it are usually stable. An automation layer built on request traffic survives UI updates that would break any selector-based script.
If you want to run prior auth submissions without building the portal layer yourself, Simplex handles the browser automation, bot detection, and portal maintenance. Hit our endpoints with patient and provider data, get back structured submission results and session replays. You own the clinical logic.