API & Services Connection™
Request Sandbox AccessMarketplaceApp RegistryCommunity

Claims Status FAQs

Suggest Edits

📘

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 RequestDescription
javascript 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 hierarchical levels (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:

SegmentDescription
HL 1Information Source (essentially, the payer - Loop 2000A).
HL 2Information Receiver (the submitter of the inquiry - Loop 2000B).
HL 3Service Provider (the provider delivering or organizing the care - Loop 2000C).
HL 4Subscriber (the holder of the insurance policy - Loop 2000D).
HL 5Dependent (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.

Sequence of segments

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

Integrity of X-12 transmissions

📘

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.

X-12 EDI 277 example

EDI 277 ResponseDescription
javascript 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.

FieldDescription
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 Claims Status API request look like?

The Claims Status API uses a POST HTTPS request. You provide the input as JSON in the body of the request. The Claims 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 Claims Status API Request for more information about the contents of the Claims Status request body.

What does a typical Claims 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 Claims Status API Response for more information about the contents of the Claims 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 Claims Status and Claims Responses and Reports?

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

How does EDI to JSON translation work

First, here is a quick look at an EDI claim status report:

https://apigw.changehealthcare.com/medicalnetwork/reports/v2/X3000000.XX

{
    "report_content": "ISA~00~          ~00~          ~ZZ~CLAIMSCH       ~ZZ~010414         ~180511~1112~|~00501~100321569~0~P~^_TA1~020120501~131121~1506~A~000_GS~FA~ECGCLAIMS~K10353~20180511~1112~000000001~X~005010X231A1_ST~999~0001~005010X231A1_AK1~HC~1~005010X223A1_AK2~837~00704~005010X223A1_IK5~A_AK9~A~000001~000001~000001_SE~0000000006~0001_GE~000001~000000001_IEA~00001~100321569_"
}

You append the /277 suffix to the same path, and the API renders the translation:

https://apigw.changehealthcare.com/medicalnetwork/reports/v2/X3000000.XX/277

{
    "claims": [
        {
            "claimStatus": {
                "effectiveDate": "20200107",
                "entity": "Mutually Defined",
                "entityCode": "ZZ",
                "statusCategoryCode": "E1",
                "statusCategoryCodeValue": "Response not possible - System Status",
                "statusCode": "689",
                "statusCodeValue": "Entity was unable to respond within the expected time frame. Usage: This code requires use of an Entity Code.",
                "trackingNumber": "ABCD"
            }
        }
...

Example of 1:1 EDI to JSON translation

Here is an example of a 1:1 translation from EDI to JSON, starting with getting a display of an EDI-formatted Remittance file:

GET https://apigw.changehealthcare.com/medicalnetwork/reports/v2/R5000000.XX

{
    "report_content": "ISA~00~          ~00~          ~ZZ~CHC            ~ZZ~658675C9801437 ~200422~2313~|~00501~156233287~0~P~^_GS~HP~CHC~658675C9801437~20200422~23135600~1~X~005010X221A1_ST~835~000000001_BPR~I~2563.13~C~ACH~CCP~01~042000013~DA~152302017834~1351840597~~01~071921891~DA~4638544662~20200423_TRN~1~895322770~1351840597_REF~EV~99992_DTM~405~20200422_N1~PR~NATIONAL GOVERNMENT SERVICES, 
}

This is quite a substantial body of EDI information.

Then, you append the /835 suffix to get the JSON translation of the same remittance file. It consists of a complete breakdown of payment information for all service identifications, payments, payment adjustments, financial information, and Payer and Payee information:

GET https://apigw.changehealthcare.com/medicalnetwork/reports/v2/R5000000.XX/835

{
    "detailInfo": [
        {
            "assignedNumber": "1",
            "paymentInfo": [
                {
                    "claimPaymentInfo": {
                        "claimFilingIndicatorCode": "MB",
                        "claimFrequencyCode": "1",
                        "claimPaymentAmount": "2563.13",
                        "claimStatusCode": "19",
                        "facilityTypeCode": "11",
                        "patientControlNumber": "00309",
                        "patientResponsibilityAmount": "711.4",
                        "payerClaimControlNumber": "0220087697150",
                        "totalClaimChargeAmount": "9006"
                    },
                    "claimReceivedDate": {
                        "date": "20200327",
                        "dateTimeQualifier": "050"
                    },
                    "crossoverCarrier": {
                        "entityIdentifierCode": "TT",
                        "entityTypeQualifier": "2",
                        "identificationCode": "00268",
                        "identificationCodeQualifier": "PI",
                        "name": "HUMANA, INC."
                    },
                    "outpatientAdjudication": {
                        "claimPaymentRemarkCode1": "MA01",
                        "claimPaymentRemarkCode2": "MA15",
                        "claimPaymentRemarkCode3": "MA18"
                    },
                    "patientName": {
                        "entityIdentifierCode": "QC",
                        "entityTypeQualifier": "1",
                        "firstName": "JANE",
                        "identificationCode": "7SL5RA7XR19",
                        "identificationCodeQualifier": "MI",
                        "name": "DOE"
                    },
                    "renderingProvider": {
                        "entityIdentifierCode": "82",
                        "entityTypeQualifier": "1",
                        "identificationCode": "1234567893",
                        "identificationCodeQualifier": "XX"

...

Updated 2 months ago

Related Topics