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 Consumer Server CapabilityStatement

Official URL: http://hl7.org/fhir/us/davinci-cdex/CapabilityStatement/data-consumer-server | Version: 2.1.0
Standards status: Trial-use | Maturity Level: 2 | Computable Name: DataConsumerServerCapabilityStatement
Other Identifiers: OID:2.16.840.1.113883.4.642.40.21.13.3
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 Consumer in Server mode when responding to a Data Source or one of its proxies during clinical data exchange. The capabilities include one or more of the following interactions:

1. Responding to a query for authorization information represented by a CommunicationRequest or ServiceRequest
2. Responding to the `$submit-attachment` operation.

Raw OpenAPI-Swagger Definition file | Download

### SHOULD Support the Following Implementation Guides:

- HL7 FHIR® US Core Implementation Guide STU3 Release 3.1.1

- HL7 FHIR® US Core Implementation Guide STU3 Release 6.1.0

- HL7 FHIR® US Core Implementation Guide STU3 Release 7.0.0

- Da Vinci Health Record Exchange (HRex) 1.1.0 - STU 1.1

### FHIR RESTful Capabilities

The Da Vinci CDex Data Consumer Server 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 the scenarios, transactions and profiles supported.
   - Follow the guidelines for Conforming to CDex Attachments if supporting this exchange.

The Da Vinci CDex Data Consumer Server MAY:

1. 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 Consumer Server 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 `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 Server SHOULD be capable of returning 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 `create`, `read`, `vread`, `update`.
- MAY support `search-type`, `patch`, `delete`, `history-instance`, `history-type`.

Fetch and Search Criteria:

- A Server SHOULD be capable of returning 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 `search-type`, `read`, `vread`.
- MAY support `create`, `update`, `patch`, `delete`, `history-instance`, `history-type`.

Fetch and Search Criteria:

- A Server SHOULD be capable of returning 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 `search-type`, `read`, `vread`.
- MAY support `create`, `update`, `patch`, `delete`, `history-instance`, `history-type`.

Fetch and Search Criteria:

- A Server SHOULD be capable of returning 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 Server SHOULD be capable of returning a ServiceRequest resource using: `GET [base]/ServiceRequest/[id]`