Insurance Eligibility Verification

What is insurance eligibility verification?

Insurance eligibility verification is the process of confirming, before a visit, that a patient's coverage is active for the planned service and what the patient owes: copay, coinsurance and remaining deductible. Providers run it through HIPAA-standard X12 270/271 transactions or payer APIs and record the result on the patient's coverage record.

Why is an active coverage response not enough?

A response that says coverage is active answers only the first question. The visit can still be denied or under-collected for reasons that sit deeper in the response.

• Service carve-outs: A plan can be active for general benefits while behavioral health, imaging or therapy is managed by a separate vendor with its own rules.
• Visit limits: Therapy and similar benefits often carry visit caps. The response may show visits used or remaining only when the inquiry asks for that service type.
• Plan replacements: A patient with a Medicare number may be enrolled in a Medicare Advantage plan, so claims sent to traditional Medicare will be rejected.
• Other coverage: A second plan may be primary, which changes who gets the first claim.
• Timing: Coverage can end at a month boundary. A check run at booking weeks earlier can be wrong on the day of service.
• Prior authorization: Some services need approval before they are performed, and the eligibility response may only hint at it.

Which standards and rules govern eligibility checks?

Eligibility is one of the most standardized transactions in US healthcare. These rules set the format, the response times and the boundaries of newer payer APIs.

• HIPAA transaction standard: 45 CFR 162.1202 adopts the X12 270/271 version 005010X279A1 as the standard for eligibility inquiries and responses between providers and health plans.
• Operating rules: HHS adopted the CAQH CORE eligibility operating rules in 45 CFR 162.1203. They set a maximum real-time response time of 20 seconds and require health plans to return patient financial responsibility, such as copay, coinsurance and deductible, for a defined set of service types.
• Payer APIs: CMS-0057-F requires impacted payers to offer a Prior Authorization API from 1 January 2027. The rule recommends, but does not require, the HL7 Da Vinci CRD, DTR and PAS guides, and it does not govern X12 270/271 eligibility checks.
• FHIR resources: In FHIR R4, eligibility is modeled with CoverageEligibilityRequest and CoverageEligibilityResponse, with the plan itself in Coverage.
• Accessibility: Under 45 CFR 84.84, recipients of HHS federal financial assistance must make web content and mobile apps meet WCAG 2.1 Level AA, from 11 May 2027 for recipients with 15 or more employees. Patient pre-registration and card upload screens are in scope.

On the security side, any vendor that handles member IDs, names and dates of birth on the provider's behalf, such as an eligibility service or a card-scanning API, is a business associate and needs a BAA.

How does an automated verification pipeline work?

An automated pipeline runs four stages. Clean results update the record with no staff touch, and only problems reach a person.

• Stage 1, triggers and capture: A new appointment, arriving as an HL7 v2 SIU message or a FHIR Appointment event, starts a check. Scheduled batch runs repeat it before the visit. When a patient photographs their card, text extraction reads payer name, member ID and group number for staff to confirm.
• Stage 2, the 270 inquiry: The pipeline normalizes names and dates, maps the payer to the clearinghouse payer ID, places the patient in the subscriber or dependent loop, and picks the service type code for the visit. Examples: 30 for general plan coverage, 98 for a physician office visit, PT for physical therapy, AD for occupational therapy, MH for mental health.
• Stage 3, the 271 response: A parser reads the benefit segments for status, network, copay, coinsurance, deductibles and other payers. Rules flag Medicare Advantage enrollment, a different primary payer and missing benefit details.
• Stage 4, record and route: The pipeline updates the EHR's coverage record and a CoverageEligibilityResponse or HL7 v2 insurance segments, estimates what to collect at check-in, and sends exceptions to a staff queue with a plain-language reason.

Store each inquiry and its response as a pair, keyed to the appointment and the run that produced it. That history shows when coverage changed, supports appeals, and lets the team replay old responses through a new parser version before release.

How do you read the parts of a 271 that matter?

Most of the useful data in a 271 sits in the EB (eligibility or benefit information) segments inside loop 2110C for subscribers and 2110D for dependents. These are the elements a parser needs to handle.

• EB01: The type of information, such as 1 for active coverage, 6 for inactive, B for copay, A for coinsurance and C for deductible.
• EB02: The coverage level, such as individual or family, which decides which deductible applies.
• EB03: The service type code the benefit applies to. Match it to the code the inquiry asked for.
• EB06: The time period, which separates a calendar-year deductible from the amount remaining.
• EB07 and EB08: The dollar amount and the percentage, used for copay, deductible and coinsurance.
• EB12: Whether the benefit is in network, out of network or does not depend on network.
• Loop 2120: Benefit-related entities, such as another payer or a carve-out vendor, with contact details.
• AAA segments: Rejections. Codes 72, 73 and 75 point to a bad member ID, a bad name or a subscriber not found.

Free-text MSG segments sometimes carry the only mention of a visit limit or referral rule. Store them, show them to staff, and treat any automated reading of them as a suggestion for staff to confirm.

When should checks run, and what happens to exceptions?

Checks should run more than once, with each run tied to a decision staff can still act on. A typical schedule and exception flow looks like this.

• 1. At booking: Confirm the plan and service benefits while the patient is still on the phone or portal.
• 2. A few days before: Rerun in batch so staff have time to request a new card, start a prior authorization or reschedule.
• 3. The day before: Rerun to catch coverage changes at the start of a month.
• 4. At check-in: Run in real time if anything changed, and show the amount to collect.
• 5. Route exceptions: Send inactive coverage, AAA rejects, other-payer flags and authorization needs to a queue sorted by appointment time.
• 6. Contact the patient: For missing or inactive coverage, send a secure link to upload a current card before the visit.
• 7. Close the loop: Compare denials on the 835 remittance with the stored 271 for that visit and adjust parsing or schedule rules.

Turning a 271 into a front-desk screen

Front-desk staff should never see raw X12. The check-in screen works best with three plain elements that the parser fills in from the response.

• Coverage badge: Active in network, active out of network, inactive as of a date, or another plan detected, such as Medicare Advantage.
• Collect today: The copay or estimated amount for this visit type, with the remaining deductible beside it.
• Next step: A plain instruction when something failed, such as asking for the card again because the member ID format does not match the payer.

Keep the raw response one click away for billing staff, and store it with a timestamp on the encounter.

Eligibility verification failure points

These failure points account for most of the gap between a check that ran and a claim that pays.

• Only asking for code 30: General coverage responses return primary care copays. Specialty, therapy and behavioral health clinics then collect the wrong amount.
• Reviewing every patient: When staff must open each clean result to find the few bad ones, the bad ones are missed.
• Bots where EDI exists: Screen scraping a payer portal for data the 271 already returns is fragile. Keep portal automation for gaps the 271 does not cover.
• Wrong loop for dependents: Sending a child or spouse as the subscriber can trigger avoidable rejections with some payers.
• No write-back: A check run in a separate portal that never updates the EHR leaves the claim with the old member ID.
• Missed plan replacements: When the parser ignores insurance type and benefit-related entity details, Medicare Advantage and Medicaid managed care enrollment goes unnoticed and claims go to the wrong payer.
• Card front only: The back of the card often carries the claims address, carve-out phone numbers and payer ID. Ask for both sides.
• No stored response: Without the timestamped 271, an appeal for a coverage denial has no proof of what the payer said on the day of service.

How Agnotic can help

Eligibility automation pays off when clean checks need no staff time and exceptions arrive with a clear next step, and Agnotic builds pipelines to that standard. Agnotic Technologies integrates X12 270/271 through your clearinghouse or payer connections, maps visit types to service type codes, parses 271 benefits into collect-today amounts, and writes results back to the EHR.

The work also covers card capture, the exception queue and the link back to 835 denials, so rules improve from real outcomes.

Sources

• 45 CFR Part 162 Subpart L: Eligibility for a health plan (162.1202)
• CMS: Eligibility and benefit (270/271) transaction standard
• CAQH CORE: Eligibility and benefits operating rules
• CMS: Interoperability and Prior Authorization final rule (CMS-0057-F)
• HL7 FHIR R4: CoverageEligibilityResponse resource
• Federal Register: Extension of compliance dates for HHS Section 504 web and mobile accessibility rule