Automating Insurance Eligibility Verification with Python and Playwright

Why Eligibility Verification Is Still Manual in Most Clinics

Insurance eligibility verification, confirming that a patient's coverage is active before their appointment, is one of the most disliked manual tasks in healthcare operations. Staff log into Availity or individual payer portals, enter member IDs, and copy results back into the Practice Management system.

For a busy group practice, this is hours of daily work. Yet most clinics still do it by hand. The reason is usually one of three: they don't know automation is viable at their scale, they've been burned by brittle scripts that break when portal UIs change, or they assume HIPAA rules it out. HIPAA does not prohibit automating an eligibility check. A payer's portal terms might, which is why the route comes before the code.

Choose the Route Before You Write a Bot

Eligibility has a standard electronic transaction, so a portal bot is rarely the first choice. Work through the routes in this order for each payer:

1. X12 270/271 through your clearinghouse. The 270 inquiry and 271 response are the HIPAA standard for eligibility. If your clearinghouse reaches the payer, use it.
2. A clearinghouse or payer API. Structured responses over a connection the payer has approved.
3. Portal automation, only where the payer's terms allow it or the payer has approved it in writing. This is where Playwright comes in.
4. Staff. If a payer offers none of the above, the check stays manual and lands in a worklist.

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.

The rest of this article covers the third route: how to build a portal check that holds up, on a portal you are permitted to automate.

Playwright Over Selenium

Playwright has largely replaced Selenium for healthcare RPA work because of two critical advantages:

1. Browser context isolation: Each bot run gets a clean browser context with no shared cookies or storage — essential when handling multiple patient sessions in parallel.
2. Auto-waiting: Playwright automatically waits for DOM elements to be stable before interacting. Selenium scripts break when payer portals add loading spinners. Playwright handles this natively.

import asyncio
from playwright.async_api import async_playwright

async def check_eligibility(member_id: str, payer_url: str) -> dict:
    async with async_playwright() as p:
        browser = await p.chromium.launch(headless=True)
        context = await browser.new_context()
        page = await context.new_page()

        await page.goto(payer_url)
        await page.fill("#member-id-input", member_id)
        await page.get_by_role("button", name="Verify Eligibility").click()

        # Playwright auto-waits for the result element to appear
        await page.wait_for_selector(".eligibility-result", timeout=15000)
        result = await page.inner_text(".eligibility-result")

        await browser.close()
        return {"member_id": member_id, "coverage_status": result}

Building for Resilience: The CSS Selector Problem

The biggest failure mode for eligibility bots is portal UI changes. Payers update their portals regularly. When the HTML structure changes, CSS selectors like #submit-claim-btn-v2 break silently — often at 3 AM when the bot is mid-run.

The solution is role-based and text-based selectors instead of fragile DOM IDs:

# Fragile — breaks the moment the payer redesigns their portal
await page.click("#btn-verify-elig")

# Resilient — targets the element by its visible role and label
await page.get_by_role("button", name="Verify Eligibility").click()
await page.get_by_label("Member ID").fill(member_id)

Playwright's get_by_role() and get_by_label() selectors survive portal redesigns because they match on semantic meaning, not arbitrary HTML attributes, so they need fewer fixes when a payer changes its pages.

HIPAA Architecture for RPA Bots

An eligibility bot doesn't inherently touch PHI stored in your system — but the member IDs it submits and the results it retrieves are sensitive. The compute environment running the bot must meet HIPAA's technical safeguard requirements:

• Compute isolation: The bot should run in a dedicated AWS Lambda function or containerized ECS task, not on a shared application server.
• Secrets management: Payer portal credentials must be stored in AWS Secrets Manager or GCP Secret Manager — never in environment variables or hardcoded in code.
• Result encryption: Eligibility results written back to the PM database must travel over TLS and land in a KMS-encrypted datastore.
• Audit logging: Every bot execution should log the patient ID, timestamp, and result to an immutable audit log, so you can show exactly what was asked, when and under which account.

For the full infrastructure pattern, see the dental RPA billing reference architecture, which uses the same Lambda + Secrets Manager + encrypted RDS stack.

Integration with Your Practice Management System

The bot's output needs to land somewhere useful. Typically this means:

1. Writing the eligibility status back to the patient record in your PM database via an internal API
2. Flagging appointments where coverage is inactive or a referral is required
3. Surfacing a pre-appointment worklist for the front desk

If you're running custom Practice Management software, this integration is a first-class feature. If you're on a third-party PM system, the bot usually writes to a bridge table that the PM system polls.

Maintenance Budget

Plan for recurring engineering time on portal maintenance. Payers change their HTML structure often enough that some tuning is always needed, and they change their terms too, so re-read them on a schedule. The role-based selector approach reduces the fixes, but payers occasionally change the label text on buttons as well, which does require a code change. Checks that run through a clearinghouse or API need far less of this.

To weigh that cost against the manual work it replaces, see how to calculate healthcare RPA ROI.

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