Da Vinci Payer Data Exchange
2.1.1 - STU 2.1

Da Vinci Payer Data Exchange, published by HL7 International / Financial Management. This guide is not an authorized publication; it is the continuous build for version 2.1.1 built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/HL7/davinci-epdx/ and changes regularly. See the Directory of published versions

## CapabilityStatement: PDex provider-access Server CapabilityStatement

Official URL: http://hl7.org/fhir/us/davinci-pdex/CapabilityStatement/pdex-provider-access-server | Version: 2.1.1
Standards status: Trial-use | Maturity Level: 2 | Computable Name: PdexProviderAccessServerCapabilityStatement
Copyright/Legal: Used by permission of HL7 International, all rights reserved Creative Commons License

This Section describes the expected capabilities of the PDex Provider Access Server actor which is responsible for providing responses to the queries submitted by the PDex Provider Access Requestors. The complete list of FHIR profiles, RESTful operations, and search parameters supported by PDex Provider Access Servers are defined. PDex Provider Access Clients have the option of choosing from this list to access necessary data based on their local use cases and other contextual requirements.

This capability statement is for use with the Provider Access Bulk API. It makes the $davinci-data-export operations available to in-network providers that have the appropriate credentials to access the secured APIs via a group resource that provides a list of Patients/Members that are identified as having a treatment relationship and have not opted out of sharing their data with providers.

The $davinci-data-export operation should support the export of Profiles supporting US Core 3.1.1 or US Core 6.1.0. Other profiles that can be included in the export are:

- CARIN Blue Button non-Financial Profiles.
- PDex Prior Authorization Profile.

Raw OpenAPI-Swagger Definition file | Download

## PDex Provider Access Server CapabilityStatement

- Implementation Guide Version: 2.1.1
- FHIR Version: 4.0.1
- Supported Formats: `json`
- Supported Patch Formats: `application/json-patch+json`
- Published on: 2024-05-02
- Published by: HL7 International / Financial Management

> 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/us/davinci-pdex/ImplementationGuide/hl7.fhir.us.davinci-pdex|2.1.0

## FHIR RESTful Capabilities

### Mode: `server`

The PDex Provider Access Server SHALL:

1. Support the US Core 3.1.1 or US Core 6.1.0 resources accessed via the Group resource.
2. Implement the RESTful behavior according to the FHIR specification for bulk asynchronous access.
3. Support json source formats for all US Core and PDex interactions.
4. Return the following response classes:

- (Status 400): invalid parameter
- (Status 401/4xx): unauthorized request
- (Status 403): insufficient scope
- (Status 404): unknown resource
- (Status 410): deleted resource.

The PDex Provider Access Server SHOULD:

1. Identify the US Core profiles supported as part of the FHIR `meta.profile` attribute for each instance.

Security

> 1. See the US Core Security Considerations section for requirements and recommendations. 2. A server SHALL reject any unauthorized requests by returning an `HTTP 401` unauthorized response code.

### 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 | V-R | S | U | C | H-I | H-T | Searches | `_include` | `_revinclude` | Operations
--- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | ---
Group | Supported Profiles Davinci ATR Group PDex Provider Group | Y | Y | Y |  |  | Y | y? | identifier, characteristic |  |  | `$davinci-data-export`

#### Resource Conformance: SHALLGroup

Core FHIR Resource
Group
Reference Policy
Interaction summary

- SHALL support
  `search-type`

  Allows discovery of existing groups. SHOULD be limited to groups a requestor is permitted to access.

  `read`

  Allows retrieval of a specific Group Resource.

- SHOULD support
  `vread`

  Allows retrieval of a historical version of a Group Resource.

  `history-instance`

  Allows review of changes to a Group Resource over time.

- MAY support
  `history-type`

  Retrieve the change history fora Group Resource.

Supported Profiles

Davinci ATR Group
PDex Provider Group

Search Parameters

Conformance | Parameter | Type | Documentation
--- | --- | --- | ---
SHALL | identifier | `token` | The client SHALL provide at least a code value and MAY provide both the system and code values. The server SHALL support both.
SHALL | characteristic | `token` | A common characteristic of all members of a group.

Extended Operations

Conformance | Operation | Documentation
--- | --- | ---
SHALL | $davinci-data-export | Each DaVinci use case as part of its implementation guide can define the exportType parameter and the behavior expected.