Medi for Insurance Eligibility Verification

Short answer

Medi surfaces the full benefit detail from a payer's 271 response — copay by service type, base deductible, remaining deductible, coinsurance percentage, out-of-pocket maximum, coverage dates, and plan type — so billing teams have the actual financial picture before a claim goes out. Many tools return only an active or inactive status and stop there. That gap matters: a biller who does not know the patient's remaining deductible before claim setup has no basis for correct patient collection at the point of service and no way to catch coordination-of-benefits errors before adjudication.

The 271 transaction standard allows payers to satisfy an eligibility inquiry by confirming active status and returning very little financial detail. The status flag itself does not prevent CO-22 (wrong payer, or another payer is primary), CO-31 (patient not identified as insured), or CO-32 (patient not an eligible dependent). Preventing those denials requires the actual benefit data the payer returned: the remaining deductible, the copay for the specific service type, and the COB context that determines payer order.

Medi connects real 271 benefit data to claim setup so billing companies work from the payer's actual financial picture — not a binary coverage signal. Eligibility checks run through Stedi, the clearinghouse Medi uses for all EDI, at $0.20 per transaction with no per-seat eligibility fee.

Sources: How Eligibility Verification Improves Billing · Eligibility, COB, and Insurance Discovery Guide · CAQH 2024 Index Report

---

Why an active/inactive status is not enough

A billing platform that reports "Active — Aetna" has done almost nothing useful. The status flag confirms the patient has coverage. It does not tell the biller what to collect, whether the claim will route to the right payer, or whether the service type being billed has coverage limits that will cause a denial at adjudication.

The payer's 271 response contains financial detail that the billing workflow depends on. When a tool discards that detail or buries it in a raw data view, the billing team is left making decisions against incomplete information — and the consequences show up on the remittance three to four weeks later.

Three specific problems result from status-only checks.

**Incorrect patient collection at check-in.** Without the remaining deductible and applicable copay from the 271, the front desk either estimates or collects nothing. Collecting too little creates patient-balance A/R that is expensive to chase. Collecting too much creates a refund liability. The actual figure exists in the 271 response. A tool that does not show it is not doing the job.

**Preventable eligibility-driven denials.** CO-31 (patient cannot be identified as insured) is the direct denial equivalent of a 271 subscriber-not-found result. If the eligibility check surfaced that error before submission, the biller could correct demographics or switch payers on the spot. When the eligibility tool does not connect that signal to the claim workflow, the biller finds out via denial instead.

**Wrong payer billed.** When a patient carries more than one policy, the 271 responses from both payers, read together, establish which plan is primary and which is secondary. A status-only check against one payer with no COB context leaves payer order to guesswork. CO-22 (this care may be covered by another payer) is the predictable result.

Per the Experian Health 2025 State of Claims survey, 68 percent of surveyed providers cite inaccurate or incomplete patient data at intake as a primary driver of claim denials. A significant portion of that problem is not front-desk error — it is software that does not surface the benefit detail the 271 already returned.

---

The benefits Medi surfaces

Medi displays the following from the 271 response in the claim context where billers need it, not in a separate eligibility module.

**Copay by service type.** A patient's copay for a specialist visit is usually different from their copay for primary care, urgent care, or behavioral health. The 271 carries copay amounts by service type code. Medi surfaces the applicable copay so the collection conversation at check-in starts from the right number.

**Base deductible and remaining deductible.** The base deductible is the patient's annual obligation before the plan pays. The remaining deductible is what is left for the current benefit year. That figure determines how much of the claim will route to patient responsibility. Knowing it before claim setup is what makes pre-visit patient collection accurate rather than approximate.

**Coinsurance percentage.** After the deductible is met, the patient's share of covered charges is the coinsurance — commonly 20 percent in an 80/20 plan, but plan-specific ratios vary. Medi surfaces the coinsurance percentage from the 271 so the patient's share of each service type can be estimated before the claim goes out.

**Out-of-pocket maximum and amount applied.** The OOP max caps the patient's total financial responsibility for the benefit year. Once it is met, covered services process at 100 percent. Knowing how much of the OOP max has been applied tells the biller whether the patient still has significant responsibility or is close to the cap.

**Plan type.** HMO, PPO, indemnity, and other plan types affect network rules, referral requirements, and how the claim routes. An HMO claim that routes to an out-of-network payer will fail. Plan type is in the 271 and Medi surfaces it at claim setup.

**Coverage effective and termination dates.** A plan that terminated two months ago will show as inactive on a real-time 271. Medi surfaces that date so a stale plan does not silently remain the claim's primary payer.

What Medi cannot control is how much of this detail any specific payer includes in its 271 response. CAQH CORE's Eligibility and Benefits Data Content Rule (EB.2.1) sets a floor for copay, deductible, and coinsurance return for CORE-certified payers — but not every payer is CORE-certified, and even certified payers have discretionary service type codes where they may decline to return patient-responsibility figures. Medi surfaces everything the payer returns. When a payer returns less, the 271 will show less.

---

How that changes the billing workflow

Claim accuracy before submission

The most direct impact is on claim setup. Knowing the plan type determines how the claim routes. Knowing which service types have authorization requirements (flagged in the 271's benefit limitation segments) determines whether an authorization reference needs to be on the claim. Coverage effective and termination dates catch stale coverage before submission rather than on the remittance.

A subscriber-not-found result from a real-time 271 check flags the claim at build time. That signal stops the claim before it goes out, giving the biller time to correct demographics, confirm the member ID against the insurance card, or redirect to the correct payer. Without that signal in the claim workflow, the same error produces a CO-31 denial three to four weeks later.

Fewer eligibility denials

CO-31 and CO-32 are largely preventable when a 271 check runs before claim submission and the result is visible in the claim context. A subscriber-not-found error before submission is an earlier, cheaper catch than a denial after submission. CO-22 volume falls when COB context from both policies is visible at claim setup and payer order is set correctly before the claim goes out.

CO-177 (patient has not met required eligibility requirements) is less predictable because it depends on plan-specific coverage conditions that some payers do not fully document in the 271. For Medicare Advantage in particular, plan-specific coverage periods and service area restrictions may not fully surface in the standard 271. Medi surfaces what the payer returns. For MA plans where the 271 is incomplete, verifying against the plan's member eligibility portal is the additional step that prevents CO-177.

Correct patient collection up front

A biller who can see the copay, the remaining deductible, and the coinsurance from the 271 has what they need to quote the patient a realistic obligation at check-in and collect against it. Chasing patient balances by statement after the fact costs more and collects less than collecting at the time of service against a known obligation.

For billing companies managing multiple practices, this matters at scale. A workflow that consistently puts the actual benefit detail in front of the collection conversation, across every practice and every patient, reduces the patient-balance A/R that accumulates when front-end collection is working from a status flag rather than real numbers.

---

How Medi runs eligibility

Medi routes 270 eligibility inquiries through Stedi, the clearinghouse Medi uses for all EDI transactions. The 271 response comes back in roughly one to three seconds for real-time checks. The full response is stored and the benefit detail is surfaced in the claim setup screen — not in a separate eligibility module, and not as a raw transaction log.

**Real-time checks** are appropriate for walk-in patients, same-day appointments, and any patient whose prior batch result flagged an exception. The response is immediate.

**Batch checks** process a list of patients overnight. The practical pattern for a high-volume billing company is to batch the prior day for all scheduled visits, then run real-time at check-in for walk-ins and for any patient whose batch result returned a question. Per the CAQH 2024 Index Report, the cost of an electronic eligibility transaction is approximately $0.34 versus $6.78 for a manual phone verification. Medi charges $0.20 per check with no per-seat fee.

Eligibility exceptions surface as actionable signals. A subscriber-not-found result flags the claim before it goes out. A conflicting 271 response — where one EB segment returns active and another returns inactive for the same service type, which happens when the payer's system draws from multiple data sources that have not been reconciled — is surfaced rather than silently resolved to one result.

For billing companies with multiple client practices, eligibility runs within each practice's context. Billing company staff can run checks across all practices they manage. The per-transaction fee appears on the invoice alongside claim and ERA transaction volume so cost-per-practice is visible.

**What Medi does not do in this area:**

• Guarantee that a 271 response captured all applicable benefit limits or exclusions. Payer 271 completeness varies.
• Replace payer-specific portal verification for Medicare Advantage or other plans with coverage conditions the 271 does not fully document.
• Provide insurance discovery across unknown payers as a built-in feature. For self-pay or no-card patients, a manual payer lookup or a third-party discovery service handles that case.
• Replace clinical judgment on medical necessity.

Full eligibility, COB, and insurance discovery workflow detail is in the Eligibility, COB, and Insurance Discovery Guide. Pricing is at /pricing.

---

Frequently asked questions

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

No. Active coverage on a 271 response means the patient has coverage with that payer as of the date of service. Payment still depends on whether the specific service is covered under the plan, whether the deductible has been met, whether medical necessity is satisfied, whether authorization was obtained when required, whether the claim was filed within the payer's timely filing window, and whether the claim routes to the correct primary payer under COB rules. An active status prevents the CO-177 eligibility denial. It does not prevent CO-22, CO-4, CO-50, or CO-197.

Why does showing real benefits matter more than just confirming active status?

Because the denial codes that cost billing companies the most time to work are caused by information problems a status flag does not address. CO-31 (patient cannot be identified as insured) is caught when a 271 returns subscriber-not-found before the claim goes out. CO-22 (another payer should have paid first) is prevented when benefit data from both policies is visible at claim setup and payer order is established correctly. A check that returns only "Active" provides no usable signal on either of those. The benefit detail is what makes the check actionable — and what makes pre-visit collection a realistic operation instead of a guess.

How does Medi price eligibility checks?

Eligibility checks are $0.20 per transaction with no monthly per-seat fee tied to eligibility access. Billing companies running eligibility for multiple client practices see the per-transaction cost on their invoice alongside claim and ERA volume. There is no minimum eligibility volume and no contract requirement. See /pricing for the full rate schedule.

What should a billing team look for in an eligibility demo?

A demo that shows only "Active" confirms the system can send a 270. It does not confirm the system is useful. Ask to see: the full benefit detail from the 271 displayed in the claim setup screen (copay by service type, remaining deductible, coinsurance); how a subscriber-not-found result is surfaced and whether it stops the claim before submission; how conflicting EB segments are handled; whether COB detail from multiple policies is visible at claim setup; and how a CO-31 or CO-22 denial in the denial queue links back to the eligibility check that ran before service. A full buyer checklist is in the Eligibility, COB, and Insurance Discovery Guide.

How often should eligibility be re-verified for established patients?

Coverage changes mid-year without any notice to the practice. Employer plan terminations, Medicaid eligibility shifts, and Medicare Advantage plan changes all happen between a patient's last visit and the next appointment. The practical standard is to verify at scheduling, run a batch check the day before the visit, and run a real-time check at check-in for any patient whose batch result flagged an exception or whose last visit was more than 30 days prior. The marginal cost of an electronic re-verification is approximately $0.34 per the CAQH 2024 Index Report, which makes pre-visit reruns economically straightforward at any practice volume.

---

A note on the pricing figures here

The pricing shown for other vendors is gathered from their public pricing pages where they publish one, and from third-party aggregators, reseller materials, and customer reports where they do not. Many of these vendors do not publish their pricing, so these figures are approximate, may not reflect negotiated or current rates, and can change without notice. Treat them as a starting point and confirm current pricing with each vendor directly. Where a vendor does not publish its pricing, this page says so rather than presenting an estimate as fact. Medi's own pricing is published in full at /pricing.

---

Sources: How Eligibility Verification Improves Billing · Eligibility, COB, and Insurance Discovery Guide · CMS Health Plan Eligibility Benefit Inquiry and Response · CAQH 2024 Index Report · Experian Health 2025 State of Claims · Stedi 270/271 EDI Reference