Da Vinci Clinical Data Exchange (CDex) Implementation Guide
0.2.0 - ballot

This page is part of the Da Vinci Clinical Documentation Exchange (v0.2.0: STU1 Ballot 1) based on FHIR R4. The current version which supercedes this version is 1.1.0. For a full list of available versions, see the Directory of published versions

CapabilityStatement: Data Consumer Server CapabilityStatement

Raw OpenAPI-Swagger Definition file | Download

Data Consumer Server CapabilityStatement

  • Implementation Guide Version: 0.2.0
  • FHIR Version: 4.0.1
  • Supported formats: xml, json
  • Published: 2020-11-04
  • Published by: HL7 International - Patient Care Work Group

This CapabilityStatement describes the expected capabilities of a Da Vinci CDex Data Consumer (often a Payer) in Server mode when responding to a Data Source (often an EHR) or one of its proxies during a clinical data exchange. This includes the following interactions:

  1. Responding to a query for Authorization information represented by a CommunicationRequest or ServiceRequest
  2. Responding to Subscription Notification posted to it endpoint updating the status of a Task

SHALL Support the Following Implementation Guides:

FHIR RESTful Capabilities

The Da Vinci CDex Data Consumer SHALL:

  1. Support theTask Based Approach approaches for requesting information as defined in this Guide:
  2. Support json source formats for all Da Vinci Notification interactions.
  3. Declare a CapabilityStatement identifying transactions and profiles supported.

The Da Vinci CDex Data Consumer SHOULD:

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

Security:

  1. For general security consideration refer to the Security and Privacy Considerations.
  2. For security considerations specific to this guide refer to the Da Vinci HRex Implementation Guide section on Security and Privacy

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.
  • RESTful Capabilities by Resource/Profile:

    Summary of Search Criteria

    Resource TypeSupported ProfilesSupported SearchesSupported _includesSupported _revincludesSupported Operations
    CommunicationRequest
    ServiceRequest
    Subscription

    CommunicationRequest

    Conformance Expectation: SHOULD

    Resource Specific Documentation:

    Required resource type to carry authorization information regarding for requesting Clniical 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 Server SHOULD be capable of returning a CommunicationRequest resource using:
      GET [base]/CommunicationRequest/[id]


    ServiceRequest

    Conformance Expectation: SHOULD

    Resource Specific Documentation:

    Required resource type to carry authorization information regarding for requesting Clniical 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]


    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 Server MAY be capable of returning a Subscription resource using:
      GET [base]/Subscription/[id]