What do the statusCode Attributes mean?

Our Attachment APIs support a series of standard responses, called Status Codes (statusCode), to show various results from submitted attachment transactions. You can use the Attachments Status Sandbox environment to exercise attachment API calls and view these results in a safe environment. Doing so helps you get a clear view of how the attachments system works, so you fully understand how to submit documents associated with any medical claim.

NOTE: See the topic Handling Errors in Attachment Submissions Transactions for more information about error remediation.

Using our Sandbox examples provides the advantage of knowing in advance what can go wrong. Our goal is to enable the sender to solve any issue; and, even better, to avoid issues in the first place.

How do you use our Sandbox? A list of test Payer IDs are each bound to specific statusCode message types. You use these Payer IDs to test specific message types in the Sandbox; they're not valid for use with the live API.

When you use the Sandbox to run example Attachments transactions, you can attach any sample documents you want for testing.

Change Healthcare (CHC) supports the ability to send fax/print/mail attachments through the Attachments Submission API, so you do not have to physically mail or fax documents yourself. It allows you to send documents using our electronic system, to payers who only allow fax attachment submissions or even hardcopies through US mail.

When you do this, you send your API electronic transaction in the normal way, to the CHC clearinghouse. It then forwards the contents to a separate fax/print facility that handles the forwarding of attachment documents to the payer.

Consider this process as a double filtering mechanism. It requires more attention to detail to help ensure a successful attachment submission. The CHC clearinghouse will do some checking of the attachments, and of the request body, before sending any contents to the fax/print facility; you will still be responsible for any issues that exist in the submission. Even if CHC finds no issues itself, the payer may reject submissions for any reason, and may or may not provide any explanation. Our API supports forwarding of payer explanations, but the payer is not required to do so.

In all cases, you should ensure a fully accurate JSON request body that will be received by the CHC clearinghouse when you send your claims documentation.

Many EDI 276 transaction responses reporting a failed attachment reception will will also show a rejectionInformation attribute. This field carries information that is added by the payer to explain why the attachment rejection happened. This data does not originate with Change Healthcare and is entirely optional for the payer. In other words, the payer may reject a transaction for any reason and not offer any explanation at all. It's best for submitters of any attachment transaction to err on the side of caution, ensure that all documents conform to file format standards, and avoid sending overly large graphic files.

You can use your API client to test all of our API response types in the Sandbox. You do this using a separate Test Payer ID, that is unique for each response type. All IDs for API response types follow a specific naming pattern:

TEST<EP/PP><StatusCode>
  • EP stands for Electronic Payer (a payer that supports electronic attachment submissions)
  • PP stands for Print/Fax Payer.
  • The two-digit Status Code (01, 02, ...) This is the status code identifying the response type for which the payer is configured.

As in:

TESTEP02

Here's how to use the test payer accounts for each Attachments API response type:

  1. Submit an attachment using the Attachment Submission API. Use a test payerId as listed in the following subsections for each response type.
  2. After a successful submission, the API returns the traceId in the response header.
  3. Send an API request for an Attachment Status API summary/detail endpoint using this traceid, or to the Metadata endpoint using transaction dates along with any filtering criteria you want to use.
  4. The Attachment Status API returns a pre-defined Sandbox status response that's configured for that payerId (listed below).
  5. A Metadata search returns a list of matching transactions with their traceId and corresponding statuses. All traceIds corresponding to a test payerId from the following lists will return a test status messages. If any traceId values appear that don't belong to the payer list, the result returns the actual status from the database.

All notifications apply to payers accepting both Solicited and Unsolicited attachments unless noted otherwise.

Detailed responses to submissions and to status queries will show the traceId of each, with a transactionDetails object:

{
    "traceId": "97dd8f2f-2ac3-4049-8191-7b69756949bb",
    "transactionDetails": {
        "submitterId": "678687687",
        "memberId": "394643195",
        "patientFirstName": "THOMAS",
        "patientLastName": "KRIVOSHEIN",
        "payerId": "06126",
        "providerId": "1952347981",
        "providerLastName": "MARSHFIELD CLINIC",
        "claimStartDate": "2021-05-13",
        "claimEndDate": "2021-05-13",
        "payerName": "WC-LIBERTY MUTUAL MIDDLE MARKT",
            },
    "status": [
        {
            "statusCode": "05",
            "statusMessage": "ACCEPTED_BY_PAYER",
            "statusTimeStamp": "2021-05-13 10:33",
            "documents": [
                {
                    "documentName": "rightarm.jpg",
                    "controlNumber": "51827660-012714"
                }
            ]
        }
    ]
}

Details include the core information for the transaction submitter. It includes information about the medical provider, the patient, the payer ID and their entity name, and claim dating information. It's followed by the summary status report for the submission. In this case, it is a successful submission. Because the summary content differs in every response type, each subsection below contains only the summary data, because the transactionDetails object will be the same across the board.

NOTE: Select Attachments features aren't yet supported by the Sandbox standard responses. Check this section for more details.

Test PayerId: TESTEP01

If you use the Sandbox with this test payerId, you'll receive this message stating that the Change Healthcare (CHC) clearinghouse has successfully received your submitted attachments transaction.

[
    {
        "statusCode": "01",
        "statusMessage": "TRANSACTION_RECEIVED",
        "statusTimeStamp": "2021-08-19T18:27Z",
        "documents": [
            {
                "documentName": "rightarm.jpg",
                "controlNumber": "123456789"
            }
        ]
    }
]

Test PayerId: TESTEP02

If you use the Sandbox with this test payerId, you'll receive this message stating that the Change Healthcare (CHC) clearinghouse has accepted your submitted attachments transaction.

[
    {
        "statusCode": "02",
        "statusMessage": "ACCEPTED_BY_CHC",
        "statusTimeStamp": "2021-05-13 10:33",
        "documents": [
            {
                "documentName": "rightarm.jpg",
                "controlNumber": "51827660-012714"
            }
        ]
    }
]

Test PayerId: TESTEP04

If you use the Sandbox with this test payerId, you'll receive this notification when the clearinghouse delivers the attachment(s) to the payer. At this point, the CHC clearinghouse has forwarded the attachment to the payer.

[
    {
        "statusCode": "04",
        "statusMessage": "DELIVERED_TO_PAYER",
        "statusTimeStamp": "2021-08-20T13:22Z",
        "documents": [
            {
                "documentName": "rightarm.jpg",
                "controlNumber": "123456789"
            },
            {
                "documentName": "rightarm1.jpg",
                "controlNumber": "123456789"
            }
        ]
    }
]

Test PayerId: TESTEP05

The payer sends acknowledgement of your attachment transmission through the CHC clearinghouse. It indicates they received your transaction and will evaluate it for accuracy and usability. This does not indicate payer acceptance of the transaction.

[
    {
        "statusCode": "05",
        "statusMessage": "ACKNOWLEDGED_BY_PAYER",
        "statusTimeStamp": "2021-08-20T13:22Z",
        "documents": [
            {
                "documentName": "rightarm.jpg",
                "controlNumber": "123456789"
            },
            {
                "documentName": "rightarm1.jpg",
                "controlNumber": "123456789"
            }
        ]
    }
]

Test PayerId: TESTEP06

If you use the Sandbox with this test payerId, you'll receive this notification indicating a fully successful attachment transaction.

[
    {
        "statusCode": "06",
        "statusMessage": "ACCEPTED_BY_PAYER",
        "statusTimeStamp": "2021-05-13 10:33",
        "documents": [
            {
                "documentName": "rightarm.jpg",
                "controlNumber": "51827660-012714"
            }
        ]
    }
]

NOTE: Test Payer ID TESTEP10 is designed for the "Partially Accepted" use case. Use at least two attachments in the same Sandbox API request to receive an accurate response for this use case.

This response occurs when the payer accepts one or more files while rejecting others in a transaction with multiple files. The rejectionInformation field may or may not be part of the response in real-life transactions, and its data contents are up to the payer to provide. You can convert the file to the correct format and re-send it in a separate transaction. Ensure that all documents conform to file format standards and also avoid sending files that exceed more than a few megabytes each. For example, modern cell phones can produce photos that are in excess of 6-8 megabytes in size; take measures to reduce their size before sending. Some diagnostics files, when sent in PDF format, may also exceed payer file size limits and need to be broken up into several smaller files.

Test PayerId: TESTEP10

[
    {
        "statusCode": "10",
        "statusMessage": "PARTIALLY_ACCEPTED",
        "statusTimeStamp": "2021-08-20T13:25Z",
        "documents": [

  {
                "documentName": "rightarm1.jpg",
                "controlNumber": "123456789",
                "statusCode": "52",
                "statusMessage": "REJECTED_BY_PAYER",
                "statusTimeStamp": "2021-08-20T13:25Z",
                "rejectionInformation": "File type not supported"
            },

{
                "documentName": "rightarm.jpg",
                "controlNumber": "123456789",
                "statusCode": "06",
                "statusMessage": "ACCEPTED_BY_PAYER",
                "statusTimeStamp": "2021-08-20T13:25Z"
            }
        ]
    }
]

Test PayerId: TESTEP51

In this test case, the CHC clearinghouse is rejecting the transaction due to errors. The clearinghouse will reject attachments with the wrong format and will not convert any file in an incorrect format; the sender must fix the problem and re-send. (Consult this topic for more information.) If information is missing from the request body, CHC also may detect that and reject it for that reason.

    "status": [
        {
            "statusCode": "51",
            "statusMessage": "REJECTED_BY_CHC",
            "statusTimeStamp": "2021-08-19T18:34Z",
            "documents": [
                {
                    "documentName": "rightarm.doc",
                    "controlNumber": "123456789"
                }
            ]
        }
    ]
}

The clearinghouse may contribute information for the rejectionInformation field. You may or may not receive helpful information here, so it's important to address any possible issues before sending the transaction to the clearinghouse through the API:

    "rejectionInformation": "File type not supported"

Test PayerId: TESTEP52

In this test case, the payer rejects the attachment. Notification reaches the CHC clearinghouse who forwards the results back to the submitter. Payers may reject an attachment due to excessive file sizes. CHAMPUS is a good example. File size is the most frequent issue in this use case.

    "status": [
        {
            "statusCode": "52",
            "statusMessage": "REJECTED_BY_PAYER",
            "statusTimeStamp": "2021-05-13 10:33",
            "documents": [
                {
                    "documentName": "rightarm.jpg",
                    "controlNumber": "51827660-012714"
                }
            ]
        }
    ]
}

The payer can optionally contribute information for the rejectionInformation field. You may or may not receive helpful information here, so it's important to address any possible issues before starting the transaction. Of course, the rejections don't apply when you're exercising these calls in the Sandbox but they definitely apply when you're exercising the API in the real world:

    "rejectionInformation": "Attachment type not supported"

TestPayerId: TESTEP53

These rejections are due to missing information in the request body and come back to the submitter from the CHC clearinghouse. It will contain the field names you'll need to fill out correctly:

{
    "statusCode": "53",
    "statusMessage": "Missing required fields transactionReceivedStartDate,transactionReceivedEndDate."
}

Test PayerId: TESTPP11

You'll receive a notification from the Change Healthcare clearinghouse once the fax transmission has reached the fax/print facility.

        "status": [
            {
                "statusCode": "11",
                "statusMessage": "Attachment reached print/fax facility",
                "statusTimeStamp": "2021-08-19T18:51Z",
                "documents": [
                    {
                        "documentName": "rightarm.jpg",
                        "controlNumber": "123456789"
                    }
                ]
            }
        ]
    }
]

Test PayerId: TESTPP12

You might receive this message when CHC's contracted print/fax facility finds issues with the documents comprising the fax. It's possible that the request has an incorrect or missing fax number, or other errors that prevent the transmission from being sent. Ensure that all information in the request is accurate. The file attachments also may be too large.

        "status": [
            {
                "statusCode": "12",
                "statusMessage": "Attachment rejected by print/fax facility",
                "statusTimeStamp": "2021-08-19T18:47Z",
                "documents": [
                    {
                        "documentName": "rightarm.jpg",
                        "controlNumber": "123456789"
                    }
                ]
            }
        ]
    }
]

Test PayerId: TESTPP13

You'll receive a notification from the Change Healthcare clearinghouse once the fax transmission has completed.

        "status": [
            {
                "statusCode": "13",
                "statusMessage": "Attachment faxed successfully",
                "statusTimeStamp": "2021-08-19T19:23Z",
                "documents": [
                    {
                        "documentName": "rightarm.jpg",
                        "controlNumber": "123456789"
                    }
                ]
            }
        ]
    }
]

Test PayerId: TESTPP14

Attachments may fail to fax; you'll receive a notification for each attempt until it goes through. when the fax/print facility receives your transaction contents, they will make three fax call attempts per day until successful transmission. Make sure to add the payerFaxNumber in your JSON request body before sending the request to the clearinghouse. The fax/print facility will not be able to handle sending the contents unless that information is your request and is correct. Ensure that all other JSON request fields are correct in the request body before sending to clearinghouse.

        "status": [
            {
                "statusCode": "14",
                "statusMessage": "Attachment failed to fax",
                "statusTimeStamp": "2021-08-19T19:21Z",
                "documents": [
                    {
                        "documentName": "rightarm.jpg",
                        "controlNumber": "123456789"
                    }
                ]
            }
        ]
    }
]

Test PayerId: TESTPP15

In rare instances, an attachment may not be mailed successfully. This is usually due to the payerAddress not being present in the JSON request to the clearinghouse, along with the correct tradingPartnerServiceId. The payerAddress is a JSON object with several fields that must be completed in the request before attempting a mail-in submission. Please verify that all information is correct before sending. Not doing so can result in extensive delays for attachments and for claims processing.

       "status": [
            {
                "statusCode": "15",
                "statusMessage": "Attachment failed to mail",
                "statusTimeStamp": "2021-08-19T19:24Z",
                "documents": [
                    {
                        "documentName": "rightarm.jpg",
                        "controlNumber": "123456789"
                    }
                ]
            }
        ]
    }
]

Test PayerId: TESTPP16

CHC's print/vax contractor also handles mailing of attachments to payers who accept only mailed hardcopies. This message indicates that the print/fax facility deems the attachments acceptable and the payerAddress information is correct; the attachments have been printed and mailed.

        "status": [
            {
                "statusCode": "16",
                "statusMessage": "Attachment mailed to the payer",
                "statusTimeStamp": "2021-08-19T19:25Z",
                "documents": [
                    {
                        "documentName": "rightarm.jpg",
                        "controlNumber": "123456789"
                    }
                ]
            }
        ]
    }
]

Test PayerId: TESTPP17

You'll receive tracking information when the API engine forwards your transaction. in both use cases below, the transaction has reached the CDC clearinghouse.

        "status": [
            {
                "statusCode": "17",
                "statusMessage": "Tracking #: 789123456",
                "statusTimeStamp": "2021-08-19T19:27Z",
                "documents": [
                    {
                        "documentName": "rightarm.jpg",
                        "controlNumber": "123456789"
                    }
                ]
            }
        ]
    }
]

Test PayerId: TESTPP18

        "status": [
            {
                "statusCode": "18",
                "statusMessage": "Tracking #: 26101357, Status : SANTA CLARITA CA Phase 2b - Destination SCF Processing, Date : 01/22/2021",
                "statusTimeStamp": "2021-08-19T19:27Z",
                "documents": [
                    {
                        "documentName": "rightarm.jpg",
                        "controlNumber": "123456789"
                    }
                ]
            }
        ]
    }
]

TestPayerId: TESTEP54

The Attachment Status API supports a powerful Metadata search feature. It supports use of common-sense search criteria to find transaction records based on a patient's or provider's name, or by many other possible data points. You can filter using multiple search criteria. A typical metadata search error message consists of: There are more than 100 records found. Please refine your search criteria. It indicates that your search is too broad. Use other search criteria to filter your replies for better accuracy.

NOTE: The Metadata Search use case is not supported by the statusCode functionality, so you will not see this error demonstration in the Sandbox. Future updates may support this feature.

TestPayerId: TESTEP56

For occasional problems in API operation, such as temporary connection problems, you'll receive an Unable to process the request at this time, please try again later message. It is a generic error message for Attachments submissions that simply did not go through. Check the Handling Errors in Attachment Submissions transactions topic for more information.

NOTE: The Unable to Process use case is not supported by the statusCode functionality, so you will not see this error demonstration in the Sandbox. Future updates may support this feature.

Did this page help you?