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.

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

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:

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.

Figure 8 below illustrates a "typical" state machine for CDex Task. The Data Consumer creates the Task with a status of "requested". The Data Source updates the status of the Task as appropriate. The Data Source SHALL support all the statuses in the [HRex Task Status ValueSet]. The Data Source

Da Vinci CDex Data Sources who choose to support Subscription SHALL comply with the [Subscription R5 Backport Implementation Guide] and the Da Vinci Health Record Exchange (HRex) Subscription requirements for subscribing to Task updates. These implementation guides "pre-adopt" the FHIR R5 topic-based subscription approach in R4 implementations since most U.S. EHR vendors have agreed to support it.

• The Data Source SHALL support the HRex Task Subscription Topic and

• The Data Source SHALL support discovery of the CDex Task Update Subscription Topic canonical URL

The Task.reasonReference DocumentReference.author is a *Must Support element with four target profile and three Coverage profiles. Servers SHALL support at least one of them, and when supporting a Coverage profile

support at least one of them, and when supporting a Coverage profile, SHALL support the Coverage Profile based on the US Core version 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:

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

• The Data Source SHOULD support discovery using the CapabilityStatement SubscriptionTopic Canonical extension and

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:

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

support all the statuses in the [HRex Task Status ValueSet]. The Data Source MAY support additional transitions, including transitions from terminal states (e.g., back to "in-progress" from "failed" or "completed"). The Data Source

support additional transitions, including transitions from terminal states (e.g., back to "in-progress" from "failed" or "completed"). The Data Source MAY use [Task.businessStatus] to track intermediate business statuses for their specific implementation

support the HRex Task Subscription Topic and MAY support other subscription topics

support discovery using the CapabilityStatement SubscriptionTopic Canonical extension and MAY support discovery by some other method