How to Set Up Automated Insurance Verification (Step-by-Step)

Manual insurance verification means calling the payer, getting transferred, waiting on hold, writing down eligibility details, and typing them into your EHR, for every patient, every day.

Automated verification queries the payer's eligibility API instead and stores the coverage details with the patient record before the patient shows up. Here are the technical steps: which APIs to use, how to structure the data flow, and how to handle the edge cases.

Why Automation Matters for Insurance Verification

The 270/271 EDI standard exists for eligibility checks, but many practices still verify by phone because payer connections look complicated. Clearinghouses like Availity, Change Healthcare, and Waystar expose REST APIs over the EDI layer: JSON in, JSON out, no X12 parsing. Staff review results instead of gathering them.

If you'd rather not build this yourself, Formisoft lets staff run an eligibility check from the patient chart that returns coverage, copay, and deductible, pay as you go. It works alongside your EHR rather than replacing it.

Step 1: Choose Your Eligibility API

Three options:

Clearinghouse APIs (Availity, Change Healthcare, Waystar): These services aggregate multiple payers into a single API. You send one eligibility request and they route it to the correct payer. Pricing varies, typically $0.10-$0.25 per check.

Direct payer APIs (Anthem, UnitedHealthcare, Aetna): Some payers offer their own eligibility APIs. Faster response times, but you need separate integrations for each payer. Only worth it if 80%+ of your patients use the same insurance.

Practice management system APIs: If your PM system already has payer connections, you might expose eligibility checks via their API instead of building direct integrations. Check their documentation. Some systems (like Kareo and AdvancedMD) support this. Others don't.

If you build your own integration, Formisoft's webhooks can pass each intake submission, insurance details included, to the service that calls your clearinghouse.

Step 2: Map Your Data Flow

You need patient demographics (name, date of birth), insurance details (member ID, payer), and the date of service. Intake collects the first two; the appointment provides the third.

The architecture:

1. Patient fills out your insurance verification form
2. Form submission triggers a webhook to your clearinghouse API
3. Clearinghouse queries the payer and returns eligibility data
4. Your system parses the response and writes it to the patient record
5. Front desk reviews the verification status before check-in

The key decision is where eligibility data lives: written into the EHR via API (requires EHR API access), or kept in the intake platform and shown at check-in (less integration work, but a second place to look).

Step 3: Handle the 270/271 Response Structure

Even behind a REST wrapper, know what the 271 response contains:

Active coverage: Is the patient currently covered? (Yes/No/Unknown) Benefit details: Copay amounts, deductible status, out-of-pocket max Service-specific coverage: Does the plan cover the CPT codes you're billing? Primary vs. Secondary: Is this the primary payer or a coordination of benefits scenario?

Most clearinghouse APIs return this as nested JSON. Here's a simplified example:

{
 "eligibility": "active",
 "effectiveDate": "2026-01-01",
 "copay": {
 "office_visit": 25.00,
 "specialist": 50.00
 },
 "deductible": {
 "individual": 1500.00,
 "met": 300.00
 }
}

Your automation needs to handle three response states:

1. Verified active: Coverage confirmed, benefits retrieved
2. Not found: Payer has no record of this member ID
3. Error: API timeout, invalid request, or payer system down

Flag the second and third cases for manual review. Don't assume every check returns clean data.

Step 4: Automate the Trigger

Verify at booking when you can, so there's time to resolve issues before the visit. If insurance details come in with intake, trigger the check on form submission: Formisoft fires a webhook on submission, passing the insurance data to your clearinghouse integration.

For recurring patients, verify at booking but also re-check 7-30 days before the visit. Coverage changes. Plans renew. A verification from three months ago isn't reliable.

Step 5: Build Your Error Handling

Common failure modes:

Member ID typos: Patient enters "ABC123456" when the real ID is "ABC-123456". Your automation should strip spaces and hyphens before sending the request.

Payer ID mismatches: Clearinghouses use different payer IDs than what appears on the insurance card. Maintain a mapping table or use the clearinghouse's payer search API to match the plan name to the correct ID.

Effective date issues: Patient books for next week, but their new plan doesn't start until next month. Your automation needs to check the effective date range, not just active/inactive status.

API timeouts: Payer systems go down. Your automation should retry once after a 5-second delay, then flag for manual review if it fails again.

Store the raw API response in your database. When something breaks, you need the original data to debug it.

Step 6: Integrate With Your EHR

The last step is writing the verified insurance data into your EHR. This requires your EHR to support an API that accepts insurance updates. Not all systems do.

If your EHR has an API, you'll typically use a PUT or PATCH request to update the patient record with the eligibility data. The exact structure depends on your EHR's data model. Epic's FHIR API uses Coverage resources. Athenahealth uses custom endpoints. Check your vendor's documentation.

If your EHR doesn't support API updates (many smaller systems don't), you have two options: display the verification results in your intake platform for manual entry, or export the data as a CSV and bulk-upload to your EHR. Neither is ideal, but both are better than phone calls.

Decide in advance which staff members own manual review, and set team roles so the right people can see the results. The automation handles the successful checks. Your team handles the exceptions.

Real-World Implementation Notes

Don't automate patient responsibility calculations. The eligibility API tells you the deductible and copay amounts, but calculating what the patient owes for a specific visit requires claims data and benefit rules that vary by plan. Verify coverage automatically. Calculate patient responsibility manually or with dedicated revenue cycle software.

Log everything. Store the full API request and response for every eligibility check. When a claim denies three months later because the verification was wrong, you need an audit trail.