Da Vinci Clinical Data Exchange (CDex)
2.1.0-preview - CI Build 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-preview 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 Source Client CapabilityStatement

Official URL: http://hl7.org/fhir/us/davinci-cdex/CapabilityStatement/data-source-client Version: 2.1.0-preview
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

Data Source Client CapabilityStatement

  • Title:Data Source Client CapabilityStatement
  • Implementation Guide Version: 2.1.0-preview
  • FHIR Version: 4.0.1
  • Intended Use: requirements
  • Supported Formats: SHALL support json; MAY support xml;
  • Published: 2024-04-23 10:37:58-0800
  • Published by: HL7 International / Payer/Provider Information Exchange Work Group
  • Status: active
  • Copyright:

    Used by permission of HL7 International all rights reserved Creative Commons License


Description:

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.

Support and Requirements for Other Artifacts

Instantiates other capabilities: Supports other guides:

Jump to:


FHIR client 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.

  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.

System-wide client Capabilities

Interactions

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

Operations

  • SHOULD support the submit-attachment+ operation.
+submit-attachment

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

Summary of Resource/Profile Capabilities

Resource Type Supported Interactions Supported Profiles Supported Searches Supported _includes Supported _revincludes Supported Operations
CommunicationRequest create, search-type, read, vread, update, patch, delete, history-instance, history-type,
DocumentReference create, search-type, read, vread, update, patch, delete, history-instance, history-type, US Core DocumentReference Profile,
Parameters create, search-type, read, vread, update, patch, delete, history-instance, history-type,
QuestionnaireResponse create, search-type, read, vread, update, patch, delete, history-instance, history-type, CDex SDC QuestionnaireResponse Profile,
ServiceRequest create, search-type, read, vread, update, patch, delete, history-instance, history-type,

RESTful client Capabilities by Resource/Profile:

CommunicationRequest

Conformance Expectation: SHOULD

Resource Specific Documentation:

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


Modify Criteria:

  • A client MAY be capable of a create interaction posting a CommunicationRequest resource using: POST [base]/CommunicationRequest/[id]{?_format=[mime-type]}
  • A client MAY be capable of putting a existing CommunicationRequest resource using: PUT [base]/CommunicationRequest/[id]{?_format=[mime-type]}
  • A client MAY be capable of patching an existing CommunicationRequest resource using: PATCH [base]/CommunicationRequest/[id]{?_format=[mime-type]}
  • A client MAY be capable of deleting a CommunicationRequest resource using: DELETE [base]//[id]

Fetch and Search Criteria:

  • A client MAY be capable of a search-type interaction fetching CommunicationRequest resources matching a search query using: GET [base]/CommunicationRequest/[id]{?[parameters]{&_format=[mime-type]}}
  • A client SHOULD be capable of a read interaction fetching a CommunicationRequest resource using: GET [base]/CommunicationRequest/[id]
  • A client SHOULD be capable of a vread interaction fetching a CommunicationRequest resource using: GET [base]/CommunicationRequest/[id]/_history/vid
  • A client MAY be capable of a history-instance interaction fetching a history of a CommunicationRequest using: GET [base]/CommunicationRequest/[id]/_history{?[parameters]&_format=[mime-type]}
  • A client MAY be capable of a history-type interaction fetching the history of CommunicationRequest resources using: GET [base]/CommunicationRequest/_history{?[parameters]&_format=[mime-type]}

DocumentReference

Conformance Expectation: SHOULD

Resource Specific Documentation:

Required resource type to support the $submit-attachment operation

Supported Profiles:


Modify Criteria:

  • A client MAY be capable of a create interaction posting a DocumentReference resource using: POST [base]/DocumentReference/[id]{?_format=[mime-type]}
  • A client SHOULD be capable of putting a existing DocumentReference resource using: PUT [base]/DocumentReference/[id]{?_format=[mime-type]}
  • A client MAY be capable of patching an existing DocumentReference resource using: PATCH [base]/DocumentReference/[id]{?_format=[mime-type]}
  • A client MAY be capable of deleting a DocumentReference resource using: DELETE [base]//[id]

Fetch and Search Criteria:

  • A client MAY be capable of a search-type interaction fetching DocumentReference resources matching a search query using: GET [base]/DocumentReference/[id]{?[parameters]{&_format=[mime-type]}}
  • A client SHOULD be capable of a read interaction fetching a DocumentReference resource using: GET [base]/DocumentReference/[id]
  • A client SHOULD be capable of a vread interaction fetching a DocumentReference resource using: GET [base]/DocumentReference/[id]/_history/vid
  • A client MAY be capable of a history-instance interaction fetching a history of a DocumentReference using: GET [base]/DocumentReference/[id]/_history{?[parameters]&_format=[mime-type]}
  • A client MAY be capable of a history-type interaction fetching the history of DocumentReference resources using: GET [base]/DocumentReference/_history{?[parameters]&_format=[mime-type]}

Parameters

Conformance Expectation: SHOULD

Resource Specific Documentation:

Required resource type to support the $submit-attachment operation


Modify Criteria:

  • A client SHOULD be capable of a create interaction posting a Parameters resource using: POST [base]/Parameters/[id]{?_format=[mime-type]}
  • A client SHOULD be capable of putting a existing Parameters resource using: PUT [base]/Parameters/[id]{?_format=[mime-type]}
  • A client MAY be capable of patching an existing Parameters resource using: PATCH [base]/Parameters/[id]{?_format=[mime-type]}
  • A client MAY be capable of deleting a Parameters resource using: DELETE [base]//[id]

Fetch and Search Criteria:

  • A client MAY be capable of a search-type interaction fetching Parameters resources matching a search query using: GET [base]/Parameters/[id]{?[parameters]{&_format=[mime-type]}}
  • A client SHOULD be capable of a read interaction fetching a Parameters resource using: GET [base]/Parameters/[id]
  • A client SHOULD be capable of a vread interaction fetching a Parameters resource using: GET [base]/Parameters/[id]/_history/vid
  • A client MAY be capable of a history-instance interaction fetching a history of a Parameters using: GET [base]/Parameters/[id]/_history{?[parameters]&_format=[mime-type]}
  • A client MAY be capable of a history-type interaction fetching the history of Parameters resources using: GET [base]/Parameters/_history{?[parameters]&_format=[mime-type]}

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:


Modify Criteria:

  • A client MAY be capable of a create interaction posting a QuestionnaireResponse resource using: POST [base]/QuestionnaireResponse/[id]{?_format=[mime-type]}
  • A client SHOULD be capable of putting a existing QuestionnaireResponse resource using: PUT [base]/QuestionnaireResponse/[id]{?_format=[mime-type]}
  • A client MAY be capable of patching an existing QuestionnaireResponse resource using: PATCH [base]/QuestionnaireResponse/[id]{?_format=[mime-type]}
  • A client MAY be capable of deleting a QuestionnaireResponse resource using: DELETE [base]//[id]

Fetch and Search Criteria:

  • A client MAY be capable of a search-type interaction fetching QuestionnaireResponse resources matching a search query using: GET [base]/QuestionnaireResponse/[id]{?[parameters]{&_format=[mime-type]}}
  • A client SHOULD be capable of a read interaction fetching a QuestionnaireResponse resource using: GET [base]/QuestionnaireResponse/[id]
  • A client SHOULD be capable of a vread interaction fetching a QuestionnaireResponse resource using: GET [base]/QuestionnaireResponse/[id]/_history/vid
  • A client MAY be capable of a history-instance interaction fetching a history of a QuestionnaireResponse using: GET [base]/QuestionnaireResponse/[id]/_history{?[parameters]&_format=[mime-type]}
  • A client MAY be capable of a history-type interaction fetching the history of QuestionnaireResponse resources using: GET [base]/QuestionnaireResponse/_history{?[parameters]&_format=[mime-type]}

ServiceRequest

Conformance Expectation: SHOULD

Resource Specific Documentation:

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


Modify Criteria:

  • A client MAY be capable of a create interaction posting a ServiceRequest resource using: POST [base]/ServiceRequest/[id]{?_format=[mime-type]}
  • A client MAY be capable of putting a existing ServiceRequest resource using: PUT [base]/ServiceRequest/[id]{?_format=[mime-type]}
  • A client MAY be capable of patching an existing ServiceRequest resource using: PATCH [base]/ServiceRequest/[id]{?_format=[mime-type]}
  • A client MAY be capable of deleting a ServiceRequest resource using: DELETE [base]//[id]

Fetch and Search Criteria:

  • A client SHOULD be capable of a search-type interaction fetching ServiceRequest resources matching a search query using: GET [base]/ServiceRequest/[id]{?[parameters]{&_format=[mime-type]}}
  • A client SHOULD be capable of a read interaction fetching a ServiceRequest resource using: GET [base]/ServiceRequest/[id]
  • A client SHOULD be capable of a vread interaction fetching a ServiceRequest resource using: GET [base]/ServiceRequest/[id]/_history/vid
  • A client MAY be capable of a history-instance interaction fetching a history of a ServiceRequest using: GET [base]/ServiceRequest/[id]/_history{?[parameters]&_format=[mime-type]}
  • A client MAY be capable of a history-type interaction fetching the history of ServiceRequest resources using: GET [base]/ServiceRequest/_history{?[parameters]&_format=[mime-type]}