This Task.input element represents the service date or the service's starting date for the claim or prior authorization. If the attachment is for a claim, it SHALL be present and precise to the day. It is optional if the attachment is for a prior authorization.

1. Servers SHALL document in their Capability Statement's CapabilityStatement,operation.documentation element or payer-supplied documentation:

1. When the payload is too big, the Server SHALL use The HTTP 413 Content Too Large client error response status code (alternate status messages "Request Entity Too Large" or "Payload Too Large").

1. Servers SHALL document instructions for the Client when the payload is (or is anticipated to be) too big. (for example, send a URL + authorization information, offload to external storage, split multiple files into multiple operations)

• If the signatures fail verification when processing the [$submit-attachment] operation, the Data Source/Responder SHALL return an HTTP 400 Bad Request and an OperationOutcome declaring that the signature was invalid.

• A "ServiceDate" Task.input element representing the date of service or starting date of the service for the claim or prior authorization. It SHALL be present if the attachment is for a claim.

For CDex attachment requests transactions, the Payer SHALL use the [CDex Task Attachment Request Profile] to solicit information from a Provider.

For CDex attachment requests transactions, the Payer SHALL use the [CDex Task Attachment Request Profile] to solicit information from a Provider.

|Attachment.Content|{{OK}}(DocumentReference, QuestionnaireResponse if support Requesting Attachments Using Questionnaire|{{OK}}(Servers SHOULD support other FHIR types)|

• The Payer SHOULD return an informational OperationOutcome with the HTTP accept response if the attachments can not be associated with a current claim or prior authorization and are being held for association with a future claim or prior authorization. An OperationOutcome example is used in Scenario 1b below.