When signatures are required, the Data Consumer SHALL use a [FHIR RESTful search] instead of [FHIR RESTful read]. There is no CDex support for signatures on a FHIR RESTful read because it fetches a single instance of a resource instead of a Bundle. If the Data Consumer attempts to fetch a resource with a read and a signature is required, the Data Source/Responder

The [Da Vinci] initiative supports this implementation guide. Da Vinci is a private effort to accelerate the adoption of Health Level Seven International Fast Healthcare Interoperability Resources (HL7® FHIR®) as the standard to support and integrate value-based care (VBC) data exchange across communities. This guide and implementers of it SHALL adhere to the [HL7 Da Vinci Guiding Principles] for exchanging patient health information.

This implementation guide inherits all of the mandatory requirements and recommendations defined in the [HRex Security and Privacy] specification. Implementers SHALL read and adhere to the guidance for the following topics:

1. User scopes SHALL be used as defined in [SMART App Launch] to restrict access to the relevant patients for a given Data Consumer. Organizational user access scopes are typically pre-negotiated and documented via business agreements. Data Sources shall translate these agreements into the appropriate SMART App Launch scopes.

1. Audit mechanisms SHALL be in place so that exchange mechanisms with or without human intervention can be subject to review/oversight.

communicate the POU for the requested data for each Task using codes from the [CDex Purpose of Use Value Set] in the POU Task.input element. The Data Consumer and Data Source SHALL use it to communicate the POU for the requested data when trading partner agreements require the POU to be exchanged.</span><!-- new-content -->

For CDex Task-based transactions, the [CDex Task Data Request Profile] SHALL be used by the Data Consumer to solicit information from a system. It represents both the data request and the returned data and provides information such as why it needs to be completed, who is to complete it, who is asking for it, when it is due, etc. The Task's status is updated as the task is fulfilled. For a detailed description of all the mandatory, [must support], and optional elements, as well as formal definitions and profile views, see the [CDex Task Data Request Profile] page.

When known, Task.reasonCode or Task.reasonReference SHALL reference the object that directly leads to the task - a particular claim, for example.

Clients SHALL support all four profiles.

do not define the detailed POU, and the implementer SHALL supply an additional, alternate code. The resource fragment below shows their use:

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:

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:

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.

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

• 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

• The Task Consumer SHALL be capable of processing Task instances

The use of CDex SHALL NOT be considered compliant with any use case specific IG where CDex is not explicitly required as part of the supported exchanges.

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:

|Attachment.Code||{{OK}}(It SHOULD be present when submitting unsolicited attachments)|

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 consumers can poll for a single Task or across several Tasks. The polling frequency balances responsiveness (short interval between data creation and consumer notification) against not over-taxing the Data Source's resources. Data Consumers SHOULD perform this operation in an automated/background manner after 1 minute to return automated responses and no more than every 5 minutes for the first 30 minutes and no more frequently than once every hour after that.

CDex Task-based transactions have many optional capabilities. Systems may choose some or all of these capabilities and implement any combination. Refer to the CDex [CapabilityStatements] resources for conformance expectations for the various actors and roles. In contrast to the expectations in the CDex CapabilityStatements, Systems SHOULD define what they support in their local capability statement in one or more of the following ways:

• An alternative is needed to cover some aspects of an exchange. For example, suppose the provider's data release process does not allow the automatic request for information specified in a use case specific IG. In that case, CDex provides an asynchronous process that allows manual review before releasing the information. However, implementers SHOULD NOT use this transaction when there is a requirement for real-time response to facilitate patient care.

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.

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.

<span class="bg-success" markdown="1">CDex Task-based queries enable Data Consumers to dynamically define POUs when requesting data. Data Consumer and Data Source MAY communicate the POU for the requested data for each Task using codes from the [CDex Purpose of Use Value Set] in the POU Task.input element. The Data Consumer and Data Source