276 / 277 claim status

Outcome

When a claim has been accepted (A2 277CA) but no 835 has arrived in the expected SLA, you can run a 276 status inquiry, parse the 277 status response, and decide next action — wait, escalate, or rebuild.

Prerequisites

Scope	What it lets you do
edi.transaction.read	View transactions
edi.status.run	Originate 276s

A trading partner with 276 outbound and 277 inbound capabilities (2.4). The claim must already have a payer_claim_control_number recorded from a prior 277CA — the 276 needs it as the cross-reference key.

276 vs 277CA — same envelope, different BHT02

The 277 transaction set has two flavors. Both share the segment structure; they differ in BHT02:

BHT02	Variant	Capability	Initiated by
08	277CA — Claim Acknowledgment	277CA inbound	Payer (auto, after 837)
00	277 — Claim Status Response	277 inbound	Payer (in response to 276)

The platform routes inbound 277s based on BHT02 — they go into different processing queues but use the same parser (packages/x12/src/inbound/status-277.ts).

276 anatomy

Source: packages/x12/src/outbound/status-276.ts. Implementation convention: 005010X212.

ISA → GS → ST*276 → BHT
  Loop 2000A — Payer Hierarchy
    HL*1**20*1
    NM1*PR (payer)
  Loop 2000B — Information Receiver Hierarchy
    HL*2*1*21*1
    NM1*41 (information receiver = us)
  Loop 2000C — Provider Hierarchy
    HL*3*2*19*1
    NM1*1P (provider)
  Loop 2000D — Subscriber Hierarchy
    HL*4*3*22*1
    DMG (subscriber DOB)
    NM1*IL (subscriber)
  Loop 2000E — Patient Hierarchy (when patient is not subscriber)
    HL*5*4*23*0
    DMG
    NM1*QC
  Loop 2200D / 2200E — Claim Status Tracking
    TRN (trace number — *we* generate this for matching the response)
    REF*BLT (bill type — institutional)
    REF*EJ (patient account number — our CLM01)
    REF*F8 (payer claim control number — from prior 277CA)
    AMT*T3 (total claim amount)
    DTP*472 (service date or range)
SE → GE → IEA

The minimal 276 requires:

• TRN02 — our trace number (we set this; the 277 echoes).
• REF*F8 — payer's claim control number from the 277CA REF*1K.
• AMT*T3 — total claim amount (payer cross-checks).
• DTP*472 — service date for additional matching.

277 status response

A 277 (BHT02 = 00) carries the adjudication state in STC:

STC01 category	Meaning	What it tells you
F0	Finalized	Adjudication complete (more detail in STC01:2).
F1	Finalized / Payment	Claim paid. The 835 either has been or is about to be sent.
F2	Finalized / Denial	Claim denied. The 835 will carry the CARC.
F3	Finalized / Adjudication complete — no payment	Adjudicated to zero (e.g. patient owes 100% to deductible).
F3F	Finalized / Forwarded	Crossover sent to next payer (Medicare crossover patterns).
P0	Pending	Still adjudicating.
P1	Pending / In Process	Reasonable wait time.
P3	Pending / Pre-pay review	Pre-payment medical review — could take weeks.
R0	Requests for additional information	Payer wants more info; will not finalize without it.

The status code in STC01:2 adds detail. Read STC03 (narrative) for human-readable text.

Steps to run a status inquiry

1. Confirm the claim has a payer_claim_control_number. Open the claim's detail in rcm-app; if missing, the 277CA never landed, and 276 will fail.

2. Trigger the inquiry. From rcm-app's claim detail → Submission tab → Run status inquiry. The rcm-core API publishes a claim.status_inquiry_queued event.

3. The gateway composes the 276 with the claim's identifiers, allocates control numbers, applies any companion guide, and submits.

4. The transaction record appears at /transactions with tx_type = 276, direction outbound. Wait for the 277.

5. The 277 arrives as tx_type = 277 (BHT02 = 00). The response-processor parses it, decodes the STC, and writes the status onto the claim:

   • F0/F1/F2/F3 → claim status reflects finalized; wait for the 835.
   • P0/P1/P3 → claim's last_status_check updated; flagged for follow-up later.
   • R0 → operator must respond with the requested information (typically through the payer portal; the 276/277 channel does not carry attachments).

Polling cadence

Daily 276 polling for stuck claims is more useful than a one-off:

1. rcm-core publishes a daily job that fetches every claim in SUBMITTED for >N days (default 14) and queues a 276 for each.

2. The gateway batches them per partner — a single 276 file can carry many claims (one 2200D loop per claim).

3. The 277 batch arrives with one STC per claim. The response- processor dispatches per-claim updates.

4. Claims in P3 (pre-pay review) for >M days raise an issue for operator follow-up.

Validation

Check	Expected
Outbound 276 record appears with correlation_id to the claim	Yes.
277 inbound record appears with correlation_id matching the 276	Yes.
Per-claim STC decoded onto each source claim	Yes.
Daily polling runs cleanly with no orphans	Yes — the partner's response carries one STC per inquiry.

Troubleshooting

Symptom	Cause	Fix
277 returns STC01 = F4 "Acknowledgment not found"	The payer cannot find our claim — wrong REF*F8	Confirm payer_claim_control_number on the claim against the 277CA.
277 stuck at P3 for weeks	Pre-pay medical review is real — payer is reviewing	Continue polling; do not rebuild.
Multi-claim 276 returns fewer 277s than queries	Partner is slow / fragmenting; the rest follow in subsequent files	Wait one cadence cycle; if still missing, escalate.
277 arrives but no source claim updated	Correlation failed (TRN02 mismatch)	Open the inbound transaction; correlate manually.

Next

8.1 — Daily monitoring