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
Official URL: http://hl7.org/fhir/us/davinci-pdex/CapabilityStatement/pdex-provider-access-server | Version: 2.1.1 | |||
Standards status: Trial-use | 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:
Raw OpenAPI-Swagger Definition file | Download
Generated Narrative: CapabilityStatement pdex-provider-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 Provider Access Server SHALL:
The PDex Provider 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 Davinci ATR Group PDex Provider Group | y | y | y | y | y | identifier, characteristic, Group-characteristic-value-reference | $davinci-data-export |
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.
vread
Allows retrieval of a historical version of a Group Resource.
history-instance
Allows review of changes to a Group Resource over time.
history-type
Retrieve the change history fora Group Resource.
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 | $davinci-data-export | Each DaVinci use case as part of its implementation guide can define the exportType parameter and the behavior expected. |