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 universally hated manual tasks in healthcare operations. Staff log into Availity, Change Healthcare, or individual payer portals, enter member IDs, and copy results back into the Practice Management system.

For a group practice seeing 50+ patients per day, 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 economically viable at their scale, they've been burned by brittle scripts that break when portal UIs change, or they assume HIPAA makes it illegal (it doesn't — you just need the right architecture).

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. I use this pattern in every production eligibility bot — it reduces quarterly maintenance from days to hours.

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 — not for HIPAA specifically, but because payers sometimes dispute automated queries.

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 one to two days of engineering time per quarter for portal maintenance. Payers change their HTML structure often enough that some tuning is always needed. The role-based selector approach reduces this significantly, but payers occasionally change the label text on buttons as well — which does require a code fix.

The cost is still a fraction of the manual labor it replaces. See the RPA cost breakdown article for a full ROI analysis of bot projects at dental group scale.

The RPA Billing Automation service covers eligibility verification, prior authorization, and claim status — built and maintained as a single bot suite.