Eligibility response reference
What Is an EDI 271 Eligibility Response?
Understand how a 271 answers an eligibility inquiry, how benefit and rejection occurrences are organized, and what its results do—and do not—establish.
An EDI 271 is an X12 Health Care Eligibility Benefit Response returned by a health plan or other information source in response to an EDI 270 inquiry. The 005010X279A1 transaction can identify the source, receiver, subscriber, and dependent; return eligibility and benefit information through EB occurrences; and report request-rejection information through AAA occurrences. It describes information supplied at the time of the response, but does not guarantee authorization, medical necessity, claim adjudication, or payment.
Where the EDI 271 fits in eligibility verification
An authorized provider, facility, pharmacy, clearinghouse, or service organization sends an EDI 270 inquiry to a health plan or eligibility service. The receiver uses the supplied patient and service-request context and returns a 271. Trace values and transaction controls allow the parties to reconcile the response with the original request.
The response may return plan and benefit information for a located subscriber or dependent, or it may report why some part of the request could not be processed. A 271 can contain multiple EB benefit occurrences because one patient can have information for several service categories, coverage levels, amounts, percentages, time periods, or networks. It can also contain AAA request-rejection occurrences at organization or patient levels.
Eligibility data is time-sensitive and is only what the information source supplied. A response is not an authorization and cannot promise how a future claim will adjudicate. Trading partners can also apply companion-guide requirements beyond the base implementation.
Participants and hierarchy in a 271
Like the 270, the 271 uses HL parent-child levels. The hierarchy determines who owns an EB, AAA, date, identifier, or message:
| Level | Role | Interpretation |
|---|---|---|
| Information source (20) | The plan or eligibility service returning the response | AAA here can describe a problem associated with the source-level request context. |
| Information receiver (21) | The provider or organization receiving information | Identifies the recipient and can carry receiver-level response context. |
| Subscriber (22) | The enrolled person identified by the inquiry | Can own patient-level EB and AAA occurrences. |
| Dependent (23) | A patient covered through the subscriber | Inherits subscriber context but retains its own trace, identity, dates, benefits, and rejections. |
HL01 identifies the current level, HL02 points to its parent, and HL03 identifies the role. NM1 names or identifies the party. TRN links the response occurrence to the inquiry, while REF, DMG, INS, and DTP add identifier, demographic, relationship, and date context. Flattened output should preserve patient type, subscriber and patient identifiers, trace values, hierarchy, and occurrence numbers.
How EB benefits and AAA request rejections differ
EB communicates benefit information. Read the benefit-information code, coverage level, service-type composite, insurance type, plan description, time-period qualifier, amount or percentage, quantity, authorization indicators, network indicator, and related dates together. A dollar amount detached from its benefit category and time period is not meaningful.
AAA communicates request-rejection information. Its follow-up action, agency qualifier, reason, and the hierarchy level where it appears determine what the receiver reported. A structurally complete AAA is valid response content; it should not automatically be classified as a malformed 271.
| Context | What to retain | Why |
|---|---|---|
| Benefit occurrence | EB occurrence, category, coverage, services, plan, amount/percent, period, network, dates | Prevents unrelated benefit dimensions from being combined. |
| Request rejection | AAA occurrence, hierarchy owner, reason, follow-up, trace, patient | Shows which part of the request could not be handled. |
| Provider detail | LS/LE loop ownership, NM1, REF, address, contact, taxonomy | Keeps provider information attached to the correct benefit occurrence. |
| Free-form message | MSG occurrence and enclosing EB/patient context | A message supplements structured fields and should not replace them. |
Synthetic EDI 271 example
This fictional excerpt is based on the repository’s parsed 005010X279A1 fixture and contains no real protected health information:
ST*271*0001*005010X279A1~
BHT*0022*11*RESP0001*20260726*1200~
HL*1**20*1~
NM1*PR*2*TEST HEALTH PLAN*****PI*842610001~
HL*2*1*21*1~
NM1*1P*2*TEST CLINIC*****XX*1234567893~
HL*3*2*22*0~
TRN*1*000012345*9876543210*TRACE-REF~
NM1*IL*1*SUBSCRIBER*SAM****MI*0000123456~
DTP*346*D8*20260101~
DTP*347*D8*20261231~
EB*1*IND*30^47^98*HM*GOLD PLAN*23~
SE*13*0001~ST declares a 271 under implementation 005010X279A1, and BHT identifies the response. The HL and NM1 pairs identify the plan, clinic, and subscriber. TRN retains the response trace, and the subscriber’s NM1 retains a leading-zero member identifier. The qualified DTP dates provide coverage-period context. EB reports a benefit occurrence for the listed service types and plan context. It does not, by itself, promise that a particular service will be authorized or paid.
EDI 271 compared with 270, 834, and 837
| Transaction | Role | Do not infer |
|---|---|---|
| 270 inquiry | Requests eligibility and benefit information. | That the patient is eligible or a service is covered. |
| 271 response | Returns eligibility, benefit, and request-rejection information. | A guarantee of authorization, medical necessity, adjudication, or payment. |
| 834 enrollment | Communicates member enrollment and maintenance activity. | The point-in-time answer to a particular eligibility request. |
| 837 claim | Submits professional, institutional, or dental claim information. | That an earlier 271 determines the claim outcome. |
How to review a 271 in EDIFileConverter.com
- Open the EDI workspace and add an authorized response with Browse files or drag and drop.
- Keep Smart mapping (per file) selected and confirm that the detected implementation is 005010X279A1.
- Select Convert & Preview to inspect labeled patient, EB, AAA, date, amount, network, and provider fields.
- Select Open full editor for filters, sorting, column controls, saved layouts, and occurrence-level review.
- Open Validation Results to review supported structural and data checks. Review valid AAA response content separately from defects in the source response.
- Select Analysis to summarize patients, benefits, service categories, request rejections, dates, identifiers, and detailed occurrences.
- Use Download to export Excel, CSV, JSON, or XML after retaining the hierarchy and qualifier fields needed to interpret each occurrence.
Important limitation: editing converted rows does not rewrite the uploaded source EDI or change information supplied by the sender. Analysis summarizes the response; it does not contact a payer or create new eligibility facts.
Common 271 interpretation mistakes
Reading one EB as the entire response
A patient can have repeated EB occurrences for different service types, benefit categories, periods, amounts, and networks. Retain occurrence and patient context before summarizing.
Separating amounts from qualifiers
A number can represent a different business concept depending on the EB category and time period. Keep amounts, percentages, quantities, coverage, network, services, and dates together.
Treating AAA as a malformed file
AAA can be valid response content reporting a request rejection. Determine its hierarchy owner and reason before deciding whether the source itself has a validation defect.
Assuming eligibility guarantees payment
The 271 reports information supplied at the time of inquiry. It does not establish authorization, medical necessity, final adjudication, or payment.
Dropping subscriber context from a dependent
A dependent response relies on its parent subscriber for reconciliation. Preserve subscriber and patient identifiers, trace values, and hierarchy links.
Frequently asked questions
What is an EDI 271 eligibility response?
It is the X12 transaction used to return eligibility, benefit, or request-rejection information in response to a 270 inquiry.
How are a 270 and 271 different?
The 270 asks the question. The 271 carries the information returned by the health plan or other information source.
What does EB mean?
EB describes one benefit-information occurrence. Read its category, coverage, services, plan, period, amount or percentage, network, and dates together.
What does AAA mean?
AAA reports request-rejection information at the hierarchy level where it occurs. It can be valid response content.
Does a 271 guarantee coverage or payment?
No. It does not guarantee authorization, medical necessity, claim adjudication, or payment.
Can a 271 contain both EB and AAA?
Yes. Benefit information and request-rejection occurrences can coexist at applicable levels in a response.