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 Server CapabilityStatement

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

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

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

Raw OpenAPI-Swagger Definition file | Download

Generated Narrative: CapabilityStatement pdex-server

PDEX 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 Server SHALL:

  1. Support the US Core 3.1.1 Patient resource profile.
  2. Support at least one additional resource profile from the list of US Core and PDex Profiles.
  3. Implement the RESTful behavior according to the FHIR specification.
  4. Support json source formats for all US Core and PDex interactions.
  5. 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 Server SHOULD:

  1. Support xml source formats for all US Core interactions.
  2. 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
  • MAYSupports the transactioninteraction.
  • MAYSupports the batchinteraction.
  • MAYSupports the search-systeminteraction.
  • MAYSupports the history-systeminteraction.

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-RSUPCH-IH-TSearches_include_revincludeOperations
AllergyIntoleranceSupported Profiles
  US Core AllergyIntolerance Profile
yyyyypatientProvenance:target
CarePlanSupported Profiles
  US Core CarePlan Profile
yyyyycategory, date, patient, statusProvenance:target
CareTeamSupported Profiles
  US Core CareTeam Profile
yyyyypatient, statusProvenance:target
ConditionSupported Profiles
  US Core Condition Profile
yyyyycategory, clinical-status, patient, onset-date, codeProvenance:target
ConsentSupported Profiles
  PDex Provider Access Consent Profile
yyyyyy_id, patientProvenance:target
CoverageSupported Profiles
  HRex Coverage Profile
yyyyy_idProvenance:target
DeviceSupported Profiles
  PDex Device
  US Core Implantable Device Profile
yyyyypatient, typeProvenance:target
DiagnosticReportSupported Profiles
  US Core DiagnosticReport Profile for Report and Note Exchange
  US Core DiagnosticReport Profile for Laboratory Results Reporting
yyyyyystatus, patient, category, code, dateProvenance:target
DocumentReferenceSupported Profiles
  US Core DocumentReference Profile
yyyyy_id, status, patient, category, type, date, periodProvenance:target$docref
EncounterSupported Profiles
  US Core Encounter Profile
yyyyy_id, class, date, identifier, patient, status, typeProvenance:target
ExplanationOfBenefitSupported Profiles
  PDex Prior Authorization
yy_id, patient, _lastUpdated, type, identifier, service-dateExplanationOfBenefit:patient, ExplanationOfBenefit:provider, ExplanationOfBenefit:care-team, ExplanationOfBenefit:coverage, ExplanationOfBenefit:insurer, ExplanationOfBenefit:*
GoalSupported Profiles
  US Core Goal Profile
yyyyylifecycle-status, patient, target-dateProvenance:target
GroupSupported Profiles
  Davinci ATR Group
  PDex Provider Group
  PDex Member Match Group
yyyyyidentifier, characteristic, Group-characteristic-value-reference
ImmunizationSupported Profiles
  US Core Immunization Profile
yyyyypatient, status, dateProvenance:target
LocationSupported Profiles
  US Core Location Profile
yyyyyname, address, address-city, address-state, address-postalcode
MedicationSupported Profiles
  US Core Medication Profile
yyyyy
MedicationRequestSupported Profiles
  US Core MedicationRequest Profile
yyyyystatus, intent, patient, encounter, authoredonMedicationRequest:medicationProvenance:target
MedicationDispenseSupported Profiles
  PDex MedicationDispense
yyyyystatus, patientMedicationDispense:medicationProvenance:target
ObservationSupported Profiles
  US Core Pediatric BMI for Age Observation Profile
  US Core Pediatric Weight for Height Observation Profile
  US Core Pulse Oximetry Profile
  US Core Smoking Status Observation Profile
  US Core Pediatric Head Occipital Frontal Circumference Percentile Profile
  US Core Pediatric Weight for Height Observation Profile
  US Core Pulse Oximetry Profile
  US Core Laboratory Result Observation Profile
  Vital Signs Profile
yyyyystatus, category, code, date, patientProvenance:target
OrganizationSupported Profiles
  US Core Organization Profile
yyyyyname, address
PatientSupported Profiles
  US Core Patient Profile
yyyyy_id, birthdate, family, gender, given, identifier, nameProvenance:target
PractitionerSupported Profiles
  US Core Practitioner Profile
yyyyyname, identifier
PractitionerRoleSupported Profiles
  US Core PractitionerRole Profile
yyyyyspecialty, practitionerPractitionerRole:endpoint, PractitionerRole:practitioner
ProcedureSupported Profiles
  US Core Procedure Profile
yyyyystatus, patient, date, codeProvenance:target
ProvenanceSupported Profiles
  PDex Provenance
  US Core Provenance Profile
yyyyyy
ValueSet $expand

Resource Conformance: SHALL AllergyIntolerance

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

Search Parameters
ConformanceParameterTypeDocumentation
SHALLpatientreference
Combined Search Parameters
ConformanceParametersTypes
 patientreference

Resource Conformance: SHALL CarePlan

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

Search Parameters
ConformanceParameterTypeDocumentation
MAYcategorytoken
MAYdatedate
MAYpatientreference
MAYstatustoken
Combined Search Parameters
ConformanceParametersTypes
 patient+category+status+datereference+token+token+date
 patient+category+statusreference+token+token
 patient+categoryreference+token
 patient+category+datereference+token+date

Resource Conformance: SHALL CareTeam

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

Search Parameters
ConformanceParameterTypeDocumentation
MAYpatientreference
MAYstatustoken
Combined Search Parameters
ConformanceParametersTypes
 patient+statusreference+token

Resource Conformance: SHALL Condition

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

Search Parameters
ConformanceParameterTypeDocumentation
SHALLpatientreference
MAYcategorytoken
MAYclinical-statustoken
MAYonset-datedate
MAYcodetoken
Combined Search Parameters
ConformanceParametersTypes
 patient+onset-datereference+date
 patient+categoryreference+token
 patient+clinical-statusreference+token
 patient+codereference+token

Resource Conformance: SHALL Consent

Core FHIR Resource
Consent
Reference Policy
resolves
Interaction summary
  • Supports read, create, search-type, vread, history-instance, history-type.

Search Parameters
ConformanceParameterTypeDocumentation
SHALL_idstring
SHALLpatientreference
 

Resource Conformance: supported Coverage

Core FHIR Resource
Coverage
Reference Policy
resolves
Interaction summary
  • Supports read, search-type, vread, history-instance, history-type.

Search Parameters
ConformanceParameterTypeDocumentation
SHALL_idstring
 

Resource Conformance: SHALL Device

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

Search Parameters
ConformanceParameterTypeDocumentation
SHALLpatientreference
MAYtypetoken
Combined Search Parameters
ConformanceParametersTypes
 patient+typereference+token

Resource Conformance: SHALL DiagnosticReport

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

Search Parameters
ConformanceParameterTypeDocumentation
SHALLpatientreference
MAYstatustoken
MAYcategorytoken
MAYcodetoken
MAYdatedate
Combined Search Parameters
ConformanceParametersTypes
 patient+category+datereference+token+date
 patient+statusreference+token
 patient+code+datereference+token+date
 patient+codereference+token
 patient+categoryreference+token

Resource Conformance: SHALL DocumentReference

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

Documentation

The DocumentReference.type binding SHALL support at a minimum the 5 Common Clinical Notes and may extend to the full US Core DocumentReference Type Value Set

Search Parameters
ConformanceParameterTypeDocumentation
SHALL_idtoken
SHALLpatientreference
MAYstatustoken
MAYcategorytoken
MAYtypetoken
MAYdatedate
MAYperioddate
Combined Search Parameters
ConformanceParametersTypes
 patient+type+periodreference+token+date
 patient+typereference+token
 patient+category+datereference+token+date
 patient+statusreference+token
 patient+categoryreference+token
Extended Operations
ConformanceOperationDocumentation
SHALL$docref

A server SHALL be capable of responding to a $docref operation and capable of returning at least a reference to a generated CCD document, if available. MAY provide references to other 'on-demand' and 'stable' documents (or 'delayed/deferred assembly') that meet the query parameters as well. If a context date range is supplied the server ** SHOULD** provide references to any document that falls within the date range If no date range is supplied, then the server SHALL provide references to last or current encounter. SHOULD document what resources, if any, are returned as included resourcesGET [base]/DocumentReference/$docref?patient=[id]

Resource Conformance: SHALL Encounter

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

Search Parameters
ConformanceParameterTypeDocumentation
SHALL_idtoken
SHALLpatientreference
SHOULDidentifiertoken
MAYclasstoken
MAYdatedate
MAYstatustoken
MAYtypetoken
Combined Search Parameters
ConformanceParametersTypes
 class+patienttoken+reference
 patient+statusreference+token
 patient+typereference+token
 date+patientdate+reference

Resource Conformance: SHALL ExplanationOfBenefit

Core FHIR Resource
ExplanationOfBenefit
Reference Policy
resolves
Interaction summary
  • SHALLsupport search-type, read.

Documentation

When a Prior Authorization references another resource (e.g., Patient or Practitioner), the reference may be versioned or versionless. Payers SHALL use versioned references whenever they maintain point-in-time data (data that was effective as of the date of service or date of admission on the claim), but MAY use versionless references when they do not maintain versioned data. Clients MAY request referenced resources as part of an EOB search (by supplying the _include parameter) or directly using read or vread. Payers SHALL support both approaches, and SHALL return the same content for referenced resources in either case. “:iterate" should be used if you request to include Coverage:payor in the EOB response bundle, e.g. GET [base]/ExplanationOfBenefit?[parameter=value]&_include=ExplanationOfBenefit:coverage&_include:iterate=Coverage:payor.

Search Parameters
ConformanceParameterTypeDocumentation
SHALL_idtoken
SHALLpatientreference
SHALL_lastUpdateddate
SHALLtypetoken
SHALLidentifiertoken
SHALLservice-datedate
 

Resource Conformance: SHALL Goal

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

Search Parameters
ConformanceParameterTypeDocumentation
SHALLpatientreference
MAYlifecycle-statustoken
MAYtarget-datedate
Combined Search Parameters
ConformanceParametersTypes
 patient+lifecycle-statusreference+token
 patient+target-datereference+date

Resource Conformance: SHALL Group

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

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.

Resource Conformance: SHALL Immunization

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

Search Parameters
ConformanceParameterTypeDocumentation
SHALLpatientreference
MAYstatustoken
MAYdatedate
Combined Search Parameters
ConformanceParametersTypes
 patient+datereference+date
 patient+statusreference+token

Resource Conformance: SHALL Location

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

Search Parameters
ConformanceParameterTypeDocumentation
SHALLnamestring
SHALLaddressstring
SHOULDaddress-citystring
SHOULDaddress-statestring
SHOULDaddress-postalcodestring
 

Resource Conformance: SHALL Medication

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

Documentation

The MedicationRequest resource can represent a medication, using an external reference to a Medication resource. If an external Medication Resource is used in a MedicationRequest, then the READ SHALL be supported.

Resource Conformance: SHALL MedicationRequest

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

Documentation

The MedicationRequest resources can represent a medication using either a code or refer to the Medication resource. When referencing Medication, the resource may be contained or an external resource. The server application MAY choose any one way or more than one method, but if an external reference to Medication is used, the server SHALL support the _includeparameter for searching this element. The client application must support all methods. For example, A server **SHALL** be capable of returning all medications for a patient using one of or both:GET /MedicationRequest?patient=[id] GET /MedicationRequest?patient=[id]&_include=MedicationRequest:medication`

Search Parameters
ConformanceParameterTypeDocumentation
MAYstatustoken
MAYintenttoken
MAYpatientreference
MAYencounterreference
MAYauthoredondate
Combined Search Parameters
ConformanceParametersTypes
 patient+intentreference+token
 patient+intent+encounterreference+token+reference
 patient+intent+authoredonreference+token+date
 patient+intent+statusreference+token+token

Resource Conformance: SHALL MedicationDispense

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

Documentation

The MedicationDispense resources can represent a medication using either a code or refer to the Medication resource. When referencing Medication, the resource may be contained or an external resource. The server application MAY choose any one way or more than one method, but if an external reference to Medication is used, the server SHALL support the _includeparameter for searching this element. The client application must support all methods. For example, A server **SHALL** be capable of returning all medications for a patient using one of or both:GET /MedicationDispense?patient=[id] GET /MedicationDispense?patient=[id]&_include=MedicationDispense:medication`

Search Parameters
ConformanceParameterTypeDocumentation
MAYstatustoken
MAYpatientreference
Combined Search Parameters
ConformanceParametersTypes
 patient+intentreference+<unknown>
 patient+intent+statusreference+<unknown>+token

Resource Conformance: SHALL Organization

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

Search Parameters
ConformanceParameterTypeDocumentation
SHALLnamestring
SHALLaddressstring
 

Resource Conformance: SHALL Patient

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

Search Parameters
ConformanceParameterTypeDocumentation
SHALL_idtoken
SHALLidentifiertoken
SHALLnamestring
MAYbirthdatedate
MAYfamilystring
MAYgendertoken
MAYgivenstring
Combined Search Parameters
ConformanceParametersTypes
 birthdate+familydate+string
 family+genderstring+token
 birthdate+namedate+string
 gender+nametoken+string
Extended Operations
ConformanceOperationDocumentation
SHALL$member-match

Resource Conformance: SHALL Practitioner

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

Search Parameters
ConformanceParameterTypeDocumentation
SHALLnamestring
SHALLidentifiertoken
 

Resource Conformance: SHALL PractitionerRole

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

Search Parameters
ConformanceParameterTypeDocumentation
SHALLspecialtytoken
SHALLpractitionerreference
 

Resource Conformance: SHALL Procedure

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

Search Parameters
ConformanceParameterTypeDocumentation
SHALLpatientreference
MAYstatustoken
MAYdatedate
MAYcodetoken
Combined Search Parameters
ConformanceParametersTypes
 patient+datereference+date
 patient+statusreference+token
 patient+code+datereference+token+date

Resource Conformance: SHALL Provenance

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

Documentation

If a system receives a provider in Provenance.agent.who as free text they must capture who sent them the information as the organization. On request they SHALL provide this organization as the source and MAY include the free text provider.

Resource Conformance: SHOULD ValueSet

Core FHIR Resource
ValueSet
Reference Policy
Interaction summary

    Extended Operations
    ConformanceOperationDocumentation
    SHOULD$expand

    A client can determine the note and report types support by a server by invoking the standard FHIR Value Set Expansion ($expand) operation defined in the FHIR R4 specification. Because servers may support different read and write formats, it also is used to determine the formats (for example, text, pdf) the server supports read and write transactions.