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

Official URL: http://hl7.org/fhir/us/davinci-pdex/CapabilityStatement/pdex-server | Version: 2.1.1
Standards status: Trial-use | Maturity Level: 2 | 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

## PDEX Server CapabilityStatement

- Implementation Guide Version: 2.1.1
- FHIR Version: 4.0.1
- Supported Formats: SHALL support `json`, SHOULD support `xml`
- Supported Patch Formats: SHOULD support `application/json-patch+json`
- Published on: 2024-10-20
- 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.

### SHOULD Support the Following Implementation Guides

- http://hl7.org/fhir/smart-app-launch/ImplementationGuide/hl7.fhir.uv.smart-app-launch|2.1.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

- MAY support the `transaction`interaction.
- MAY support the `batch`interaction.
- MAY support the `search-system`interaction.
- MAY support the `history-system`interaction.

### 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 | P | C | H-I | H-T | Searches | `_include` | `_revinclude` | Operations
--- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | ---
AllergyIntolerance | Supported Profiles US Core AllergyIntolerance Profile | Y | Y | Y |  |  |  | Y | y? | clinical-status, patient |  | `Provenance:target` |
CarePlan | Supported Profiles US Core CarePlan Profile | Y | Y | Y |  |  |  | Y | y? | category, date, patient, status, patient+category+status, patient+category+status+date, patient+category, patient+category+date |  | `Provenance:target` |
CareTeam | Supported Profiles US Core CareTeam Profile | Y | Y | Y |  |  |  | Y | y? | patient, status, role, patient+status, patient+role | `CareTeam:participant:PractitionerRole`, `CareTeam:participant:Practitioner`, `CareTeam:participant:Patient`, `CareTeam:participant:RelatedPerson` | `Provenance:target` |
Condition | Supported Profiles US Core Condition Profile | Y | Y | Y |  |  |  | Y | y? | category, clinical-status, patient, onset-date, asserted-date, recorded-date, abatement-date, code, encounter, patient+recorded-date, patient+asserted-date, patient+category+clinical-status, patient+onset-date, patient+abatement-date, patient+clinical-status, patient+category+encounter, patient+code, patient+category |  | `Provenance:target` |
Consent | Supported Profiles PDex Provider Access Consent Profile | y | y | y |  |  | y | y | y | _id, patient |  | `Provenance:target` |
Coverage | Supported Profiles HRex Member Match Coverage Profile | Y | Y | Y |  |  |  | Y | y? | patient |  | `Provenance:target` |
DiagnosticReport | Supported Profiles US Core DiagnosticReport Profile for Report and Note Exchange US Core DiagnosticReport Profile for Laboratory Results Reporting | Y | Y | Y |  |  |  | Y | y? | status, patient, category, code, date, patient+type, patient+status |  | `Provenance:target` |
DocumentReference | Supported Profiles US Core DocumentReference Profile | Y | Y | Y |  |  |  | Y | y? | _id, status, patient, category, type, date, period, patient+type, patient+status, patient+type+period, patient+category+date, patient+category |  | `Provenance:target` | `$docref`
Encounter | Supported Profiles US Core Encounter Profile | Y | Y | Y |  |  |  | Y | y? | _id, class, date, identifier, patient, location, status, type, discharge-disposition, patient+type, class+patient, patient+status, date+patient, patient+location, patient+discharge-disposition |  | `Provenance:target` |
ExplanationOfBenefit | Supported Profiles PDex Prior Authorization | Y |  | Y |  |  |  |  |  | _id, patient, _lastUpdated, type, identifier, service-date | `ExplanationOfBenefit:patient`, `ExplanationOfBenefit:provider`, `ExplanationOfBenefit:care-team`, `ExplanationOfBenefit:coverage`, `ExplanationOfBenefit:insurer`, `ExplanationOfBenefit:*` |  |
Goal | Supported Profiles US Core Goal Profile | Y | Y | Y |  |  |  | Y | y? | lifecycle-status, patient, target-date, description, patient+target-date, patient+description, patient+lifecycle-status |  | `Provenance:target` |
Group | Supported Profiles Davinci ATR Group PDex Provider Group PDex Member Match Group | Y | Y | Y |  |  |  | Y | y? | identifier, characteristic |  |  | `$bulk-member-match`, `$davinci-data-export`
Immunization | Supported Profiles US Core Immunization Profile | Y | Y | Y |  |  |  | Y | y? | patient, status, date, patient+date, patient+status |  | `Provenance:target` |
Location | Supported Profiles US Core Location Profile | Y | Y | Y |  |  |  | Y | y? | name, address, address-city, address-state, address-postalcode |  |  |
Medication | Supported Profiles US Core Medication Profile | Y | Y | y? |  |  |  | Y | y? |  |  |  |
MedicationDispense | Supported Profiles PDex MedicationDispense | Y | Y | Y |  |  |  | Y | y? | status, type, patient, patient+status+type, patient+status | `MedicationDispense:medication` | `Provenance:target` |
MedicationRequest | Supported Profiles US Core MedicationRequest Profile | Y | Y | Y |  |  |  | Y | y? | status, intent, patient, encounter, authoredon, patient+intent+encounter, patient+intent+status, patient+intent+authoredon, patient+intent | `MedicationRequest:medication` | `Provenance:target` |
Observation | Supported 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 | Y | Y | Y |  |  |  | Y | y? | status, category, code, date, patient, patient+category+status, patient+category+date, patient+category, patient+code |  | `Provenance:target` |
Organization | Supported Profiles US Core Organization Profile | Y | Y | Y |  |  |  | Y | y? | name, address |  |  |
Patient | Supported Profiles US Core Patient Profile | Y | Y | Y |  |  |  | Y | y? | _id, birthdate, death-date, family, gender, given, identifier, name, family+gender, birthdate+name, gender+name, death-date+family |  | `Provenance:target` | `$member-match`
Practitioner | Supported Profiles US Core Practitioner Profile | Y | Y | Y |  |  |  | Y | y? | _id, name, identifier |  |  |
PractitionerRole | Supported Profiles US Core PractitionerRole Profile | Y | Y | Y |  |  |  | Y | y? | specialty, practitioner | `PractitionerRole:endpoint`, `PractitionerRole:practitioner` |  |
Procedure | Supported Profiles US Core Procedure Profile | Y | Y | Y |  |  |  | Y | y? | status, patient, date, code, patient+code+date, patient+status, patient+date |  | `Provenance:target` |
Provenance | Supported Profiles PDex Provenance US Core Provenance Profile | Y | Y | y? |  | y? |  | Y | y? |  |  |  |
ValueSet |  |  |  |  |  |  |  |  |  |  |  |  | `$expand`

#### Resource Conformance: SHALLAllergyIntolerance

Core FHIR Resource
AllergyIntolerance
Reference Policy
`resolves`
Interaction summary

- SHALL support `search-type`, `read`.
- SHOULD support `vread`, `history-instance`.
- MAY support `history-type`.

Supported Profiles

US Core AllergyIntolerance Profile

Search Parameters

Conformance | Parameter | Type | Documentation
--- | --- | --- | ---
SHALL | patient | `reference` | The client SHALL provide at least a id value and MAY provide both the Type and id values. The server SHALL support both.
MAY | clinical-status | `token` | The client SHALL provide at least a code value and MAY provide both the system and code values. The server SHALL support both.

Combined Search Parameters

Conformance | Parameters | Types
--- | --- | ---
| patient+clinical-status | `reference`+`token`

#### Resource Conformance: SHALLCarePlan

Core FHIR Resource
CarePlan
Reference Policy
`resolves`
Interaction summary

- SHALL support `search-type`, `read`.
- SHOULD support `vread`, `history-instance`.
- MAY support `history-type`.

Supported Profiles

US Core CarePlan Profile

Documentation

> - Additional considerations for systems aligning with HL7 Consolidated (C-CDA) Care Plan requirements:
>   - US Core Goal SHOULD be present in CarePlan.goal
>   - US Core Condition SHOULD be present in CarePlan.addresses
>   - Assessment and Plan MAY be included as narrative text

Search Parameters

Conformance | Parameter | Type | Documentation
--- | --- | --- | ---
MAY | category | `token` | The client SHALL provide at least a code value and MAY provide both the system and code values. The server SHALL support both.
MAY | date | `date` | A client SHALL provide a value precise to the second + time offset. A server SHALL support a value precise to the second + time offset.
MAY | patient | `reference` | The client SHALL provide at least a id value and MAY provide both the Type and id values. The server SHALL support both.
MAY | status | `token` | The client SHALL provide at least a code value and MAY provide both the system and code values. The server SHALL support both.

Combined Search Parameters

Conformance | Parameters | Types
--- | --- | ---
SHALL | patient+category | `reference`+`token`
SHOULD | patient+category+status | `reference`+`token`+`token`
SHOULD | patient+category+status+date | `reference`+`token`+`token`+`date`
SHOULD | patient+category+date | `reference`+`token`+`date`

#### Resource Conformance: SHALLCareTeam

Core FHIR Resource
CareTeam
Reference Policy
`resolves`
Interaction summary

- SHALL support `search-type`, `read`.
- SHOULD support `vread`, `history-instance`.
- MAY support `history-type`.

Supported Profiles

US Core CareTeam Profile

Documentation

> In order to access care team member's names, identifiers, locations, and contact information, the CareTeam profile supports several types of care team participants. They are represented as references to other profiles and include the following four profiles which are marked as must support:

> 1. US Core Practitioner Profile
> 2. US Core PractitionerRole Profile
> 3. US Core Patient Profile
> 4. US Core RelatedPerson Profile
> - Although both US Core Practitioner Profile and US Core PractitionerRole are must support, the server system is not required to support both types of references (and `_include` search parameters), but SHALL support at least one of them.
> - The client application SHALL support all four profile references.
> - Because the US Core PractitionerRole Profile supplies the provider's location and contact information and a reference to the Practitioner, server systems SHOULD reference it instead of the US Core Practitioner Profile.
> - Servers that supports only US Core Practitioner Profile SHALL provide implementation specific guidance how to access a provider's location and contact information using only the Practitioner resource.

Search Parameters

Conformance | Parameter | Type | Documentation
--- | --- | --- | ---
SHOULD | role | `token` | The client SHALL provide at least a code value and MAY provide both the system and code values. The server SHALL support both.
MAY | patient | `reference` | The client SHALL provide at least a id value and MAY provide both the Type and id values. The server SHALL support both.
MAY | status | `token` | The client SHALL provide at least a code value and MAY provide both the system and code values. The server SHALL support both.

Combined Search Parameters

Conformance | Parameters | Types
--- | --- | ---
SHALL | patient+status | `reference`+`token`
SHOULD | patient+role | `reference`+`token`

#### Resource Conformance: SHALLCondition

Core FHIR Resource
Condition
Reference Policy
`resolves`
Interaction summary

- SHALL support `search-type`, `read`.
- SHOULD support `vread`, `history-instance`.
- MAY support `history-type`.

Supported Profiles

US Core Condition Profile

Search Parameters

Conformance | Parameter | Type | Documentation
--- | --- | --- | ---
SHALL | patient | `reference` | The client SHALL provide at least a id value and MAY provide both the Type and id values. The server SHALL support both.
MAY | category | `token` | The client SHALL provide at least a code value and MAY provide both the system and code values. The server SHALL support both.
MAY | clinical-status | `token` | The client SHALL provide at least a code value and MAY provide both the system and code values. The server SHALL support both.
MAY | onset-date | `date` | A client SHALL provide a value precise to the second + time offset. A server SHALL support a value precise to the second + time offset.
MAY | asserted-date | `date` | A client SHALL provide a value precise to the second + time offset. A server SHALL support a value precise to the second + time offset.
MAY | recorded-date | `date` | A client SHALL provide a value precise to the second + time offset. A server SHALL support a value precise to the second + time offset.
MAY | abatement-date | `date` | A client SHALL provide a value precise to the second + time offset. A server SHALL support a value precise to the second + time offset.
MAY | code | `token` | The client SHALL provide at least a code value and MAY provide both the system and code values. The server SHALL support both.
MAY | encounter | `reference` | The client SHALL provide at least a id value and MAY provide both the Type and id values. The server SHALL support both.

Combined Search Parameters

Conformance | Parameters | Types
--- | --- | ---
SHALL | patient+category | `reference`+`token`
SHOULD | patient+recorded-date | `reference`+`date`
SHOULD | patient+asserted-date | `reference`+`date`
SHOULD | patient+category+clinical-status | `reference`+`token`+`token`
SHOULD | patient+onset-date | `reference`+`date`
SHOULD | patient+abatement-date | `reference`+`date`
SHOULD | patient+clinical-status | `reference`+`token`
SHOULD | patient+category+encounter | `reference`+`token`+`reference`
SHOULD | patient+code | `reference`+`token`

#### Resource Conformance: SHALLConsent

Core FHIR Resource
Consent
Reference Policy
`resolves`
Interaction summary

- Supports `read`, `create`, `search-type`, `vread`, `history-instance`, `history-type`.

Supported Profiles

PDex Provider Access Consent Profile

Search Parameters

Conformance | Parameter | Type | Documentation
--- | --- | --- | ---
SHALL | _id | `string` |
SHALL | patient | `reference` |

#### Resource Conformance: SHALLCoverage

Core FHIR Resource
Coverage
Reference Policy
`resolves`
Interaction summary

- SHALL support `search-type`, `read`.
- SHOULD support `vread`, `history-instance`.
- MAY support `history-type`.

Supported Profiles

HRex Member Match Coverage Profile

Search Parameters

Conformance | Parameter | Type | Documentation
--- | --- | --- | ---
SHALL | patient | `reference` | The client SHALL provide at least a id value and MAY provide both the Type and id values. The server SHALL support both.

#### Resource Conformance: SHALLDiagnosticReport

Core FHIR Resource
DiagnosticReport
Reference Policy
`resolves`
Interaction summary

- SHALL support `search-type`, `read`.
- SHOULD support `vread`, `history-instance`.
- MAY support `history-type`.

Supported Profiles

US Core DiagnosticReport Profile for Report and Note Exchange
US Core DiagnosticReport Profile for Laboratory Results Reporting

Documentation

> - Implantable medical devices that have UDI information SHALL represent the UDI code in `Device.udiCarrier.carrierHRF`.

>   - All of the five UDI-PI elements that are present in the UDI code SHALL be represented in the corresponding US Core Implantable Device Profile element.

>   UDI may not be present in all scenarios such as historical implantable devices, patient reported implant information, payer reported devices, or improperly documented implants. If UDI is not present and the manufacturer and/or model number information is available, they SHOULD be included to support historical reports of implantable medical devices as follows:

>   manufacturer -> `Device.manufacturer`
>   model -> `Device.model`

> - Servers SHOULD support query by Device.type to allow clients to request the patient's devices by a specific type. Note: The Device.type is too granular to differentiate implantable vs. non-implantable devices.

Search Parameters

Conformance | Parameter | Type | Documentation
--- | --- | --- | ---
SHALL | patient | `reference` | The client SHALL provide at least a id value and MAY provide both the Type and id values. The server SHALL support both.
MAY | status | `token` | The client SHALL provide at least a code value and MAY provide both the system and code values. The server SHALL support both.
MAY | category | `token` | The client SHALL provide at least a code value and MAY provide both the system and code values. The server SHALL support both.
MAY | code | `token` | The client SHALL provide at least a code value and MAY provide both the system and code values. The server SHALL support both.
MAY | date | `date` | A client SHALL provide a value precise to the second + time offset. A server SHALL support a value precise to the second + time offset.

Combined Search Parameters

Conformance | Parameters | Types
--- | --- | ---
SHOULD | patient+type | `reference`+`<unknown>`
SHOULD | patient+status | `reference`+`token`

#### Resource Conformance: SHALLDocumentReference

Core FHIR Resource
DocumentReference
Reference Policy
`resolves`
Interaction summary

- SHALL support `search-type`, `read`.
- SHOULD support `vread`, `history-instance`.
- MAY support `history-type`.

Supported Profiles

US Core DocumentReference Profile

Documentation

> - The `DocumentReference.type` binding SHALL support at a minimum the US Core 6.1 5 Common Clinical Notes and may extend to the full US Core DocumentReference Type Value Set
> - The DocumentReference resources can represent the referenced content using either an address where the document can be retrieved using `DocumentReference.attachment.url` or the content as inline base64 encoded data using `DocumentReference.attachment.data`.
>   - Although both are marked as must support, the server system is not required to support an address, and inline base64 encoded data, but SHALL support at least one of these elements.
>   - The client application SHALL support both elements.
>   - The `content.url` may refer to a FHIR Binary Resource (i.e. [base]/Binary/[id]), FHIR Document Bundle (i.e [base]/Bundle/[id] or another endpoint.
>     - If the endpoint is outside the FHIR base URL, it SHOULD NOT require additional authorization to access.
> - Every DocumentReference must have a responsible Organization. The organization responsible for the DocumentReference SHALL be present either in `DocumentReference.custodian` or accessible in the Provenance resource targeting the DocumentReference using `Provenance.agent.who` or `Provenance.agent.onBehalfOf`.

Search Parameters

Conformance | Parameter | Type | Documentation
--- | --- | --- | ---
SHALL | _id | `token` |
SHALL | patient | `reference` | The client SHALL provide at least a id value and MAY provide both the Type and id values. The server SHALL support both.
MAY | status | `token` | The client SHALL provide at least a code value and MAY provide both the system and code values. The server SHALL support both.
MAY | category | `token` | The client SHALL provide at least a code value and MAY provide both the system and code values. The server SHALL support both.
MAY | type | `token` | The client SHALL provide at least a code value and MAY provide both the system and code values. The server SHALL support both.
MAY | date | `date` | A client SHALL provide a value precise to the second + time offset. A server SHALL support a value precise to the second + time offset.
MAY | period | `date` | A client SHALL provide a value precise to the second + time offset. A server SHALL support a value precise to the second + time offset.

Combined Search Parameters

Conformance | Parameters | Types
--- | --- | ---
SHALL | patient+type | `reference`+`token`
SHALL | patient+category+date | `reference`+`token`+`date`
SHALL | patient+category | `reference`+`token`
SHOULD | patient+status | `reference`+`token`
SHOULD | patient+type+period | `reference`+`token`+`date`

Extended Operations

Conformance | Operation | Documentation
--- | --- | ---
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 resources`GET [base]/DocumentReference/$docref?patient=[id]`

#### Resource Conformance: SHALLEncounter

Core FHIR Resource
Encounter
Reference Policy
`resolves`
Interaction summary

- SHALL support `search-type`, `read`.
- SHOULD support `vread`, `history-instance`.
- MAY support `history-type`.

Supported Profiles

US Core Encounter Profile

Documentation

> - The Encounter resource can represent a reason using either a code with `Encounter.reasonCode`, or a reference with `Encounter.reasonReference` to Condition or other resource.

>   - Although both are marked as must support, the server systems are not required to support both a code and a reference, but they SHALL support at least one of these elements.
>   - The client application SHALL support both elements.
>   - if `Encounter.reasonReference` references an Observation, it SHOULD conform to a US Core Observation if applicable. (for example, a laboratory result should conform to the US Core Laboratory Result Observation Profile)

> - The location address can be represented by either by the Location referenced by `Encounter.location.location` or indirectly through the Organization referenced by `Encounter.serviceProvider`.

>   - Although both are marked as must support, the server systems are not required to support both `Encounter.location.location` and `Encounter.serviceProvider`, but they SHALL support at least one of these elements.
>   - The client application SHALL support both elements.
>   - if using `Encounter.location.location` it SHOULD conform to US Core Location.

Search Parameters

Conformance | Parameter | Type | Documentation
--- | --- | --- | ---
SHALL | _id | `token` |
SHALL | patient | `reference` | The client SHALL provide at least a id value and MAY provide both the Type and id values. The server SHALL support both.
SHOULD | 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.
MAY | class | `token` | The client SHALL provide at least a code value and MAY provide both the system and code values. The server SHALL support both.
MAY | date | `date` | A client SHALL provide a value precise to the second + time offset. A server SHALL support a value precise to the second + time offset.
MAY | location | `reference` | The client SHALL provide at least a id value and MAY provide both the Type and id values. The server SHALL support both.
MAY | status | `token` | The client SHALL provide at least a code value and MAY provide both the system and code values. The server SHALL support both.
MAY | type | `token` | The client SHALL provide at least a code value and MAY provide both the system and code values. The server SHALL support both.
MAY | discharge-disposition | `token` | The client SHALL provide at least a code value and MAY provide both the system and code values. The server SHALL support both.

Combined Search Parameters

Conformance | Parameters | Types
--- | --- | ---
SHALL | date+patient | `date`+`reference`
SHOULD | patient+type | `reference`+`token`
SHOULD | class+patient | `token`+`reference`
SHOULD | patient+status | `reference`+`token`
SHOULD | patient+location | `reference`+`reference`
SHOULD | patient+discharge-disposition | `reference`+`token`

#### Resource Conformance: SHALLExplanationOfBenefit

Core FHIR Resource
ExplanationOfBenefit
Reference Policy
`resolves`
Interaction summary

- SHALL support `search-type`
  `read`

  Searches using service-date, _lastUpdated, or type require a patient search argument.

  _include:* SHALL be supported.

Supported Profiles

PDex Prior Authorization

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

Conformance | Parameter | Type | Documentation
--- | --- | --- | ---
SHALL | _id | `token` |
SHALL | patient | `reference` |
SHALL | _lastUpdated | `date` |
SHALL | type | `token` |
SHALL | identifier | `token` |
SHALL | service-date | `date` |

#### Resource Conformance: SHALLGoal

Core FHIR Resource
Goal
Reference Policy
`resolves`
Interaction summary

- SHALL support `search-type`, `read`.
- SHOULD support `vread`, `history-instance`.
- MAY support `history-type`.

Supported Profiles

US Core Goal Profile

Documentation

> - Although both `Goal.startDate` and `Goal.target.dueDate` are marked as must support, the server system is not required to support both, but SHALL support at least one of these elements. The client application SHALL support both elements.

Search Parameters

Conformance | Parameter | Type | Documentation
--- | --- | --- | ---
SHALL | patient | `reference` | The client SHALL provide at least a id value and MAY provide both the Type and id values. The server SHALL support both.
MAY | lifecycle-status | `token` | The client SHALL provide at least a code value and MAY provide both the system and code values. The server SHALL support both.
MAY | target-date | `date` | A client SHALL provide a value precise to the day. A server SHALL support a value a value precise to the day.
MAY | description | `token` |

Combined Search Parameters

Conformance | Parameters | Types
--- | --- | ---
SHOULD | patient+target-date | `reference`+`date`
SHOULD | patient+description | `reference`+`token`
SHOULD | patient+lifecycle-status | `reference`+`token`

#### 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
PDex Member Match 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 | $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: SHALLImmunization

Core FHIR Resource
Immunization
Reference Policy
`resolves`
Interaction summary

- SHALL support `search-type`, `read`.
- SHOULD support `vread`, `history-instance`.
- MAY support `history-type`.

Supported Profiles

US Core Immunization Profile

Documentation

> - Based upon the ONC U.S. Core Data for Interoperability (USCDI) requirements, CVX vaccine codes are required and the NDC vaccine codes SHOULD be supported as translations to them.

Search Parameters

Conformance | Parameter | Type | Documentation
--- | --- | --- | ---
SHALL | patient | `reference` | The client SHALL provide at least a id value and MAY provide both the Type and id values. The server SHALL support both.
MAY | status | `token` | The client SHALL provide at least a code value and MAY provide both the system and code values. The server SHALL support both.
MAY | date | `date` | A client SHALL provide a value precise to the second + time offset. A server SHALL support a value precise to the second + time offset.

Combined Search Parameters

Conformance | Parameters | Types
--- | --- | ---
SHOULD | patient+date | `reference`+`date`
SHOULD | patient+status | `reference`+`token`

#### Resource Conformance: SHALLLocation

Core FHIR Resource
Location
Reference Policy
`resolves`
Interaction summary

- SHALL support `search-type`, `read`.
- SHOULD support `vread`, `history-instance`.
- MAY support `history-type`.

Supported Profiles

US Core Location Profile

Documentation

> - The US Core Location and PractitionerRole Profiles are not explicitly referenced in any US Core Profile. However they SHOULD be used as the default profile if referenced by another US Core profile.

Search Parameters

Conformance | Parameter | Type | Documentation
--- | --- | --- | ---
SHALL | name | `string` |
SHALL | address | `string` |
SHOULD | address-city | `string` |
SHOULD | address-state | `string` |
SHOULD | address-postalcode | `string` |

#### Resource Conformance: SHALLMedication

Core FHIR Resource
Medication
Reference Policy
`resolves`
Interaction summary

- SHALL support `read`.
- SHOULD support `vread`, `history-instance`.
- MAY support `search-type`, `history-type`.

Supported Profiles

US Core Medication Profile

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: SHALLMedicationDispense

Core FHIR Resource
MedicationDispense
Reference Policy
`resolves`
Interaction summary

- SHALL support `search-type`, `read`.
- SHOULD support `vread`, `history-instance`.
- MAY support `history-type`.

Supported Profiles

PDex MedicationDispense

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 _include`parameter 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

Conformance | Parameter | Type | Documentation
--- | --- | --- | ---
SHALL | patient | `reference` | The client SHALL provide at least a id value and MAY provide both the Type and id values. The server SHALL support both.
MAY | status | `token` | The client SHALL provide at least a code value and MAY provide both the system and code values. The server SHALL support both.
MAY | type | `token` | The client SHALL provide at least a code value and MAY provide both the system and code values. The server SHALL support both.

Combined Search Parameters

Conformance | Parameters | Types
--- | --- | ---
SHOULD | patient+status+type | `reference`+`token`+`token`
SHOULD | patient+status | `reference`+`token`

#### Resource Conformance: SHALLMedicationRequest

Core FHIR Resource
MedicationRequest
Reference Policy
`resolves`
Interaction summary

- SHALL support `search-type`, `read`.
- SHOULD support `vread`, `history-instance`.
- MAY support `history-type`.

Supported Profiles

US Core MedicationRequest Profile

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 _include`parameter 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

Conformance | Parameter | Type | Documentation
--- | --- | --- | ---
MAY | status | `token` | The client SHALL provide at least a code value and MAY provide both the system and code values. The server SHALL support both.
MAY | intent | `token` | The client SHALL provide at least a code value and MAY provide both the system and code values. The server SHALL support both.
MAY | patient | `reference` | The client SHALL provide at least a id value and MAY provide both the Type and id values. The server SHALL support both.
MAY | encounter | `reference` | The client SHALL provide at least a id value and MAY provide both the Type and id values. The server SHALL support both.
MAY | authoredon | `date` | A client SHALL provide a value precise to the second + time offset. A server SHALL support a value precise to the second + time offset.

Combined Search Parameters

Conformance | Parameters | Types
--- | --- | ---
SHALL | patient+intent+status | `reference`+`token`+`token`
SHALL | patient+intent | `reference`+`token`
SHOULD | patient+intent+encounter | `reference`+`token`+`reference`
SHOULD | patient+intent+authoredon | `reference`+`token`+`date`

#### Resource Conformance: SHALLObservation

Core FHIR Resource
Observation
Reference Policy
`resolves`
Interaction summary

- SHALL support `search-type`, `read`.
- SHOULD support `vread`, `history-instance`.
- MAY support `history-type`.

Supported 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

Search Parameters

Conformance | Parameter | Type | Documentation
--- | --- | --- | ---
MAY | status | `token` | The client SHALL provide at least a code value and MAY provide both the system and code values. The server SHALL support both.
MAY | category | `token` | The client SHALL provide at least a code value and MAY provide both the system and code values. The server SHALL support both.
MAY | code | `token` | The client SHALL provide at least a code value and MAY provide both the system and code values. The server SHALL support both.
MAY | date | `date` | A client SHALL provide a value precise to the second + time offset. A server SHALL support a value precise to the second + time offset.
MAY | patient | `reference` | The client SHALL provide at least a id value and MAY provide both the Type and id values. The server SHALL support both.

Combined Search Parameters

Conformance | Parameters | Types
--- | --- | ---
| patient+code+date | `reference`+`token`+`date`
SHALL | patient+category+date | `reference`+`token`+`date`
SHALL | patient+category | `reference`+`token`
SHALL | patient+code | `reference`+`token`
SHOULD | patient+category+status | `reference`+`token`+`token`

#### Resource Conformance: SHALLOrganization

Core FHIR Resource
Organization
Reference Policy
`resolves`
Interaction summary

- SHALL support `search-type`, `read`.
- SHOULD support `vread`, `history-instance`.
- MAY support `history-type`.

Supported Profiles

US Core Organization Profile

Documentation

> - Systems SHALL support National Provider Identifier (NPI) for organizations and SHOULD support Clinical Laboratory Improvement Amendments (CLIA) identifiers for `Organization.Identifier`.

Search Parameters

Conformance | Parameter | Type | Documentation
--- | --- | --- | ---
SHALL | name | `string` |
SHALL | address | `string` |

#### Resource Conformance: SHALLPatient

Core FHIR Resource
Patient
Reference Policy
`resolves`
Interaction summary

- SHALL support `search-type`, `read`.
- SHOULD support `vread`, `history-instance`.
- MAY support `history-type`.

Supported Profiles

US Core Patient Profile

Documentation

> - For ONC's USCDI requirements, each Patient must support the following additional elements. These elements are included in the formal definition of the profile. The patient examples include all of these elements.

>   1. contact detail (e.g. a telephone number or an email address)
>   2. a communication language
>   3. a race
>   4. an ethnicity
>   5. a birth sex*
>   6. previous name
>      - Previous name is represented by providing an end date in the `Patient.name.period` element for a previous name.
>   7. suffix
>      - Suffix is represented using the `Patient.name.suffix` element.

> - The Patient's Social Security Numbers SHOULD NOT be used as a patient identifier in `Patient.identifier.value`.

Search Parameters

Conformance | Parameter | Type | Documentation
--- | --- | --- | ---
SHALL | _id | `token` |
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 | name | `string` |
MAY | birthdate | `date` | A client SHALL provide a value precise to the day. A server SHALL support a value a value precise to the day.
MAY | death-date | `date` | A client SHALL provide a value precise to the day. A server SHALL support a value a value precise to the day.
MAY | family | `string` | A server SHALL support a value precise to the day.
MAY | gender | `token` | The client SHALL provide at least a code value and MAY provide both the system and code values. The server SHALL support both.
MAY | given | `string` |

Combined Search Parameters

Conformance | Parameters | Types
--- | --- | ---
| birthdate+family | `date`+`string`
SHALL | birthdate+name | `date`+`string`
SHALL | gender+name | `token`+`string`
SHOULD | family+gender | `string`+`token`
SHOULD | death-date+family | `date`+`string`

Extended Operations

Conformance | Operation | Documentation
--- | --- | ---
SHALL | $member-match |

#### Resource Conformance: SHALLPractitioner

Core FHIR Resource
Practitioner
Reference Policy
`resolves`
Interaction summary

- SHALL support `search-type`, `read`.
- SHOULD support `vread`, `history-instance`.
- MAY support `history-type`.

Supported Profiles

US Core Practitioner Profile

Documentation

> Servers that support only US Core Practitioner Profile SHALL provide implementation specific guidance how to access a provider’s location and contact information using only the Practitioner resource.

Search Parameters

Conformance | Parameter | Type | Documentation
--- | --- | --- | ---
SHALL | name | `string` |
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.
SHOULD | _id | `token` |

#### Resource Conformance: SHALLPractitionerRole

Core FHIR Resource
PractitionerRole
Reference Policy
`resolves`
Interaction summary

- SHALL support `search-type`, `read`.
- SHOULD support `vread`, `history-instance`.
- MAY support `history-type`.

Supported Profiles

US Core PractitionerRole Profile

Documentation

> - The US Core Location and PractitionerRole Profiles are not explicitly referenced in any US Core Profile. However they SHOULD be used as the default profile if referenced by another US Core profile.

Search Parameters

Conformance | Parameter | Type | Documentation
--- | --- | --- | ---
SHALL | specialty | `token` |
SHALL | practitioner | `reference` | The client SHALL provide at least a id value and MAY provide both the Type and id values. The server SHALL support both.

#### Resource Conformance: SHALLProcedure

Core FHIR Resource
Procedure
Reference Policy
`resolves`
Interaction summary

- SHALL support `search-type`, `read`.
- SHOULD support `vread`, `history-instance`.
- MAY support `history-type`.

Supported Profiles

US Core Procedure Profile

Documentation

> - Procedure codes can be taken from SNOMED-CT, CPT, HCPCS II, ICD-10-PCS, CDT. LOINC.
>   - Only LOINC concepts that reflect actual procedures SHOULD be used
> - A procedure including an implantable device SHOULD use `Procedure.focalDevice` with a reference to the US Core Implantable Device Profile.

Search Parameters

Conformance | Parameter | Type | Documentation
--- | --- | --- | ---
SHALL | patient | `reference` | The client SHALL provide at least a id value and MAY provide both the Type and id values. The server SHALL support both.
MAY | status | `token` | The client SHALL provide at least a code value and MAY provide both the system and code values. The server SHALL support both.
MAY | date | `date` | A client SHALL provide a value precise to the second + time offset. A server SHALL support a value precise to the second + time offset.
MAY | code | `token` | The client SHALL provide at least a code value and MAY provide both the system and code values. The server SHALL support both.

Combined Search Parameters

Conformance | Parameters | Types
--- | --- | ---
SHALL | patient+date | `reference`+`date`
SHOULD | patient+code+date | `reference`+`token`+`date`
SHOULD | patient+status | `reference`+`token`

#### Resource Conformance: SHALLProvenance

Core FHIR Resource
Provenance
Reference Policy
`resolves`
Interaction summary

- SHALL support `read`.
- SHOULD support `vread`, `history-instance`.
- MAY support `search-type`, `patch`, `history-type`.

Supported Profiles

PDex Provenance
US Core Provenance Profile

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: SHOULDValueSet

Core FHIR Resource
ValueSet
Reference Policy
Interaction summary

Extended Operations

Conformance | Operation | Documentation
--- | --- | ---
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.