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

1. Requesting Clinical Data using a FHIR RESTful query
2. POSTing a Task resource representing a request for clinical data
3. POSTing a Subscription resource
4. Polling a Task resource

SHALL Support the Following Implementation Guides:

• HL7 FHIR® US Core Implementation Guide STU3 Release 3.1.1

• Da Vinci Health Record Exchange (HRex) 0.2.0 - STU R1 - 2nd ballot

FHIR RESTful Capabilities

The Da Vinci CDex Data Consumer 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 Consumer 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

RESTful Capabilities by Resource/Profile:

Summary of Search Criteria

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 Client SHOULD be capable of fetching 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 Client SHOULD be capable of fetching 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 Client SHOULD be capable of fetching 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 Client SHOULD be capable of fetching a Task resource using:
  GET [base]/Task/[id]