Claim status with X12 276/277 and what the 277 leaves out

A claim went out last month. No 835 has arrived. The practice asks where it is. You send a 276 and the 277 answers A1 with status 20: received, accepted for processing. That is the whole answer.

The transaction

HIPAA adopts X12 276/277 version 005010X212 as the claim status standard in 45 CFR 162.1402. 45 CFR 162.1403 adds the CAQH CORE Phase II 250 claim status rule and the 270 connectivity rule, in force since January 1, 2013. CMS states that health plans must furnish real-time online access to claim status (CMS).

The 276 identifies the claim: billing provider, subscriber, patient, payer, the patient control number you sent in CLM01, the date of service and the charge. If you hold the payer claim control number from the 277CA or an 835, send it too. The match is then exact.

The 277 returns STC segments at claim level and, when the payer supports it, at line level. The CORE Claim Status Infrastructure Rule vCS2.0 requires a 277, or a 999 rejection, within 20 seconds in real time, for 90 percent of requests in a calendar month. A batch 276 submitted by 9:00 pm Eastern must get its 277 by 7:00 am Eastern the next business day. The rule also states that CAQH CORE rules do not require entities to build batch capabilities.

Reading STC01

STC01 is a composite. The first component is a claim status category code and the second a claim status code. The third is an entity identifier code, present when the status points at a person or organization. STC02 is the status date. STC04 is the total claim charge (CORE 277CA rule, table 3). Later elements carry the paid amount, the adjudication date and the check or EFT reference once the claim is finalized.

Category codes come from X12 code list 507 (claim status category codes). The page describes them as groupings of the status codes in list 508. The families:

• A0 to A8, acknowledgments. A1 received, A2 accepted into adjudication, A3 returned as unprocessable, A4 not found, A6 rejected for missing information, A7 rejected for invalid information, A8 rejected for a relational field error.
• P0 to P5, pending. P1 in process, P2 payer review, P3 waiting on information requested from the provider, P4 waiting on the patient, P5 administrative or system hold.
• F0 to F4, finalized. F1 payment, F2 denial, F3 revised, F4 adjudication complete with no payment.
• R0 to R17, requests for additional information. R4 documentation, R9 medical necessity, R11 pre-payment review.
• E0 to E4, the payer could not respond. E1 system status, E2 information holder not responding.
• D0, data search unsuccessful.

Status codes come from list 508 (claim status codes). The list runs from 0 to 808 with gaps and stop dates. The ones you will see most: 1, for more detailed information see remittance advice; 3, adjudicated and awaiting payment cycle; 20, accepted for processing; 21, missing or invalid information, which must be paired with a second status code naming the field; 33, subscriber and subscriber id not found; 65, claim or line has been paid; 116, claim submitted to incorrect payer; 187, dates of service; 562, entity's National Provider Identifier, which requires an entity code.

A pair reads as one sentence. A2 with 20 says accepted into adjudication. F1 with 65 says paid. F2 with 1 says denied, see the remittance advice. A7 with 562 and entity 85 says rejected for an invalid billing provider NPI. The same composite appears in the 277CA. A CMS presentation on acknowledgments shows STC*A8:496:85**U*1000.00~, which is category A8, status 496 (submitter not approved to submit for this entity) and entity 85 (CMS).

Why the response is thin

The operating rule covers infrastructure. The CS2.0 rule sets response time, availability, acknowledgments and companion guide format. It has no data content requirement. The rule's own text says a 277 may contain either the appropriate STC claim or line level status segments or the data segments with the requested details. The payer chooses.

So a payer may return a category code, a status code and a date, and nothing at line level. The reason codes that explain a denial live in the 835, and status code 1 points you there. Category D0 means the search failed. Usually your identifiers did not match the payer's record: a different patient control number, a different name format, or a date range that misses the claim. Category A4 means the payer has no record of the claim at all.

When the 277 does not answer the question

1. Resend with the payer claim control number. For an accepted claim, the 277CA carries it in 2200D REF02 (CORE 277CA rule).
2. Match a D0 or A4 against your 999 and 277CA history. If the 277CA rejected the claim with A3, A6, A7 or A8, the payer never adjudicated it, and no 276 will find it. Fix and resubmit.
3. Look for an 835 that already paid or denied the claim under a different patient control number. Match on member ID, date of service and charge.
4. For P3 and R-family codes the payer wants something. The 277 often does not say what. The payer's letter or portal does. Record the request date and the category.
5. For a P1 that persists past the payer's stated adjudication window, use the portal or a phone call, and log the reference number you receive.

Store every 277: the raw X12, the STC composite split into category, status and entity, the status date, and the identifiers you sent. A claim's status history is the ordered sequence of these records plus the 277CA and 835 events. The latest category tells the collector what to do next. The history tells them what already happened.