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:

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:

This sequence will change based on different claim factors. See pages 8 to 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 through 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

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.

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.

Do you bill for a failed claim due to technical error?

Every transaction that makes it to the clearinghouse is billable. All errors at the API level, and some errors at the ingress of the clearinghouse, are considered non-billable.

What does a typical Claims Status API request look like?

The Claims Status API uses a POST 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"

...

I am retrieving the claim's status and in the sandbox response returns an array of claims, how can I get the status for a specific claim? Do I use the checkNumber and trackingNumber properties to find the claim? (I submit the claim using the Professional API and have saved the traceId (from meta). Is this the correct number to save so I can look for it in the Status API response?)

Regarding the Claim Status API, match all of this information closely to the actual submission:

"providers": [

        {

            "organizationName": "Joe's Clinic",

            "taxId": "822777888",

            "providerType": "BillingProvider"

        },

        {

            "organizationName": "Joe's Clinic",

            "npi": "1234567890",

            "providerType": "ServiceProvider"

        }

    ],

    "subscriber": {

        "memberId": "ABC123456",

        "firstName": "GEORGE",

        "lastName": "DOE",

       "gender": "M",

        "dateOfBirth": "18800101",

        "groupNumber": "1987654"

    },

    "encounter": {

        "beginningDateOfService": "20220202",

        "endDateOfService": "20220202",

        "submittedAmount": "294",

        "trackingNumber": "ABC1234567"

You can use the trackingNumber in any way you want. For example, in the Claims API specification, the patientControlNumber field is used to track a claim from creation through payment. You can use the trackingNumber field to tie specific transactions to each other. This tracking number is not submitted on the claim, but it is a way for you to identify the specific Claim Status request you are submitting.
Best practice would be to ensure these are the same so any claim status requests can immediately be linked back to the original submission.

The Contents of the Claim Status API Request page states: Different payers have different recommendations for what you must include in a request, for example, Blue Cross affiliates such as BCBSNC require the NPI (provider identifier) in EDI 276 requests, and recommends adding the Patient Account Number (in Loop 2200D, element REF01) to associate submitted requests to correct responses. When we use the sandbox, how is validation completed? Are you hitting sandboxes of each payer? If not, how can we validate that we have all of the fields each payer requires?

📘

NOTE

The sandbox returns a canned response based on the received data. There is not a validation check or confirmation of specifically required information. These checks would only happen in production. You would need to manually review the companion guides offered by the specific payers to confirm what is required for each.

How to manage adjustment codes from payer in claims API?

Codes, such as the following are returned by the payer and it is payer dependent. Not all payers return the same information. We have examples of what a typical response looks like in our documentation.

Does the Claim Submission or Claim Status APIs return Customer Account number from the Insurance record?

It will have the memberID for the patient, not necessarily their account number from the billing system.

Cannot uniquely identify individual service item in staging Claim Status API Response?

Refer to the API JSON to EDI mapping, contents of the Claim Status API Request and Response.

Can you explain what the Claims Status API is? Is it different from the professional and institutional claims APIs?

The submitter uses a Claim Status request to ask about the status of a previously submitted claim. The payer returns the response as an X12 EDI 277 transaction, which is translated back to JSON by the API gateway. It describes where the claim is in the adjudication process (for example, Pending or Finalized).
If the claim is finalized, the response provides the disposition of the claim (for example, Paid or Denied). For denied or rejected outcomes, the response includes the reasons for the denial or rejection.

Claim status response message: "Patient eligibility not found with entity. Usage: This code requires use of an Entity Code". What does this mean?

This reads that the payer (entity: Insurer) cannot find the patient in their system. This would either indicate that you are calling the wrong payer or there could be a typo in the request that is sending wrong information.

Here are the claim status codes. Reverify the patient's insurance information and make sure all the details are correct.

A provider has two different teams; one enters the claim and the other verifies and submits it. Before submitting, can they enter the claim, save it, and have it released when ready?

Our APIs do not have a cache/drafting feature. Customers can develop and automate this feature. Customers should hold the claims on their end and programmatically set up a console to separate working on claims from submitting them.

How could I get the submitted claim status with Claim Status API ? Need I put controlNumber or patientControlNumber in get status API request?

Please be aware that payers do require time to process the claims before Claim Status may be available. I have provided a sample Claim Status request below that is used for the majority of payers. Please update your request format to match that of the below.

{
    "controlNumber": "234456789",
    "tradingPartnerName": "Payer A",
    "tradingPartnerServiceId": "9496",
    "providers": [
        {
            "organizationName": "Joe's Clinic",
            "taxId": "822777888",
            "providerType": "BillingProvider"
        },
        {
            "organizationName": "Joe's Clinic",
            "npi": "1234567890",
            "providerType": "ServiceProvider"
        }
    ],
    "subscriber": {
        "memberId": "ABC123456",
        "firstName": "GEORGE",
        "lastName": "DOE",
        "gender": "M",
        "dateOfBirth": "18800101",
        "groupNumber": "1987654"
    },
    "encounter": {
        "beginningDateOfService": "20220202",
        "endDateOfService": "20220202",
        "submittedAmount": "294",
        "trackingNumber": "ABC1234567"
    }
}

Can we use UUID for the tracking number? If not, what should we use?

Yes, you can. The trackingNumber in a Claim Status request is only used to tie the request to the response, it does not impact how the payer pulls the claim.

Do we need to use same control ID for a claim in submission and checking its claim status?

The controlNumber should be unique for each individual submission.

If a claim is rejected after submission, should we submit the same claim with frequency code value '7' or can we submit the same claim with modified data in a new submission with code '1'?

Code '1' is typically used for rejected claims. Code '7' is only used when submitting a corrected claim. A correct claim is only submitted when the payer has actually adjudicated the submission and processed the claim for payment. That is, a claimFrequencyCode '1' should be used for all original submissions even if a claim has been rejected. ClaimFrequencyCode '7' is only used specifically if a payer denies a claim and corrections need to be made.

Related Topics

• API Reference
• Troubleshoot APIs with Metadata