# EDI 276 Claim Status Request: HIPAA 5010 Guide

> EDI 276 claim status request explained: the 005010X212 guide, HL levels, TRN, REF, AMT and DTP segments, a live example, and common errors.

<QuickAnswer>
The EDI 276 is the X12 Health Care Claim Status Request. A provider, billing service or clearinghouse sends it to a health plan to ask where one or more submitted claims stand. Under HIPAA it follows the 005010X212 implementation guide, and the health plan replies with a 277 Health Care Claim Status Response.
</QuickAnswer>

**The EDI 276 replaces the phone call to the payer asking "did you get my claim, and what happened to it?"** Billing teams send it for claims that have not paid or denied within the expected window, and some practice management systems send it automatically on a schedule. The payer answers with a [277 claim status response](/guides/edi/277-claim-status-response) carrying status codes for each claim.

This guide covers what a 276 carries, how its hierarchy works, every segment you will map, a live two-claim example built from fictional data, and the mistakes that produce "claim not found." It describes the X12 structure only; it is not legal, billing or compliance advice.

<EDIGuideCTA
  transactionType="276"
  headline="Check a 276's structure before the payer does"
  body="Paste a 276 into OrderSync's free EDI inspector to see the payer, provider, patient and claim levels labeled, with a plain-English summary. Use test files with fictional data rather than live patient records."
/>

## What Is an EDI 276?

**An EDI 276 is the Health Care Claim Status Request transaction set defined by [ASC X12](https://x12.org/examples/005010x212), used to ask a health plan for the status of specific health care claims.** For HIPAA covered entities, [45 CFR 162.1402](https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-162/subpart-N/section-162.1402) adopts the X12 276/277 Technical Report Type 3 `005010X212`, with its April 2008 errata `005010X212E1`, as the standard for the health care claim status transaction. The errata did not change the identifier: the value in `GS08` and `ST03` is `005010X212`, which [CMS's 5010 errata schedule](https://www.cms.gov/Regulations-and-Guidance/Administrative-Simplification/Versions5010andD0/Downloads/Errata_Req_and_Testing.pdf) also shows with no separate errata version.

Authoritative references for 276 work:

- The [X12 005010X212 examples](https://x12.org/examples/005010x212) include a full 276 for three claims and the matching 277, with the TR3's explanations. The TR3 itself is licensed through [X12's technical reports](https://x12.org/products/technical-reports)
- HHS adopted CAQH CORE operating rules for claim status, including the Phase II Claim Status Rule and Connectivity Rule listed in [45 CFR 162.920](https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-162/subpart-I/section-162.920), with compliance from January 1, 2013 according to [CMS](https://www.cms.gov/priorities/key-initiatives/burden-reduction/administrative-simplification/operating-rules)
- Each payer's companion guide sets which search fields it requires, how many claims you can ask about in one 276, and whether it answers in real time or batch

**Who sends it?** The provider, its billing service, or a clearinghouse acting for it.

**Who receives it?** The health plan (the information source) or a payer's claims vendor.

**When is it sent?** After a claim has been submitted and accepted, typically once it is past the payer's normal turnaround without an [835 remittance](/guides/edi/835-health-care-claim-payment-advice). Many teams also send 276s before resubmitting a claim, to avoid creating a duplicate.

**Why does it matter?** Unpaid claims age. The 276 gets you a coded answer you can route: paid, pending, denied, or not on file. That is faster to act on than a call queue, and it leaves a record.

## How a Claim Status Inquiry Works

1. **The claim is billed.** The provider sends an [837 claim](/guides/edi/837-health-care-claim) and gets a 999 and, often, a 277CA acknowledgment back.
2. **Time passes without payment.** The claim shows as open in the practice management system.
3. **The system builds a 276.** It identifies the payer, the information receiver, the billing provider, the patient and each claim (by patient account number, charge amount and service dates).
4. **The clearinghouse routes it.** It validates the 276 and sends it to the payer, and may return a 999 if the file fails validation.
5. **The payer answers with a 277.** Each claim comes back with `STC` status codes, and often the payer's claim control number and payment details.
6. **The team acts.** Paid claims wait for the 835, pending claims get a follow-up date, rejected or not-found claims get corrected or resubmitted.

## Interactive Example: 276 for Two Claims

A fictional family practice asks a fictional health plan about two professional claims: one for JOHN SAMPLE with service on 2026-10-15 for $285.00, and one for JANE SAMPLE with service on 2026-10-20 for $410.00. Each patient is the subscriber, so each claim sits under its own subscriber level. Every name, member ID, payer ID and NPI is fictional, and `ISA15` is `T` (test).

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

<EDISample id="276-claim-status-request" />

## 276 Structure at a Glance

`BHT01` value `0010` declares the hierarchy: information source, information receiver, provider of service, subscriber, dependent. One 276 can carry many claims across many providers and patients.

| Loop | Segment | Name | Notes |
|---|---|---|---|
| Header | **ST** | Transaction Set Header | `ST01` = `276`, `ST03` = `005010X212` |
| Header | **BHT** | Beginning of Hierarchical Transaction | Structure `0010`, purpose `13` (request) |
| 2000A / 2100A | **HL / NM1** | Information source (payer) | `HL03` = `20`, `NM101` = `PR` |
| 2000B / 2100B | **HL / NM1** | Information receiver | `HL03` = `21`, `NM101` = `41`: who gets the 277 |
| 2000C / 2100C | **HL / NM1** | Service provider | `HL03` = `19`, `NM101` = `1P`, usually with the NPI |
| 2000D | **HL / DMG** | Subscriber level | `HL03` = `22`; `DMG` birth date and gender |
| 2100D | **NM1** | Subscriber Name | `NM101` = `IL`, member ID in `NM109` |
| 2200D | **TRN** | Claim Status Tracking Number | Your trace number for this claim |
| 2200D | **REF** | Claim identifiers | Payer claim control number (`1K`), bill type (`BLT`), patient control number (`EJ`) and others |
| 2200D | **AMT** | Claim Submitted Charges | `AMT01` = `T3` total claim charge |
| 2200D | **DTP** | Claim Service Date | `472`, a date or a range |
| 2210D | **SVC / REF / DTP** | Service line | Optional, to ask about specific lines |
| 2000E-2210E | | Dependent levels | When the patient is a dependent of the subscriber |
| Trailer | **SE** | Transaction Set Trailer | Segment count and control number |

## Key Segments Explained

### BHT: Beginning of Hierarchical Transaction

```
BHT*0010*13*CS20261105001*20261105*1000~
```

| Element | Name | Example | What it means |
|---|---|---|---|
| **BHT01** | Hierarchical Structure Code | `0010` | Information source, information receiver, provider of service, subscriber, dependent |
| **BHT02** | Transaction Set Purpose Code | `13` | Request |
| **BHT03** | Reference Identification | `CS20261105001` | Your reference for this request |
| **BHT04 / BHT05** | Date / Time | `20261105` / `1000` | When the 276 was created |

### HL: The Five Levels

```
HL*1**20*1~
HL*2*1*21*1~
HL*3*2*19*1~
HL*4*3*22*0~
HL*5*3*22*0~
```

| HL03 | Level | Who it is |
|---|---|---|
| `20` | Information source | The payer |
| `21` | Information receiver | The submitter that receives the 277, often the clearinghouse or billing service |
| `19` | Provider of service | The billing or rendering provider |
| `22` | Subscriber | The insured member |
| `23` | Dependent | A patient covered under the subscriber |

In the sample, both subscriber levels (`HL*4` and `HL*5`) point to the same provider level (`HL02` = `3`). A batch of claims for one provider looks like this: one payer, one receiver, one provider, many subscribers.

### NM1: The Parties

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

`NM101` names the role (`PR` payer, `41` submitter, `1P` provider, `IL` subscriber, `QC` patient at the dependent level). `NM108` names the ID type: `PI` payer ID, `46` electronic transmitter identification number, `XX` NPI, `MI` member ID. The NPI here, `1234567893`, is a check-digit-valid test value, not a real provider. Payers match on the provider ID you billed under, so send the same NPI that was on the 837.

### TRN: Claim Status Tracking Number

```
TRN*1*SMPCLM1001~
```

| Element | Name | Example | What it means |
|---|---|---|---|
| **TRN01** | Trace Type Code | `1` | Current transaction trace number |
| **TRN02** | Reference Identification | `SMPCLM1001` | Your trace number for this claim inquiry |

The 277 returns it as `TRN*2`. Some payers ask you to use the patient control number from the 837 (`CLM01`) here; the Illinois Medicaid companion guide, for example, does. Whatever you use, it has to be unique enough to match the answer.

### REF: Claim Identifiers

```
REF*EJ*SMPCLM1001~
```

| REF01 | Meaning | Where it comes from |
|---|---|---|
| `1K` | Payer claim control number | The payer's number, from a prior 277CA, 277 or 835 |
| `EJ` | Patient control number | `CLM01` on your 837, as the X212 examples show |
| `BLT` | Institutional bill type | The bill type on an institutional claim |

If you have the payer claim control number, send it. It is the most precise search key a payer has. Without it, the payer searches on member, provider, dates and charges, and any mismatch can mean "not found."

### AMT and DTP: Charges and Service Dates

```
AMT*T3*285~
DTP*472*D8*20261015~
```

`AMT01` = `T3` is the total submitted charge, which must match the claim total on the 837. `DTP01` = `472` is the service date; use `D8` for one date or `RD8` with `CCYYMMDD-CCYYMMDD` for a range, as in the X12 example `DTP*472*RD8*20050831-20050906`.

### SVC: Service Line (Optional)

```
SVC*HC:99203*150*****1~
```

This line from the X12 example asks about one procedure on a claim: `SVC01` is the procedure composite (`HC` for HCPCS/CPT, then the code), `SVC02` the line charge, and `SVC07` the units. Most inquiries stay at the claim level; payers' guides say when line-level detail is supported.

## 276 vs 277, 277CA, 837 and 835

| Document | Sent by | Purpose |
|---|---|---|
| **[837 Health Care Claim](/guides/edi/837-health-care-claim)** | Provider | Bills the claim |
| **[999 Implementation Acknowledgment](/guides/edi/999-implementation-acknowledgment)** | Clearinghouse or payer | Says the file passed or failed syntax and TR3 validation |
| **277CA Claim Acknowledgment** | Clearinghouse or payer | Says each claim was accepted into processing or rejected at intake |
| **276 Claim Status Request** | Provider | Asks where specific claims stand |
| **[277 Claim Status Response](/guides/edi/277-claim-status-response)** | Health plan | Answers with status codes and payment details |
| **[835 Claim Payment/Advice](/guides/edi/835-health-care-claim-payment-advice)** | Health plan | Explains payment and adjustments |

## Common 276 Errors and How to Prevent Them

| Error | What happens | Prevention |
|---|---|---|
| **Charges in `AMT*T3` differ from the 837** | Claim not found | Pull the amount from the billed claim record, not from the balance |
| **Service dates differ from the 837** | Claim not found, or a status code pointing at dates | Send the same `DTP*472` dates the claim carried |
| **Different provider ID than billed** | Not found, or a provider entity error | Use the 837's billing provider NPI |
| **Member ID or name mismatch** | Subscriber not found | Use the ID and name as submitted on the claim |
| **Dependent sent at the subscriber level, or the reverse** | Not found | Mirror the subscriber/patient structure of the original claim |
| **Asking too soon** | Status "not found" for a claim still in intake | Check the 999 and 277CA first; follow the payer's guidance on timing |
| **Non-unique `TRN02`** | Responses matched to the wrong claim | Generate a unique trace per claim inquiry |
| **Wrong version in `GS08`** | 999 rejection | Send `005010X212` |

## 276 Implementation Checklist

- Confirm the payer or clearinghouse supports `005010X212` 276s, and whether real time, batch or both
- Read each payer's companion guide for required search fields and claim limits per request
- Store the payer claim control number from every 277CA, 277 and 835, and send it when you have it
- Pull member, provider, charge and date values from the billed claim, not from current account data
- Generate unique `TRN02` values and keep them with the claim
- Schedule 276s from your follow-up rules rather than sending them for every open claim daily
- Handle 999 rejections separately from 277 responses
- Test paid, pending, denied and not-found scenarios with each major payer

If you are new to X12, our [essential guide to EDI](/blog/essential-guide-to-edi) covers envelopes, segments and delimiters, and [EDI vs API](/blog/edi-vs-api) compares batch EDI with API-based exchange.

## 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, 276s included. Paste a test 276 to see the payer, provider, patient and claim levels labeled with a plain-English summary, and get structural errors explained. 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

<div className="not-prose">

### What is an EDI 276?

The EDI 276 is the X12 Health Care Claim Status Request. A provider, billing service or clearinghouse sends it to a health plan to ask about the status of submitted claims. The plan answers with a 277.

### What does 005010X212 mean?

It identifies the HIPAA implementation guide for the 276/277 claim status transaction: X12 version 005010, technical report X212. It appears in GS08 and ST03. The 2008 errata, 005010X212E1, did not change that identifier.

### What is the difference between a 276 and a 277?

The 276 is the provider's question about specific claims. The 277 is the health plan's answer, with STC status codes for each claim and, when the claim is finalized, payment amounts and dates.

### What information does a 276 need to find a claim?

The payer, the provider identifier used on the claim, the member ID and name, the total claim charge, and the service dates. The payer's claim control number in a REF*1K segment, when you have it, is the most precise key.

### How soon after billing should I send a 276?

That depends on the payer. Check the 999 and the 277CA first to confirm the claim was accepted into processing, then follow the payer's companion guide and your own follow-up rules for when to ask about status.

### Can one 276 ask about several claims?

Yes. The hierarchy allows many providers, subscribers and claims in one transaction, as the X12 example with three claims shows. Payers can limit how many claims they accept per request, especially in real time.

### Is the 276 the same as the 277CA?

No. The 276 is a request the provider sends. The 277CA is an acknowledgment the clearinghouse or payer sends after receiving an 837, without being asked, to report whether each claim was accepted for processing.

</div>
