# EDI 270 Eligibility Inquiry: HIPAA 5010 Guide
> EDI 270 eligibility inquiry explained: the 005010X279A1 guide, HL levels, TRN, DMG and EQ segments, a live example, and the errors behind 271 rejections.
The EDI 270 is the X12 Eligibility, Coverage or Benefit Inquiry. A provider, or a clearinghouse acting for one, sends it to a health plan to ask whether a patient has active coverage and what benefits apply. Under HIPAA it follows the 005010X279A1 implementation guide, and the health plan answers with a 271.
**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](/guides/edi/271-eligibility-benefit-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](https://x12.org/examples/005010x279), 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](https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-162/subpart-L/section-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](https://x12.org/examples/005010x279) shows real 270 and 271 transmissions with the TR3's own explanations. The full TR3 is licensed through [X12's technical reports](https://x12.org/products/technical-reports)
- [CMS's 5010 errata schedule](https://www.cms.gov/Regulations-and-Guidance/Administrative-Simplification/Versions5010andD0/Downloads/Errata_Req_and_Testing.pdf) 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](https://www.cms.gov/priorities/key-initiatives/burden-reduction/administrative-simplification/operating-rules) 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](https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-162/subpart-I/section-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](/guides/edi/837-health-care-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.
| Part | Value | Meaning |
|---|---|---|
| Version and release | `005010` | X12 version 5, release 1 |
| TR3 identifier | `X279` | The 270/271 Health Care Eligibility Benefit Inquiry and Response implementation guide |
| Errata suffix | `A1` | The first errata to that guide, which CMS lists as the version required for compliance |
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](/guides/edi/834-benefit-enrollment-and-maintenance) 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](/guides/edi/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.
| Loop | Segment | Name | Notes |
|---|---|---|---|
| Header | **ST** | Transaction Set Header | `ST01` = `270`, `ST03` = `005010X279A1` |
| Header | **BHT** | Beginning of Hierarchical Transaction | Structure `0022`, purpose `13` (request), reference, date, time |
| 2000A | **HL** | Information Source Level | `HL03` = `20` |
| 2100A | **NM1** | Information Source Name | The payer, `NM101` = `PR` |
| 2000B | **HL** | Information Receiver Level | `HL03` = `21` |
| 2100B | **NM1** | Information Receiver Name | The provider asking, usually `NM101` = `1P` with an NPI |
| 2000C | **HL** | Subscriber Level | `HL03` = `22` |
| 2000C | **TRN** | Subscriber Trace Number | Your trace number, echoed on the 271 |
| 2100C | **NM1** | Subscriber Name | `NM101` = `IL`, member ID in `NM109` |
| 2100C | **REF / N3 / N4** | Additional IDs and address | Situational; the TR3 and payer guide say when |
| 2100C | **DMG** | Subscriber Demographic Information | Birth date and gender |
| 2100C | **DTP** | Subscriber Date | `291` (plan) date of the inquiry |
| 2110C | **EQ** | Eligibility or Benefit Inquiry | Service type code, or a procedure code |
| 2000D-2110D | **HL / TRN / NM1 / DMG / DTP / EQ** | Dependent levels | Only when the patient is a dependent without their own member ID |
| Trailer | **SE** | Transaction Set Trailer | Segment count and control number |
## Key Segments Explained
### BHT: Beginning of Hierarchical Transaction
```
BHT*0022*13*EQ20261105001*20261105*0915~
```
| Element | Name | Example | What it means |
|---|---|---|---|
| **BHT01** | Hierarchical Structure Code | `0022` | Information source, information receiver, subscriber, dependent |
| **BHT02** | Transaction Set Purpose Code | `13` | Request |
| **BHT03** | Reference Identification | `EQ20261105001` | The submitter's reference for this inquiry |
| **BHT04** | Date | `20261105` | Creation date |
| **BHT05** | Time | `0915` | Creation time |
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~
```
| Element | Name | What it means |
|---|---|---|
| **HL01** | Hierarchical ID Number | Sequential ID for this level |
| **HL02** | Hierarchical Parent ID Number | The `HL01` of the parent level (blank on the first) |
| **HL03** | Hierarchical Level Code | `20` information source, `21` information receiver, `22` subscriber, `23` dependent |
| **HL04** | Hierarchical Child Code | `1` this level has children, `0` it does not |
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~
```
| Element | Name | Example | What it means |
|---|---|---|---|
| **NM101** | Entity Identifier Code | `PR`, `1P`, `IL` | Payer, provider, insured or subscriber |
| **NM102** | Entity Type Qualifier | `1` or `2` | `1` person, `2` non-person entity |
| **NM103** | Last or Organization Name | `SAMPLE` | |
| **NM104** | First Name | `JOHN` | |
| **NM108** | Identification Code Qualifier | `PI`, `XX`, `MI` | Payer ID, NPI, member ID |
| **NM109** | Identification Code | `TEST000000001` | The ID itself |
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~
```
| Element | Name | Example | What it means |
|---|---|---|---|
| **TRN01** | Trace Type Code | `1` | Current transaction trace number |
| **TRN02** | Reference Identification | `TRC-000001` | Your trace number for this patient's inquiry |
| **TRN03** | Originating Company Identifier | `9123456789` | Identifies who assigned the trace |
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~
```
| Element | Name | Example | What it means |
|---|---|---|---|
| **EQ01** | Service Type Code | `30` | Health benefit plan coverage |
| **EQ02** | Composite Medical Procedure Identifier | | A procedure code, for inquiries about a specific service |
| **EQ03** | Coverage Level Code | | Individual, family and so on |
| **EQ04** | Insurance Type Code | | Narrows the inquiry to a type of insurance |
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
| Document | Sent by | Sent to | Purpose |
|---|---|---|---|
| **270 Eligibility Inquiry** | Provider | Health plan | Is this patient covered, and for what? |
| **[271 Eligibility Response](/guides/edi/271-eligibility-benefit-response)** | Health plan | Provider | Coverage status, plan dates and benefit amounts, or a rejection |
| **[278 Services Review](/guides/edi/278-health-care-services-review)** | Provider / health plan | Each other | Prior authorization, referral and admission review |
| **[837 Health Care Claim](/guides/edi/837-health-care-claim)** | Provider | Health plan | Bills for the care delivered |
| **[276 Claim Status Request](/guides/edi/276-claim-status-request)** | Provider | Health plan | Where is my claim? |
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](/guides/edi/277-claim-status-response) follow up.
## Common 270 Errors and How to Prevent Them
| Error | What happens | Prevention |
|---|---|---|
| **Wrong `GS08`/`ST03` version** | 999 rejection before the payer reads it | Send `005010X279A1` unless the payer's guide says otherwise |
| **Member ID typed with spaces or a prefix missing** | 271 `AAA` reason `72` (invalid/missing subscriber ID) or `75` (not found) | Store the ID exactly as printed; check the payer's prefix rules |
| **Birth date wrong or in the wrong format** | `AAA` reason `58` or `71` | Validate `CCYYMMDD`; confirm against the patient's card or ID |
| **Patient with own ID sent as a dependent** | Subscriber not found | Use the subscriber level when the patient has a unique member ID |
| **Provider not enrolled with the payer or clearinghouse** | `AAA` at the receiver level, such as `50` or `51` | Complete payer enrollment before going live; check NPI on `2100B` |
| **Wrong payer ID** | Inquiry routed to the wrong plan or rejected by the clearinghouse | Map payer IDs from the clearinghouse payer list, not from the card |
| **`HL` parent or child codes inconsistent** | 999 rejection | Generate `HL` values programmatically, never by hand |
| **Too many service types in one `EQ` request** | Partial answers or rejections | Follow the payer's list of supported service type codes |
## 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](/blog/essential-guide-to-edi) explains envelopes, segments and delimiters, and the [EDI document types reference](/edi-document-types) 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](/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
### What is an EDI 270?
The EDI 270 is the X12 Eligibility, Coverage or Benefit Inquiry. A provider or clearinghouse sends it to a health plan to ask whether a patient has active coverage and what benefits apply. The health plan answers with a 271.
### What does 005010X279A1 mean?
It identifies the HIPAA implementation guide for the 270/271: X12 version 005010, technical report X279, errata A1. It appears in GS08 and ST03. CMS lists 005010X279A1 as the errata version required for compliance.
### Is the 270 required under HIPAA?
When a HIPAA covered entity conducts the eligibility transaction electronically, it must use the adopted standard, which 45 CFR 162.1202 names as the X12 270/271 (005010X279). Your compliance team or counsel should advise on how that applies to your organization.
### What is service type code 30?
Service type code 30 means health benefit plan coverage. It is the generic eligibility question, asking the payer to report the patient's coverage in general. Specific codes such as 98 (office visit) or 88 (pharmacy) ask about particular benefits.
### What is the difference between a 270 and a 271?
The 270 is the inquiry the provider sends. The 271 is the health plan's response, carrying coverage status, plan dates and benefit details in EB segments, or an AAA segment explaining why the request was rejected.
### Why did my 270 come back "subscriber not found"?
Usually the member ID, name or birth date does not match the payer's records, or a patient with their own member ID was sent as a dependent. The 271's AAA segment carries a reject reason code, such as 72 or 75, that points to the problem.
### Can I send a 270 in batch?
Yes. The TR3 supports real-time and batch exchange, and many practices batch the next day's appointments overnight. Whether a payer supports batch, real time or both is set by its companion guide and your clearinghouse.
### Who answers a 270, the payer or the clearinghouse?
The health plan, or its eligibility vendor, answers it. A clearinghouse routes the 270 and returns the 271, and it may reject a malformed file itself with a 999 before it reaches the payer.