USCore

This page is part of the US Core (v3.1.1: STU3) based on FHIR R4. The current version which supercedes this version is 5.0.1. For a full list of available versions, see the Directory of published versions

Downloads: CapabilityStatement: (XML, JSON),OpenAPI-Swagger Definition file

US Core Server CapabilityStatement

Implementation Guide Version: 3.1.1
FHIR Version: 4.0.1
Supported formats: xml, json
Published: 2020-07-28
Published by: HL7 International - US Realm Steering Committee

This Section describes the expected capabilities of the US Core Server actor which is responsible for providing responses to the queries submitted by the US Core Requestors. The complete list of FHIR profiles, RESTful operations, and search parameters supported by 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 and the ONC U.S. Core Data for Interoperability (USCDI). US Core Clients have the option of choosing from this list to access necessary data based on their local use cases and other contextual requirements.

FHIR RESTful Capabilities

The US Core Server SHALL:

Support the US Core Patient resource profile.
Support at least one additional resource profile from the list of US Core Profiles.
Implement the RESTful behavior according to the FHIR specification.
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.
Support json source formats for all US Core interactions.

The US Core Server SHOULD:

Support xml source formats for all US Core interactions.
Identify the US Core profiles supported as part of the FHIR meta.profile attribute for each instance.
Support xml resource formats for all Argonaut questionnaire interactions.

Security:

See the General Security Considerations section for requirements and recommendations.
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.

RESTful Capabilities by Resource/Profile:

Summary of Search Criteria

Resource Type Supported Profiles Supported Searches Supported _includes Supported _revincludes Supported Operations

AllergyIntolerance US Core AllergyIntolerance Profile clinical-status, patient patient+clinical-status Provenance:target

CarePlan US Core CarePlan Profile category, date, patient, status patient+category+status+date, patient+category+status, patient+category, patient+category+date Provenance:target

CareTeam US Core CareTeam Profile patient, status patient+status Provenance:target

Condition US Core Condition Profile category, clinical-status, patient, onset-date, code patient+onset-date, patient+category, patient+clinical-status, patient+code Provenance:target

Device US Core Implantable Device Profile patient, type patient+type Provenance:target

DiagnosticReport US Core DiagnosticReport Profile for Report and Note exchange, US Core DiagnosticReport Profile for Laboratory Results Reporting status, patient, category, code, date patient+category+date, patient+status, patient+code+date, patient+code, patient+category Provenance:target

DocumentReference US Core DocumentReference Profile _id, status, patient, category, type, date, period patient+type+period, patient+type, patient+category+date, patient+status, patient+category Provenance:target docref

Encounter US Core Encounter Profile _id, class, date, identifier, patient, status, type class+patient, patient+status, patient+type, date+patient Provenance:target

Goal US Core Goal Profile lifecycle-status, patient, target-date patient+lifecycle-status, patient+target-date Provenance:target

Immunization US Core Immunization Profile patient, status, date patient+date, patient+status Provenance:target

Location US Core Location Profile name, address, address-city, address-state, address-postalcode

Resource Type	Supported Profiles	Supported Searches	Supported `_includes`	Supported `_revincludes`	Supported Operations
AllergyIntolerance	US Core AllergyIntolerance Profile	clinical-status, patient patient+clinical-status		Provenance:target
CarePlan	US Core CarePlan Profile	category, date, patient, status patient+category+status+date, patient+category+status, patient+category, patient+category+date		Provenance:target
CareTeam	US Core CareTeam Profile	patient, status patient+status		Provenance:target
Condition	US Core Condition Profile	category, clinical-status, patient, onset-date, code patient+onset-date, patient+category, patient+clinical-status, patient+code		Provenance:target
Device	US Core Implantable Device Profile	patient, type patient+type		Provenance:target
DiagnosticReport	US Core DiagnosticReport Profile for Report and Note exchange, US Core DiagnosticReport Profile for Laboratory Results Reporting	status, patient, category, code, date patient+category+date, patient+status, patient+code+date, patient+code, patient+category		Provenance:target
DocumentReference	US Core DocumentReference Profile	_id, status, patient, category, type, date, period patient+type+period, patient+type, patient+category+date, patient+status, patient+category		Provenance:target	docref
Encounter	US Core Encounter Profile	_id, class, date, identifier, patient, status, type class+patient, patient+status, patient+type, date+patient		Provenance:target
Goal	US Core Goal Profile	lifecycle-status, patient, target-date patient+lifecycle-status, patient+target-date		Provenance:target
Immunization	US Core Immunization Profile	patient, status, date patient+date, patient+status		Provenance:target
Location	US Core Location Profile	name, address, address-city, address-state, address-postalcode
Medication	US Core Medication Profile
MedicationRequest	US Core MedicationRequest Profile	status, intent, patient, encounter, authoredon patient+intent, patient+intent+encounter, patient+intent+authoredon, patient+intent+status	MedicationRequest:medication	Provenance:target
Observation	US Core Smoking Status Observation Profile, US Core Pediatric Weight for Height Observation Profile, US Core Laboratory Result Observation Profile, US Core Pediatric BMI for Age Observation Profile, US Core Pulse Oximetry Profile, US Core Pediatric Head Occipital-frontal Circumference Percentile Profile	status, category, code, date, patient patient+category+date, patient+category+status, patient+code+date, patient+code, patient+category		Provenance:target
Organization	US Core Organization Profile	name, address
Patient	US Core Patient Profile	_id, birthdate, family, gender, given, identifier, name birthdate+family, family+gender, birthdate+name, gender+name		Provenance:target
Practitioner	US Core Practitioner Profile	name, identifier
PractitionerRole	US Core PractitionerRole Profile	specialty, practitioner	PractitionerRole:endpoint, PractitionerRole:practitioner
Procedure	US Core Procedure Profile	status, patient, date, code patient+date, patient+status, patient+code+date		Provenance:target
Provenance	US Core Provenance Profile
ValueSet					expand

Medication

US Core Medication Profile

MedicationRequest US Core MedicationRequest Profile status, intent, patient, encounter, authoredon patient+intent, patient+intent+encounter, patient+intent+authoredon, patient+intent+status MedicationRequest:medication Provenance:target

Observation US Core Smoking Status Observation Profile, US Core Pediatric Weight for Height Observation Profile, US Core Laboratory Result Observation Profile, US Core Pediatric BMI for Age Observation Profile, US Core Pulse Oximetry Profile, US Core Pediatric Head Occipital-frontal Circumference Percentile Profile status, category, code, date, patient patient+category+date, patient+category+status, patient+code+date, patient+code, patient+category Provenance:target

Organization US Core Organization Profile name, address

Patient US Core Patient Profile _id, birthdate, family, gender, given, identifier, name birthdate+family, family+gender, birthdate+name, gender+name Provenance:target

Practitioner US Core Practitioner Profile name, identifier

PractitionerRole US Core PractitionerRole Profile specialty, practitioner PractitionerRole:endpoint, PractitionerRole:practitioner

Procedure US Core Procedure Profile status, patient, date, code patient+date, patient+status, patient+code+date Provenance:target

Provenance

US Core Provenance Profile

ValueSet expand

AllergyIntolerance

Conformance Expectation: SHALL

Supported Profiles: US Core AllergyIntolerance Profile

Reference Policy: resolves

Profile Interaction Summary:

SHALL support search-type, read.
SHOULD support vread, history-instance.
MAY support create, update, patch, delete, history-type.

Fetch and Search Criteria:

A Server SHALL be capable of returning a AllergyIntolerance resource using:
GET [base]/AllergyIntolerance/[id]

A Server SHALL be capable of supporting the following _revincludes:
Provenance:target - GET [base]/AllergyIntolerance?[parameter=value]&_revinclude=Provenance:target

Search Parameter Summary:

Conformance Parameter Type Example

MAY clinical-status token GET [base]/AllergyIntolerance?clinical-status=[system]|[code]

SHALL patient reference GET [base]/AllergyIntolerance?patient=[patient]

Conformance	Parameter	Type	Example
MAY	clinical-status	token	`GET [base]/AllergyIntolerance?clinical-status=[system]\|[code]`
SHALL	patient	reference	`GET [base]/AllergyIntolerance?patient=[patient]`

Search Parameter Combination Summary:

Conformance Parameter Combination Types Example

SHOULD patient+clinical-status reference+token GET [base]/AllergyIntolerance?patient=[patient]&clinical-status=[system]|[code]

Conformance	Parameter Combination	Types	Example
SHOULD	patient+clinical-status	reference+token	`GET [base]/AllergyIntolerance?patient=[patient]&clinical-status=[system]\|[code]`

CarePlan

Conformance Expectation: SHALL

Supported Profiles: US Core CarePlan Profile

Reference Policy: resolves

Profile Interaction Summary:

SHALL support search-type, read.
SHOULD support vread, history-instance.
MAY support create, update, patch, delete, history-type.

Fetch and Search Criteria:

A Server SHALL be capable of returning a CarePlan resource using:
GET [base]/CarePlan/[id]

A Server SHALL be capable of supporting the following _revincludes:
Provenance:target - GET [base]/CarePlan?[parameter=value]&_revinclude=Provenance:target

Search Parameter Summary:

Conformance Parameter Type Example

MAY category token GET [base]/CarePlan?category=[system]|[code]

MAY date date GET [base]/CarePlan?date=[date]

MAY patient reference GET [base]/CarePlan?patient=[patient]

MAY status token GET [base]/CarePlan?status=[status]

Conformance	Parameter	Type	Example
MAY	category	token	`GET [base]/CarePlan?category=[system]\|[code]`
MAY	date	date	`GET [base]/CarePlan?date=[date]`
MAY	patient	reference	`GET [base]/CarePlan?patient=[patient]`
MAY	status	token	`GET [base]/CarePlan?status=[status]`

Search Parameter Combination Summary:

Conformance Parameter Combination Types Example

SHOULD patient+category+status+date reference+token+token+date GET [base]/CarePlan?patient=[patient]&category=[system]|[code]&status=[status]&date=[date]

SHOULD patient+category+status reference+token+token GET [base]/CarePlan?patient=[patient]&category=[system]|[code]&status=[status]

SHALL patient+category reference+token GET [base]/CarePlan?patient=[patient]&category=[system]|[code]

SHOULD patient+category+date reference+token+date GET [base]/CarePlan?patient=[patient]&category=[system]|[code]&date=[date]

Conformance	Parameter Combination	Types	Example
SHOULD	patient+category+status+date	reference+token+token+date	`GET [base]/CarePlan?patient=[patient]&category=[system]\|[code]&status=[status]&date=[date]`
SHOULD	patient+category+status	reference+token+token	`GET [base]/CarePlan?patient=[patient]&category=[system]\|[code]&status=[status]`
SHALL	patient+category	reference+token	`GET [base]/CarePlan?patient=[patient]&category=[system]\|[code]`
SHOULD	patient+category+date	reference+token+date	`GET [base]/CarePlan?patient=[patient]&category=[system]\|[code]&date=[date]`

CareTeam

Conformance Expectation: SHALL

Supported Profiles: US Core CareTeam Profile

Reference Policy: resolves

Profile Interaction Summary:

SHALL support search-type, read.
SHOULD support vread, history-instance.
MAY support create, update, patch, delete, history-type.

Fetch and Search Criteria:

A Server SHALL be capable of returning a CareTeam resource using:
GET [base]/CareTeam/[id]

A Server SHALL be capable of supporting the following _revincludes:
Provenance:target - GET [base]/CareTeam?[parameter=value]&_revinclude=Provenance:target

Search Parameter Summary:

Conformance Parameter Type Example

MAY patient reference GET [base]/CareTeam?patient=[patient]

MAY status token GET [base]/CareTeam?status=[status]

Conformance	Parameter	Type	Example
MAY	patient	reference	`GET [base]/CareTeam?patient=[patient]`
MAY	status	token	`GET [base]/CareTeam?status=[status]`

Search Parameter Combination Summary:

Conformance Parameter Combination Types Example

SHALL patient+status reference+token GET [base]/CareTeam?patient=[patient]&status=[status]

Conformance	Parameter Combination	Types	Example
SHALL	patient+status	reference+token	`GET [base]/CareTeam?patient=[patient]&status=[status]`

Condition

Conformance Expectation: SHALL

Supported Profiles: US Core Condition Profile

Reference Policy: resolves

Profile Interaction Summary:

SHALL support search-type, read.
SHOULD support vread, history-instance.
MAY support create, update, patch, delete, history-type.

Fetch and Search Criteria:

A Server SHALL be capable of returning a Condition resource using:
GET [base]/Condition/[id]

A Server SHALL be capable of supporting the following _revincludes:
Provenance:target - GET [base]/Condition?[parameter=value]&_revinclude=Provenance:target

Search Parameter Summary:

Conformance Parameter Type Example

MAY category token GET [base]/Condition?category=[system]|[code]

MAY clinical-status token GET [base]/Condition?clinical-status=[system]|[code]

SHALL patient reference GET [base]/Condition?patient=[patient]

MAY onset-date date GET [base]/Condition?onset-date=[onset-date]

MAY code token GET [base]/Condition?code=[system]|[code]

Conformance	Parameter	Type	Example
MAY	category	token	`GET [base]/Condition?category=[system]\|[code]`
MAY	clinical-status	token	`GET [base]/Condition?clinical-status=[system]\|[code]`
SHALL	patient	reference	`GET [base]/Condition?patient=[patient]`
MAY	onset-date	date	`GET [base]/Condition?onset-date=[onset-date]`
MAY	code	token	`GET [base]/Condition?code=[system]\|[code]`

Search Parameter Combination Summary:

Conformance Parameter Combination Types Example

SHOULD patient+onset-date reference+date GET [base]/Condition?patient=[patient]&onset-date=[onset-date]

SHOULD patient+category reference+token GET [base]/Condition?patient=[patient]&category=[system]|[code]

SHOULD patient+clinical-status reference+token GET [base]/Condition?patient=[patient]&clinical-status=[system]|[code]

SHOULD patient+code reference+token GET [base]/Condition?patient=[patient]&code=[system]|[code]

Conformance	Parameter Combination	Types	Example
SHOULD	patient+onset-date	reference+date	`GET [base]/Condition?patient=[patient]&onset-date=[onset-date]`
SHOULD	patient+category	reference+token	`GET [base]/Condition?patient=[patient]&category=[system]\|[code]`
SHOULD	patient+clinical-status	reference+token	`GET [base]/Condition?patient=[patient]&clinical-status=[system]\|[code]`
SHOULD	patient+code	reference+token	`GET [base]/Condition?patient=[patient]&code=[system]\|[code]`

Device

Conformance Expectation: SHALL

Supported Profiles: US Core Implantable Device Profile

Reference Policy: resolves

Profile Interaction Summary:

SHALL support search-type, read.
SHOULD support vread, history-instance.
MAY support create, update, patch, delete, history-type.

Fetch and Search Criteria:

A Server SHALL be capable of returning a Device resource using:
GET [base]/Device/[id]

A Server SHALL be capable of supporting the following _revincludes:
Provenance:target - GET [base]/Device?[parameter=value]&_revinclude=Provenance:target

Search Parameter Summary:

Conformance Parameter Type Example

SHALL patient reference GET [base]/Device?patient=[patient]

MAY type token GET [base]/Device?type=[system]|[code]

Conformance	Parameter	Type	Example
SHALL	patient	reference	`GET [base]/Device?patient=[patient]`
MAY	type	token	`GET [base]/Device?type=[system]\|[code]`

Search Parameter Combination Summary:

Conformance Parameter Combination Types Example

SHOULD patient+type reference+token GET [base]/Device?patient=[patient]&type=[system]|[code]

Conformance	Parameter Combination	Types	Example
SHOULD	patient+type	reference+token	`GET [base]/Device?patient=[patient]&type=[system]\|[code]`

DiagnosticReport

Conformance Expectation: SHALL

Supported Profiles: US Core DiagnosticReport Profile for Report and Note exchange, US Core DiagnosticReport Profile for Laboratory Results Reporting

Reference Policy: resolves

Profile Interaction Summary:

SHALL support create^†, search-type, read.
SHOULD support vread, history-instance.
MAY support update, patch, delete, history-type.

create^†
This conformance expectation applies only to the US Core DiagnosticReport Profile for Report and Note exchange profile. The conformance expectation for the US Core DiagnosticReport Profile for Laboratory Results Reporting is MAY.

Fetch and Search Criteria:

A Server SHALL be capable of returning a DiagnosticReport resource using:
GET [base]/DiagnosticReport/[id]

A Server SHALL be capable of supporting the following _revincludes:
Provenance:target - GET [base]/DiagnosticReport?[parameter=value]&_revinclude=Provenance:target

Search Parameter Summary:

Conformance Parameter Type Example

MAY status token GET [base]/DiagnosticReport?status=[status]

SHALL patient reference GET [base]/DiagnosticReport?patient=[patient]

MAY category token GET [base]/DiagnosticReport?category=[system]|[code]

MAY code token GET [base]/DiagnosticReport?code=[system]|[code]

MAY date date GET [base]/DiagnosticReport?date=[date]

Conformance	Parameter	Type	Example
MAY	status	token	`GET [base]/DiagnosticReport?status=[status]`
SHALL	patient	reference	`GET [base]/DiagnosticReport?patient=[patient]`
MAY	category	token	`GET [base]/DiagnosticReport?category=[system]\|[code]`
MAY	code	token	`GET [base]/DiagnosticReport?code=[system]\|[code]`
MAY	date	date	`GET [base]/DiagnosticReport?date=[date]`

Search Parameter Combination Summary:

Conformance Parameter Combination Types Example

SHALL patient+category+date reference+token+date GET [base]/DiagnosticReport?patient=[patient]&category=[system]|[code]&date=[date]

SHOULD patient+status reference+token GET [base]/DiagnosticReport?patient=[patient]&status=[status]

SHOULD patient+code+date reference+token+date GET [base]/DiagnosticReport?patient=[patient]&code=[system]|[code]&date=[date]

SHALL patient+code reference+token GET [base]/DiagnosticReport?patient=[patient]&code=[system]|[code]

SHALL patient+category reference+token GET [base]/DiagnosticReport?patient=[patient]&category=[system]|[code]

Conformance	Parameter Combination	Types	Example
SHALL	patient+category+date	reference+token+date	`GET [base]/DiagnosticReport?patient=[patient]&category=[system]\|[code]&date=[date]`
SHOULD	patient+status	reference+token	`GET [base]/DiagnosticReport?patient=[patient]&status=[status]`
SHOULD	patient+code+date	reference+token+date	`GET [base]/DiagnosticReport?patient=[patient]&code=[system]\|[code]&date=[date]`
SHALL	patient+code	reference+token	`GET [base]/DiagnosticReport?patient=[patient]&code=[system]\|[code]`
SHALL	patient+category	reference+token	`GET [base]/DiagnosticReport?patient=[patient]&category=[system]\|[code]`

DocumentReference

Conformance Expectation: SHALL

Supported Profiles: US Core DocumentReference Profile

Resource Specific Documentation:

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

Reference Policy: resolves

Profile Interaction Summary:

SHALL support create, search-type, read.
SHOULD support vread, history-instance.
MAY support update, patch, delete, history-type.

Operation Summary:

SHALL support the $docref operation
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]

Fetch and Search Criteria:

A Server SHALL be capable of returning a DocumentReference resource using:
GET [base]/DocumentReference/[id]

A Server SHALL be capable of supporting the following _revincludes:
Provenance:target - GET [base]/DocumentReference?[parameter=value]&_revinclude=Provenance:target

Search Parameter Summary:

Conformance Parameter Type Example

SHALL _id token GET [base]/DocumentReference?_id=[id]

MAY status token GET [base]/DocumentReference?status=[status]

SHALL patient reference GET [base]/DocumentReference?patient=[patient]

MAY category token GET [base]/DocumentReference?category=[system]|[code]

MAY type token GET [base]/DocumentReference?type=[system]|[code]

MAY date date GET [base]/DocumentReference?date=[date]

MAY period date GET [base]/DocumentReference?period=[period]

Conformance	Parameter	Type	Example
SHALL	_id	token	`GET [base]/DocumentReference?_id=[id]`
MAY	status	token	`GET [base]/DocumentReference?status=[status]`
SHALL	patient	reference	`GET [base]/DocumentReference?patient=[patient]`
MAY	category	token	`GET [base]/DocumentReference?category=[system]\|[code]`
MAY	type	token	`GET [base]/DocumentReference?type=[system]\|[code]`
MAY	date	date	`GET [base]/DocumentReference?date=[date]`
MAY	period	date	`GET [base]/DocumentReference?period=[period]`

Search Parameter Combination Summary:

Conformance Parameter Combination Types Example

SHOULD patient+type+period reference+token+date GET [base]/DocumentReference?patient=[patient]&type=[system]|[code]&period=[period]

SHALL patient+type reference+token GET [base]/DocumentReference?patient=[patient]&type=[system]|[code]

SHALL patient+category+date reference+token+date GET [base]/DocumentReference?patient=[patient]&category=[system]|[code]&date=[date]

SHOULD patient+status reference+token GET [base]/DocumentReference?patient=[patient]&status=[status]

SHALL patient+category reference+token GET [base]/DocumentReference?patient=[patient]&category=[system]|[code]

Conformance	Parameter Combination	Types	Example
SHOULD	patient+type+period	reference+token+date	`GET [base]/DocumentReference?patient=[patient]&type=[system]\|[code]&period=[period]`
SHALL	patient+type	reference+token	`GET [base]/DocumentReference?patient=[patient]&type=[system]\|[code]`
SHALL	patient+category+date	reference+token+date	`GET [base]/DocumentReference?patient=[patient]&category=[system]\|[code]&date=[date]`
SHOULD	patient+status	reference+token	`GET [base]/DocumentReference?patient=[patient]&status=[status]`
SHALL	patient+category	reference+token	`GET [base]/DocumentReference?patient=[patient]&category=[system]\|[code]`

Encounter

Conformance Expectation: SHALL

Supported Profiles: US Core Encounter Profile

Reference Policy: resolves

Profile Interaction Summary:

SHALL support search-type, read.
SHOULD support vread, history-instance.
MAY support create, update, patch, delete, history-type.

Fetch and Search Criteria:

A Server SHALL be capable of returning a Encounter resource using:
GET [base]/Encounter/[id]

A Server SHALL be capable of supporting the following _revincludes:
Provenance:target - GET [base]/Encounter?[parameter=value]&_revinclude=Provenance:target

Search Parameter Summary:

Conformance Parameter Type Example

SHALL _id token GET [base]/Encounter?_id=[id]

MAY class token GET [base]/Encounter?class=[system]|[code]

MAY date date GET [base]/Encounter?date=[date]

SHOULD identifier token GET [base]/Encounter?identifier=[system]|[code]

SHALL patient reference GET [base]/Encounter?patient=[patient]

MAY status token GET [base]/Encounter?status=[status]

MAY type token GET [base]/Encounter?type=[system]|[code]

Conformance	Parameter	Type	Example
SHALL	_id	token	`GET [base]/Encounter?_id=[id]`
MAY	class	token	`GET [base]/Encounter?class=[system]\|[code]`
MAY	date	date	`GET [base]/Encounter?date=[date]`
SHOULD	identifier	token	`GET [base]/Encounter?identifier=[system]\|[code]`
SHALL	patient	reference	`GET [base]/Encounter?patient=[patient]`
MAY	status	token	`GET [base]/Encounter?status=[status]`
MAY	type	token	`GET [base]/Encounter?type=[system]\|[code]`

Search Parameter Combination Summary:

Conformance Parameter Combination Types Example

SHOULD class+patient token+reference GET [base]/Encounter?class=[system]|[code]&patient=[patient]

SHOULD patient+status reference+token GET [base]/Encounter?patient=[patient]&status=[status]

SHOULD patient+type reference+token GET [base]/Encounter?patient=[patient]&type=[system]|[code]

SHALL date+patient date+reference GET [base]/Encounter?date=[date]&patient=[patient]

Conformance	Parameter Combination	Types	Example
SHOULD	class+patient	token+reference	`GET [base]/Encounter?class=[system]\|[code]&patient=[patient]`
SHOULD	patient+status	reference+token	`GET [base]/Encounter?patient=[patient]&status=[status]`
SHOULD	patient+type	reference+token	`GET [base]/Encounter?patient=[patient]&type=[system]\|[code]`
SHALL	date+patient	date+reference	`GET [base]/Encounter?date=[date]&patient=[patient]`

Goal

Conformance Expectation: SHALL

Supported Profiles: US Core Goal Profile

Reference Policy: resolves

Profile Interaction Summary:

SHALL support search-type, read.
SHOULD support vread, history-instance.
MAY support create, update, patch, delete, history-type.

Fetch and Search Criteria:

A Server SHALL be capable of returning a Goal resource using:
GET [base]/Goal/[id]

A Server SHALL be capable of supporting the following _revincludes:
Provenance:target - GET [base]/Goal?[parameter=value]&_revinclude=Provenance:target

Search Parameter Summary:

Conformance Parameter Type Example

MAY lifecycle-status token GET [base]/Goal?lifecycle-status=[system]|[code]

SHALL patient reference GET [base]/Goal?patient=[patient]

MAY target-date date GET [base]/Goal?target-date=[target-date]

Conformance	Parameter	Type	Example
MAY	lifecycle-status	token	`GET [base]/Goal?lifecycle-status=[system]\|[code]`
SHALL	patient	reference	`GET [base]/Goal?patient=[patient]`
MAY	target-date	date	`GET [base]/Goal?target-date=[target-date]`

Search Parameter Combination Summary:

Conformance Parameter Combination Types Example

SHOULD patient+lifecycle-status reference+token GET [base]/Goal?patient=[patient]&lifecycle-status=[system]|[code]

SHOULD patient+target-date reference+date GET [base]/Goal?patient=[patient]&target-date=[target-date]

Conformance	Parameter Combination	Types	Example
SHOULD	patient+lifecycle-status	reference+token	`GET [base]/Goal?patient=[patient]&lifecycle-status=[system]\|[code]`
SHOULD	patient+target-date	reference+date	`GET [base]/Goal?patient=[patient]&target-date=[target-date]`

Immunization

Conformance Expectation: SHALL

Supported Profiles: US Core Immunization Profile

Reference Policy: resolves

Profile Interaction Summary:

SHALL support search-type, read.
SHOULD support vread, history-instance.
MAY support create, update, patch, delete, history-type.

Fetch and Search Criteria:

A Server SHALL be capable of returning a Immunization resource using:
GET [base]/Immunization/[id]

A Server SHALL be capable of supporting the following _revincludes:
Provenance:target - GET [base]/Immunization?[parameter=value]&_revinclude=Provenance:target

Search Parameter Summary:

Conformance Parameter Type Example

SHALL patient reference GET [base]/Immunization?patient=[patient]

MAY status token GET [base]/Immunization?status=[status]

MAY date date GET [base]/Immunization?date=[date]

Conformance	Parameter	Type	Example
SHALL	patient	reference	`GET [base]/Immunization?patient=[patient]`
MAY	status	token	`GET [base]/Immunization?status=[status]`
MAY	date	date	`GET [base]/Immunization?date=[date]`

Search Parameter Combination Summary:

Conformance Parameter Combination Types Example

SHOULD patient+date reference+date GET [base]/Immunization?patient=[patient]&date=[date]

SHOULD patient+status reference+token GET [base]/Immunization?patient=[patient]&status=[status]

Conformance	Parameter Combination	Types	Example
SHOULD	patient+date	reference+date	`GET [base]/Immunization?patient=[patient]&date=[date]`
SHOULD	patient+status	reference+token	`GET [base]/Immunization?patient=[patient]&status=[status]`

Location

Conformance Expectation: SHALL

Supported Profiles: US Core Location Profile

Reference Policy: resolves

Profile Interaction Summary:

SHALL support search-type, read.
SHOULD support vread, history-instance.
MAY support create, update, patch, delete, history-type.

Fetch and Search Criteria:

A Server SHALL be capable of returning a Location resource using:
GET [base]/Location/[id]

Search Parameter Summary:

Conformance Parameter Type Example

SHALL name string GET [base]/Location?name=[name]

SHALL address string GET [base]/Location?address=[address]

SHOULD address-city string GET [base]/Location?address-city=[address-city]

SHOULD address-state string GET [base]/Location?address-state=[address-state]

SHOULD address-postalcode string GET [base]/Location?address-postalcode=[address-postalcode]

Conformance	Parameter	Type	Example
SHALL	name	string	`GET [base]/Location?name=[name]`
SHALL	address	string	`GET [base]/Location?address=[address]`
SHOULD	address-city	string	`GET [base]/Location?address-city=[address-city]`
SHOULD	address-state	string	`GET [base]/Location?address-state=[address-state]`
SHOULD	address-postalcode	string	`GET [base]/Location?address-postalcode=[address-postalcode]`

Medication

Conformance Expectation: SHALL

Supported Profiles: US Core Medication Profile

Resource Specific Documentation:

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

Reference Policy: resolves

Profile Interaction Summary:

SHALL support read.
SHOULD support vread, history-instance.
MAY support create, search-type, update, patch, delete, history-type.

Fetch and Search Criteria:

A Server SHALL be capable of returning a Medication resource using:
GET [base]/Medication/[id]

MedicationRequest

Conformance Expectation: SHALL

Supported Profiles: US Core MedicationRequest Profile

Resource Specific 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

Reference Policy: resolves

Profile Interaction Summary:

SHALL support search-type, read.
SHOULD support vread, history-instance.
MAY support create, update, patch, delete, history-type.

Fetch and Search Criteria:

A Server SHALL be capable of returning a MedicationRequest resource using:
GET [base]/MedicationRequest/[id]

A Server SHOULD be capable of supporting the following _includes:
MedicationRequest:medication - GET [base]/MedicationRequest?[parameter=value]&_include=MedicationRequest:medication

A Server SHALL be capable of supporting the following _revincludes:
Provenance:target - GET [base]/MedicationRequest?[parameter=value]&_revinclude=Provenance:target

Search Parameter Summary:

Conformance Parameter Type Example

MAY status token GET [base]/MedicationRequest?status=[status]

MAY intent token GET [base]/MedicationRequest?intent=[system]|[code]

MAY patient reference GET [base]/MedicationRequest?patient=[patient]

MAY encounter reference GET [base]/MedicationRequest?encounter=[encounter]

MAY authoredon date GET [base]/MedicationRequest?authoredon=[authoredon]

Conformance	Parameter	Type	Example
MAY	status	token	`GET [base]/MedicationRequest?status=[status]`
MAY	intent	token	`GET [base]/MedicationRequest?intent=[system]\|[code]`
MAY	patient	reference	`GET [base]/MedicationRequest?patient=[patient]`
MAY	encounter	reference	`GET [base]/MedicationRequest?encounter=[encounter]`
MAY	authoredon	date	`GET [base]/MedicationRequest?authoredon=[authoredon]`

Search Parameter Combination Summary:

Conformance Parameter Combination Types Example

SHALL patient+intent reference+token GET [base]/MedicationRequest?patient=[patient]&intent=[system]|[code]

SHOULD patient+intent+encounter reference+token+reference GET [base]/MedicationRequest?patient=[patient]&intent=[system]|[code]&encounter=[encounter]

SHOULD patient+intent+authoredon reference+token+date GET [base]/MedicationRequest?patient=[patient]&intent=[system]|[code]&authoredon=[authoredon]

SHALL patient+intent+status reference+token+token GET [base]/MedicationRequest?patient=[patient]&intent=[system]|[code]&status=[status]

Conformance	Parameter Combination	Types	Example
SHALL	patient+intent	reference+token	`GET [base]/MedicationRequest?patient=[patient]&intent=[system]\|[code]`
SHOULD	patient+intent+encounter	reference+token+reference	`GET [base]/MedicationRequest?patient=[patient]&intent=[system]\|[code]&encounter=[encounter]`
SHOULD	patient+intent+authoredon	reference+token+date	`GET [base]/MedicationRequest?patient=[patient]&intent=[system]\|[code]&authoredon=[authoredon]`
SHALL	patient+intent+status	reference+token+token	`GET [base]/MedicationRequest?patient=[patient]&intent=[system]\|[code]&status=[status]`

Observation

Conformance Expectation: SHALL

Supported Profiles: US Core Smoking Status Observation Profile, US Core Pediatric Weight for Height Observation Profile, US Core Laboratory Result Observation Profile, US Core Pediatric BMI for Age Observation Profile, US Core Pulse Oximetry Profile, US Core Pediatric Head Occipital-frontal Circumference Percentile Profile

Reference Policy: resolves

Profile Interaction Summary:

SHALL support search-type, read.
SHOULD support vread, history-instance.
MAY support create, update, patch, delete, history-type.

Fetch and Search Criteria:

A Server SHALL be capable of returning a Observation resource using:
GET [base]/Observation/[id]

A Server SHALL be capable of supporting the following _revincludes:
Provenance:target - GET [base]/Observation?[parameter=value]&_revinclude=Provenance:target

Search Parameter Summary:

Conformance Parameter Type Example

MAY status token GET [base]/Observation?status=[status]

MAY category token GET [base]/Observation?category=[system]|[code]

MAY code token GET [base]/Observation?code=[system]|[code]

MAY date date GET [base]/Observation?date=[date]

MAY patient reference GET [base]/Observation?patient=[patient]

Conformance	Parameter	Type	Example
MAY	status	token	`GET [base]/Observation?status=[status]`
MAY	category	token	`GET [base]/Observation?category=[system]\|[code]`
MAY	code	token	`GET [base]/Observation?code=[system]\|[code]`
MAY	date	date	`GET [base]/Observation?date=[date]`
MAY	patient	reference	`GET [base]/Observation?patient=[patient]`

Search Parameter Combination Summary:

Conformance Parameter Combination Types Example

SHALL patient+category+date reference+token+date GET [base]/Observation?patient=[patient]&category=[system]|[code]&date=[date]

SHOULD patient+category+status reference+token+token GET [base]/Observation?patient=[patient]&category=[system]|[code]&status=[status]

SHOULD patient+code+date reference+token+date GET [base]/Observation?patient=[patient]&code=[system]|[code]&date=[date]

SHALL patient+code reference+token GET [base]/Observation?patient=[patient]&code=[system]|[code]

SHALL patient+category reference+token GET [base]/Observation?patient=[patient]&category=[system]|[code]

Conformance	Parameter Combination	Types	Example
SHALL	patient+category+date	reference+token+date	`GET [base]/Observation?patient=[patient]&category=[system]\|[code]&date=[date]`
SHOULD	patient+category+status	reference+token+token	`GET [base]/Observation?patient=[patient]&category=[system]\|[code]&status=[status]`
SHOULD	patient+code+date	reference+token+date	`GET [base]/Observation?patient=[patient]&code=[system]\|[code]&date=[date]`
SHALL	patient+code	reference+token	`GET [base]/Observation?patient=[patient]&code=[system]\|[code]`
SHALL	patient+category	reference+token	`GET [base]/Observation?patient=[patient]&category=[system]\|[code]`

Organization

Conformance Expectation: SHALL

Supported Profiles: US Core Organization Profile

Reference Policy: resolves

Profile Interaction Summary:

SHALL support search-type, read.
SHOULD support vread, history-instance.
MAY support create, update, patch, delete, history-type.

Fetch and Search Criteria:

A Server SHALL be capable of returning a Organization resource using:
GET [base]/Organization/[id]

Search Parameter Summary:

Conformance Parameter Type Example

SHALL name string GET [base]/Organization?name=[name]

SHALL address string GET [base]/Organization?address=[address]

Conformance	Parameter	Type	Example
SHALL	name	string	`GET [base]/Organization?name=[name]`
SHALL	address	string	`GET [base]/Organization?address=[address]`

Patient

Conformance Expectation: SHALL

Supported Profiles: US Core Patient Profile

Reference Policy: resolves

Profile Interaction Summary:

SHALL support search-type, read.
SHOULD support vread, history-instance.
MAY support create, update, patch, delete, history-type.

Fetch and Search Criteria:

A Server SHALL be capable of returning a Patient resource using:
GET [base]/Patient/[id]

A Server SHALL be capable of supporting the following _revincludes:
Provenance:target - GET [base]/Patient?[parameter=value]&_revinclude=Provenance:target

Search Parameter Summary:

Conformance Parameter Type Example

SHALL _id token GET [base]/Patient?_id=[id]

MAY birthdate date GET [base]/Patient?birthdate=[birthdate]

MAY family string GET [base]/Patient?family=[family]

MAY gender token GET [base]/Patient?gender=[system]|[code]

MAY given string GET [base]/Patient?given=[given]

SHALL identifier token GET [base]/Patient?identifier=[system]|[code]

SHALL name string GET [base]/Patient?name=[name]

Conformance	Parameter	Type	Example
SHALL	_id	token	`GET [base]/Patient?_id=[id]`
MAY	birthdate	date	`GET [base]/Patient?birthdate=[birthdate]`
MAY	family	string	`GET [base]/Patient?family=[family]`
MAY	gender	token	`GET [base]/Patient?gender=[system]\|[code]`
MAY	given	string	`GET [base]/Patient?given=[given]`
SHALL	identifier	token	`GET [base]/Patient?identifier=[system]\|[code]`
SHALL	name	string	`GET [base]/Patient?name=[name]`

Search Parameter Combination Summary:

Conformance Parameter Combination Types Example

SHOULD birthdate+family date+string GET [base]/Patient?birthdate=[birthdate]&family=[family]

SHOULD family+gender string+token GET [base]/Patient?family=[family]&gender=[system]|[code]

SHALL birthdate+name date+string GET [base]/Patient?birthdate=[birthdate]&name=[name]

SHALL gender+name token+string GET [base]/Patient?gender=[system]|[code]&name=[name]

Conformance	Parameter Combination	Types	Example
SHOULD	birthdate+family	date+string	`GET [base]/Patient?birthdate=[birthdate]&family=[family]`
SHOULD	family+gender	string+token	`GET [base]/Patient?family=[family]&gender=[system]\|[code]`
SHALL	birthdate+name	date+string	`GET [base]/Patient?birthdate=[birthdate]&name=[name]`
SHALL	gender+name	token+string	`GET [base]/Patient?gender=[system]\|[code]&name=[name]`

Practitioner

Conformance Expectation: SHALL

Supported Profiles: US Core Practitioner Profile

Reference Policy: resolves

Profile Interaction Summary:

SHALL support search-type, read.
SHOULD support vread, history-instance.
MAY support create, update, patch, delete, history-type.

Fetch and Search Criteria:

A Server SHALL be capable of returning a Practitioner resource using:
GET [base]/Practitioner/[id]

Search Parameter Summary:

Conformance Parameter Type Example

SHALL name string GET [base]/Practitioner?name=[name]

SHALL identifier token GET [base]/Practitioner?identifier=[system]|[code]

Conformance	Parameter	Type	Example
SHALL	name	string	`GET [base]/Practitioner?name=[name]`
SHALL	identifier	token	`GET [base]/Practitioner?identifier=[system]\|[code]`

PractitionerRole

Conformance Expectation: SHALL

Supported Profiles: US Core PractitionerRole Profile

Reference Policy: resolves

Profile Interaction Summary:

SHALL support search-type, read.
SHOULD support vread, history-instance.
MAY support create, update, patch, delete, history-type.

Fetch and Search Criteria:

A Server SHALL be capable of returning a PractitionerRole resource using:
GET [base]/PractitionerRole/[id]

A Server SHOULD be capable of supporting the following _includes:
PractitionerRole:endpoint - GET [base]/PractitionerRole?[parameter=value]&_include=PractitionerRole:endpoint
PractitionerRole:practitioner - GET [base]/PractitionerRole?[parameter=value]&_include=PractitionerRole:practitioner

Search Parameter Summary:

Conformance Parameter Type Example

SHALL specialty token GET [base]/PractitionerRole?specialty=[system]|[code]

SHALL practitioner reference GET [base]/PractitionerRole?practitioner=[practitioner]

Conformance	Parameter	Type	Example
SHALL	specialty	token	`GET [base]/PractitionerRole?specialty=[system]\|[code]`
SHALL	practitioner	reference	`GET [base]/PractitionerRole?practitioner=[practitioner]`

Procedure

Conformance Expectation: SHALL

Supported Profiles: US Core Procedure Profile

Reference Policy: resolves

Profile Interaction Summary:

SHALL support search-type, read.
SHOULD support vread, history-instance.
MAY support create, update, patch, delete, history-type.

Fetch and Search Criteria:

A Server SHALL be capable of returning a Procedure resource using:
GET [base]/Procedure/[id]

A Server SHALL be capable of supporting the following _revincludes:
Provenance:target - GET [base]/Procedure?[parameter=value]&_revinclude=Provenance:target

Search Parameter Summary:

Conformance Parameter Type Example

MAY status token GET [base]/Procedure?status=[status]

SHALL patient reference GET [base]/Procedure?patient=[patient]

MAY date date GET [base]/Procedure?date=[date]

MAY code token GET [base]/Procedure?code=[system]|[code]

Conformance	Parameter	Type	Example
MAY	status	token	`GET [base]/Procedure?status=[status]`
SHALL	patient	reference	`GET [base]/Procedure?patient=[patient]`
MAY	date	date	`GET [base]/Procedure?date=[date]`
MAY	code	token	`GET [base]/Procedure?code=[system]\|[code]`

Search Parameter Combination Summary:

Conformance Parameter Combination Types Example

SHALL patient+date reference+date GET [base]/Procedure?patient=[patient]&date=[date]

SHOULD patient+status reference+token GET [base]/Procedure?patient=[patient]&status=[status]

SHOULD patient+code+date reference+token+date GET [base]/Procedure?patient=[patient]&code=[system]|[code]&date=[date]

Conformance	Parameter Combination	Types	Example
SHALL	patient+date	reference+date	`GET [base]/Procedure?patient=[patient]&date=[date]`
SHOULD	patient+status	reference+token	`GET [base]/Procedure?patient=[patient]&status=[status]`
SHOULD	patient+code+date	reference+token+date	`GET [base]/Procedure?patient=[patient]&code=[system]\|[code]&date=[date]`

Provenance

Conformance Expectation: SHALL

Supported Profiles: US Core Provenance Profile

Resource Specific 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.

Reference Policy: resolves

Profile Interaction Summary:

SHALL support read.
SHOULD support vread, history-instance.
MAY support create, search-type, update, patch, delete, history-type.

Fetch and Search Criteria:

A Server SHALL be capable of returning a Provenance resource using:
GET [base]/Provenance/[id]

ValueSet

Conformance Expectation: SHOULD

Operation Summary:

SHOULD support the $expand operation
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.