Da Vinci Clinical Data Exchange (CDex)
2.1.0 - STU 2.1

Publication Build: This will be filled in by the publication tooling

## CapabilityStatement: Data Source Client CapabilityStatement

Official URL: http://hl7.org/fhir/us/davinci-cdex/CapabilityStatement/data-source-client | Version: 2.1.0
Standards status: Trial-use | Maturity Level: 2 | Computable Name: DataSourceClientCapabilityStatement
Other Identifiers: OID:2.16.840.1.113883.4.642.40.21.13.4
Copyright/Legal: Used by permission of HL7 International all rights reserved Creative Commons License

This CapabilityStatement describes the expected capabilities of a Da Vinci CDex Data Source in Client mode during clinical data exchange with a Data Consumer. The capabilities include one or more of the following interactions:

1. Post the `$submit-attachment` operation to a Data Consumer endpoint.
2. Launch Da Vinci DTR.
3. Query for Authorization information represented by a CommunicationRequest or ServiceRequest.
4. Post a subscription notification to a Data Consumer endpoint updating the status of a task.

Raw OpenAPI-Swagger Definition file | Download

### SHOULD Support the Following Implementation Guides:

- Documentation Templates and Rules 2.1.0

### SHOULD Implement All Or Parts Of The Following Capability Statements:

- US Core Version 3.1.1 Client CapabilityStatement

- US Core Version 6.1.0 Client CapabilityStatement

- US Core Version 7.0.0 Client CapabilityStatement

### FHIR RESTful Capabilities

The Da Vinci CDex Data Source Client SHALL:

1. Support at least one of the CDex approaches for exchanging clinical information

   1. Task-Based Approach
   2. Attachments

2. Follow the guidelines for Generating and Verifying Signed Resources if signatures are required.

3. Support JSON source formats for all Da Vinci CDex interactions.

4. Declare a CapabilityStatement identifying transactions, and profiles supported.

   - Follow the guidelines for Conforming to CDex Attachments if supporting this exchange. The Da Vinci CDex Data Source Client MAY:

5. Support XML source formats for all Da Vinci CDex interactions.

   > Implementers that choose to support XML need to be aware that JSON Web Signatures can only be created and validated in the original native JSON. Transforms to and from XML will invalidate signatures.

Security:

1. For general security consideration refer to the FHIR Security and Privacy Considerations.
2. For security considerations specific to this guide refer to the Security and Privacy section.

Summary of System Wide Interactions

- MAY support the `transaction` interaction.
- MAY support the `batch` interaction.
- MAY support the `search-system` interaction.
- MAY support the `history-system` interaction.

Summary of System Wide Operations

- SHOULD support the `$submit-attachment` operation.

> If Attachments is supported, the Data Source Client SHALL support the `$submit-attachment` operation.

### RESTful Capabilities by Resource/Profile:

#### Summary

Resource Type | Supported Profiles | Supported Searches | Supported `_includes` | Supported `_revincludes` | Supported Operations
--- | --- | --- | --- | --- | ---
CommunicationRequest | - | - | - | - | -
DocumentReference | , , | - | - | - | -
Parameters | - | - | - | - | -
QuestionnaireResponse | CDex SDC QuestionnaireResponse Profile | - | - | - | -
ServiceRequest | - | - | - | - | -

#### CommunicationRequest

Conformance Expectation: SHOULD

Resource Specific Documentation:

> Required resource type to carry authorization information regarding for requesting Clinical information

Profile Interaction Summary:

- SHOULD support `read`†, `vread`.
- MAY support `create`, `search-type`, `update`, `patch`, `delete`, `history-instance`, `history-type`.

> read†

> Either a CommunicationRequest or ServiceRequest is required if an Authorization is required for a particular clinical data exchange scenario

Fetch and Search Criteria:

- A Client SHOULD be capable of fetching a CommunicationRequest resource using: `GET [base]/CommunicationRequest/[id]`

#### DocumentReference

Conformance Expectation: SHOULD

Resource Specific Documentation:

> Required resource type to support the `$submit-attachment` operation

Supported Profiles:

- SHALL support:
- SHALL support:
- SHALL support:

Profile Interaction Summary:

- SHOULD support `read`, `vread`, `update`.
- MAY support `create`, `search-type`, `patch`, `delete`, `history-instance`, `history-type`.

Fetch and Search Criteria:

- A Client SHOULD be capable of fetching a DocumentReference resource using: `GET [base]/DocumentReference/[id]`

#### Parameters

Conformance Expectation: SHOULD

Resource Specific Documentation:

> Required resource type to support the `$submit-attachment` operation

Profile Interaction Summary:

- SHOULD support `create`, `read`, `vread`, `update`.
- MAY support `search-type`, `patch`, `delete`, `history-instance`, `history-type`.

Fetch and Search Criteria:

- A Client SHOULD be capable of fetching a Parameters resource using: `GET [base]/Parameters/[id]`

#### QuestionnaireResponse

Conformance Expectation: SHOULD

Resource Specific Documentation:

> Required resource type to support the `$submit-attachment` operation for Requesting Attachments Using Questionnaires. SHALL* support CDex SDC QuestionnaireResponse Profile for signed QuestionnaireResponse.

Supported Profiles:

- SHOULD support: CDex SDC QuestionnaireResponse Profile

Profile Interaction Summary:

- SHOULD support `read`, `vread`, `update`.
- MAY support `create`, `search-type`, `patch`, `delete`, `history-instance`, `history-type`.

Fetch and Search Criteria:

- A Client SHOULD be capable of fetching a QuestionnaireResponse resource using: `GET [base]/QuestionnaireResponse/[id]`

#### ServiceRequest

Conformance Expectation: SHOULD

Resource Specific Documentation:

> Required resource type to carry authorization information regarding for requesting Clinical information

Profile Interaction Summary:

- SHOULD support `search-type`, `read`†, `vread`.
- MAY support `create`, `update`, `patch`, `delete`, `history-instance`, `history-type`.

> read†

> Either a CommunicationRequest or ServiceRequest is required if an Authorization is required for a particular clinical data exchange scenario

Fetch and Search Criteria:

- A Client SHOULD be capable of fetching a ServiceRequest resource using: `GET [base]/ServiceRequest/[id]`