EDI 270 Eligibility Inquiry: HIPAA 5010 Guide

The EDI 270 is the question a front desk asks before a patient is seen: "Is this person covered, and for what?" Practice management systems send it at scheduling or check-in, usually in real time through a clearinghouse, and the health plan replies within the same session with a 271 eligibility response. A clean 270 gets a useful 271 back. A 270 with a mistyped member ID or the wrong birth date gets an AAA rejection, and someone ends up on the phone.

This guide covers what the 270 carries, where it sits in the HIPAA transaction set, every segment you will map, a live example built from fictional data, and the errors behind most eligibility rejections. It is written for billing teams, clearinghouse users and developers. It describes the X12 structure only; it is not legal or compliance advice.

What Is an EDI 270?

An EDI 270 is the Eligibility, Coverage or Benefit Inquiry transaction set defined by ASC X12, used by a health care provider to ask a health plan about a patient's coverage and benefits. In US healthcare it is one of the HIPAA standard transactions. The federal rule at 45 CFR 162.1202 adopts the X12 270/271 Technical Report Type 3 (TR3), report 005010X279, as the standard for the eligibility for a health plan transaction (pharmacy eligibility uses an NCPDP standard instead).

Authoritative references for 270 work:

• The X12 005010X279 example set shows real 270 and 271 transmissions with the TR3's own explanations. The full TR3 is licensed through X12's technical reports
• CMS's 5010 errata schedule lists the base version as 005010X279 and the errata version as 005010X279A1, and says HIPAA compliance requires the errata version where one exists
• CMS's operating rules page explains that HHS adopted operating rules for eligibility, authored by CAQH CORE, with a compliance date of January 1, 2013. The adopted rules are listed in 45 CFR 162.920
• Each health plan publishes a companion guide that narrows the TR3: which search options it supports, which service type codes it answers, and how it handles real-time versus batch

Who sends it? The provider (a practice, hospital, lab or other facility), or a clearinghouse or vendor on the provider's behalf.

Who receives it? The health plan, or the plan's eligibility vendor. The TR3 calls it the information source.

When is it sent? Before a visit, at check-in, before a procedure, and in batches the night before a clinic day. Most traffic is real time: one 270 out, one 271 back.

Why does it matter? Coverage and cost-sharing change. Plans terminate, deductibles reset each plan year, and a patient may have switched employers. A 270 before the visit is the cheapest point to catch that, well ahead of a denied 837 claim.

005010X279A1: What the Guide Identifier Means

You will see 005010X279A1 in two places in every 270: GS08 in the functional group header and ST03 in the transaction set header.

The functional group code in GS01 is HS for a 270 group. The 271 that comes back uses HB. Your translator uses GS08 to pick the right map, so a 270 sent with 005010X279 (no A1) can be rejected by a payer that only accepts the errata version.

How an Eligibility Check Works

1. Patient is scheduled or checks in. The practice management system has the patient's name, birth date and the member ID from their card.
2. System builds a 270. It names the payer, the provider (usually by NPI), the subscriber and, if needed, the dependent, and asks about one or more service types.
3. Clearinghouse routes it. The clearinghouse validates the 270, wraps it in the payer's envelope and sends it on, usually over a real-time connection.
4. Payer looks up the member. It searches its enrollment data, which comes from 834 enrollment files and its own systems.
5. Payer returns a 271. It either reports coverage and benefits in EB segments or rejects the request with an AAA segment and a reason code.
6. Practice acts on it. Staff confirm coverage, collect the copay, flag a terminated plan, or fix the inquiry and resend.

If the 270 is syntactically broken, the clearinghouse or payer may return a 999 implementation acknowledgment rejecting it instead of a 271. A 999 says the file failed validation; a 271 with an AAA says the file was readable but the payer could not answer it.

Interactive Example: 270 Eligibility Inquiry

A fictional family practice asks a fictional health plan whether its patient, the subscriber JOHN SAMPLE, has active coverage today. The request uses the generic inquiry pattern from the X12 TR3 examples: service type 30 (health benefit plan coverage) with the member ID, name and birth date. Every name, member ID, payer ID and NPI in this sample is fictional, and ISA15 is set to T to mark it as test data.

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

270 Structure at a Glance

The 270 is hierarchical. Each HL segment opens a level, and everything until the next HL belongs to that level. BHT01 value 0022 declares the structure: information source, information receiver, subscriber, dependent.

Key Segments Explained

BHT: Beginning of Hierarchical Transaction

BHT*0022*13*EQ20261105001*20261105*0915~

The 271 returns the same BHT03 in its own BHT, as the X12 examples show. Store it with the request.

HL: Hierarchical Level

HL*1**20*1~
HL*2*1*21*1~
HL*3*2*22*0~

Getting HL04 wrong is a classic validation failure: a subscriber level marked 1 with no dependent under it, or 0 with one.

NM1: Payer, Provider and Subscriber Names

NM1*PR*2*EXAMPLE HEALTH PLAN*****PI*EXHP1~
NM1*1P*2*SAMPLE FAMILY MEDICINE*****XX*1234567893~
NM1*IL*1*SAMPLE*JOHN****MI*TEST000000001~

The payer ID in the 2100A NM1 is usually the clearinghouse's payer ID for routing, not anything printed on the card. Your clearinghouse's payer list is the source of truth. The NPI in this sample, 1234567893, is a test value that passes the NPI check-digit rule; it is not a real provider.

TRN: Subscriber Trace Number

TRN*1*TRC-000001*9123456789~

The 271 echoes this as TRN*2 (referenced transaction trace number). When you send a batch of inquiries, the trace number is what ties each 271 subscriber loop back to the right appointment.

DMG and DTP: Birth Date and Inquiry Date

DMG*D8*19800101*M~
DTP*291*D8*20261105~

DMG02 is the birth date in CCYYMMDD format and DMG03 the gender code. Payers use the birth date to confirm they found the right person, so a transposed day and month is a common cause of "subscriber not found." DTP01 qualifier 291 (plan) with a single date asks about coverage on that date. The payer's companion guide says what date it assumes when the DTP is left off, whether it accepts a date range, and how far forward or back it will answer.

EQ: Eligibility or Benefit Inquiry

EQ*30~

Service type 30 is the generic request: "tell me about this person's coverage." Other common codes include 1 (medical care), 33 (chiropractic), 35 (dental care), 47 (hospital), 86 (emergency services), 88 (pharmacy), 98 (professional physician visit, office), MH (mental health) and UC (urgent care). Payers differ in how many specific service types they answer and whether they return extra detail for them, so check the companion guide before you build a 270 that asks for ten codes at once.

Subscriber or Dependent?

The 270 has two places to put the patient: the subscriber level (HL03 = 22) and the dependent level (HL03 = 23). The X12 examples show both patterns. The deciding question is the patient's ID. When the patient has their own unique member ID on the card, the TR3 directs that they be sent at the subscriber level even if they are covered through a parent or spouse. The dependent level is for patients who can only be identified through the subscriber's ID. Sending a child with their own ID in the dependent loop is a frequent cause of "not found" responses.

270 vs 271, 276, 278 and 837

Eligibility comes first in the revenue cycle. A 271 can tell you that a service needs authorization, which is when the 278 comes in. After the visit, the 837 bills it, and the 276 and 277 follow up.

Common 270 Errors and How to Prevent Them

270 Implementation Checklist

• Confirm the payer or clearinghouse accepts 005010X279A1 and whether it supports real time, batch or both
• Get each payer's companion guide and note its required search fields and supported service types
• Map member ID, name and birth date from the registration screen exactly as entered from the card
• Send the rendering or billing provider NPI the payer expects in 2100B
• Generate unique BHT03 and TRN02 values and store them for matching 271s
• Decide when to use the dependent level, using the patient's own member ID as the test
• Handle the 999 and the 271 separately: one means syntax failure, the other means a business answer
• Test a found subscriber, a not-found member, a terminated plan and a dependent

If you are new to X12 in general, our essential guide to EDI explains envelopes, segments and delimiters, and the EDI document types reference lists the other 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, 270s included. Paste a test 270 to see its loops and segments labeled, with a plain-English summary and explanations of structural errors. 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