Checking insurance eligibility means spending time copying patient details into a payer portal, finding the coverage and benefits for the visit, and entering the answer back into your system. Your team repeats that work for each patient, across websites with different logins and layouts, time and time again.
We built Skyvern to fix this (I'm Skyvern's CEO). We use AI agents and computer vison to automate repetitive healthcare workflows like this, saving your team countless hours of repeated navigation and data entry.
In this article I'll go over how you can automate insurance eligibility verification with Skyvern (it's simple you'll see).
If you'd rather skip the details and see exactly how Skyvern can automate your specific workflow, book a personalized demo with us*. We'll explore your use-case and show you how you can automate your workflow.*
What Skyvern does #
Skyvern can sign into a payer portal, enter the member information, navigate to the benefits page, and extract the fields your practice needs. Your integration supplies the appointment details and receives the result, so the browser work can run as part of your existing process.
Skyvern uses language models and computer vision to interpret the page. You can instruct it to find the member search and enter a subscriber ID, and it works out how to perform those actions in the interface. That gives you a way to build around the task while relying less on instructions tied to the position or code of individual page elements. You still configure and test the workflow for each payer.
I would use this for the checks your team still performs in a browser. If an existing payer API or clearinghouse connection already returns the information you need, keep using it. The opportunity for Skyvern is the portal work that remains, including getting the answer back into the appointment record so staff can use it.
How to build the workflow, step by step #
Let's build a workflow that checks coverage and office visit benefits for an upcoming appointment. In Skyvern, we'll build it in Studio, then connect it to the appointment schedule once a single check works.
1. Choose a payer and define the inputs
Start with a portal your team uses frequently and a type of visit they already know how to verify. That gives you a familiar result to compare with the automation.
In Skyvern Studio, create a blank agent through Agents → All Agents → Create → Blank Agent. Name it for the payer and task, then open Inputs and add the values that change with each appointment. For this example, use string inputs:
| Input | Fictional example |
|---|---|
appointment_id |
APPT-1042 |
patient_name |
Example Patient |
member_id |
DEMO123456 |
date_of_birth |
1985-03-12 |
date_of_service |
2026-10-15 |
service_type |
Office visit |
provider_id |
DEMO-PROVIDER |
Adjust the inputs to match what the payer asks for. The appointment ID stays with your integration so it can attach the answer to the right record. Use a payer-approved test record for the first run. The invented values above only illustrate the format.
2. Connect the payer portal login
Open Credentials, choose Add → Password, and save the portal's login URL and account details. Back in Studio, add a Login block and select that saved login in its Credential field. This keeps the password out of the task instructions.
Configure the account's two-factor authentication at this point. For a supported authenticator setup, Skyvern can generate codes from the saved authenticator key. Email codes need a connected inbox or a way to forward them, while SMS codes need to be supplied to Skyvern.
Run the login block and confirm that it reaches the signed-in portal. Getting authentication working first makes later failures easier to diagnose.
3. Tell Skyvern how to perform the check
Add a Browser Task block after Login. Leave its URL blank to continue in the signed-in browser, then enter the instructions in its Prompt field. The double braces reference the inputs you defined earlier.
Use this as a starting point:
Open the eligibility and benefits search. Find the member using member ID {{ member_id }} and date of birth {{ date_of_birth }}. Confirm that the returned patient matches {{ patient_name }}. If the match is ambiguous or no member is found, stop and report the reason.
Request eligibility for {{ date_of_service }}, using provider {{ provider_id }} and service type {{ service_type }} where the portal asks for them. Open the results showing coverage and the benefits for that service. Finish with those results visible for extraction. Report any required information that the supplied inputs do not contain.
Adapt this to the payer's terminology and search requirements. Naming the service and date gives the agent a specific question to answer.
4. Specify the information to extract
After the Browser Task, add an Extraction block. Set its Data Extraction Goal to collect the coverage response and office visit benefits displayed for the requested date. Tell it to preserve qualifications such as individual versus family deductibles and in-network versus out-of-network benefits.
Enable Data Schema and use Generate with AI to create a JSON Schema with these fields, then review the generated definition:
| Field | Expected value |
|---|---|
coverage_status |
active ,inactive , orunknown |
effective_from |
Date, or null if absent |
effective_to |
Date, or null if absent |
office_visit_copay |
Amount with its conditions, or null |
remaining_deductible |
Amount with its conditions, or null |
missing_information |
A list of requested details the portal did not provide |
For example, a fictional extracted response could look like this:
{
"coverage_status": "active",
"effective_from": "2026-01-01",
"effective_to": "2026-12-31",
"office_visit_copay": "$30 per in-network office visit",
"remaining_deductible": "$600 remaining on the individual in-network deductible",
"missing_information": []
}
Keep the conditions attached to the amounts. A bare 30 loses the information staff need to interpret the copay. If the portal spreads benefits across separate pages, add navigation and extraction blocks for those pages, then combine their outputs in your integration. An Extraction block reads the current page.
5. Run a check and inspect the result
Save the agent, select Run, and supply your test inputs. Watch the browser as it works, then use the Run pane to inspect the outputs and the recording or screenshots. Skyvern's run controls let you review what happened at each step.
Compare the extracted response with a manual check of the same record. Confirm the patient match and service date before checking the benefit details. Pay particular attention to qualifiers: a family deductible copied into an individual deductible field can look plausible while answering the wrong question.
Test a member lookup that does not return a result as well. Your integration should treat that as an unresolved check. Only record inactive coverage when the payer explicitly reports it.
6. Attach the answer to the appointment
Once the result is accurate, connect it to the system staff already use. In the agent's settings, set the Webhook Callback URL to an endpoint your integration controls. Skyvern can notify that endpoint when the run finishes, allowing your integration to process the result.
When submitting the check, save the relationship between the appointment ID and the Skyvern run ID. On completion, use that mapping to attach the extracted benefits, run outcome, and completion time to the appointment. Keeping the run ID also gives you a way to investigate a result later.
Define which missing details require staff review. A failed login should produce a request to resolve access, while a missing copay should produce a benefits follow-up. Neither should overwrite a previous coverage result with an empty answer.
7. Connect the upcoming appointment schedule
Have your scheduling integration select the appointments that need verification and start the payer agent with each appointment's inputs. Begin with a small batch and check that every submitted appointment receives either a usable result or a visible reason for follow-up.
Account limits matter here. If signing in a second time ends the first session, enable Run workflows sequentially for this credential in the saved credential's settings. Checks using that account will run one at a time, avoiding competition for the same session.
Before adding another payer, measure the time staff still spend reviewing and correcting results. That is how I would judge whether the workflow is ready to expand. A fast browser run has limited value if someone has to repeat the lookup, while an accurate result attached to the appointment removes work from the team's day.
If you want help building your first eligibility workflow, bring us the payer portal and the result your staff need. We can work through the setup with you.