Standard Attachment Transaction StatusCode Responses

Our Attachment APIs support a series of standard responses, called 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 Handling Errors in Attachment Submissions Transactions for more information about error remediation.

Our sandbox examples provide the alerts you about what can go wrong. Our goal is to enable the sender to solve any issues; 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. Use these payer IDs to test specific message types in the sandbox; they are not valid for use with the live API.

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

About Fax and Email Transactions

Optum supports the ability to send fax/print/mail attachments through the Attachments Submission API /attachments/submission/v1/uploads endpoint, so you do not have to physically mail or fax documents. 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, send your API electronic transaction in the normal way to the 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 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 Optum finds no issues, the payer may reject submissions for any reasons, and might 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 clearinghouse when you send your claims documentation.

Rejections of Attachment Transactions by Payers

Many EDI 276 transaction responses reporting a failed attachment reception will also show a rejectionInformation attribute. This field carries information that is added by the payer to explain why the attachment was rejected. This data does not originate with Optum and is entirely optional for the payer. In other words, the payer may reject a transaction for any reasons and not offer any explanation at all. It is 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.

How to Use the Test Payers in the Sandbox API

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, which is unique for each response type. All IDs for API responses 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

How to use the test payer accounts for each Attachments API response type

1. Submit an attachment using the Attachments Submission API. Use a Test payer ID for each response type.
2. After 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 is configured for that payerId.
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 do not 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.

StatusCode Responses

StatusCode and StatusMessage Fields

The statusCode and statusMessage fields are a code pair that simply describe the current non-failure state of the attachment transaction. The message TRANSACTION_RECEIVED (statusCode 01) shows that the attachment's been received by the clearinghouse. For other messages included and for relevant examples, see Use Test Payers in Sandbox.

📘

NOTE

Select Attachments features are not yet supported by the sandbox standard responses. For more information, see Unsupported use cases.

Unsupported use cases

Metadata Search Error messages

The Attachment Status API /attachments/status/v1/metadata 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.

Unable to Process Errors message

For occasional problems in API operation, such as temporary connection problems, you will 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.