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

Official URL: http://hl7.org/fhir/us/davinci-cdex/CapabilityStatement/data-source-server Version: 2.1.0-preview
Standards status: Trial-use Maturity Level: 2 Computable Name: DataSourceServerCapabilityStatement
Other Identifiers: OID:2.16.840.1.113883.4.642.40.21.13.5

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 Server mode when responding to a Data Consumer during clinical data exchange. The capabilities include one or more of the following interactions:

  1. Responding to a FHIR RestFul Query for Clinical Data
  2. Responding to a Task-based query request for clinical data including:
    • Polling or Subscription requests for Task update notifications
  3. Responding to
    • Requesting Attachments Using Attachments Codes
    • Requesting Attachments Using Questionnaires

Raw OpenAPI-Swagger Definition file | Download

Data Source Server CapabilityStatement

  • Title:Data Source Server 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-05-13 20:39:21-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 Server mode when responding to a Data Consumer during clinical data exchange. The capabilities include one or more of the following interactions:

  1. Responding to a FHIR RestFul Query for Clinical Data
  2. Responding to a Task-based query request for clinical data including:
    • Polling or Subscription requests for Task update notifications
  3. Responding to
    • Requesting Attachments Using Attachments Codes
    • Requesting Attachments Using Questionnaires

Support and Requirements for Other Artifacts

Instantiates other capabilities: Supports other guides:

Jump to:


FHIR server RESTful Capabilities

The Da Vinci CDex Data Source Server SHALL:

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

    1. Direct Query
    2. Task-Based Approach
    3. Attachments

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

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

  4. Declare a CapabilityStatement identifying the scenarios, 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 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.

Summary of Resource/Profile Capabilities

Resource Type Supported Interactions Supported Profiles Supported Searches Supported _includes Supported _revincludes Supported Operations
Bundle create, search-type, read, vread, update, patch, delete, history-instance, history-type, CDex Signature Bundle Profile,
Patient create, search-type, read, vread, update, patch, delete, history-instance, history-type, CDex Patient Demographics Profile, $match
PractitionerRole create, search-type, read, vread, update, patch, delete, history-instance, history-type, CDex PractitionerRole Profile,
Provenance 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,
Subscription create, search-type, read, vread, update, patch, delete, history-instance, history-type,
Task create, search-type, read, vread, update, patch, delete, history-instance, history-type, CDex Task Data Request Profile, CDex Task Attachment Request Profile,

RESTful server Capabilities by Resource/Profile:

Bundle

Conformance Expectation: SHOULD

Resource Specific Documentation:

Required resource type for responding to Clinical data requests. SHALL support CDex Signature Bundle Profile for signed Bundles.

Supported Profiles:


Modify Criteria:

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

Fetch and Search Criteria:

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

Patient

Conformance Expectation: SHOULD

Resource Specific Documentation:

Required resource type to supply patient demographic data when requesting attachments.

Supported Profiles:

Reference Policy: logical,

Patient Interaction Summary:

  • MAY support create, search-type, read, vread, update, patch, delete, history-instance, history-type,

Modify Criteria:

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

Fetch and Search Criteria:

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

PractitionerRole

Conformance Expectation: SHOULD

Resource Specific Documentation:

Required resource type to supply patient demographic data when requesting attachments.

Supported Profiles:

Reference Policy: logical,


Modify Criteria:

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

Fetch and Search Criteria:

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

Provenance

Conformance Expectation: SHOULD

Resource Specific Documentation:

Required resource type to fetch provenance along with clinical information


Modify Criteria:

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

Fetch and Search Criteria:

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

QuestionnaireResponse

Conformance Expectation: SHOULD

Resource Specific Documentation:

Required resource type complete questionnaires from data source. SHALL support CDex SDC QuestionnaireResponse Profile for signed QuestionnaireResponse.

Supported Profiles:


Modify Criteria:

  • A server SHOULD 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]}

Subscription

Conformance Expectation: SHOULD

Resource Specific Documentation:

Required resource type to subscribe to data source for Task-based requests.


Modify Criteria:

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

Fetch and Search Criteria:

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

Task

Conformance Expectation: SHOULD

Resource Specific Documentation:

  1. If Da Vinci CDex Data Source Server supports Task-based query, they SHALL support the CDex Task Data Request Profile.
  2. If Da Vinci CDex Data Source Server supports requesting attachments, they SHALL support the:
    • CDex Task Attachment Request Profile
    • CDex Patient Demographic Profile
    • CDex PractitionerRequest Profile

Supported Profiles:

Reference Policy: logical,


Modify Criteria:

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

Fetch and Search Criteria:

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