Eligibility, Coverage or Benefit Inquiry
The HIPAA X12 270 is a request from a healthcare provider to a payer asking whether a patient has active insurance coverage and what benefits apply.
In this guide
270 Eligibility Inquiry moves from Provider / Clearinghouse to Payer / Health Plan (Provider → Payer) via AS2, SFTP, API, Clearinghouse. The interactive diagram below traces every business and technical step the message passes through — press Play Flow to watch it travel, or click any 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
Receiver — Payer / Health Plan
Related transaction flows
Need help understanding this EDI flow?
Ask EDI AI →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.
Overview
Lets front-office staff or clearinghouses verify a patient's eligibility in real time before or at the point of service, reducing claim denials.
Sender
Provider / Clearinghouse
Receiver
Payer / Health Plan
Direction
Provider → Payer
Standard / Version
ANSI ASC X12 005010X279A1
Segment structure
Key segments that make up this transaction set:
| Segment | Name | Purpose |
|---|---|---|
| BHT | Beginning of Hierarchical Transaction | Identifies the transaction purpose and reference number. |
| HL | Hierarchical Level | Structures information provider, subscriber, and dependent loops. |
| NM1 | Individual or Organizational Name | Identifies the subscriber/patient and provider. |
| EQ | Subscriber Eligibility or Benefit Inquiry | Specifies the service type being inquired about. |
Interactive example
Click any segment below to see its business meaning.
ST
This is an envelope or control segment. Select a highlighted segment on the left (shown in green) for a full business explanation.
View raw EDI
ST*270*0001*005010X279A1~
BHT*0022*13*INQ-4471*20230920*0900~
HL*1**20*1~
NM1*PR*2*Acme Health Plan*****PI*66783~
HL*2*1*21*1~
NM1*1P*2*Riverside Medical Group*****XX*1932837465~
HL*3*2*22*0~
NM1*IL*1*DOE*JANE****MI*W123456789~
DMG*D8*19850612*F~
EQ*30~
SE*10*0001~Mapping example
A representative field-level mapping from a common source system into this transaction:
| Source | Source Field | Target Field |
|---|---|---|
| Practice Management System | patient.member_id | NM109 (Identification Code) at IL loop |
| Practice Management System | patient.dob | DMG02 (Date of Birth) |
| Practice Management System | encounter.service_type | EQ01 (Service Type Code) |
Validation rules
- Subscriber loop (HL level 22) must include a valid member ID or a full name plus date of birth.
- Payer identification in the 2100A NM1 loop must match an enrolled trading partner ID.
- EQ01 service type codes must come from the HIPAA-designated code list.
Common errors & troubleshooting
271 returns 'Subscriber Not Found'
Cause: Member ID has extra formatting characters (spaces, dashes) not present in the payer's system of record.
Fix: Strip formatting characters from the member ID before submission and validate against the payer's ID format spec.
Real-time inquiry times out
Cause: 270 was sent without a required service type code the payer's system needs to route the request.
Fix: Always populate EQ01 rather than relying on a payer default.
Related articles
Frequently asked questions
In most high-volume practices, yes — it's typically run at scheduling or check-in to confirm active coverage before the visit occurs.
Still have questions about 270?
Ask EDI AI →