Da Vinci Clinical Data Exchange (CDex)
2.1.0-snapshot - CI Build United States of America flag

This page is part of the Da Vinci Clinical Documentation Exchange (v2.1.0-snapshot: QA Preview) based on FHIR (HL7® FHIR® Standard) R4. The current version which supersedes this version is 2.1.0. For a full list of available versions, 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-snapshot
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

Data Consumer Server CapabilityStatement

  • Title:Data Consumer Server CapabilityStatement
  • Implementation Guide Version: 2.1.0-snapshot
  • FHIR Version: 4.0.1
  • Intended Use: Requirements
  • Supported Formats: SHALL support json; MAY support xml;
  • Supported Patch Formats: MAY support application/json-patch+json;
  • Published: 2024-09-10 15:05:28-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 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.

Support and Requirements for Other Artifacts

Supports other guides:

Jump to:


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

System-wide Server 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 Consumer Server 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 Profileversion: null3.1.1), US Core DocumentReference Profileversion: null6.1.0), US Core DocumentReference Profileversion: null7.0.0),
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 Profileversion: null2.1.0-snapshot),
ServiceRequest create, search-type, read, vread, update, patch, delete, history-instance, history-type,

RESTful Server 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 Server MAY be capable of a create interaction creating a CommunicationRequest resource using: POST [base]/CommunicationRequest/[id]{?_format=[mime-type]}
  • A Server MAY be capable of updating a existing CommunicationRequest resource using: PUT [base]/CommunicationRequest/[id]{?_format=[mime-type]}
  • A Server MAY be capable of patching an existing CommunicationRequest resource using: PATCH [base]/CommunicationRequest/[id]{?_format=[mime-type]}
  • A Server MAY be capable of deleting a CommunicationRequest resource using: DELETE [base]//[id]

Fetch and Search Criteria:

  • A Server SHOULD be capable of a search-type interaction returning CommunicationRequest resources matching a search query using: GET [base]/CommunicationRequest/[id]{?[parameters]{&_format=[mime-type]}}
  • A Server SHOULD be capable of a read interaction returning a CommunicationRequest resource using: GET [base]/CommunicationRequest/[id]
  • A Server SHOULD be capable of a vread interaction returning a CommunicationRequest resource using: GET [base]/CommunicationRequest/[id]/_history/vid
  • A Server MAY be capable of a history-instance interaction returning a history of a CommunicationRequest using: GET [base]/CommunicationRequest/[id]/_history{?[parameters]&_format=[mime-type]}
  • A Server MAY be capable of a history-type interaction returning 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 Server SHOULD be capable of a create interaction creating a DocumentReference resource using: POST [base]/DocumentReference/[id]{?_format=[mime-type]}
  • A Server SHOULD be capable of updating a existing DocumentReference resource using: PUT [base]/DocumentReference/[id]{?_format=[mime-type]}
  • A Server MAY be capable of patching an existing DocumentReference resource using: PATCH [base]/DocumentReference/[id]{?_format=[mime-type]}
  • A Server MAY be capable of deleting a DocumentReference resource using: DELETE [base]//[id]

Fetch and Search Criteria:

  • A Server MAY be capable of a search-type interaction returning DocumentReference resources matching a search query using: GET [base]/DocumentReference/[id]{?[parameters]{&_format=[mime-type]}}
  • A Server SHOULD be capable of a read interaction returning a DocumentReference resource using: GET [base]/DocumentReference/[id]
  • A Server SHOULD be capable of a vread interaction returning a DocumentReference resource using: GET [base]/DocumentReference/[id]/_history/vid
  • A Server MAY be capable of a history-instance interaction returning a history of a DocumentReference using: GET [base]/DocumentReference/[id]/_history{?[parameters]&_format=[mime-type]}
  • A Server MAY be capable of a history-type interaction returning 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 Server MAY be capable of a create interaction creating a Parameters resource using: POST [base]/Parameters/[id]{?_format=[mime-type]}
  • A Server MAY be capable of updating a existing Parameters resource using: PUT [base]/Parameters/[id]{?_format=[mime-type]}
  • A Server MAY be capable of patching an existing Parameters resource using: PATCH [base]/Parameters/[id]{?_format=[mime-type]}
  • A Server MAY be capable of deleting a Parameters resource using: DELETE [base]//[id]

Fetch and Search Criteria:

  • A Server SHOULD be capable of a search-type interaction returning Parameters resources matching a search query using: GET [base]/Parameters/[id]{?[parameters]{&_format=[mime-type]}}
  • A Server SHOULD be capable of a read interaction returning a Parameters resource using: GET [base]/Parameters/[id]
  • A Server SHOULD be capable of a vread interaction returning a Parameters resource using: GET [base]/Parameters/[id]/_history/vid
  • A Server MAY be capable of a history-instance interaction returning a history of a Parameters using: GET [base]/Parameters/[id]/_history{?[parameters]&_format=[mime-type]}
  • A Server MAY be capable of a history-type interaction returning 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 Server MAY be capable of a create interaction creating a QuestionnaireResponse resource using: POST [base]/QuestionnaireResponse/[id]{?_format=[mime-type]}
  • A Server MAY be capable of updating a existing QuestionnaireResponse resource using: PUT [base]/QuestionnaireResponse/[id]{?_format=[mime-type]}
  • A Server MAY be capable of patching an existing QuestionnaireResponse resource using: PATCH [base]/QuestionnaireResponse/[id]{?_format=[mime-type]}
  • A Server MAY be capable of deleting a QuestionnaireResponse resource using: DELETE [base]//[id]

Fetch and Search Criteria:

  • A Server SHOULD be capable of a search-type interaction returning QuestionnaireResponse resources matching a search query using: GET [base]/QuestionnaireResponse/[id]{?[parameters]{&_format=[mime-type]}}
  • A Server SHOULD be capable of a read interaction returning a QuestionnaireResponse resource using: GET [base]/QuestionnaireResponse/[id]
  • A Server SHOULD be capable of a vread interaction returning a QuestionnaireResponse resource using: GET [base]/QuestionnaireResponse/[id]/_history/vid
  • A Server MAY be capable of a history-instance interaction returning a history of a QuestionnaireResponse using: GET [base]/QuestionnaireResponse/[id]/_history{?[parameters]&_format=[mime-type]}
  • A Server MAY be capable of a history-type interaction returning 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 Server MAY be capable of a create interaction creating a ServiceRequest resource using: POST [base]/ServiceRequest/[id]{?_format=[mime-type]}
  • A Server MAY be capable of updating a existing ServiceRequest resource using: PUT [base]/ServiceRequest/[id]{?_format=[mime-type]}
  • A Server MAY be capable of patching an existing ServiceRequest resource using: PATCH [base]/ServiceRequest/[id]{?_format=[mime-type]}
  • A Server MAY be capable of deleting a ServiceRequest resource using: DELETE [base]//[id]

Fetch and Search Criteria:

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