Eligibility, COB, and Insurance Discovery Guide

Short answer

A useful eligibility check returns far more than active or inactive. A complete 271 response carries copay amounts, base and remaining deductible, coinsurance percentage, plan name, group number, effective dates, and service-type limitations. Coordination of benefits (COB) determines which payer is primary when a patient carries more than one policy, and getting that order wrong is the most common cause of a CO-22 denial. Insurance discovery is the fallback when the patient has no card or a prior self-pay account turns out to have had coverage all along. Medi connects all three signals to claim setup, payer routing, and denial follow-up. None of them guarantees payment, since adjudication still depends on coding, medical necessity, authorization, and timely filing. But working eligibility correctly prevents the denials that are easiest to prevent.

CMS publishes the administrative simplification framework for Health Plan Eligibility Benefit Inquiry and Response and Coordination of Benefits. CAQH CORE operating rules set the floor for what CORE-certified payers must return. The CAQH 2024 Index Report puts a manual eligibility transaction at about $6.78 and an electronic one at about $0.34.

What a good eligibility response actually contains

Knowing a patient is "active" is almost useless at claim build. The question a biller needs answered is concrete: what is this patient's financial responsibility for this service type, and does anything about the plan limit or exclude this procedure?

A correctly populated 271 answers that. It carries copay amounts by service type (primary care, specialist, urgent care), the base deductible and how much remains for the current benefit period, the coinsurance percentage (for example, 80/20 after the deductible), out-of-pocket maximum and how much remains, plan name and group number, coverage effective and termination dates, and benefit limitations or exclusions tied to specific service type codes.

Payers vary enormously on how much of this they return. A payer can satisfy the 271 standard by confirming active status and almost no financial detail. CAQH CORE's Eligibility and Benefits Data Content Rule (version EB.2.1) requires CORE-certified payers to return base and remaining deductible, copay, and coinsurance for each required service type code. But not every payer is CORE-certified, and even certified payers have discretionary STCs (service type codes) where they may decline to return patient responsibility figures.

This is the gap experienced billers see and new software buyers miss. A platform that displays "Active, United Healthcare" has done almost nothing. A platform that surfaces "$35 copay, $1,200 deductible remaining, 20% coinsurance after deductible, benefit period through December 31" has done the work that prevents a surprise denial, a patient dispute, and a collections problem three months later.

Availity makes the difference concrete. Its eligibility and coverage tool returns structured benefit detail (fixed copay by service category, deductible remaining, coinsurance), not just a status flag. That is why experienced billers prefer it to platforms that tunnel the 271 through a basic active/inactive display. The data exists in the transaction set; the question is whether the software surfaces it or buries it.

Per the 2025 Experian Health State of Claims survey, 68 percent of surveyed providers name inaccurate or incomplete patient data at intake as a primary driver of denials. Much of that is not bad front-desk work. It is software that does not surface the benefit detail the 271 already returned.

The 270/271 transaction in plain English

The 270 is the eligibility and benefit inquiry; the 271 is the response. Both are X12 EDI transactions governed by HIPAA administrative simplification rules and maintained by X12. The transaction set reference for the 271 is 005010X279A1.

The 270 inquiry sends patient demographics (first name, last name, date of birth, member ID or Social Security Number), the payer's identification, the provider's NPI, the date of service or service date range queried, and optionally a service type code specifying which benefit category to check. With no service type code, the payer should return all available benefit information.

The 271 is organized as a hierarchy: payer information, then subscriber (the primary insured), then dependent information if the patient is a dependent rather than the subscriber. Within the subscriber or dependent loop, the EB segments carry the benefit detail.

Each EB segment in the 271 carries:

• EB01: a code for the type of information (1 = active coverage, 6 = inactive, I = copayment, A = coinsurance, C = deductible, and so on)
• EB02 and EB03: codes for the coverage level and service type
• EB04: the insurance type code (HMO, PPO, indemnity, etc.)
• EB06, EB07: the monetary amount or percentage associated with the benefit
• EB08: the coinsurance percentage

Supporting segments carry additional detail: AMT segments hold dollar amounts for deductibles and out-of-pocket maximums, DTP segments carry effective dates and termination dates, and NTE segments carry free-text notes the payer optionally includes.

What payers frequently omit or return inconsistently: out-of-network benefit detail (many return only in-network figures), benefit limitations for mental health or physical therapy visit counts, prior authorization requirements by service type, coordination of benefits information about other coverage on file, and plan-specific exclusions. A payer companion guide, published by most large payers and available from clearinghouses like Stedi, documents what each payer includes and omits.

Watch for a conflicting EB segment: one segment returns active coverage, another returns inactive for the same service type. This happens when the payer's eligibility system holds coverage data from multiple sources that were never reconciled. Software that does not detect and surface the conflict leaves the biller with false confidence in coverage that may not survive adjudication.

Real-time 271 checks return in roughly one to three seconds. Batch checks process a list of patients overnight and suit appointments scheduled in advance. The best practice is hybrid: batch the day prior for all scheduled visits, then run real-time at check-in for walk-ins, late additions, or any patient whose batch result raised a question. Per the 2024 CAQH Index, 96 percent of medical eligibility transactions are now electronic, saving about $6.44 per transaction versus manual phone verification.

Coordination of Benefits in practice

COB determines which payer pays first when a patient carries more than one policy. Getting the order right is a claim validity requirement, not a nicety. Most payers return CO-22 rather than pay a claim where they have reason to believe another payer is primary.

Payer order for most commercial plans follows several standard frameworks.

The birthday rule applies when dependent children are covered under both parents' employer plans. The plan of the parent whose birthday falls first in the calendar year (by month and day, not birth year) is primary for the child. If both parents share the same birthday, the plan that has covered the parent longer is primary. The gender rule, where the father's plan is always primary, has been phased out by most major payers but persists in some older plan documents. When one plan uses the birthday rule and another uses the gender rule, the gender rule controls.

For Medicare, the Medicare Secondary Payer (MSP) framework takes over. MSP is federal law and preempts state law and private contract terms. Per the CMS MSP fact sheet MLN006903, Medicare is secondary in these situations:

• Working aged: the patient is 65 or older, is covered through a current employer's group health plan, and the employer has 20 or more employees
• Disabled: the patient is under 65, disabled, covered through current employment, and the employer has 100 or more employees
• ESRD (end-stage renal disease): the patient is in the first 30 months of Medicare entitlement, and employer size does not matter during the 30-month coordination period
• Workers' compensation: the illness or injury is work-related
• Liability and no-fault insurance: a third party is responsible for the incident

Billing Medicare as primary when MSP applies is not just a denial. It is a recoverable overpayment. CMS can demand repayment within 60 days of a settlement or payment, and civil money penalties for MSP reporting failures can reach $1,000 per day per record. As of 2026, CMS is auditing 250 MSP records per quarter, up sharply from prior years.

The most common COB failure modes: the patient changed employers mid-year and the prior group plan is still on file; both parents' employer plans cover a child but registration captured only one; Medicare is billed primary where MSP makes it secondary because the employer has only 18 employees (under the 20-employee threshold); and secondary claims go out without the primary payer's EOB attached, so the secondary denies without reviewing the claim.

COB workflows that work maintain a structured questionnaire at registration, enforce coverage effective dates so a terminated plan cannot silently stay primary, and run an aging queue for secondary submissions so COB delays do not push secondary claims past timely filing.

Common eligibility-related denials and how to prevent them

These four CARC codes account for most eligibility and COB denial volume billing companies manage. Each has a distinct cause and a distinct prevention path.

CO-22 deserves attention because it is the downstream consequence of every COB mistake made upstream. Per FCSO Medicare CO-22 guidance, prevention rests on three anchors: correct payer order established at registration, primary adjudication proof attached when billing secondary, and resubmission workflows that handle the cross-claim timing correctly.

CO-31 and CO-32 are overwhelmingly preventable with a real-time 271 inquiry before or at the point of service. A subscriber-not-found error from a 271 check is the earliest signal that a claim to that payer will return CO-31. That signal should stop the claim at build, not after submission.

CO-177 is less predictable because it depends on payer-specific eligibility rules the 271 does not always document. Medicare Advantage plans in particular carry coverage conditions, benefit periods, and service area restrictions a generic 271 may not surface. For MA, verify coverage against the specific plan's member eligibility portal or a payer-specific check rather than a generic 271 inquiry.

Insurance discovery: when it matters

Insurance discovery is a separate query from a standard 271 check. A 271 asks a specific payer "is this patient your member?" Insurance discovery sends a patient's demographic data across a network of payers and databases to find whether any active coverage exists, without knowing the payer in advance.

Three scenarios where it adds real value:

The patient presents without an insurance card, or as self-pay but with a demographic profile that suggests employer coverage. A standard 271 has nowhere to go. Insurance discovery fans the inquiry across probable payers (often 13 to 16 real-time checks against major carriers) and returns matches with subscriber and benefit details and a confidence level. Per Stedi's insurance discovery documentation, results take up to 120 seconds, far slower than a real-time 271, so it is a workflow tool rather than a point-of-service lookup.

A prior self-pay or bad-debt account had Medicaid coverage at the time of service that was never captured. Post-service Medicaid discovery tools, including Infinx and ZOLL, monitor patient accounts continuously and flag retroactive Medicaid approvals as they post. Data cited by FinThrive suggests discovery tools find active coverage for more than 40 percent of presumed self-pay patients at some facilities, with retroactive Medicaid accounting for around 5 percent of uninsured patients.

A claim returned CO-22, the billing company suspects a secondary policy exists, and the patient has not provided the details. Discovery can find the secondary plan faster than repeated calls.

Limits worth knowing: discovery returns active coverage for the date-of-service range provided and cannot surface retroactive or future coverage through standard checks. It will not reliably find dental-only or vision-only plans. And finding a policy does not determine primacy, so a separate COB check is still required to establish payer order.

Vendors like Waystar (which acquired Recondo Technology's eligibility and patient-access capabilities), Infinx, and Inovalon operate discovery networks. They differ on the breadth of the payer network they query, match rates for incomplete demographics, and whether results flow into the billing workflow or require manual reentry.

Where does Medi fit?

Medi connects eligibility signals, COB context, and insurance discovery leads to the work that depends on them: claim setup, payer routing, and denial follow-up. Stedi handles the 270/271 EDI transactions. Medi stores the response, surfaces the benefit detail in the claim context, and ties eligibility exceptions to the denial queue when a CO-22, CO-31, CO-32, or CO-177 comes back.

For billing companies, the value is operational. An eligibility check that returns as a raw API response and vanishes into a log is not useful. An eligibility check that surfaces a $1,500 remaining deductible in the claim setup screen, flags a COB mismatch before submission, and ties a CO-31 denial back to the member ID verified at service is useful.

Medi does not:

• Guarantee payment based on an active eligibility response
• Guarantee that a 271 response captured all applicable benefit limits or exclusions
• Guarantee that MSP or COB order is always determinable from available plan data
• Replace clinical judgment on whether a service meets plan medical necessity criteria

The honest framing for billing-company buyers: eligibility, COB, and insurance discovery work reduces the uncertainty that causes preventable denials. What a biller needs is the benefit detail (not just active/inactive), the COB structure visible in claim setup, and eligibility exceptions routed to a denial queue when they produce a denial. Not a standalone eligibility module that lives outside the revenue cycle workflow.

See billing-company operations for the broader operational context, and request a demo to see how eligibility data connects to claim setup and denial follow-up.

What should buyers verify in an eligibility workflow demo?

A demo that only shows an eligibility check returning "Active" has shown you nothing worth evaluating. Verify these specifics:

• Does the 271 response display structured benefit detail (copay by service type, base deductible, remaining deductible, coinsurance percentage), or only active/inactive status?
• Can the biller see benefit detail in the context of claim setup, or is eligibility a separate module with no connection to the claim?
• How does the system handle a conflicting 271 response, where one EB segment returns active and another returns inactive for the same service type?
• Can the system run batch eligibility the day prior for all scheduled patients, and flag exceptions for review before those patients arrive?
• When a 271 returns a subscriber-not-found error, does the system surface it as an actionable task before claim submission?
• Does the COB workflow distinguish payer order, capture the primary EOB, and tie secondary submission to the primary's remittance?
• When a CO-22 or CO-31 denial arrives, does the denial queue link back to the eligibility check that ran before or at service?
• Is insurance discovery available for patients who present without insurance information, and do discovery results flow into the claim setup workflow or require manual entry?
• Which payers are supported for real-time 271 checks, and how current is the payer network?
• How are eligibility responses stored for audit, and can a biller retrieve exactly what was returned on the date of service?

See the denial management workflow guide for how eligibility-related denials fit into the broader denial triage and follow-up workflow.

Frequently asked questions

Does an active eligibility response mean the claim will be paid?

No. Active coverage on a 271 means the patient has coverage with that payer as of the date of service. Payment still depends on whether the service is covered under the plan, whether the deductible is met, whether medical necessity is satisfied, whether authorization is required, whether the claim is billed to the correct payer in the correct order (COB), whether it is filed within the timely filing window, and whether it passes adjudication. Active status prevents CO-177; it does not prevent CO-22, CO-4, CO-50, or CO-197.

What is the difference between a 270/271 transaction and an insurance discovery check?

A 270/271 asks a specific payer whether the patient is a member, so you have to know the payer to run it. An insurance discovery check sends demographics across a network of payers to find any active coverage when you do not know the payer. Discovery is slower (up to 120 seconds) and less reliable for incomplete demographics, but it fills the gap when a patient presents without insurance information. Both differ from COB, which determines payer order among known plans.

What is the birthday rule and when does it apply?

The birthday rule determines primary coverage for dependent children covered by both parents' employer plans. The plan of the parent whose birthday (month and day, not birth year) falls first in the calendar year is primary. It applies only when the child is a dependent on two different employer-sponsored group plans, not to Medicare, Medicaid, workers' compensation, or liability situations. Some older plan documents still use the gender rule (father's plan is always primary); when birthday and gender rules conflict, the gender rule typically controls for that plan pairing.

When is Medicare secondary under MSP rules?

Medicare is secondary in five main situations: working aged (patient is 65 or older, covered by an employer plan, employer has 20 or more employees); disabled (patient is under 65, covered by an employer plan, employer has 100 or more employees); ESRD (during the first 30 months of Medicare eligibility regardless of employer size); workers' compensation (for the work-related condition); and liability or no-fault (for the accident-related condition). Federal law governs MSP; a private plan cannot contract its way out of primary responsibility when MSP rules apply. Per CMS, billing Medicare as primary when it is secondary creates a conditional payment obligation that CMS will recover.

What does CO-22 actually require to fix?

CO-22 means the payer believes another plan should have paid first. The fix depends on the situation. If the claim went to the wrong primary payer, resubmit to the correct primary, then submit the secondary claim with the primary EOB attached. If the payer's COB data is outdated (a terminated prior employer plan is still on file), contact the payer's COB department to update their records and resubmit. If MSP rules apply and Medicare was billed primary, submit to the employer plan first, then Medicare as secondary with the employer plan's EOB. FCSO Medicare CO-22 guidance describes the documentation required for Medicare secondary submissions.

How often should eligibility be re-verified?

Best practice is to verify at scheduling, again the day before the visit via batch, and again at check-in for any patient whose batch result returned an exception or whose last visit was more than 30 days prior. Coverage changes between scheduling and the date of service: employer plan terminations, Medicaid eligibility shifts, and Medicare Advantage plan changes all happen mid-year. Per CAQH 2024 Index data, an electronic re-verification costs about $0.34, so pre-visit re-runs pay for themselves.

What should be stored from an eligibility check for audit purposes?

Store the full 271 response, not just the displayed result. The raw transaction preserves the exact benefit data returned on the date of service. That matters when a payer denies a claim against benefits the 271 showed as covered, or when a patient disputes their responsibility against what the check showed at service. The inquiry date and time, the date of service covered, and the payer identifier all belong in the stored record. Regulators and payers in dispute resolution routinely ask for evidence of the eligibility check run before service.

How current is this guide?

Last reviewed 2026-06-07. X12 transaction set references are at x12.org. CMS MSP guidance is at cms.gov Medicare Secondary Payer. CAQH CORE eligibility operating rules are at caqh.org/core. Cost-per-transaction figures are from the CAQH 2024 Index Report. Denial statistics are from the Experian Health 2025 State of Claims survey.