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

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.0 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 with US core 6.1 support

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

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

This Section describes the expected capabilities of the PDex with US Core 6.1 Support 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 and US Core Servers are defined. Systems implementing this capability statement should meet the ONC 2015 Common Clinical Data Set (CCDS) access requirement for Patient Selection 170.315(g)(7) and Application Access - Data Category Request 170.315(g)(8) and the ONC U.S. Core Data for Interoperability (USCDI) Version 3 July 2022. 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 with US core 6.1 support

  • Implementation Guide Version: 2.1.0
  • FHIR Version: 4.0.1
  • Supported Formats: SHALL support json, SHOULD support xml
  • Supported Patch Formats: SHOULDsupport 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.

This CapabilityStatement instantiates the CapabilityStatementUS Core Server CapabilityStatement

SHOULD Support the Following Implementation Guides

FHIR RESTful Capabilities

Mode: server

The PDex Server with US Core 6.1. Support SHALL:

  1. Support the US Core Patient resource profile AND at least one additional resource profile from the list of US Core Profiles AND and all Must Support US Core Profiles and resources it references.
    • Refer to the US Core 6.1 Capability Statement to determine Must Support Reference between Profiles. The table summarizes the Must Support references to other US Core Profiles and FHIR resources for each US Core Profile:
  2. Implement the RESTful behavior according to the FHIR specification.
  3. Follow the requirements documented in the US Core 6.1 General Requirements and US Core Must Support pages
  4. Return the following response classes:
    • (Status 400): invalid parameter
    • (Status 401/4xx): unauthorized request
    • (Status 403): insufficient scopes
    • (Status 404): unknown resource
  5. Support JSON source formats for all US Core interactions.

The US Core Server SHOULD:

  1. Follow the guidance documented in the US Core 6.1 General Guidance page
  2. Support XML source formats for all US Core interactions.
  3. Identify the US Core profiles supported as part of the FHIR meta.profile attribute for each instance.
Security
  1. See the US Core 6.1 General Security Considerations section for requirements and recommendations.
  2. A server SHALL reject any unauthorized requests by returning an HTTP 401 "Unauthorized", HTTP 403 "Forbidden", or HTTP 404 "Not Found"
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-RSUPCDH-IH-TSearches_include_revincludeOperations
AllergyIntoleranceSupported Profiles
  US Core AllergyIntolerance Profile
yyyyyyyyyclinical-status, patient, patient+clinical-statusProvenance:target
CarePlanSupported Profiles
  US Core CarePlan Profile
yyyyyyyyycategory, date, patient, status, patient+category+status, patient+category+status+date, patient+category, patient+category+dateProvenance:target
CareTeamSupported Profiles
  US Core CareTeam Profile
yyyyyyyyypatient, status, role, patient+status, patient+roleCareTeam:participant:PractitionerRole, CareTeam:participant:Practitioner, CareTeam:participant:Patient, CareTeam:participant:RelatedPersonProvenance:target
ConditionSupported Profiles
  US Core Condition Encounter Diagnosis Profile
  US Core Condition Problems and Health Concerns Profile
yyyyyyyyycategory, 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+categoryProvenance:target
ConsentSupported Profiles
  PDex Provider Access Consent Profile
yyyyyy_id, patientProvenance:target
CoverageSupported Profiles
  US Core Coverage Profile
yyyyyyyyypatientProvenance:target
DeviceSupported Profiles
  US Core Implantable Device Profile
  PDex Device
yyyyyyyyypatient, type, status, patient+type, patient+statusProvenance:target
DiagnosticReportSupported Profiles
  US Core DiagnosticReport Profile for Report and Note Exchange
  US Core DiagnosticReport Profile for Laboratory Results Reporting
yyyyyyyyystatus, patient, category, code, date, patient+code+date, patient+status, patient+category+date, patient+category, patient+codeProvenance:target
DocumentReferenceSupported Profiles
  US Core DocumentReference Profile
yyyyyyyyy_id, status, patient, category, type, date, period, patient+type, patient+status, patient+type+period, patient+category+date, patient+categoryProvenance:target$docref
EncounterSupported Profiles
  US Core Encounter Profile
yyyyyyyyy_id, class, date, identifier, patient, location, status, type, discharge-disposition, patient+type, class+patient, patient+status, date+patient, patient+location, patient+discharge-dispositionProvenance:target
Endpoint yyyyyyyyy
GoalSupported Profiles
  US Core Goal Profile
yyyyyyyyylifecycle-status, patient, target-date, description, patient+target-date, patient+description, patient+lifecycle-statusProvenance:target
GroupSupported Profiles
  Davinci ATR Group
  PDex Provider Group
  PDex Member Match Group
yyyyyidentifier, characteristic, Group-characteristic-value-reference
HealthcareService yyyyyyyyy
ImmunizationSupported Profiles
  US Core Immunization Profile
yyyyyyyyypatient, status, date, patient+date, patient+statusProvenance:target
LocationSupported Profiles
  US Core Location Profile
yyyyyyyyyname, address, address-city, address-state, address-postalcode
Media yyyyyyyyy
MedicationSupported Profiles
  US Core Medication Profile
yyyyyyyyy
MedicationDispenseSupported Profiles
  US Core MedicationDispense Profile
  PDex MedicationDispense
yyyyyyyyystatus, type, patient, patient+status+type, patient+statusMedicationDispense:medicationProvenance:target
MedicationRequestSupported Profiles
  US Core MedicationRequest Profile
yyyyyyyyystatus, intent, patient, encounter, authoredon, patient+intent+encounter, patient+intent+status, patient+intent+authoredon, patient+intentMedicationRequest:medicationProvenance:target
ObservationSupported Profiles
  US Core Laboratory Result Observation Profile
  US Core Observation Pregnancy Status Profile
  US Core Observation Pregnancy Intent Profile
  US Core Observation Occupation Profile
  US Core Respiratory Rate Profile
  US Core Simple Observation Profile
  US Core Heart Rate Profile
  US Core Body Temperature Profile
  US Core Pediatric Weight for Height Observation Profile
  US Core Pulse Oximetry Profile
  US Core Smoking Status Observation Profile
  US Core Observation Sexual Orientation Profile
  US Core Head Circumference Profile
  US Core Body Height Profile
  US Core BMI Profile
  US Core Observation Screening Assessment Profile
  US Core Blood Pressure Profile
  US Core Observation Clinical Result Profile
  US Core Pediatric BMI for Age Observation Profile
  US Core Pediatric Head Occipital Frontal Circumference Percentile Profile
  US Core Body Weight Profile
  US Core Vital Signs Profile
yyyyyyyyystatus, category, code, date, patient, patient+code+date, patient+category+status, patient+category+date, patient+category, patient+codeProvenance:target
OrganizationSupported Profiles
  US Core Organization Profile
yyyyyyyyyname, address
PatientSupported Profiles
  US Core Patient Profile
yyyyyyyyy_id, birthdate, death-date, family, gender, given, identifier, name, birthdate+family, family+gender, birthdate+name, gender+name, death-date+familyProvenance:target
PractitionerSupported Profiles
  US Core Practitioner Profile
yyyyyyyyy_id, name, identifier
PractitionerRoleSupported Profiles
  US Core PractitionerRole Profile
yyyyyyyyyspecialty, practitionerPractitionerRole:endpoint, PractitionerRole:practitioner
ProcedureSupported Profiles
  US Core Procedure Profile
yyyyyyyyystatus, patient, date, code, patient+code+date, patient+status, patient+dateProvenance:target
ProvenanceSupported Profiles
  US Core Provenance Profile
  PDex Provenance
yyyyyyyyy
QuestionnaireSupported Profiles
  SDCBaseQuestionnaire
yyyyyyyyy
QuestionnaireResponseSupported Profiles
  US Core QuestionnaireResponse Profile
yyyyyyyyy_id, patient, status, authored, questionnaire, patient+questionnaire, patient+authored, patient+statusProvenance:target
RelatedPersonSupported Profiles
  US Core RelatedPerson Profile
yyyyyyyyy_id, patient, name, patient+nameProvenance:target
ServiceRequestSupported Profiles
  US Core ServiceRequest Profile
yyyyyyyyystatus, patient, category, code, authored, _id, patient+category+authored, patient+status, patient+category, patient+code+authored, patient+codeProvenance:target
SpecimenSupported Profiles
  US Core Specimen Profile
yyyyyyyyy_id, patient
ValueSet $expand

Resource Conformance: SHALL AllergyIntolerance

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

Search Parameters
ConformanceParameterTypeDocumentation
SHALLpatientreference

The client SHALL provide at least a id value and MAY provide both the Type and id values.

The server SHALL support both.

MAYclinical-statustoken

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
ConformanceParametersTypes
SHOULDpatient+clinical-statusreference+token

Resource Conformance: SHALL CarePlan

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

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
ConformanceParameterTypeDocumentation
MAYcategorytoken

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

The server SHALL support both.

MAYdatedate

A client SHALL provide a value precise to the second + time offset.

A server SHALL support a value precise to the second + time offset.

MAYpatientreference

The client SHALL provide at least a id value and MAY provide both the Type and id values.

The server SHALL support both.

MAYstatustoken

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
ConformanceParametersTypes
SHALLpatient+categoryreference+token
SHOULDpatient+category+statusreference+token+token
SHOULDpatient+category+status+datereference+token+token+date
SHOULDpatient+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 create, update, patch, delete, history-type.

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
ConformanceParameterTypeDocumentation
SHOULDroletoken

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

The server SHALL support both.

MAYpatientreference

The client SHALL provide at least a id value and MAY provide both the Type and id values.

The server SHALL support both.

MAYstatustoken

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
ConformanceParametersTypes
SHALLpatient+statusreference+token
SHOULDpatient+rolereference+token

Resource Conformance: SHALL Condition

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

Documentation
  • For Encounter Diagnosis use the US Core Condition Encounter Diagnosis Profile.
    • When Condition.category is "encounter-diagnosis" the encounter, SHOULD be referenced in Condition.encounter.
  • For Problems and Health Concerns use the US Core Condition Problems and Health Concerns Profile.
    • When Condition.category is a "problems-list-item", the `Condition.clinicalStatus SHOULD NOT be unknown.
  • There is no single element in Condition that represents the date of diagnosis. It may be the assertedDate Extension, Condition.onsetDateTime, or Condition.recordedDate.
    • Although all three are marked as must support, the server is not required to support all.
    • A server SHALL support Condition.recordedDate.
    • A server SHALL support at least one of the assertedDate Extension and Condition.onsetDateTime. A server may support both, which means they support all 3 locations.
    • The client application SHALL support all three elements.
Search Parameters
ConformanceParameterTypeDocumentation
SHALLpatientreference

The client SHALL provide at least a id value and MAY provide both the Type and id values.

The server SHALL support both.

MAYcategorytoken

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

The server SHALL support both.

MAYclinical-statustoken

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

The server SHALL support both.

MAYonset-datedate

A client SHALL provide a value precise to the second + time offset.

A server SHALL support a value precise to the second + time offset.

MAYasserted-datedate

A client SHALL provide a value precise to the second + time offset.

A server SHALL support a value precise to the second + time offset.

MAYrecorded-datedate

A client SHALL provide a value precise to the second + time offset.

A server SHALL support a value precise to the second + time offset.

MAYabatement-datedate

A client SHALL provide a value precise to the second + time offset.

A server SHALL support a value precise to the second + time offset.

MAYcodetoken

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

The server SHALL support both.

MAYencounterreference

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
ConformanceParametersTypes
SHALLpatient+categoryreference+token
SHOULDpatient+recorded-datereference+date
SHOULDpatient+asserted-datereference+date
SHOULDpatient+category+clinical-statusreference+token+token
SHOULDpatient+onset-datereference+date
SHOULDpatient+abatement-datereference+date
SHOULDpatient+clinical-statusreference+token
SHOULDpatient+category+encounterreference+token+reference
SHOULDpatient+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: SHALL Coverage

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

Search Parameters
ConformanceParameterTypeDocumentation
SHALLpatientreference

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: SHALL Device

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

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
ConformanceParameterTypeDocumentation
SHALLpatientreference

The client SHALL provide at least a id value and MAY provide both the Type and id values.

The server SHALL support both.

MAYtypetoken

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

The server SHALL support both.

MAYstatustoken

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
ConformanceParametersTypes
SHOULDpatient+typereference+token
SHOULDpatient+statusreference+token

Resource Conformance: SHALL DiagnosticReport

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

Search Parameters
ConformanceParameterTypeDocumentation
SHALLpatientreference

The client SHALL provide at least a id value and MAY provide both the Type and id values.

The server SHALL support both.

MAYstatustoken

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

The server SHALL support both.

MAYcategorytoken

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

The server SHALL support both.

MAYcodetoken

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

The server SHALL support both.

MAYdatedate

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
ConformanceParametersTypes
SHALLpatient+category+datereference+token+date
SHALLpatient+categoryreference+token
SHALLpatient+codereference+token
SHOULDpatient+code+datereference+token+date
SHOULDpatient+statusreference+token

Resource Conformance: SHALL DocumentReference

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

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
ConformanceParameterTypeDocumentation
SHALL_idtoken
SHALLpatientreference

The client SHALL provide at least a id value and MAY provide both the Type and id values.

The server SHALL support both.

MAYstatustoken

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

The server SHALL support both.

MAYcategorytoken

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

The server SHALL support both.

MAYtypetoken

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

The server SHALL support both.

MAYdatedate

A client SHALL provide a value precise to the second + time offset.

A server SHALL support a value precise to the second + time offset.

MAYperioddate

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
ConformanceParametersTypes
SHALLpatient+typereference+token
SHALLpatient+category+datereference+token+date
SHALLpatient+categoryreference+token
SHOULDpatient+statusreference+token
SHOULDpatient+type+periodreference+token+date
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 document(s). SHOULD document what resources, if any, are returned as included resources

GET [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 create, update, patch, delete, history-type.

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
ConformanceParameterTypeDocumentation
SHALL_idtoken
SHALLpatientreference

The client SHALL provide at least a id value and MAY provide both the Type and id values.

The server SHALL support both.

SHOULDidentifiertoken

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

The server SHALL support both.

MAYclasstoken

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

The server SHALL support both.

MAYdatedate

A client SHALL provide a value precise to the second + time offset.

A server SHALL support a value precise to the second + time offset.

MAYlocationreference

The client SHALL provide at least a id value and MAY provide both the Type and id values.

The server SHALL support both.

MAYstatustoken

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

The server SHALL support both.

MAYtypetoken

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

The server SHALL support both.

MAYdischarge-dispositiontoken

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
ConformanceParametersTypes
SHALLdate+patientdate+reference
SHOULDpatient+typereference+token
SHOULDclass+patienttoken+reference
SHOULDpatient+statusreference+token
SHOULDpatient+locationreference+reference
SHOULDpatient+discharge-dispositionreference+token

Resource Conformance: SHALL Endpoint

Core FHIR Resource
Endpoint
Reference Policy
resolves
Interaction summary
  • SHOULDsupport read, vread.
  • MAYsupport create, search-type, update, patch, delete, history-instance, history-type.

Documentation

The Media Resource is a Must Support referenced resource when using the US Core PractitionerRole Profile.

Resource Conformance: SHALL Goal

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

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
ConformanceParameterTypeDocumentation
SHALLpatientreference

The client SHALL provide at least a id value and MAY provide both the Type and id values.

The server SHALL support both.

MAYlifecycle-statustoken

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

The server SHALL support both.

MAYtarget-datedate

A client SHALL provide a value precise to the day.

A server SHALL support a value a value precise to the day.

MAYdescriptiontoken
Combined Search Parameters
ConformanceParametersTypes
SHOULDpatient+target-datereference+date
SHOULDpatient+descriptionreference+token
SHOULDpatient+lifecycle-statusreference+token

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: MAY HealthcareService

Core FHIR Resource
HealthcareService
Reference Policy
resolves
Interaction summary
  • SHOULDsupport read, vread.
  • MAYsupport create, search-type, update, patch, delete, history-instance, history-type.

Documentation

The HealthcareService Resource is a referenced resource when using the US Core PractitionRole Profile and subject to constraint us-core-13: "SHALL have a practitioner, an organization, a healthcare service, or a location."

Resource Conformance: SHALL Immunization

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

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
ConformanceParameterTypeDocumentation
SHALLpatientreference

The client SHALL provide at least a id value and MAY provide both the Type and id values.

The server SHALL support both.

MAYstatustoken

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

The server SHALL support both.

MAYdatedate

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
ConformanceParametersTypes
SHOULDpatient+datereference+date
SHOULDpatient+statusreference+token

Resource Conformance: SHALL Location

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

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
ConformanceParameterTypeDocumentation
SHALLnamestring
SHALLaddressstring
SHOULDaddress-citystring
SHOULDaddress-statestring
SHOULDaddress-postalcodestring
 

Resource Conformance: SHALL Media

Core FHIR Resource
Media
Reference Policy
resolves
Interaction summary
  • SHOULDsupport read, vread.
  • MAYsupport create, search-type, update, patch, delete, history-instance, history-type.

Documentation

The Media Resource is a Must Support referenced resource when using the US Core DiagnosticReport Profile for Report and Note Exchange.

Resource Conformance: SHALL Medication

Core FHIR Resource
Medication
Reference Policy
resolves
Interaction summary
  • SHALLsupport read.
  • SHOULDsupport vread, history-instance.
  • MAYsupport create, search-type, update, patch, delete, 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 MedicationDispense

Core FHIR Resource
MedicationDispense
Reference Policy
resolves
Interaction summary
  • SHALLsupport search-type, read.
  • SHOULDsupport vread, history-instance.
  • MAYsupport create, update, patch, delete, 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 _include` parameter for searching this element. The client application must support all methods.

For example, A server SHALL be capable of returning dispense records for all medications for a patient using one of or both:

GET /MedicationDispense?patient=[id]

GET /MedicationDispense?patient=[id]&_include=MedicationDispense:medication

Search Parameters
ConformanceParameterTypeDocumentation
SHALLpatientreference

The client SHALL provide at least a id value and MAY provide both the Type and id values.

The server SHALL support both.

MAYstatustoken

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

The server SHALL support both.

MAYtypetoken

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
ConformanceParametersTypes
SHOULDpatient+status+typereference+token+token
SHOULDpatient+statusreference+token

Resource Conformance: SHALL MedicationRequest

Core FHIR Resource
MedicationRequest
Reference Policy
resolves
Interaction summary
  • SHALLsupport search-type, read.
  • SHOULDsupport vread, history-instance.
  • MAYsupport create, update, patch, delete, 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 _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

  • The MedicationRequest resource can represent that information is from a secondary source using either a boolean flag or reference in MedicationRequest.reportedBoolean, or a reference using MedicationRequest.reportedReference to Practitioner or other resource.
    • Although both are marked as must support, the server systems are not required to support both a boolean and a reference, but SHALL choose to support at least one of these elements.
    • The client application SHALL support both elements.
Search Parameters
ConformanceParameterTypeDocumentation
MAYstatustoken

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

The server SHALL support both.

MAYintenttoken

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

The server SHALL support both.

MAYpatientreference

The client SHALL provide at least a id value and MAY provide both the Type and id values.

The server SHALL support both.

MAYencounterreference

The client SHALL provide at least a id value and MAY provide both the Type and id values.

The server SHALL support both.

MAYauthoredondate

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
ConformanceParametersTypes
SHALLpatient+intent+statusreference+token+token
SHALLpatient+intentreference+token
SHOULDpatient+intent+encounterreference+token+reference
SHOULDpatient+intent+authoredonreference+token+date

Resource Conformance: SHALL Observation

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

Supported Profiles

http://hl7.org/fhir/us/core/StructureDefinition/us-core-observation-lab
http://hl7.org/fhir/us/core/StructureDefinition/us-core-observation-pregnancystatus
http://hl7.org/fhir/us/core/StructureDefinition/us-core-observation-pregnancyintent
http://hl7.org/fhir/us/core/StructureDefinition/us-core-observation-occupation
http://hl7.org/fhir/us/core/StructureDefinition/us-core-respiratory-rate
http://hl7.org/fhir/us/core/StructureDefinition/us-core-simple-observation
http://hl7.org/fhir/us/core/StructureDefinition/us-core-heart-rate
http://hl7.org/fhir/us/core/StructureDefinition/us-core-body-temperature
http://hl7.org/fhir/us/core/StructureDefinition/pediatric-weight-for-height
http://hl7.org/fhir/us/core/StructureDefinition/us-core-pulse-oximetry
http://hl7.org/fhir/us/core/StructureDefinition/us-core-smokingstatus
http://hl7.org/fhir/us/core/StructureDefinition/us-core-observation-sexual-orientation
http://hl7.org/fhir/us/core/StructureDefinition/us-core-head-circumference
http://hl7.org/fhir/us/core/StructureDefinition/us-core-body-height
http://hl7.org/fhir/us/core/StructureDefinition/us-core-bmi
http://hl7.org/fhir/us/core/StructureDefinition/us-core-observation-screening-assessment
http://hl7.org/fhir/us/core/StructureDefinition/us-core-blood-pressure
http://hl7.org/fhir/us/core/StructureDefinition/us-core-observation-clinical-result
http://hl7.org/fhir/us/core/StructureDefinition/pediatric-bmi-for-age
http://hl7.org/fhir/us/core/StructureDefinition/head-occipital-frontal-circumference-percentile
http://hl7.org/fhir/us/core/StructureDefinition/us-core-body-weight
http://hl7.org/fhir/us/core/StructureDefinition/us-core-vital-signs

Documentation
  • Systems SHOULD support Observation.effectivePeriod to accurately represent tests that are collected over a period of time (for example, a 24-Hour Urine Collection test).
  • An Observation without a value, SHALL include a reason why the data is absent unless there are component observations, or references to other Observations that are grouped within it
    • Systems that never provide an observation without a value are not required to support Observation.dataAbsentReason
  • An Observation.component without a value, SHALL include a reason why the data is absent.
    • Systems that never provide an component observation without a component value are not required to support Observation.component.dataAbsentReason.
  • Systems SHOULD support Observation.effectivePeriod to accurately represent procedure tests that are collected over a period of time.
Search Parameters
ConformanceParameterTypeDocumentation
MAYstatustoken

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

The server SHALL support both.

MAYcategorytoken

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

The server SHALL support both.

MAYcodetoken

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

The server SHALL support both.

MAYdatedate

A client SHALL provide a value precise to the second + time offset.

A server SHALL support a value precise to the second + time offset.

MAYpatientreference

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
ConformanceParametersTypes
SHALLpatient+category+datereference+token+date
SHALLpatient+categoryreference+token
SHALLpatient+codereference+token
SHOULDpatient+code+datereference+token+date
SHOULDpatient+category+statusreference+token+token

Resource Conformance: SHALL Organization

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

Documentation
  • Systems SHALL support National Provider Identifier (NPI) for organizations and SHOULD support Clinical Laboratory Improvement Amendments (CLIA) identifiers for Organization.Identifier.
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 create, update, patch, delete, history-type.

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
ConformanceParameterTypeDocumentation
SHALL_idtoken
SHALLidentifiertoken

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

The server SHALL support both.

SHALLnamestring
MAYbirthdatedate

A client SHALL provide a value precise to the day.

A server SHALL support a value a value precise to the day.

MAYdeath-datedate

A client SHALL provide a value precise to the day.

A server SHALL support a value a value precise to the day.

MAYfamilystring

A server SHALL support a value precise to the day.

MAYgendertoken

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

The server SHALL support both.

MAYgivenstring
Combined Search Parameters
ConformanceParametersTypes
SHALLbirthdate+namedate+string
SHALLgender+nametoken+string
SHOULDbirthdate+familydate+string
SHOULDfamily+genderstring+token
SHOULDdeath-date+familydate+string

Resource Conformance: SHALL Practitioner

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

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
ConformanceParameterTypeDocumentation
SHALLnamestring
SHALLidentifiertoken

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

The server SHALL support both.

SHOULD_idtoken
 

Resource Conformance: SHALL PractitionerRole

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

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
ConformanceParameterTypeDocumentation
SHALLspecialtytoken

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

The server SHALL support both.

SHALLpractitionerreference

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: SHALL Procedure

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

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
ConformanceParameterTypeDocumentation
SHALLpatientreference

The client SHALL provide at least a id value and MAY provide both the Type and id values.

The server SHALL support both.

MAYstatustoken

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

The server SHALL support both.

MAYdatedate

A client SHALL provide a value precise to the second + time offset.

A server SHALL support a value precise to the second + time offset.

MAYcodetoken

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
ConformanceParametersTypes
SHALLpatient+datereference+date
SHOULDpatient+code+datereference+token+date
SHOULDpatient+statusreference+token

Resource Conformance: SHALL Provenance

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

Documentation
  • The US Core Provenance resource SHALL be supported for these US Core resources:
    • AllergyIntolerance
    • CarePlan
    • CareTeam
    • Condition
    • Coverage
    • Device
    • DiagnosticReport
    • DocumentReference
    • Encounter
    • Goal
    • Immunization
    • MedicationDispense
    • MedicationRequest
    • Observation
    • Patient
    • Procedure
    • QuestionnaireResponse
    • RelatedPerson
    • ServiceRequest
  • 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.
  • Systems that need to know the activity has occurred SHOULD populate the activity.

Resource Conformance: SHOULD Questionnaire

Core FHIR Resource
Questionnaire
Reference Policy
Interaction summary
  • SHOULDsupport read, vread.
  • MAYsupport create, search-type, update, patch, delete, history-instance, history-type.

Documentation

US Core defines two ways to represent the questions and responses to screening and assessment instruments:

  • Observation: US Core Observation Screening Assessment Profile
  • Questionnaire/QuestionnaireResponse: SDC Base Questionnaire/US Core QuestionnaireResponse Profile

US Core Servers SHALL support US Core Observation Screening Assessment Profile and SHOULD support the SDC Base Questionnaire Profile/US Core QuestionnaireResponse Profile

Resource Conformance: SHOULD QuestionnaireResponse

Core FHIR Resource
QuestionnaireResponse
Reference Policy
Interaction summary
  • SHOULDsupport search-type, read, vread, history-instance.
  • MAYsupport create, update, patch, delete, history-type.

Documentation

US Core defines two ways to represent the questions and responses to screening and assessment instruments:

  • Observation: US Core Observation Screening Assessment Profile
  • Questionnaire/QuestionnaireResponse: SDC Base Questionnaire/US Core QuestionnaireResponse Profile

US Core Servers SHALL support US Core Observation Screening Assessment Profile and SHOULD support the SDC Base Questionnaire Profile/US Core QuestionnaireResponse Profile

Search Parameters
ConformanceParameterTypeDocumentation
SHALL_idtoken
SHALLpatientreference

The client SHALL provide at least a id value and MAY provide both the Type and id values.

The server SHALL support both.

MAYstatustoken

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

The server SHALL support both.

MAYauthoreddate

A client SHALL provide a value precise to the second + time offset.

A server SHALL support a value precise to the second + time offset.

MAYquestionnairereference

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
ConformanceParametersTypes
SHOULDpatient+questionnairereference+reference
SHOULDpatient+authoredreference+date
SHOULDpatient+statusreference+token

Resource Conformance: SHALL RelatedPerson

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

Search Parameters
ConformanceParameterTypeDocumentation
SHALL_idtoken
SHOULDpatientreference

The client SHALL provide at least a id value and MAY provide both the Type and id values.

The server SHALL support both.

SHOULDnamestring
Combined Search Parameters
ConformanceParametersTypes
SHOULDpatient+namereference+string

Resource Conformance: SHALL ServiceRequest

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

Search Parameters
ConformanceParameterTypeDocumentation
SHALLpatientreference

The client SHALL provide at least a id value and MAY provide both the Type and id values.

The server SHALL support both.

SHALL_idtoken
MAYstatustoken

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

The server SHALL support both.

MAYcategorytoken

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

The server SHALL support both.

MAYcodetoken

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

The server SHALL support both.

MAYauthoreddate

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
ConformanceParametersTypes
SHALLpatient+category+authoredreference+token+date
SHALLpatient+categoryreference+token
SHALLpatient+codereference+token
SHOULDpatient+statusreference+token
SHOULDpatient+code+authoredreference+token+date

Resource Conformance: SHALL Specimen

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

Search Parameters
ConformanceParameterTypeDocumentation
SHALL_idtoken
SHOULDpatientreference
 

Resource Conformance: SHOULD ValueSet

Core FHIR Resource
ValueSet
Reference Policy
Interaction summary

    Extended Operations
    ConformanceOperationDocumentation
    SHOULD$expand

    If a server supports DocumentReference for creating, using, and sharing clinical notes, it SHOULD also support the context and contextdirection parameters of the $expand operation to enable clients to determine the supported note and report types, as well as the supported read/write formats for notes on the server.