Da Vinci Clinical Data Exchange (CDex)
2.1.0 - STU 2.1 United States of America flag

Da Vinci Clinical Data Exchange (CDex), published by HL7 International / Payer/Provider Information Exchange Work Group. This guide is not an authorized publication; it is the continuous build for version 2.1.0 built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/HL7/davinci-ecdx/ and changes regularly. See the Directory of published versions

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:

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.

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:

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:

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]