API & Services Connection™
Request Sandbox AccessMarketplaceApp RegistryCommunity

Claims Status FAQs

📘

NOTE

Please see the API FAQs section for tips and solutions to some of the most common questions asked by customers, developer community, and internal staff about the use of the Change Healthcare API.

What information goes in the API request header?

See API FAQs.

How can I use X12 EDI as the coding for my API request?

📘

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.

Claims Status Raw-X12 endpoint

https://apigw.changehealthcare.com/medicalnetwork/claimstatus/v2/raw-x12

An X12 EDI 276 Claim Status request appears similar to the following:

EDI 276 Request

Description

POST ${api_basepath}/raw-x12 HTTP/1.1
Host: ${apigee_host}
Authorization: Bearer <Your-Access-Token>
Content-Type: application/json
{
    "x12": "ISA*00*..........*01*password  *ZZ*something*
    ZZ*EMDEON.........*200729*0835*^*00501*000000001*
0*P*:~GS*HR*LCX1210000*MTEXE*20200729*0835*000000001*
X*005010X212~ST*276*000000001*005010X212~BHT*0010*13*
000000001*20200729*0835~HL*1**20*1~NM1*PR*2*MedWest*****
PI*serviceId~HL*2*1*21*1~NM1*41*2*TestProvider*****46*
0123456789~HL*3*2*19*1~NM1*1P*2*happy doctors group*****
XX*1760854442~HL*4*3*22*1~DMG*D8*18800102*M~NM1*IL*1*
doeone*johnone****MI*0000000000~HL*5*3*23*0~DMG*D8*
18800101*F~NM1*QC*1*doeone*janeone~TRN*1*ABCD~REF*
6P*0000000000~DTP*472*RD8*20100101-20100102~SE*18*
000000001~GE*1*000000001~IEA*1*000000001~"
}

A few notes about this example in the X12 transmission payload:

  • The ISA, GS and ST control segments are used as envelopes to encapsulate the medical transaction data and confidentially manage its transmission.
  • The GS header ends with the Version ID code (005010X212), which describes the EDI standard used in the transaction.
  • The ST header states the type of medical transaction, which is 276 in this example (Claim Status submission).

    When the envelope headers are complete:
  • The Beginning of Hierarchical Transaction (BHT) field shows the start of the data that forms the Claim Status medical transaction.
  • The end of the claim status request body carries the TRN (Claim Tracking Number) and REF (Payer Claim Control Number) segments.

HL Segments

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:

Segment

Description

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.

  • An NM1 segment follows each HL segment in the request body. It separately describes each of these five entities in our example. A 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.

  • The TRN segment is required when the patient has their own policy ID number (the subscriber, or a dependent that has a unique policy ID).

  • The Reference Information (REF) 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.

📘

NOTE

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

POST ${api_basepath}/raw-x12 HTTP/1.1
Host: ${apigee_host}
Authorization: Bearer <Your-Access-Token>
Content-Type: application/json
{
"x12": "ISA*00*.........*01*SomePwd*ZZ*EMDEON.........*
ZZ*TPG00000*201006*1752*^*00501*000000001*0*T*:~GS*
HN*MTEXE*LCX1210000*20131015*2219*000000001*X*005010X212~ST*
277*000000001*005010X212~BHT*0010*08*000000001*20200729*
0835*DG~HL*1**20*1~NM1*PR*2*Unknown*****PI*serviceId~
HL*2*1*21*1~NM1*41*2*TestProvider*****46*0123456789~
HL*3*2*19*1~NM1*1P*2*happy doctors group*****XX*1760854442~
HL*4*3*22*0~NM1*IL*1*doeone*johnone****MI*0000000000~
TRN*2*000000001~
STC*F1:65:1E*20170415**1229*219*20170415**20170415*1111111~
REF*1K*AAAAAAAAAAA1~DTP*472*D8*20160722~
TRN*2*C1234567891028297LL~
STC*F3:101:1E*20170412**1229*184.05~REF*1K*AAAAAAAAAAA2~
DTP*472*D8*20160722~TRN*2*C1234567891028297LL~
STC*F3:101:1E*20161201**1229*219~REF*1K*AAAAAAAAAAA3~
DTP*472*D8*20160722~SE*23*000000001~GE*1*000000001~
IEA*1*000000001~"
}

Core claim information consists of the STC segments, which vary by loop based on the entities receiving the status information:

  • Information Receiver status information
  • Provider status information
  • Claim Level status information
  • Service Line status information

Claim Level status information and service line status information can include monetary amounts.
The second and third STC segments in the response above show monetary amounts of $184.05 and $219.
Responses may or may not provide monetary amounts, based on the current claim status. Also, payers may or may not support service line reporting. See page 138 of the ASC X12 276/277 Implementation Guide for Claim Level Status Information and page 160 for Service Lines Status Information.

Zooming in on the STC Codes

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:

```javascript
    STC*F1:65:1E*
```

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.

Field

Description

First sub-field, (F1)

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.

Second sub-field, (65)

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.

Third sub-field (1E)

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

What is the Tracking Number field?

The trackingNumber field is a tracking value that you can use at your discretion. It will accept any value and is not required. It exists so that you can link the 277 response back to your original request, and the payer will always echo this value back exactly as you sent it.

How often can I check the status of pending claims?

Our general recommendation is every 5 to 7 days. Customers can determine if that fits their needs and adjust as necessary.

What does a typical Claim Status API request look like?

The Claim Status API uses a POST HTTPS request. You provide the input as JSON in the body of the request. The Claim Status request body is usually relatively brief, if the optional dependent is not involved in the medical encounter, the request body will be even shorter:

```javascript
POST ${api_basepath} HTTP/1.1
Host: ${apigee_host}
Authorization: Bearer <Your-Access-Token>
Content-Type: application/json

{
    "controlNumber": "000000001",
    "tradingPartnerServiceId": "serviceId",
    "providers": [{
        "organizationName": "TestProvider",
        "taxId": "0123456789",
        "providerType": "BillingProvider"
    },
    {
        "organizationName": "happy doctors group",
        "npi": "1760854442",
        "providerType": "ServiceProvider"
    }],
    "subscriber": {
        "memberId": "0000000000",
        "firstName": "johnone",
        "lastName": "doeone",
        "gender": "M",
        "dateOfBirth": "18800102",
        "groupNumber": "0000000000"
    },
    "dependent": {
        "firstName": "janeone",
        "lastName": "doeone",
        "gender": "F",
        "dateOfBirth": "18800101",
        "groupNumber": "0000000000"
    },
    "encounter": {
        "beginningDateOfService": "20100101",
        "endDateOfService": "20100102",
        "trackingNumber": "ABCD"
    }
}
```

See Contents of the Claim Status API Request for more information about the contents of the Claim Status request body.

What does a typical Claim Status API response look like?

Responses to our Medical Network APIs can be lengthy due to the many data points that a payer or trading partner provides in the query response. Our APIs translate back and forth between JSON and X12 EDI when the information departs into, and returns from, the medical network. We also support Raw X12 APIs should you wish to directly communicate using that data format.

See Contents of the Claim Status API Response for more information about the contents of the Claim Status response data.

```javascript
{
    "controlNumber": "000000001",
    "tradingPartnerServiceId": "serviceId",
    "providers": [
        {
            "organizationName": "TestProvider",
            "taxId": "0123456789",
            "providerType": "BillingProvider"
        },
        {
            "organizationName": "happy doctors group",
            "npi": "1760854442",
            "providerType": "ServiceProvider"
        }
    ],
    "subscriber": {
        "firstName": "johnone",
        "lastName": "doeone",
        "memberId": "0000000000"
    },
    "claims": [
        {
            "claimStatus": {
                "statusCategoryCode": "F1",
                "statusCategoryCodeValue": "Finalized/Payment-The claim/line has been paid.",
                "statusCode": "65",
                "statusCodeValue": "Claim/line has been paid.",
                "entityCode": "1E",
                "entity": "Health Maintenance Organization (HMO)",
                "effectiveDate": "20170415",
                "submittedAmount": "1229",
                "amountPaid": "219",
                "paidDate": "20170415",
                "checkIssueDate": "20170415",
                "checkNumber": "1111111",
                "trackingNumber": "000000001",
                "claimServiceDate": "20160722",
                "tradingPartnerClaimNumber": "AAAAAAAAAAA1"
            }
        },
        {
            "claimStatus": {
                "statusCategoryCode": "F3",
                "statusCategoryCodeValue": "Finalized/Revised - Adjudication information has been changed",
                "statusCode": "101",
                "statusCodeValue": "Claim was processed as adjustment to previous claim.",
                "entityCode": "1E",
                "entity": "Health Maintenance Organization (HMO)",
                "effectiveDate": "20170412",
                "submittedAmount": "1229",
                "amountPaid": "184.05",
                "trackingNumber": "C1234567891028297LL",
                "claimServiceDate": "20160722",
                "tradingPartnerClaimNumber": "AAAAAAAAAAA2"
            }
        },
        {
            "claimStatus": {
                "statusCategoryCode": "F3",
                "statusCategoryCodeValue": "Finalized/Revised - Adjudication information has been changed",
                "statusCode": "101",
                "statusCodeValue": "Claim was processed as adjustment to previous claim.",
                "entityCode": "1E",
                "entity": "Health Maintenance Organization (HMO)",
                "effectiveDate": "20161201",
                "submittedAmount": "1229",
                "amountPaid": "219",
                "trackingNumber": "C1234567891028297LL",
                "claimServiceDate": "20160722",
                "tradingPartnerClaimNumber": "AAAAAAAAAAA3"
            }
        }
    ],
    "reassociationKey": "000000001",
    "status": "success"
}
```

What's the difference between Claim Status and Claim Reports and Responses?

Claim Status' main task is to check the status of a claim in the payer’s system. If a provider has not received a payer report on a claim, or if they have not received payment, they run a claim status request to find out the most recent status of that claim. Claim Responses and Reports is a fetching tool for claims information from your mailbox.

Both APIs support Professional and Institutional claims.

For more information, go to Claims Responses and Reports.

You can also check our Claims Responses and Reports API reference for more information.

Updated about 1 month ago

Related Topics
Did this page help you?