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:
| Attachment | Definition |
|---|---|
| Unsolicited | Voluntarily sent by the provider without a request by the payer. |
| Solicited | Sent in response to a request by the payer for more information about a medical claim. |
Some payers will be configured for only unsolicited or solicited attachments, while some can handle both.
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 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
payerFaxNumberorpayerAddress. - 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
payerFaxNumberorpayerAddress.
Updated 1 day ago