The CDex Profile elements consist of Mandatory, Must Support, and Optional elements. Elements that are neither Mandatory or Must Support are Optional. Mandatory elements are elements with a minimum cardinality greater than 0. [Must Support] elements are marked with the mustSupport flag and SHALL be interpreted as follows:

element is required and the Task Source SHALL populating the data element with value unless:

Source SHALL use that extension to communicate the reason for missing data.

• If the minimum cardinality of an element is equal to 0, the Task Source SHALL be capable of populating the data element when sharing Task compliant with a CDex profile. Although the system needs to demonstrate it is capable of populating and sharing of the element, it is acceptable to omit the element if the system doesn't have values in a particular instance. A system that is incapable of ever sharing the

• The Task Consumer SHALL be capable of processing Task instances

Systems may choose some or all of these capabilities and implement any combination of unsolicited or solicited attachments for prior authorization, claims, or both. Therefore, in contrast to the expectations in the CDex CapabilityStatements, they SHOULD define what they support in their local capability statement in one or more of the following ways:

The Da Vinci Burden Reduction Implementation Guides (IGs), [Da Vinci Coverage Requirements Discovery (CRD)], [Da Vinci Documentation Templates and Rules (DTR)], and [Da Vinci Prior Authorization Support (PAS)], support an integrated workflow to enable automated submission of required documentation and prior authorization from EHR and payer systems respectively. Although the PAS guide leverages CDex, implementers SHOULD follow the Burden Reduction IGs to request additional information for prior authorization. See [Using CDex Attachments with DaVinci PAS] page for more details.

data - and receivers SHOULD NOT reject instances that contain unexpected data elements if those elements are not [modifier elements]. However, Task Sources cannot rely on Task Consumers to store, process, or do anything other than ignore data that is not marked as mustSupport.

The CDex Profile elements consist of Mandatory, Must Support, and Optional elements. Elements that are neither Mandatory or Must Support are Optional. Mandatory elements are elements with a minimum cardinality greater than 0. [Must Support] elements are marked with the mustSupport flag and SHALL be interpreted as follows:

element is required and the Task Source SHALL populating the data element with value unless:

Source SHALL use that extension to communicate the reason for missing data.

• If the minimum cardinality of an element is equal to 0, the Task Source SHALL be capable of populating the data element when sharing Task compliant with a CDex profile. Although the system needs to demonstrate it is capable of populating and sharing of the element, it is acceptable to omit the element if the system doesn't have values in a particular instance. A system that is incapable of ever sharing the

• The Task Consumer SHALL be capable of processing Task instances

Systems may choose some or all of these capabilities and implement any combination of unsolicited or solicited attachments for prior authorization, claims, or both. Therefore, in contrast to the expectations in the CDex CapabilityStatements, they SHOULD define what they support in their local capability statement in one or more of the following ways:

The Da Vinci Burden Reduction Implementation Guides (IGs), [Da Vinci Coverage Requirements Discovery (CRD)], [Da Vinci Documentation Templates and Rules (DTR)], and [Da Vinci Prior Authorization Support (PAS)], support an integrated workflow to enable automated submission of required documentation and prior authorization from EHR and payer systems respectively. Although the PAS guide leverages CDex, implementers SHOULD follow the Burden Reduction IGs to request additional information for prior authorization. See [Using CDex Attachments with DaVinci PAS] page for more details.

• if multiple documents need to be signed, systems SHOULD minimize the number of interactions required by the user

data - and receivers SHOULD NOT reject instances that contain unexpected data elements if those elements are not [modifier elements]. However, Task Sources cannot rely on Task Consumers to store, process, or do anything other than ignore data that is not marked as mustSupport.

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.

• 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.