Health Care Claim Status Request
The HIPAA X12 276 asks a payer for the current processing status of a previously submitted health care claim.
In this guide
276 Claim Status Request moves from Provider / Clearinghouse to Payer (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 276 Claim Status Request Works
Sender
Provider / Clearinghouse
Receiver
Payer
Direction
Provider → Payer
Standard
ANSI ASC X12
Version
005010X212
Transport
AS2 / SFTP / API / Clearinghouse
Business Purpose
Healthcare
Sender — Provider / Clearinghouse
EDI Transmission
276
Health Care Claim Status Request
ANSI ASC X12 005010X212
Receiver — Payer
Related transaction flows
Need help understanding this EDI flow?
Ask EDI AI →276 Claim Status Request workflow. Steps: Identify Aging Claims, Generate 276 Request, Send via Clearinghouse, Payer Receives Request, Look Up Claim Status, Return 277 Response. Transmitted from Provider / Clearinghouse to Payer via AS2, SFTP, API, Clearinghouse, following ANSI ASC X12 005010X212.
Overview
Reduces phone calls to payer call centers by letting providers programmatically check whether a claim is in process, paid, or denied.
Sender
Provider / Clearinghouse
Receiver
Payer
Direction
Provider → Payer
Standard / Version
ANSI ASC X12 005010X212
Segment structure
Key segments that make up this transaction set:
| Segment | Name | Purpose |
|---|---|---|
| BHT | Beginning of Hierarchical Transaction | Transaction purpose and submitter reference. |
| HL | Hierarchical Level | Structures payer, provider, subscriber, and claim loops. |
| TRN | Trace Number | Submitter's tracking number for the status request. |
| REF | Reference Identification | Payer claim control number, if known. |
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*276*0001*005010X212~
BHT*0010*13*STAT-8821*20230920*0930~
HL*1**20*1~
NM1*PR*2*Acme Health Plan*****PI*66783~
HL*2*1*21*1~
NM1*41*2*Riverside Medical Group*****46*1932837465~
HL*3*2*19*1~
NM1*1P*2*Riverside Medical Group*****XX*1932837465~
HL*4*3*22*0~
NM1*IL*1*DOE*JANE****MI*W123456789~
TRN*1*STAT-8821~
REF*1K*CLM-556210~
SE*13*0001~Mapping example
A representative field-level mapping from a common source system into this transaction:
| Source | Source Field | Target Field |
|---|---|---|
| Billing System | claim.payer_claim_number | REF02 (Reference Identification) |
| Billing System | claim.patient_member_id | NM109 at IL loop |
Validation rules
- If a payer claim number is unknown, the request must include enough identifying data (patient ID, dates of service, billed amount) for the payer to locate the claim.
- Provider NPI in the 2100B/2100C loops must match the NPI used on the original 837 claim.
Common errors & troubleshooting
277 comes back as 'Claim Not Found'
Cause: Dates of service or billed amount used for lookup don't exactly match the original 837.
Fix: Always store the payer's claim control number from the 835 or acknowledgment and use it for status requests once available.
Frequently asked questions
Most payers recommend waiting until their standard claim processing window has passed (commonly 7-14 days) before checking status, to avoid 'still processing' responses.
Still have questions about 276?
Ask EDI AI →