271 Eligibility Response: How to Read It

A 271 eligibility response is the payer's answer to an eligibility inquiry: the electronic message that reports whether a patient's coverage is active and what benefits apply. It is the second half of the 270/271 transaction, where the provider sends a 270 question and the payer returns the 271. To read a 271, you work through it in layers: first the subscriber and plan, then the coverage status (active or inactive), then the service-type benefits that carry copay, coinsurance, deductible, and any authorization flags. A clean 271 lets a system post those fields straight to the schedule. The common problem is that many 271 responses come back thin, confirming active coverage while omitting the visit-specific detail a front desk needs. This guide walks through what a 271 returns and where it falls short.

What is a 271 eligibility response?

The 271 eligibility response is the X12 EDI message a payer returns to confirm a patient's coverage and benefits. When a provider sends a 270 (Health Care Eligibility Benefit Inquiry) with the patient, plan, and service in question, the payer replies with a 271 (Health Care Eligibility Benefit Response). The 271 carries the subscriber's plan, whether coverage is active on the date of service, and a set of benefit lines organized by service type. CMS defines the exact fields it accepts and returns for Medicare eligibility in its HETS 270/271 companion guide, which is a useful reference for the segment structure any payer's 271 follows. Because the format is standardized, software can parse a 271 into structured fields rather than reading it by hand.

How do you read a 271 response?

You read a 271 in layers, from the patient up to the specific benefit. Start with the loops that identify the subscriber and, if different, the dependent, and confirm the name and member ID match your patient. Move to the benefit information, where each EB (Eligibility or Benefit Information) segment states one benefit: its status, the service type it applies to, the coverage level, and any dollar or percentage amount. The first thing to find is the active-or-inactive status for the plan as a whole, then the service-type code for the visit you are checking, for example 30 for a general health benefit or 98 for a professional office visit. Read the copay, coinsurance, and deductible attached to that service type, not the plan-level numbers, because they can differ. Note any message segments that flag prior authorization or referral requirements, since those change what has to happen before the visit.

What is the difference between a 270 and a 271 transaction?

The difference between a 270 and a 271 is direction: the 270 is the question and the 271 is the answer. Together they form the 270/271 transaction, the standardized pair HIPAA names for real-time and batch eligibility. The provider or clearinghouse sends the 270 with who the patient is, which payer and plan, and what is being checked, and the payer's system matches the member and returns the 271 with coverage status and benefits. The federally adopted CAQH CORE operating rules set response-time and content expectations for these transactions, as summarized on the CMS page for eligibility and claim status operating rules. In practice a single 270 batch against tomorrow's schedule produces one 271 per patient, which is what makes the pair automatable at volume.

What benefits does a 271 return for copay and deductible?

A 271 returns cost-share and accumulator detail per service type through its EB segments. For a covered service you can typically read the copay amount, the coinsurance percentage, the individual and family deductible, how much of the deductible has been met, and the out-of-pocket maximum with its remaining balance. Each of these is tied to a service-type code, a coverage level (individual or family), and a time period (calendar year, remaining, or per visit), so the same 271 can list a plan-level deductible and a service-specific copay side by side. Reading the wrong line is a common error: the plan-level copay may not be the one that applies to the scheduled visit. Getting this right before the appointment is what lets a front desk quote an accurate patient responsibility instead of guessing.

Why is a 271 response incomplete or wrong?

A 271 is often incomplete because the payer returns a valid response that is thin, confirming the plan is active while omitting the visit-specific benefit a practice needs. Some payers return only plan-level coverage and no service-type breakdown, others omit visit limits, and some return stale accumulator balances that lag real claims activity. A 271 can also be wrong in a narrow sense: it answers exactly the service type you asked about, so a 270 that asks the general health-benefit code may come back active while the specific procedure is not covered. These gaps carry downstream cost. Registration and eligibility has been reported as the largest single source of claim denials, at nearly 27% in the Change Healthcare denials data summarized by MGMA, and ACA marketplace insurers denied 19% of in-network claims in 2024. When a 271 is thin, the missing detail becomes a portal check, a phone call, or a denial after the visit.

How Flexbone reads the 271 and fills the gaps

Flexbone treats the 271 as the first pass, not the final answer. Our agents send the 270, parse the returned 271 into structured fields (status, plan, service-type copay, coinsurance, deductible, and authorization flags), and check each result for the gaps above. When a 271 is thin or a payer is portal-only, the agent logs into the payer portal or places a phone call to capture the missing benefit, then reconciles both sources into one record. The verified result is written back to the practice management or insurance eligibility verification system as structured data, not a screenshot, so billing sees the copay and deductible before the visit. The work is audit-first: every check keeps the raw 271, the portal capture, and the call log, so a biller can trace any field to its source. The platform is built to be HIPAA compliant and aligned with SOC 2 controls, and we scope claims to what we have actually measured in the engagements we run. For how EDI and portals divide the work, see automating eligibility: 270/271 vs portals.

If your team is reconciling thin 271 responses by hand, we can walk through how the agents parse, fill, and write back benefits for your payer mix. To see it on your own workflow, book a demo.