Data Exchange For Quality Measures Implementation Guide
1.0.0-ballot - STU 1 Ballot

Data Exchange For Quality Measures Implementation Guide - Downloaded Version 1.0.0-ballot See the Directory of published versions

## CapabilityStatement: Consumer Server CapabilityStatement

Official URL: http://hl7.org/fhir/uv/deqm/CapabilityStatement/consumer-server | Version: 1.0.0-ballot | Highlight text changes?
Standards status: Trial-use Active as of 2020-07-05 | Maturity Level: 4 | Computable Name: ConsumerServerCapabilityStatement

This profile defines the expected capabilities of a Da Vinci DEQM Consumer Server when conforming to the Da Vinci DEQM Implementation Guide. Consumers include systems that are primary consumers of patient healthcare information and systems that consume data from Producers. This CapabilityStatement resource includes the complete list of the recommended Da Vinci DEQM profiles and RESTful operations that a Da Vinci DEQM Consumer Server could support. Servers have the option of choosing from this list based on their local use cases and other contextual requirements.

Raw OpenAPI-Swagger Definition file | Download

Language: en

## Consumer Server CapabilityStatement

- Implementation Guide Version: 1.0.0-ballot
- FHIR Version: 4.0.1
- Supported Formats: `xml`, `json`
- Supported Patch Formats: `application/json-patch+json`
- Published on: 2020-07-05
- Published by: HL7 International / Clinical Quality Information

> Note to Implementers: FHIR Capabilities

> Any FHIR capability may be 'allowed' by the system unless explicitly marked as 'SHALL NOT'. A few items are marked as MAY in the Implementation Guide to highlight their potential relevance to the use case.

### SHALL Support the Following Implementation Guides

- http://hl7.org/fhir/uv/deqm/ImplementationGuide/hl7.fhir.uv.deqm
- http://hl7.org/fhir/uv/cqm/ImplementationGuide/hl7.fhir.uv.cqm

## FHIR RESTful Capabilities

### Mode: `server`

Da Vinci DEQM Consumer Server SHALL

1. Support the Submit Data transaction defined in the Framework Section of this Implementation Guide.
2. Declare a CapabilityStatement identifying the list of supported profiles and operations.
   - Use the DEQM Submit Data Update Type Extension to indicate whether it whether it supports snapshot or incremental data exchange.
3. Implement the FHIR RESTful API for operations including returning the appropriate response classes as described in the FHIR specification for Extended Operations on the RESTful API .
4. Support both xml and json resource formats for all interactions.

Security

> For general security consideration refer to the Security and Privacy Considerations.

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.

### Capabilities by Resource/Profile

#### Summary

The summary table lists the resources that are part of this configuration, and for each resource it lists:

- The relevant profiles (if any)
- The interactions supported by each resource (Read, Search, Update, and Create, are always shown, while VRead, Patch, Delete, History on Instance, or History on Type are only present if at least one of the resources has support for them.
- The required, recommended, and some optional search parameters (if any).
- The linked resources enabled for `_include`
- The other resources enabled for `_revinclude`
- The operations on the resource (if any)

Resource Type | Profile | R | S | U | C | Searches | `_include` | `_revinclude` | Operations
--- | --- | --- | --- | --- | --- | --- | --- | --- | ---
Measure | Supported Profiles CRMI Shareable Measure | Y |  |  |  |  |  |  | `$data-requirements`, `$submit-data`, `$bulk-submit-data`

#### Resource Conformance: SHALLMeasure

Core FHIR Resource
Measure
Reference Policy
Interaction summary

- SHOULD support `read`.

Supported Profiles

CRMI Shareable Measure

Extended Operations

Conformance | Operation | Documentation
--- | --- | ---
SHALL | $data-requirements |
SHALL | $submit-data | SHALL Use the DEQM Submit Data Update Type Extension to indicate whether it whether it supports snapshot or incremental data exchange. SHALL reject the submit data payload if there is mismatch between the update type stated in the data exchange MeasureReport submitted by the Producer (client) and the capabilities supported by the Consumer (server) by returning a 400 Bad Request http error code. An OperationOutcome SHOULD be returned stating that the [snapshot/incremental] update is not supported .
SHOULD | $bulk-submit-data | SHALL Use the DEQM Submit Data Update Type Extension to indicate whether it whether it supports snapshot or incremental data exchange. SHALL reject the submit data payload if there is mismatch between the update type stated in the data exchange MeasureReport submitted by the Producer (client) and the capabilities supported by the Consumer (server) by returning a 400 Bad Request http error code. An OperationOutcome SHOULD be returned stating that the [snapshot/incremental] update is not supported .