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

Raw OpenAPI-Swagger Definition file | Download

Data Source 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 Source (often an EHR) in Server mode when responding to a Data Consumer (often a Payer) during a clinical data exchange. This includes the following interactions:

  1. Responding to a FHIR RestFul Query for Clinical Data
  2. Responding to a POST of a Task resource representing a request for clinical data
  3. Responding to a POST of a Subscription resource
  4. Responding to polling of a Task resource

SHALL Support the Following Implementation Guides:

FHIR RESTful Capabilities

The Da Vinci CDex Data Source SHALL:

  1. Support at least one of the two FHIR transaction approaches for requesting information as defined in this Guide:
    1. Direct Query
    2. Task Based Approachs
  2. Support json source formats for all Da Vinci CDex interactions.
  3. Declare a CapabilityStatement identifying the scenarios, 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 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
    Bundle
    Coverage HRex Coverage Profile
    Subscription
    TaskCDex Task Data Request Profile

    Bundle

    Conformance Expectation: SHOULD

    Resource Specific Documentation:

    Required resource type to fetch Clinical Information from data source

    Profile Interaction Summary:

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

    Fetch and Search Criteria:

    • A Server SHOULD be capable of returning a Bundle resource using:
      GET [base]/Bundle/[id]


    Coverage

    Conformance Expectation: SHOULD

    Supported Profiles: HRex Coverage Profile

    Resource Specific Documentation:

    Required resource type to carry information regarding reason for requesting Clniical information for prior authorization.

    Profile Interaction Summary:

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

    Fetch and Search Criteria:

    • A Server SHOULD be capable of returning a Coverage resource using:
      GET [base]/Coverage/[id]


    Subscription

    Conformance Expectation: SHOULD

    Resource Specific Documentation:

    Required resource type to subscribe to data source

    Profile Interaction Summary:

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

    Fetch and Search Criteria:

    • A Server SHOULD be capable of returning a Subscription resource using:
      GET [base]/Subscription/[id]


    Task

    Conformance Expectation: SHOULD

    Supported Profiles: CDex Task Data Request Profile

    Resource Specific Documentation:

    Required resource type to request and fetch clinical information from data source

    Profile Interaction Summary:

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

    Fetch and Search Criteria:

    • A Server SHOULD be capable of returning a Task resource using:
      GET [base]/Task/[id]