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
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:
Raw OpenAPI-Swagger Definition file | Download
Generated Narrative: CapabilityStatement pdex-payer-access-server
json
application/json-patch+json
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.
server
The PDex Payer Access Server SHALL:
The PDex Payer Access Server SHOULD:
meta.profile
attribute for each instance.
- 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.
The summary table lists the resources that are part of this configuration, and for each resource it lists:
_include
_revinclude
Resource Type | Profile | R | V-R | S | U | C | H-I | H-T | Searches | _include | _revinclude | Operations |
---|---|---|---|---|---|---|---|---|---|---|---|---|
Group | Supported Profiles PDex Member Match Group | y | y | y | y | y | identifier, characteristic, Group-characteristic-value-reference |
search-type
, read
.vread
, history-instance
.history-type
.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. |
SHALL | Group-characteristic-value-reference | composite | 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). |
Conformance | Operation | Documentation |
---|---|---|
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. |