Da Vinci Payer Data Exchange
2.1.0-ballot - STU2 Ballot United States of America flag

This page is part of the Da Vinci Payer Data Exchange (v2.1.0-ballot: STU2.1 Ballot 1) based on FHIR (HL7® FHIR® Standard) R4. The current version which supersedes this version is 2.0.0. For a full list of available versions, see the Directory of published versions

CapabilityStatement: PDex Payer-Access Server CapabilityStatement

Official URL: http://hl7.org/fhir/us/davinci-pdex/CapabilityStatement/pdex-payer-access-server Version: 2.1.0-ballot
Standards status: Trial-use Computable Name: PdexPayerAccessServerCapabilityStatement

Copyright/Legal: Used by permission of HL7 International, all rights reserved Creative Commons License

This Section describes the expected capabilities of the PDex Payer Access Server actor which is responsible for providing responses to the queries submitted by the PDex Payer Access Requestors. The complete list of FHIR profiles, RESTful operations, and search parameters supported by PDex Payer Access Servers are defined. PDex Payer 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 Payer-to-Payer Bulk Access API. It makes the $bulk-member-match and $davinci-data-export operations available to other payers that have the appropriate credentials to access the secured APIs.

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

Generated Narrative: CapabilityStatement pdex-payer-access-server

PDex Payer Access Server CapabilityStatement

  • Implementation Guide Version: 2.1.0-ballot
  • 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.0.0

FHIR RESTful Capabilities

Mode: server

The PDex Payer 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 Payer 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.
Summary of System-wide Interactions

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 TypeProfileRV-RSUCH-IH-TSearches_include_revincludeOperations
GroupSupported Profiles
  PDex Member Match Group		yyyyyidentifier, characteristic, Group-characteristic-value-reference

Resource Conformance: SHALL Group

Core FHIR Resource
Group
Reference Policy
Interaction summary
  • SHALLsupport search-type, read.
  • SHOULDsupport vread, history-instance.
  • MAYsupport history-type.

Supported Profiles

http://hl7.org/fhir/us/davinci-pdex/StructureDefinition/pdex-member-match-group

Search Parameters
ConformanceParameterTypeDocumentation
SHALLidentifiertoken

The client SHALL provide at least a code value and MAY provide both the system and code values.

The server SHALL support both.

SHALLcharacteristictoken

A common characteristic of all members of a group.

SHALLGroup-characteristic-value-referencecomposite

multipleAnd: It's up to the server whether the parameter may repeat in order to specify multiple values that must all be true. multipleOr: The parameter may only have one value (no comma separators).

 
Extended Operations
ConformanceOperationDocumentation
SHALL$bulk-member-match

Client will submit multi-member-match-request bundle. Server will respond with a multi-member-match-response and instantiate a Group resource conforming to the PDexMemberMatchGroup that contains a set of matched members that the Server identified.

SHALL$davinci-data-export

Each DaVinci use case as part of its implementation guide can define the exportType parameter and the behavior expected.