EDI 271 Eligibility Response: HIPAA 5010 Guide

The EDI 271 is where a front desk learns what the patient owes and whether the visit is covered. It answers a 270 eligibility inquiry, usually within seconds over a real-time clearinghouse connection. Reading it well means understanding one segment above all others: EB, the eligibility or benefit line, which repeats as many times as the plan has something to say.

This guide covers how a 271 is organized, how to read EB segments without misquoting a patient's cost share, the AAA reject codes, two live examples from fictional data, and the errors teams make when they turn a 271 into a copay estimate. It describes the X12 structure only. It is not legal, billing or medical advice, and the health plan's own documents govern what a member's coverage is.

What Is an EDI 271?

An EDI 271 is the Eligibility, Coverage or Benefit Information transaction set defined by ASC X12, used by a health plan to answer a provider's 270 with coverage status and benefit details. It shares its implementation guide with the 270: the X12 Technical Report Type 3 005010X279, adopted for the HIPAA eligibility transaction in 45 CFR 162.1202. CMS's 5010 errata schedule lists 005010X279A1 as the errata version required for compliance, and that is the value you will see in GS08 and ST03. The functional group code in GS01 is HB.

Authoritative references for 271 work:

• The X12 005010X279 examples include a full 271 with active coverage, copays and a primary care provider, and a 271 rejected with an AAA segment
• CMS's operating rules page explains that HHS adopted CAQH CORE operating rules for the eligibility transaction, effective January 1, 2013. They are incorporated in 45 CFR 162.920 and add requirements such as connectivity on top of the TR3
• Each health plan's companion guide says which benefits it returns, at what level of detail, and for which service type codes

Who sends it? The health plan or its eligibility vendor (the information source).

Who receives it? The provider that asked, usually through the clearinghouse that routed the 270.

When is it sent? In reply to each 270: within the same session for real-time inquiries, or as a returned batch file.

Why does it matter? The 271 drives what the front desk collects and whether a visit goes ahead. Misread a remaining deductible or apply an out-of-network copay to an in-network visit, and the patient statement after the 835 remittance will not match what you told them.

Interactive Example: 271 With Active Coverage

The fictional health plan answers the fictional practice's 270 for JOHN SAMPLE. The response echoes the trace number in TRN*2, confirms the plan begin date in DTP*346, and lists seven EB lines: active coverage, an in-network calendar-year deductible and the amount remaining, the out-of-pocket maximum, an office visit copay, coinsurance, and an out-of-network deductible. All names, IDs and amounts are fictional, and ISA15 is T (test).

Use the Plain English tab for a readable summary, or click any segment to break it down element by element.

Interactive Example: 271 Rejected With AAA

Here the member ID on the inquiry did not pass the payer's validation. Instead of benefits, the subscriber loop carries AAA*Y**72*C: the request was valid as a transaction (Y), the reject reason is 72 (invalid or missing subscriber/insured ID), and the follow-up action is C (please correct and resubmit).

271 Structure at a Glance

The 271 mirrors the 270's hierarchy (BHT01 = 0022). Where the 270 has EQ inquiry segments, the 271 has EB benefit segments.

Key Segments Explained

TRN: Trace Number Echo

TRN*2*TRC-000001*9123456789~

TRN01 = 2 means referenced transaction trace number: this is your trace from the 270 coming back. Match on it, not on name, when you process batch responses. A payer can also add its own TRN*1 trace.

DTP: Plan and Eligibility Dates

DTP*346*D8*20260101~

A plan end date in the past, or an EB01 of 6 (inactive), is the clearest sign the patient's coverage has ended. Check the dates before you look at benefit amounts.

EB: Eligibility or Benefit Information

EB*C*IND*30***23*1500*****Y~

Common EB01 codes:

Read each EB as one sentence built from all its elements. EB*C*IND*30***29*900*****Y in the sample says: deductible, individual, health benefit plan coverage, remaining, $900, in network. Take any one element out of that sentence (the 29, the IND or the Y) and the dollar amount means something different.

AAA: Request Validation

AAA*Y**72*C~

Reject reason codes you will see most:

Follow-up action codes include C (please correct and resubmit), N (resubmission not allowed), R (resubmission allowed), P (please resubmit original transaction), W (please wait 30 days and resubmit), X (please wait 10 days and resubmit) and Y (do not resubmit; the payer will respond again shortly). The level of the AAA matters: in loop 2000A it is the payer, in 2000B or 2100B it is the provider, and in 2100C or 2100D it is the patient.

MSG, LS and LE: Messages and Related Entities

MSG carries free text tied to a benefit, such as a note on how a benefit applies. Read it, but do not try to parse amounts out of it. LS*2120 and LE*2120 wrap a loop that names an entity related to a benefit, such as the primary care provider (NM101 = P3) in the X12 example, or another payer to bill.

270 vs 271 vs 999

A 999 rejection means the 270 never reached the payer's eligibility logic. A 271 with an AAA means it did, and the payer could not match or answer it.

Where the 271 Sits in the Revenue Cycle

1. Registration captures the patient's coverage from the card.
2. The 270 asks the payer; the 271 answers.
3. If the 271 shows a service needs authorization, the provider sends a 278 services review.
4. After the visit, the provider bills with an 837 claim.
5. The 276 and 277 track the claim; the 835 explains payment.

Common 271 Errors and How to Prevent Them

271 Implementation Checklist

• Confirm GS01 = HB and 005010X279A1 handling in your translator
• Parse every EB element, not only EB01 and EB07
• Build display logic around EB02, EB03, EB06 and EB12 together
• Route AAA rejections by level (payer, provider, subscriber, dependent) and follow-up action code
• Match responses to requests on TRN02, and store BHT03
• Surface EB11 authorization flags to the team that sends 278s
• Keep the raw 271 with the appointment for audit and patient questions
• Test active, inactive, not-found, dependent and multi-service-type responses with each major payer

For a general primer on X12 envelopes and segments, see our essential guide to EDI. The EDI document types reference lists other X12 transaction sets.

Where OrderSync Fits

OrderSync's product is built for supplier order flows: it reads inbound purchase orders in any format (EDI 850 and 875, PDF, email, spreadsheets), matches customers, items and units, and outputs ERP data or valid X12.

For healthcare EDI teams, the useful piece is the free EDI inspector, which parses any X12 file, 271s included. Paste a test 271 to see each EB line and AAA rejection labeled, with a plain-English summary. Follow your organization's policies on protected health information before pasting a production file; test files with fictional data work just as well for checking structure.

Frequently Asked Questions