CDex Data Source servers SHALL support resolving logical identifiers for the Patient resource.

If the Data Consumer attempts to fetch a resource with a read and a signature is required, the Data Source/Responder SHALL return an HTTP 400 Bad Request and an OperationOutcome describing the business rule error.

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.

Implementers SHALL read and adhere to the guidance for the following topics in the HRex Security and Privacy:^{[§][CONF-014]}

• Da Vinci's Guiding Principles
• Statutes, Regulations
• Clinical Safety Guidelines
• FHIR Security and Implementation Guidance
• Security/Privacy-Related Technologies, Including Explicit Consent and Security - Labels
• Exchange Security
• Additionally Protected Information
• Security Contexts for Da Vinci IGs

User scopes SHALL be used as defined in SMART App Launch to restrict access to the relevant patients for a given Data Consumer.

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

The Data Consumer and Data Source SHALL use it [codes from the CDex Purpose of Use Value Set in the POU Task.input element.] to communicate the POU for the requested data when trading partner agreements require the POU to be exchanged.

The Data Source SHALL support all the statuses in the HRex Task Status ValueSet.

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.

Da Vinci CDex Data Sources who choose to support Subscription ...SHALL support the HRex Task Subscription Topic….

Da Vinci CDex Data Sources who choose to support Subscription ...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 ….

The Task.reasonReference DocumentReference.author is a Must Support element with four target profile and three Coverage profiles ... when supporting a Coverage profile, SHALL support the Coverage Profile based on the US Core version [they are supporting].

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

Must Support elements are marked with the mustSupport flag and SHALL be interpreted [by the Task Source and Task Consumer] as follows in CONF-088, CONF-090, CONF-092, CONF-094, CONF-096.

Must Support elements are marked with the mustSupport flag and SHALL be interpreted [by the Task Source and Task Consumer] as follows in CONF-089, CONF-091, CONF-093, CONF-095, CONF-097.

[for Must Support elements are marked with the mustSupport flag and ] the minimum cardinality of an element is greater than 0, the element is required and the Task Source SHALL populatie the data element with a value unless {CONF-091].

[for Must Support elements are marked with the mustSupport flag and ] the minimum cardinality of an element is greater than 0, the element is required and the Task Source SHALL populatie the data element with a value unless {CONF-091].

[For Must Support elements are marked with the mustSupport flag and ] the minimum cardinality of an element is greater than 0, the element is required unless the profile references a dataAbsentReason (DAR) extension, then the Task Source SHALL use that extension to communicate the reason for missing data.

[For Must Support elements are marked with the mustSupport flag and ] the minimum cardinality of an element is greater than 0, the element is required unless the profile references a dataAbsentReason (DAR) extension, then the Task Source SHALL use that extension to communicate the reason for missing data.

[For Must Support elements marked with the mustSupport flag and ] 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.

[For Must Support elements marked with the mustSupport flag and ] 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.

[ For Must Support elements are marked with the mustSupport flag , the] ... Task Consumer SHALL be capable of processing Task instances containing the data elements without generating an error or causing the application to fail.

[ For Must Support elements are marked with the mustSupport flag , the] ... Task Consumer SHALL be capable of processing Task instances containing the data elements without generating an error or causing the application to fail.

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 ...SHOULD define what they support in their local capability statement in one or more of the following ways:

1. (Preferred) Formally derived implementable profile from CDex Task Attachment Request Profile
2. Document their systems' capabilities for requesting attachments in CapabilityStatement.rest.resource.documentation for the Task resource.
3. (Preferred) Formal OperationDefinition derived from $submit-attachment
4. Document their systems' capabilities for submitting attachments in CapabilityStatement.rest.documentation

When submitting unsolicited attachments [using the $submit-attachment operation], the [Data Source/]Provider SHOULD populate Attachment.Code[parameter].

CDex Data Source servers SHOULD support the patient match operation and declare it in their CapabilityStatement.

To the extent that the Data Source keeps a record of the provenance of the data, the FHIR Provenance Resource can be requested as documented on US Core's Basic Provenance page. When returning provenance, they SHOULD use the HRex Provenance Profile.

Although the PAS guide leverages CDex, implementers SHOULD follow the Burden Reduction IGs to request additional information for prior authorization.

Da Vinci CDex Data Sources who choose to support Subscription ... SHOULD support discovery using the CapabilityStatement SubscriptionTopic Canonical extension and

Systems SHOULD define what they support in their local capability statement in one or more of the following ways:

1. (Preferred) Formally derived implementable profile from [CDex Task Data Request Profile] (StructureDefinition-cdex-task-data-request.html)
2. Document their systems' capabilities for requesting attachments in CapabilityStatement.rest.resource.documentation for the Task resource.
3. (Preferred) Formal OperationDefinition derived from $submit-attachment
4. Document their systems' capabilities for submitting attachments in CapabilityStatement.rest.documentation

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

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

CDex is not intended to supersede other Da Vinci guides, which focus on a particular use case and define how to share clinical information. However, CDex may be used to request clinical data from a provider when 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 Consumers] ...SHOULD NOT reject instances that contain unexpected data elements if those elements are not modifier elements.

[Data Consumers] ...SHOULD NOT reject instances that contain unexpected data elements if those elements are not modifier elements.

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 Source MAY support additional transitions [than shwn in the CDex State Diagram], 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.

Da Vinci CDex Data Sources who choose to support Subscription ... MAY support other subscription topics [in addtion to the HRex Task Subscription Topic].

Da Vinci CDex Data Sources who choose to support Subscription … MAY support discovery by some other method.

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.