Attachment Submission API Use Cases and Results

📘

NOTE

The examples described in this topic apply to electronic payers; for example, payers that support submissions of attachments electronically through an API.

Submitting attachments has two significant use cases:

Some payers will be configured for only unsolicited or solicited attachments, while some can handle both.

Some payers support the electronic submission of medical documentation attachments, while some support only fax and mailing of attachments or even limit submissions to mail only. Optum works with a print/fax service facility to manage any electronic submissions that must be provided as hardcopy to specific payers. It means that all attachment submissions can be done electronically using our APIs and transactions sent for print/fax-only payers will still be handled correctly. However, correct address and fax number information is an absolute requirement for these submissions.

Optum also performs some support for unusual exceptions, such as the case where an administrator at the payer office requests an attachment (hence soliciting an attachment) but the payer is only configured to handle unsolicited attachments through the clearinghouse.

Permutations of these use cases apply when you combine solicited and unsolicited transaction states with the type of payer as the recipient. In some cases, Optum will perform error checking before forwarding any attachment content or may route attachments differently from what the submitter expects. Examples of these transaction cases and their outcomes include the following:

• A submission of a solicited attachment with address/fax information, for an electronic payer configured only for unsolicited attachments: attachment will be processed by print/fax.

• A submission of an unsolicited attachment with address/fax information, for an electronic payer configured only for solicited attachments: attachment will be processed by print/fax.

• A submission of a solicited attachment with or without address/fax information, for an electronic payer configured only for solicited attachments: attachment will be processed electronically. Address/fax information is not required for electronic payer submissions.

• A submission of an unsolicited attachment with or without address/fax information, for an electronic payer configured only for unsolicited attachments: attachment will be processed electronically. Address/fax information is not required for electronic payer submissions.

• A submission of an unsolicited OR solicited attachment with or without address/fax information, for an electronic payer that can handle both solicited and unsolicited attachments: attachments will be processed electronically. This is the most forgiving use case.

Two specific use cases receive validation error messages from the API:

• A submission of a solicited attachment without address/fax information, for an electronic payer configured for unsolicited attachments: the Attachment Submissions API returns a validation error. It reads: Trading partner not established for unsolicited attachments, please provide a payerFaxNumber or payerAddress.
• A submission of an unsolicited attachment without address/fax information, for an electronic payer configured only for solicited attachments: the Attachment Submissions API returns a validation error. It reads: Trading partner not established for solicited attachments, please provide a payerFaxNumber or payerAddress.