|NOTE: Before using the claimstatus /Raw-X12 endpoint, contact your Change Healthcare implementation analyst. Our Raw-X12 service requires custom headers with credentials, and other information specific to each customer's contracted Payer List relationships that you will need to obtain from your analyst contact.|
The Claims Status Raw-X12 endpoint supports the X12 EDI standard if you choose to implement the 276 transaction set in its native EDI format. The 277 transaction responses you receive will also appear in EDI format.
We support a traditional X12 EDI request if you choose to implement the 276 transaction set in its native EDI format. The 277 transaction responses you receive will also appear in EDI format.
The Claims Status Raw-X12 endpoint is as follows:
An X12 EDI 276 Claim Status request appears similar to the following:
|EDI 276 Request||Description|
A few notes about this example: In the X12 transmission payload, the
The transaction example contains five
HL segments. The first field of each HL segment identifies its position in the hierarchical levels in the claim. Here is the simple segment list shown in the example:
HL 1- Information Source (essentially, the payer - Loop 2000A)
HL 2- Information Receiver (the submitter of the inquiry - Loop 2000B)
HL 3- Service Provider (the provider delivering or organizing the care - Loop 2000C)
HL 4- Subscriber (the holder of the insurance policy - Loop 2000D)
HL 5- Dependent (if necessary, the other member of the family needing care - Loop 2000E)
This sequence will change based on different claim factors. See pages 8-10 of the ASC X12 276/277 Implementation Guide for details.
NM1 segment follows each HL segment in the request body. It separately describes each of these five entities in our example. Demographic information (
DMG) follows for the subscriber and dependent records. The 276 submission requires all of this information to help ensure the payer/information source can locate the claim and send an informative response.
TRN segment is required when the patient has their own policy ID number (the subscriber, or a dependent that has a unique policy ID).
REF (Reference Information) segment appears whenever the information receiver knows the specific payer-assigned claim number, and is inquiring about that claim. The REF segment takes several different forms depending on the type of claim, but is always defined as the Claim Status Tracking Number. See pages 59-65 of the ASC X12 276/277 Implementation Guide to find out more details about how this works.
| Ensuring Integrity of X12 Transmissions|
When you create and send your X12 content through our API, ensure that the final field in the ISA header, ISA16, contains the colon character (":"). ISA16 is a single-character field that defines the component element separator in the ISA header. For your X12 EDI transactions to work in your contracted APIs you must use the colon character in this field. It should be used only in ISA16 and not for any other X12 header or trailer. See Appendix C of the ASC X12 276/277 Implementation Guide for more information about the Claim Status transaction structure.
The X12 EDI 277 response for this example is the following:
|EDI 277 Response||Description|
Core claim information consists of the
The first element of all STC segments,
STC01, is named Health care status claim. Field STC01 is a composite field that holds several code values. Consider the following snippet:
This is the first part of the substantial STC segment. In a composite field, the colon (:) is used as a separator to isolate each coding value. It's another use of the composite element delimiter.
- The first sub-field, (
F1), is the Health Care Claim Status Category code. Here, the code indicates the claim or service line item is Finalized and Paid (Finalized/Paid). This list is publicly available and is not published in the Implementation Guide;
- The second sub-field, (
65), is the Claim Status Code. This code is added by the adjudication authority. The value shown also indicates the claim item is Paid. This list is publicly available and is not published in the Implementation Guide;
- The third sub-field (
1E) is the entity identifier. Here, it shows that the payment is coming from an HMO. The code defines the context for the previous two values, and comes from a substantial code list (see page 161-167 of the ASC X12 276/277 Implementation Guide).
Updated 11 months ago