Healthcare270271EligibilityHIPAA

X12 270/271 Eligibility Inquiry and Response: A Practical Guide

How the HIPAA X12 270/271 pair works together to verify patient insurance eligibility in real time, with the segment structure and benefit codes that matter most.

Dr. Elena Torres · Healthcare EDI ConsultantPublished 2026-05-22Updated 2026-08-3013 min read
Technical Review by James Okafor, HIPAA Transactions Specialist
In this article

Few HIPAA transactions have as much day-to-day operational impact as the 270/271 pair. Every time a front-desk system checks 'is this patient covered,' it's almost certainly firing a 270 and parsing a 271 behind the scenes. Getting this pair right — and understanding its benefit codes — directly affects claim denial rates.

1. Why eligibility checks matter

Eligibility verification catches coverage problems before a service is rendered, rather than after a claim is denied weeks later. It also surfaces patient financial responsibility (copay, deductible) so front-desk staff can collect accurately at time of service.

2. The 270 request

A 270 is built as a hierarchy: Information Source (the payer) → Information Receiver (the provider) → Subscriber (the patient). The EQ segment specifies which service type category is being asked about, using standardized codes like 30 (Health Benefit Plan Coverage) or 88 (Pharmacy).

270 Eligibility Inquiry — interactive EDI message visualizer

ST

This is an envelope or control segment. Select a highlighted segment on the left (shown in green) for a full business explanation.

3. The 271 response

The 271 mirrors the same hierarchy and answers with one or more EB (Eligibility or Benefit Information) segments — one to confirm overall active/inactive status, and additional ones for specific benefit values like copay or coinsurance percentage.

271 Eligibility Response — interactive EDI message visualizer

ST

This is an envelope or control segment. Select a highlighted segment on the left (shown in green) for a full business explanation.

4. Understanding EB codes

EB01 CodeMeaning
1Active Coverage
6Inactive
BCo-Payment
ACo-Insurance
CDeductible

5. Example transactions

Below is a realistic pair: a provider asking about a patient's general health coverage, and the payer confirming active coverage with a $30 copay.

270 Eligibility Inquiry (excerpt)edi
HL*3*2*22*0~
NM1*IL*1*DOE*JANE****MI*W123456789~
DMG*D8*19850612*F~
EQ*30~
271 Eligibility Response (excerpt)edi
EB*1**30**Gold PPO Plan~
EB*B**30**Gold PPO Plan*27*30~

6. Real-time vs. batch processing

Most payers support real-time 270/271 exchange with a response expected within 20-30 seconds, which is what powers point-of-service eligibility checks. Some smaller or legacy payer systems still only support batch processing, returning 271 responses within a scheduled window (often overnight), which requires a different workflow — verification the day before rather than at check-in.

7. How the 270/271 flow works

The diagram below shows the complete round trip: how a front-desk check-in becomes a 270 inquiry, travels through a clearinghouse to the payer, and returns as a 271 with coverage detail — usually in well under a minute. Press Play Flow to watch it travel, or click a step for detail.

How it works

How 270 Eligibility Inquiry Works

Sender

Provider / Clearinghouse

Receiver

Payer / Health Plan

Direction

Provider → Payer

Standard

ANSI ASC X12

Version

005010X279A1

Transport

AS2 / SFTP / API / Clearinghouse

Business Purpose

Healthcare

Sender — Provider / Clearinghouse

EDI Transmission

270

Eligibility, Coverage or Benefit Inquiry

ANSI ASC X12 005010X279A1

AS2SFTPAPIClearinghouse

Receiver — Payer / Health Plan

Need help understanding this EDI flow?

Ask EDI AI →
Figure: 270 Eligibility Inquiry workflow from Provider / Clearinghouse through EDI transmission to Payer / Health Plan. Standard: ANSI ASC X12 005010X279A1 · Transaction: 270 · Direction: Provider → Payer

270 Eligibility Inquiry workflow. Steps: Patient Check-In, Generate 270 Inquiry, Send via Clearinghouse, Payer Receives Inquiry, Member Lookup, Return 271 Response. Transmitted from Provider / Clearinghouse to Payer / Health Plan via AS2, SFTP, API, Clearinghouse, following ANSI ASC X12 005010X279A1.

8. Common errors

ErrorLikely CauseFix
271 returns 'Subscriber Not Found'Member ID has extra formatting not present at the payerStrip formatting before submission
Real-time inquiry times out270 sent without a required EQ01 service type codeAlways populate EQ01 explicitly
Front desk sees coverage but no copayPayer only returns general active-coverage EB, not benefit-specific EBConfirm payer supports service-type-specific benefit detail

Frequently asked questions

In most high-volume practices, yes — typically run at scheduling or check-in.

Have a follow-up question about this topic?

Ask EDI AI →