EDI 276 Claim Status Request: HIPAA 5010 Guide

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 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.

What Is an EDI 276?

An EDI 276 is the Health Care Claim Status Request transaction set defined by ASC X12, used to ask a health plan for the status of specific health care claims. For HIPAA covered entities, 45 CFR 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 also shows with no separate errata version.

Authoritative references for 276 work:

• The X12 005010X212 examples 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
• 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, with compliance from January 1, 2013 according to CMS
• 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. 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 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.

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.

Key Segments Explained

BHT: Beginning of Hierarchical Transaction

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

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~

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~

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~

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

Common 276 Errors and How to Prevent Them

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 covers envelopes, segments and delimiters, and 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, 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