Da Vinci Clinical Data Exchange (CDex)
1.0.0 - STU R1 US

This page is part of the Da Vinci Clinical Documentation Exchange (v1.0.0: STU1) 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 Source Client CapabilityStatement

Official URL: http://hl7.org/fhir/us/davinci-cdex/CapabilityStatement/data-source-client Version: 1.0.0
Active as of 2022-02-28 Computable Name: DataSourceClientCapabilityStatement

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 (often an EHR) in Client mode during a clinical data exchange with a Data Consumer. This includes the following interactions:

  1. POSTing the $submit-attachment operation to exchange clinical data using a FHIR based Attachments transaction.
  2. Query for Authorization information represented by a CommunicationRequest or ServiceRequest.
  3. Posting a subscription notification to a Data Consumer endpoint updating the status of a Task.

Raw OpenAPI-Swagger Definition file | Download

SHALL Implement All Or Parts Of The Following Capability Statements:

FHIR RESTful Capabilities

The Da Vinci CDex Data Source SHALL:

  1. Support at least one of these FHIR transaction approaches for exchanging clinical information as defined in this Guide:
    1. Task Based Approach
    2. Attachments
  2. Follow the guidelines for Generating and Verifying Signed Resources if signatures are required.1. Support json source formats for all Da Vinci CDex interactions.
  3. Declare a CapabilityStatement identifying transactions and profiles supported.

The Da Vinci CDex Data Source SHOULD:

  1. Support xml source formats for all Da Vinci CDex interactions.

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 Source Client 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 US Core DocumentReference Profile - - - -
ServiceRequest - - - - -
Subscription - - - - -

CommunicationRequest

Conformance Expectation: SHOULD

Resource Specific Documentation:

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

Profile Interaction Summary:

  • SHOULD support read†, vread.
  • MAY support create, search-type, 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 Client SHOULD be capable of fetching 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 Client SHOULD be capable of fetching a DocumentReference resource using: GET [base]/DocumentReference/[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 Client SHOULD be capable of fetching a ServiceRequest resource using: GET [base]/ServiceRequest/[id]

Subscription

Conformance Expectation: SHOULD

Resource Specific Documentation:

Required resource type to subscribe to data source

Profile Interaction Summary:

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

If subscriptions are supported the subscription notification is posted to it endpoint updating the status of a Task

update†

If subscriptions are supported the subscription notification is posted to it endpoint updating the status of a Task

Fetch and Search Criteria:

  • A Client MAY be capable of fetching a Subscription resource using: GET [base]/Subscription/[id]