This operation is used to submit attachments (aditional information) for Claims or Prior Authorization. This operation accepts the clinical/administrative attachments and the necessary information needed to re-associate them to the claim or prior authorization, and returns a transaction layer HTTP response. This operation can be used by any HTTP endpoint, not just FHIR RESTful servers.

The input parameters are:

1. One or more Attachments as FHIR Resources
2. Data elements for reassociation to the Claim/Prior Authorization
   • What is the documentation for:
     • Claim
     • Prior Authorization
   • A unique claim/prior authorization identifier (referred to as the "re-association tracking control numbers")*
   • Optionally, one or more unique claim line item identifiers
   • A unique organization/location identifier (e.g., NPI)
   • A unique provider identifier (e.g., NPI)
   • A unique Patient member identifier
   • Date of Service

There are no output parameters.

*Note that an Unsolicited Claim attachment implies that the provider assigns the tracking control number on the claim and also on the submitted attachments for that claim for re-association. Solicited Claim attachments are when the payer assigns the Claim control number and sends the provider a request for additional information for that specific claim. Similarly for Prior Authorization, the prior auth identifier is provider assigned when the attachments are sent upon prior auth generation, and the prior auth identifier is the payer assigned control number when the attachments are in response to a request for additional information by the payer.

The following rules apply when using $submit-attachment:

• The operation only accepts POST transactions - any other HTTP method will result in an HTTP error
• The ServiceDate parameter SHALL be present and precise to the day if the attachment is for a claim. It is optional if the attachment is for a prior authorization.
• For the Attachment parameter, Servers SHALL support DocumentReference resource type and SHOULD support other types.
  • The DocumentReference resources can represent the referenced content using either an address where the document can be retrieved using DocumentReference.attachment.url or the content as inline base64 encoded data using DocumentReference.attachment.data. The server system is not required to support both an address and inline base64 encoded data, but SHALL support at least one of these elements.
  • These capabilities SHOULD be discoverable and documented by the server (for example, in the CapabilityStatement for FHIR Servers).
• When processing messages, a server may return one of several status codes:
  • 200 OK: Indicates that the server has accepted the clinical attachments.
  • 4xx: Indicates some error in the submission. The client SHOULD interpret a 4xx response to indicate that there is no point resubmitting the unaltered operation,
  • 5xx: Indicates some system error. The client SHOULD interpret a 5xx response to indicate an unexpected error occurred on the part of the server, with the implication that it may be appropriate to resubmit the original operation.
  • The server MAY return an OperationOutcome with additional information, and SHOULD do so if the response code is 400 or greater. For example, if the payer has no knowledge of the claim or prior authorization, the OperationOurtcome can alert submitter to check whether they sent it to the wrong payer.

See the Attachments page for additional guidance and examples.