US Core Implementation Guide
9.0.0 - STU 9 US

US Core Implementation Guide - Downloaded Version 9.0.0 See the Directory of published versions

## CapabilityStatement: US Core Server CapabilityStatement

Official URL: http://hl7.org/fhir/us/core/CapabilityStatement/us-core-server | Version: 9.0.0
Standards status: Trial-use | Maturity Level: 3 | Computable Name: UsCoreServerCapabilityStatement
Other Identifiers: OID:2.16.840.1.113883.4.642.40.2.13.2

This CapabilityStatement 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 Office of the National Coordinator for Health Information Technology (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 6 July 2025.

Raw OpenAPI-Swagger Definition file | Download

### Support and Requirements for Other Artifacts

#### Supports other guides:

- SHOULD support SMART App Launch version 2.0.0 and later

### FHIR Server RESTful Capabilities

The US Core Server 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.

   - A summary table listing all the Must Support references to other US Core Profiles and FHIR resources for each US Core Profile is located in the Must Support - Resource References section of the guide.

2. Follow the narrative requirements documented in the:

   - Conformance pages
   - Guidance pages
   - Profile Specific Implementation Guidance for each Profile that the US Core Server supports.

   The Server Requirements Table and US Core Server Requirements Resource and US Core Certifying System Requirements Resource list the requirements defined in these pages and sections.

3. Return the following response classes:

   - (Status 400): invalid parameter
   - (Status 401/4xx): unauthorized request
   - (Status 403): insufficient scopes
   - (Status 404): unknown resource

4. Support JSON source formats for all US Core interactions.

The US Core Server SHOULD:

1. Follow the guidance documented in the 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.

> NOTE: US Core SearchParameters referenced in this CapabilityStatement that are derived from standard FHIR SearchParameters are only defined to document Server and Client expectations. They specify additional expectations for the following SearchParameter elements:

> - `multipleAnd`
> - `multipleOr`
> - `comparator`
> - `modifier`
> - `chain`

> They SHALL NOT be interpreted as search parameters for search. Servers and Clients SHOULD use the standard FHIR SearchParameters.

Security:

1. See the 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"

### System-wide Server Capabilities

#### Interactions

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

#### Summary of Resource/Profile Capabilities

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, patient+category, patient+category+date, patient+category+status+date | - | Provenance:target | -
CareTeam | •US Core CareTeam Profile | patient, role, status , patient+status, patient+role | CareTeam:participant:PractitionerRole CareTeam:participant:Practitioner CareTeam:participant:Patient CareTeam:participant:RelatedPerson | Provenance:target | -
Condition | •US Core Condition Encounter Diagnosis Profile •US Core Condition Problems and Health Concerns Profile | abatement-date, asserted-date, category, clinical-status, code, encounter, onset-date, patient, recorded-date, _lastUpdated , patient+clinical-status, patient+code, patient+category, patient+abatement-date, patient+recorded-date, patient+_lastUpdated, patient+asserted-date, patient+category+clinical-status, patient+onset-date, patient+category+encounter | - | Provenance:target | -
Coverage | •US Core Coverage Profile | patient | - | Provenance:target | -
Device | •US Core Device Profile | patient, status, type , patient+type, patient+status | - | Provenance:target | -
DiagnosticReport | •US Core DiagnosticReport Profile for Report and Note exchange •US Core DiagnosticReport Profile for Laboratory Results Reporting | category, code, date, _lastUpdated, patient, status , patient+code+date, patient+category+_lastUpdated, patient+category+date, patient+category, patient+status, patient+code | - | Provenance:target | -
DocumentReference | •US Core DocumentReference Profile •US Core ADI DocumentReference Profile | _id, category, date, patient, period, status, type , patient+type, patient+category+date, patient+category, patient+type+period, patient+status | - | Provenance:target | $docref
Encounter | •US Core Encounter Profile | _id, class, date, _lastUpdated, discharge-disposition, identifier, location, patient, status, type , patient+type, class+patient, patient+status, patient+_lastUpdated, patient+location, date+patient, patient+discharge-disposition | - | Provenance:target | -
Endpoint | - | - | - | - | -
FamilyMemberHistory | •US Core FamilyMemberHistory Profile | patient, code , patient+code | - | Provenance:target | -
Goal | •US Core Goal Profile | description, lifecycle-status, patient, target-date , patient+description, patient+target-date, patient+lifecycle-status | - | Provenance:target | -
HealthcareService | - | - | - | - | -
Immunization | •US Core Immunization Profile | date, patient, status , patient+date, patient+status | - | Provenance:target | -
Location | •US Core Location Profile | address, address-city, address-postalcode, address-state, name | - | - | -
Medication | •US Core Medication Profile | - | - | - | -
MedicationDispense | •US Core MedicationDispense Profile | patient, status, type , patient+status+type, patient+status | MedicationDispense:medication | Provenance:target | -
MedicationRequest | •US Core MedicationRequest Profile | authoredon, encounter, intent, patient, status , patient+intent+authoredon, patient+intent+encounter, patient+intent, patient+intent+status | MedicationRequest:medication | Provenance:target | -
Observation | •US Core Observation ADI Documentation Profile •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 Treatment Intervention Preference Profile •US Core Care Experience Preference 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 Average Blood Pressure 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 | category, code, date, _lastUpdated, patient, status , patient+code+date, patient+category+_lastUpdated, patient+category+date, patient+category, patient+category+status, patient+code | - | Provenance:target | -
Organization | •US Core Organization Profile | address, name | - | - | -
Patient | •US Core Patient Profile | _id, birthdate, death-date, family, given, identifier, name , birthdate+name, birthdate+family, death-date+family | - | Provenance:target | -
Practitioner | •US Core Practitioner Profile | _id, identifier, name | - | - | -
PractitionerRole | •US Core PractitionerRole Profile | practitioner, specialty | PractitionerRole:endpoint PractitionerRole:practitioner | - | -
Procedure | •US Core Procedure Profile | code, date, patient, status , patient+code+date, patient+date, patient+status | - | Provenance:target | -
Provenance | •US Core Provenance Profile | - | - | - | -
Questionnaire | •SDC Base Questionnaire Profile | - | - | - | -
QuestionnaireResponse | •US Core QuestionnaireResponse Profile | _id, authored, patient, questionnaire, status , patient+questionnaire, patient+authored, patient+status | - | Provenance:target | -
RelatedPerson | •US Core RelatedPerson Profile | _id, name, patient , patient+name | - | Provenance:target | -
ServiceRequest | •US Core ServiceRequest Profile | _id, authored, category, code, patient, status , patient+code+authored, patient+category+authored, patient+category, patient+status, patient+code | - | Provenance:target | -
Specimen | •US Core Specimen Profile | _id, patient | - | - | -
ValueSet | - | - | - | - | $expand

### RESTful Server Capabilities by Resource/Profile:

#### AllergyIntolerance

Conformance Expectation: SHALL

Supported Profiles:

- SHALL support US Core AllergyIntolerance Profile

FHIR RESTful Interactions

Summary:

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

Modify Criteria Details:

- A Server MAY be capable of creating a AllergyIntolerance resource using: `POST [base]/AllergyIntolerance {?_format=[mime-type]}`
- A Server MAY be capable of updating a existing AllergyIntolerance resource using: `PUT [base]/AllergyIntolerance/[id] {?_format=[mime-type]}`
- A Server MAY be capable of patching an existing AllergyIntolerance resource using: `PATCH [base]/AllergyIntolerance/[id] {?_format=[mime-type]}`
- A Server MAY be capable of deleting a AllergyIntolerance resource using: `DELETE [base]/AllergyIntolerance/[id]`

Fetch and Search Criteria Details:

- A Server SHALL be capable of a `search-type` interaction returning AllergyIntolerance resources matching a search query using: `GET [base]/AllergyIntolerance/[id]{?[parameters]{&_format=[mime-type]}}`
- A Server SHALL be capable of a `read` interaction returning a AllergyIntolerance resource using: `GET [base]/AllergyIntolerance/[id]`
- A Server SHOULD be capable of a `vread` interaction returning a AllergyIntolerance resource using: `GET [base]/AllergyIntolerance/[id]/_history/vid`
- A Server SHOULD be capable of a `history-instance` interaction returning a history of a AllergyIntolerance using: `GET [base]/AllergyIntolerance/[id]/_history{?[parameters]&_format=[mime-type]}`
- A Server MAY be capable of a `history-type` interaction returning the history of AllergyIntolerance resources using: `GET [base]/AllergyIntolerance/_history{?[parameters]&_format=[mime-type]}`
- A Server SHALL be capable of supporting the following _revincludes:
  - Provenance:target - `GET [base]/AllergyIntolerance?[parameter=value]&_revinclude=Provenance:target`

Search Parameter Requirements (When Used Alone or in Combination):

Conformance | Parameter | Type | Example
--- | --- | --- | ---
SHALL | patient | Reference | `GET [base]/AllergyIntolerance?patient=[type]/[id]`
SHOULD | patient+clinical-status | Reference+Token | `GET [base]/AllergyIntolerance?patient=[type]/[id]&clinical-status=[system]|[code]`

- clinical-status (Token):

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

  The server SHALL support both.

- patient (Reference):

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

  The server SHALL support both.

#### CarePlan

Conformance Expectation: SHALL

Supported Profiles:

- SHALL support US Core CarePlan Profile

FHIR RESTful Interactions

Summary:

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

Modify Criteria Details:

- A Server MAY be capable of creating a CarePlan resource using: `POST [base]/CarePlan {?_format=[mime-type]}`
- A Server MAY be capable of updating a existing CarePlan resource using: `PUT [base]/CarePlan/[id] {?_format=[mime-type]}`
- A Server MAY be capable of patching an existing CarePlan resource using: `PATCH [base]/CarePlan/[id] {?_format=[mime-type]}`
- A Server MAY be capable of deleting a CarePlan resource using: `DELETE [base]/CarePlan/[id]`

Fetch and Search Criteria Details:

- A Server SHALL be capable of a `search-type` interaction returning CarePlan resources matching a search query using: `GET [base]/CarePlan/[id]{?[parameters]{&_format=[mime-type]}}`
- A Server SHALL be capable of a `read` interaction returning a CarePlan resource using: `GET [base]/CarePlan/[id]`
- A Server SHOULD be capable of a `vread` interaction returning a CarePlan resource using: `GET [base]/CarePlan/[id]/_history/vid`
- A Server SHOULD be capable of a `history-instance` interaction returning a history of a CarePlan using: `GET [base]/CarePlan/[id]/_history{?[parameters]&_format=[mime-type]}`
- A Server MAY be capable of a `history-type` interaction returning the history of CarePlan resources using: `GET [base]/CarePlan/_history{?[parameters]&_format=[mime-type]}`
- A Server SHALL be capable of supporting the following _revincludes:
  - Provenance:target - `GET [base]/CarePlan?[parameter=value]&_revinclude=Provenance:target`

Search Parameter Requirements (When Used Alone or in Combination):

Conformance | Parameter | Type | Example
--- | --- | --- | ---
SHOULD | patient+category+status | Reference+Token+Token | `GET [base]/CarePlan?patient=[type]/[id]&category=[system]|[code]&status=[system]|[code]`
SHALL | patient+category | Reference+Token | `GET [base]/CarePlan?patient=[type]/[id]&category=[system]|[code]`
SHOULD | patient+category+date | Reference+Token+Date/DateTime | `GET [base]/CarePlan?patient=[type]/[id]&category=[system]|[code]&date=[dateTime]`
SHOULD | patient+category+status+date | Reference+Token+Token+Date/DateTime | `GET [base]/CarePlan?patient=[type]/[id]&category=[system]|[code]&status=[system]|[code]&date=[dateTime]`

- category (Token):

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

  The server SHALL support both.

- date (Date/DateTime):

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

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

- patient (Reference):

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

  The server SHALL support both.

- status (Token):

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

  The server SHALL support both.

#### CareTeam

Conformance Expectation: SHALL

Supported Profiles:

- SHALL support US Core CareTeam Profile

FHIR RESTful Interactions

Summary:

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

Modify Criteria Details:

- A Server MAY be capable of creating a CareTeam resource using: `POST [base]/CareTeam {?_format=[mime-type]}`
- A Server MAY be capable of updating a existing CareTeam resource using: `PUT [base]/CareTeam/[id] {?_format=[mime-type]}`
- A Server MAY be capable of patching an existing CareTeam resource using: `PATCH [base]/CareTeam/[id] {?_format=[mime-type]}`
- A Server MAY be capable of deleting a CareTeam resource using: `DELETE [base]/CareTeam/[id]`

Fetch and Search Criteria Details:

- A Server SHALL be capable of a `search-type` interaction returning CareTeam resources matching a search query using: `GET [base]/CareTeam/[id]{?[parameters]{&_format=[mime-type]}}`
- A Server SHALL be capable of a `read` interaction returning a CareTeam resource using: `GET [base]/CareTeam/[id]`
- A Server SHOULD be capable of a `vread` interaction returning a CareTeam resource using: `GET [base]/CareTeam/[id]/_history/vid`
- A Server SHOULD be capable of a `history-instance` interaction returning a history of a CareTeam using: `GET [base]/CareTeam/[id]/_history{?[parameters]&_format=[mime-type]}`
- A Server MAY be capable of a `history-type` interaction returning the history of CareTeam resources using: `GET [base]/CareTeam/_history{?[parameters]&_format=[mime-type]}`
- A Server SHOULD be capable of supporting the following _includes:
  - CareTeam:participant:PractitionerRole - `GET [base]/CareTeam?[parameter=value]&_include=CareTeam:participant:PractitionerRole`
  - CareTeam:participant:Practitioner - `GET [base]/CareTeam?[parameter=value]&_include=CareTeam:participant:Practitioner`
  - CareTeam:participant:Patient - `GET [base]/CareTeam?[parameter=value]&_include=CareTeam:participant:Patient`
  - CareTeam:participant:RelatedPerson - `GET [base]/CareTeam?[parameter=value]&_include=CareTeam:participant:RelatedPerson`
- A Server SHALL be capable of supporting the following _revincludes:
  - Provenance:target - `GET [base]/CareTeam?[parameter=value]&_revinclude=Provenance:target`

Search Parameter Requirements (When Used Alone or in Combination):

Conformance | Parameter | Type | Example
--- | --- | --- | ---
SHOULD | role | Token | `GET [base]/CareTeam?role=[system]|[code]`
SHALL | patient+status | Reference+Token | `GET [base]/CareTeam?patient=[type]/[id]&status=[system]|[code]`
SHOULD | patient+role | Reference+Token | `GET [base]/CareTeam?patient=[type]/[id]&role=[system]|[code]`

- patient (Reference):

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

  The server SHALL support both.

- role (Token):

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

  The server SHALL support both.

- status (Token):

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

  The server SHALL support both.

#### Condition

Conformance Expectation: SHALL

Supported Profiles:

- SHALL support US Core Condition Encounter Diagnosis Profile
- SHALL support US Core Condition Problems and Health Concerns Profile

FHIR RESTful Interactions

Summary:

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

Modify Criteria Details:

- A Server MAY be capable of creating a Condition resource using: `POST [base]/Condition {?_format=[mime-type]}`
- A Server MAY be capable of updating a existing Condition resource using: `PUT [base]/Condition/[id] {?_format=[mime-type]}`
- A Server MAY be capable of patching an existing Condition resource using: `PATCH [base]/Condition/[id] {?_format=[mime-type]}`
- A Server MAY be capable of deleting a Condition resource using: `DELETE [base]/Condition/[id]`

Fetch and Search Criteria Details:

- A Server SHALL be capable of a `search-type` interaction returning Condition resources matching a search query using: `GET [base]/Condition/[id]{?[parameters]{&_format=[mime-type]}}`
- A Server SHALL be capable of a `read` interaction returning a Condition resource using: `GET [base]/Condition/[id]`
- A Server SHOULD be capable of a `vread` interaction returning a Condition resource using: `GET [base]/Condition/[id]/_history/vid`
- A Server SHOULD be capable of a `history-instance` interaction returning a history of a Condition using: `GET [base]/Condition/[id]/_history{?[parameters]&_format=[mime-type]}`
- A Server MAY be capable of a `history-type` interaction returning the history of Condition resources using: `GET [base]/Condition/_history{?[parameters]&_format=[mime-type]}`
- A Server SHALL be capable of supporting the following _revincludes:
  - Provenance:target - `GET [base]/Condition?[parameter=value]&_revinclude=Provenance:target`

Search Parameter Requirements (When Used Alone or in Combination):

Conformance | Parameter | Type | Example
--- | --- | --- | ---
SHALL | patient | Reference | `GET [base]/Condition?patient=[type]/[id]`
SHOULD | patient+clinical-status | Reference+Token | `GET [base]/Condition?patient=[type]/[id]&clinical-status=[system]|[code]`
SHOULD | patient+code | Reference+Token | `GET [base]/Condition?patient=[type]/[id]&code=[system]|[code]`
SHALL | patient+category | Reference+Token | `GET [base]/Condition?patient=[type]/[id]&category=[system]|[code]`
SHOULD | patient+abatement-date | Reference+Date/DateTime | `GET [base]/Condition?patient=[type]/[id]&abatement-date=[dateTime]`
SHOULD | patient+recorded-date | Reference+Date/DateTime | `GET [base]/Condition?patient=[type]/[id]&recorded-date=[dateTime]`
SHOULD | patient+_lastUpdated | Reference+Date/DateTime | `GET [base]/Condition?patient=[type]/[id]&_lastUpdated=[dateTime]`
SHOULD | patient+asserted-date | Reference+Date/DateTime | `GET [base]/Condition?patient=[type]/[id]&asserted-date=[dateTime]`
SHOULD | patient+category+clinical-status | Reference+Token+Token | `GET [base]/Condition?patient=[type]/[id]&category=[system]|[code]&clinical-status=[system]|[code]`
SHOULD | patient+onset-date | Reference+Date/DateTime | `GET [base]/Condition?patient=[type]/[id]&onset-date=[dateTime]`
SHOULD | patient+category+encounter | Reference+Token+Reference | `GET [base]/Condition?patient=[type]/[id]&category=[system]|[code]&encounter=[type]/[id]`

- abatement-date (Date/DateTime):

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

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

- asserted-date (Date/DateTime):

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

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

- category (Token):

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

  The server SHALL support both.

- clinical-status (Token):

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

  The server SHALL support both.

- code (Token):

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

  The server SHALL support both.

- encounter (Reference):

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

  The server SHALL support both.

- onset-date (Date/DateTime):

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

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

- patient (Reference):

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

  The server SHALL support both.

- recorded-date (Date/DateTime):

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

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

- _lastUpdated (Date/DateTime):

  A server SHALL document the types of changes that can be detected using this parameter.

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

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

#### Coverage

Conformance Expectation: SHALL

Supported Profiles:

- SHALL support US Core Coverage Profile

FHIR RESTful Interactions

Summary:

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

Modify Criteria Details:

- A Server MAY be capable of creating a Coverage resource using: `POST [base]/Coverage {?_format=[mime-type]}`
- A Server MAY be capable of updating a existing Coverage resource using: `PUT [base]/Coverage/[id] {?_format=[mime-type]}`
- A Server MAY be capable of patching an existing Coverage resource using: `PATCH [base]/Coverage/[id] {?_format=[mime-type]}`
- A Server MAY be capable of deleting a Coverage resource using: `DELETE [base]/Coverage/[id]`

Fetch and Search Criteria Details:

- A Server SHALL be capable of a `search-type` interaction returning Coverage resources matching a search query using: `GET [base]/Coverage/[id]{?[parameters]{&_format=[mime-type]}}`
- A Server SHALL be capable of a `read` interaction returning a Coverage resource using: `GET [base]/Coverage/[id]`
- A Server SHOULD be capable of a `vread` interaction returning a Coverage resource using: `GET [base]/Coverage/[id]/_history/vid`
- A Server SHOULD be capable of a `history-instance` interaction returning a history of a Coverage using: `GET [base]/Coverage/[id]/_history{?[parameters]&_format=[mime-type]}`
- A Server MAY be capable of a `history-type` interaction returning the history of Coverage resources using: `GET [base]/Coverage/_history{?[parameters]&_format=[mime-type]}`
- A Server SHALL be capable of supporting the following _revincludes:
  - Provenance:target - `GET [base]/Coverage?[parameter=value]&_revinclude=Provenance:target`

Search Parameter Requirements (When Used Alone or in Combination):

Conformance | Parameter | Type | Example
--- | --- | --- | ---
SHALL | patient | Reference | `GET [base]/Coverage?patient=[type]/[id]`

- patient (Reference):

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

  The server SHALL support both.

#### Device

Conformance Expectation: SHALL

Supported Profiles:

- SHALL support US Core Device Profile

FHIR RESTful Interactions

Summary:

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

Modify Criteria Details:

- A Server MAY be capable of creating a Device resource using: `POST [base]/Device {?_format=[mime-type]}`
- A Server MAY be capable of updating a existing Device resource using: `PUT [base]/Device/[id] {?_format=[mime-type]}`
- A Server MAY be capable of patching an existing Device resource using: `PATCH [base]/Device/[id] {?_format=[mime-type]}`
- A Server MAY be capable of deleting a Device resource using: `DELETE [base]/Device/[id]`

Fetch and Search Criteria Details:

- A Server SHALL be capable of a `search-type` interaction returning Device resources matching a search query using: `GET [base]/Device/[id]{?[parameters]{&_format=[mime-type]}}`
- A Server SHALL be capable of a `read` interaction returning a Device resource using: `GET [base]/Device/[id]`
- A Server SHOULD be capable of a `vread` interaction returning a Device resource using: `GET [base]/Device/[id]/_history/vid`
- A Server SHOULD be capable of a `history-instance` interaction returning a history of a Device using: `GET [base]/Device/[id]/_history{?[parameters]&_format=[mime-type]}`
- A Server MAY be capable of a `history-type` interaction returning the history of Device resources using: `GET [base]/Device/_history{?[parameters]&_format=[mime-type]}`
- A Server SHALL be capable of supporting the following _revincludes:
  - Provenance:target - `GET [base]/Device?[parameter=value]&_revinclude=Provenance:target`

Search Parameter Requirements (When Used Alone or in Combination):

Conformance | Parameter | Type | Example
--- | --- | --- | ---
SHALL | patient | Reference | `GET [base]/Device?patient=[type]/[id]`
SHOULD | patient+type | Reference+Token | `GET [base]/Device?patient=[type]/[id]&type=[system]|[code]`
SHOULD | patient+status | Reference+Token | `GET [base]/Device?patient=[type]/[id]&status=[system]|[code]`

- patient (Reference):

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

  The server SHALL support both.

- status (Token):

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

  The server SHALL support both.

- type (Token):

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

  The server SHALL support both.

#### DiagnosticReport

Conformance Expectation: SHALL

Supported Profiles:

- SHALL support US Core DiagnosticReport Profile for Report and Note exchange
- SHALL support US Core DiagnosticReport Profile for Laboratory Results Reporting

FHIR RESTful Interactions

Summary:

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

Modify Criteria Details:

- A Server SHALL be capable of creating a DiagnosticReport resource using: `POST [base]/DiagnosticReport {?_format=[mime-type]}`
- A Server MAY be capable of updating a existing DiagnosticReport resource using: `PUT [base]/DiagnosticReport/[id] {?_format=[mime-type]}`
- A Server MAY be capable of patching an existing DiagnosticReport resource using: `PATCH [base]/DiagnosticReport/[id] {?_format=[mime-type]}`
- A Server MAY be capable of deleting a DiagnosticReport resource using: `DELETE [base]/DiagnosticReport/[id]`

Fetch and Search Criteria Details:

- A Server SHALL be capable of a `search-type` interaction returning DiagnosticReport resources matching a search query using: `GET [base]/DiagnosticReport/[id]{?[parameters]{&_format=[mime-type]}}`
- A Server SHALL be capable of a `read` interaction returning a DiagnosticReport resource using: `GET [base]/DiagnosticReport/[id]`
- A Server SHOULD be capable of a `vread` interaction returning a DiagnosticReport resource using: `GET [base]/DiagnosticReport/[id]/_history/vid`
- A Server SHOULD be capable of a `history-instance` interaction returning a history of a DiagnosticReport using: `GET [base]/DiagnosticReport/[id]/_history{?[parameters]&_format=[mime-type]}`
- A Server MAY be capable of a `history-type` interaction returning the history of DiagnosticReport resources using: `GET [base]/DiagnosticReport/_history{?[parameters]&_format=[mime-type]}`
- A Server SHALL be capable of supporting the following _revincludes:
  - Provenance:target - `GET [base]/DiagnosticReport?[parameter=value]&_revinclude=Provenance:target`

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

Search Parameter Requirements (When Used Alone or in Combination):

Conformance | Parameter | Type | Example
--- | --- | --- | ---
SHALL | patient | Reference | `GET [base]/DiagnosticReport?patient=[type]/[id]`
SHOULD | patient+code+date | Reference+Token+Date/DateTime | `GET [base]/DiagnosticReport?patient=[type]/[id]&code=[system]|[code]&date=[dateTime]`
SHOULD | patient+category+_lastUpdated | Reference+Token+Date/DateTime | `GET [base]/DiagnosticReport?patient=[type]/[id]&category=[system]|[code]&_lastUpdated=[dateTime]`
SHALL | patient+category+date | Reference+Token+Date/DateTime | `GET [base]/DiagnosticReport?patient=[type]/[id]&category=[system]|[code]&date=[dateTime]`
SHALL | patient+category | Reference+Token | `GET [base]/DiagnosticReport?patient=[type]/[id]&category=[system]|[code]`
SHOULD | patient+status | Reference+Token | `GET [base]/DiagnosticReport?patient=[type]/[id]&status=[system]|[code]`
SHALL | patient+code | Reference+Token | `GET [base]/DiagnosticReport?patient=[type]/[id]&code=[system]|[code]`

- category (Token):

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

  The server SHALL support both.

- code (Token):

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

  The server SHALL support both.

- date (Date/DateTime):

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

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

- _lastUpdated (Date/DateTime):

  A server SHALL document the types of changes that can be detected using this parameter.

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

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

- patient (Reference):

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

  The server SHALL support both.

- status (Token):

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

  The server SHALL support both.

#### DocumentReference

Conformance Expectation: SHALL

Supported Profiles:

- SHALL support US Core DocumentReference Profile
- SHALL support US Core ADI DocumentReference Profile

FHIR RESTful Interactions

Summary:

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

Modify Criteria Details:

- A Server SHALL be capable of creating a DocumentReference resource using: `POST [base]/DocumentReference {?_format=[mime-type]}`
- A Server MAY be capable of updating a existing DocumentReference resource using: `PUT [base]/DocumentReference/[id] {?_format=[mime-type]}`
- A Server MAY be capable of patching an existing DocumentReference resource using: `PATCH [base]/DocumentReference/[id] {?_format=[mime-type]}`
- A Server MAY be capable of deleting a DocumentReference resource using: `DELETE [base]/DocumentReference/[id]`

Fetch and Search Criteria Details:

- A Server SHALL be capable of a `search-type` interaction returning DocumentReference resources matching a search query using: `GET [base]/DocumentReference/[id]{?[parameters]{&_format=[mime-type]}}`
- A Server SHALL be capable of a `read` interaction returning a DocumentReference resource using: `GET [base]/DocumentReference/[id]`
- A Server SHOULD be capable of a `vread` interaction returning a DocumentReference resource using: `GET [base]/DocumentReference/[id]/_history/vid`
- A Server SHOULD be capable of a `history-instance` interaction returning a history of a DocumentReference using: `GET [base]/DocumentReference/[id]/_history{?[parameters]&_format=[mime-type]}`
- A Server MAY be capable of a `history-type` interaction returning the history of DocumentReference resources using: `GET [base]/DocumentReference/_history{?[parameters]&_format=[mime-type]}`
- A Server SHALL be capable of supporting the following _revincludes:
  - Provenance:target - `GET [base]/DocumentReference?[parameter=value]&_revinclude=Provenance:target`

Search Parameter Requirements (When Used Alone or in Combination):

Conformance | Parameter | Type | Example
--- | --- | --- | ---
SHALL | _id | Token | `GET [base]/DocumentReference?_id=[id]`
SHALL | patient | Reference | `GET [base]/DocumentReference?patient=[type]/[id]`
SHALL | patient+type | Reference+Token | `GET [base]/DocumentReference?patient=[type]/[id]&type=[system]|[code]`
SHALL | patient+category+date | Reference+Token+Date/DateTime | `GET [base]/DocumentReference?patient=[type]/[id]&category=[system]|[code]&date=[dateTime]`
SHALL | patient+category | Reference+Token | `GET [base]/DocumentReference?patient=[type]/[id]&category=[system]|[code]`
SHOULD | patient+type+period | Reference+Token+Date/DateTime | `GET [base]/DocumentReference?patient=[type]/[id]&type=[system]|[code]&period=[dateTime]`
SHOULD | patient+status | Reference+Token | `GET [base]/DocumentReference?patient=[type]/[id]&status=[system]|[code]`

- category (Token):

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

  The server SHALL support both.

- date (Date/DateTime):

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

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

- patient (Reference):

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

  The server SHALL support both.

- period (Date/DateTime):

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

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

- status (Token):

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

  The server SHALL support both.

- type (Token):

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

  The server SHALL support both.

FHIR Operations:

- SHALL support `$docref`

> `$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]`

#### Encounter

Conformance Expectation: SHALL

Supported Profiles:

- SHALL support US Core Encounter Profile

FHIR RESTful Interactions

Summary:

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

Modify Criteria Details:

- A Server MAY be capable of creating a Encounter resource using: `POST [base]/Encounter {?_format=[mime-type]}`
- A Server MAY be capable of updating a existing Encounter resource using: `PUT [base]/Encounter/[id] {?_format=[mime-type]}`
- A Server MAY be capable of patching an existing Encounter resource using: `PATCH [base]/Encounter/[id] {?_format=[mime-type]}`
- A Server MAY be capable of deleting a Encounter resource using: `DELETE [base]/Encounter/[id]`

Fetch and Search Criteria Details:

- A Server SHALL be capable of a `search-type` interaction returning Encounter resources matching a search query using: `GET [base]/Encounter/[id]{?[parameters]{&_format=[mime-type]}}`
- A Server SHALL be capable of a `read` interaction returning a Encounter resource using: `GET [base]/Encounter/[id]`
- A Server SHOULD be capable of a `vread` interaction returning a Encounter resource using: `GET [base]/Encounter/[id]/_history/vid`
- A Server SHOULD be capable of a `history-instance` interaction returning a history of a Encounter using: `GET [base]/Encounter/[id]/_history{?[parameters]&_format=[mime-type]}`
- A Server MAY be capable of a `history-type` interaction returning the history of Encounter resources using: `GET [base]/Encounter/_history{?[parameters]&_format=[mime-type]}`
- A Server SHALL be capable of supporting the following _revincludes:
  - Provenance:target - `GET [base]/Encounter?[parameter=value]&_revinclude=Provenance:target`

Search Parameter Requirements (When Used Alone or in Combination):

Conformance | Parameter | Type | Example
--- | --- | --- | ---
SHALL | _id | Token | `GET [base]/Encounter?_id=[id]`
SHOULD | identifier | Token | `GET [base]/Encounter?identifier=[system]|[code]`
SHALL | patient | Reference | `GET [base]/Encounter?patient=[type]/[id]`
SHOULD | patient+type | Reference+Token | `GET [base]/Encounter?patient=[type]/[id]&type=[system]|[code]`
SHOULD | class+patient | Token+Reference | `GET [base]/Encounter?class=[system]|[code]&patient=[type]/[id]`
SHOULD | patient+status | Reference+Token | `GET [base]/Encounter?patient=[type]/[id]&status=[system]|[code]`
SHOULD | patient+_lastUpdated | Reference+Date/DateTime | `GET [base]/Encounter?patient=[type]/[id]&_lastUpdated=[dateTime]`
SHOULD | patient+location | Reference+Reference | `GET [base]/Encounter?patient=[type]/[id]&location=[type]/[id]`
SHALL | date+patient | Date/DateTime+Reference | `GET [base]/Encounter?date=[dateTime]&patient=[type]/[id]`
SHOULD | patient+discharge-disposition | Reference+Token | `GET [base]/Encounter?patient=[type]/[id]&discharge-disposition=[system]|[code]`

- class (Token):

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

  The server SHALL support both.

- date (Date/DateTime):

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

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

- _lastUpdated (Date/DateTime):

  A server SHALL document the types of changes that can be detected using this parameter.

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

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

- discharge-disposition (Token):

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

  The server SHALL support both.

- identifier (Token):

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

  The server SHALL support both.

- location (Reference):

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

  The server SHALL support both.

- patient (Reference):

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

  The server SHALL support both.

- status (Token):

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

  The server SHALL support both.

- type (Token):

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

  The server SHALL support both.

#### Endpoint

Conformance Expectation: SHALL

Resource Specific Documentation:

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

FHIR RESTful Interactions

Summary:

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

Modify Criteria Details:

- A Server MAY be capable of creating a Endpoint resource using: `POST [base]/Endpoint {?_format=[mime-type]}`
- A Server MAY be capable of updating a existing Endpoint resource using: `PUT [base]/Endpoint/[id] {?_format=[mime-type]}`
- A Server MAY be capable of patching an existing Endpoint resource using: `PATCH [base]/Endpoint/[id] {?_format=[mime-type]}`
- A Server MAY be capable of deleting a Endpoint resource using: `DELETE [base]/Endpoint/[id]`

Fetch and Search Criteria Details:

- A Server MAY be capable of a `search-type` interaction returning Endpoint resources matching a search query using: `GET [base]/Endpoint/[id]{?[parameters]{&_format=[mime-type]}}`
- A Server SHOULD be capable of a `read` interaction returning a Endpoint resource using: `GET [base]/Endpoint/[id]`
- A Server SHOULD be capable of a `vread` interaction returning a Endpoint resource using: `GET [base]/Endpoint/[id]/_history/vid`
- A Server MAY be capable of a `history-instance` interaction returning a history of a Endpoint using: `GET [base]/Endpoint/[id]/_history{?[parameters]&_format=[mime-type]}`
- A Server MAY be capable of a `history-type` interaction returning the history of Endpoint resources using: `GET [base]/Endpoint/_history{?[parameters]&_format=[mime-type]}`

#### FamilyMemberHistory

Conformance Expectation: SHALL

Supported Profiles:

- SHALL support US Core FamilyMemberHistory Profile

FHIR RESTful Interactions

Summary:

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

Modify Criteria Details:

- A Server MAY be capable of creating a FamilyMemberHistory resource using: `POST [base]/FamilyMemberHistory {?_format=[mime-type]}`
- A Server MAY be capable of updating a existing FamilyMemberHistory resource using: `PUT [base]/FamilyMemberHistory/[id] {?_format=[mime-type]}`
- A Server MAY be capable of patching an existing FamilyMemberHistory resource using: `PATCH [base]/FamilyMemberHistory/[id] {?_format=[mime-type]}`
- A Server MAY be capable of deleting a FamilyMemberHistory resource using: `DELETE [base]/FamilyMemberHistory/[id]`

Fetch and Search Criteria Details:

- A Server SHALL be capable of a `search-type` interaction returning FamilyMemberHistory resources matching a search query using: `GET [base]/FamilyMemberHistory/[id]{?[parameters]{&_format=[mime-type]}}`
- A Server SHALL be capable of a `read` interaction returning a FamilyMemberHistory resource using: `GET [base]/FamilyMemberHistory/[id]`
- A Server SHOULD be capable of a `vread` interaction returning a FamilyMemberHistory resource using: `GET [base]/FamilyMemberHistory/[id]/_history/vid`
- A Server SHOULD be capable of a `history-instance` interaction returning a history of a FamilyMemberHistory using: `GET [base]/FamilyMemberHistory/[id]/_history{?[parameters]&_format=[mime-type]}`
- A Server MAY be capable of a `history-type` interaction returning the history of FamilyMemberHistory resources using: `GET [base]/FamilyMemberHistory/_history{?[parameters]&_format=[mime-type]}`
- A Server SHALL be capable of supporting the following _revincludes:
  - Provenance:target - `GET [base]/FamilyMemberHistory?[parameter=value]&_revinclude=Provenance:target`

Search Parameter Requirements (When Used Alone or in Combination):

Conformance | Parameter | Type | Example
--- | --- | --- | ---
SHALL | patient | Reference | `GET [base]/FamilyMemberHistory?patient=[type]/[id]`
SHOULD | patient+code | Reference+Token | `GET [base]/FamilyMemberHistory?patient=[type]/[id]&code=[system]|[code]`

- patient (Reference):

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

  The server SHALL support both.

- code (Token):

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

  The server SHALL support both.

#### Goal

Conformance Expectation: SHALL

Supported Profiles:

- SHALL support US Core Goal Profile

FHIR RESTful Interactions

Summary:

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

Modify Criteria Details:

- A Server MAY be capable of creating a Goal resource using: `POST [base]/Goal {?_format=[mime-type]}`
- A Server MAY be capable of updating a existing Goal resource using: `PUT [base]/Goal/[id] {?_format=[mime-type]}`
- A Server MAY be capable of patching an existing Goal resource using: `PATCH [base]/Goal/[id] {?_format=[mime-type]}`
- A Server MAY be capable of deleting a Goal resource using: `DELETE [base]/Goal/[id]`

Fetch and Search Criteria Details:

- A Server SHALL be capable of a `search-type` interaction returning Goal resources matching a search query using: `GET [base]/Goal/[id]{?[parameters]{&_format=[mime-type]}}`
- A Server SHALL be capable of a `read` interaction returning a Goal resource using: `GET [base]/Goal/[id]`
- A Server SHOULD be capable of a `vread` interaction returning a Goal resource using: `GET [base]/Goal/[id]/_history/vid`
- A Server SHOULD be capable of a `history-instance` interaction returning a history of a Goal using: `GET [base]/Goal/[id]/_history{?[parameters]&_format=[mime-type]}`
- A Server MAY be capable of a `history-type` interaction returning the history of Goal resources using: `GET [base]/Goal/_history{?[parameters]&_format=[mime-type]}`
- A Server SHALL be capable of supporting the following _revincludes:
  - Provenance:target - `GET [base]/Goal?[parameter=value]&_revinclude=Provenance:target`

Search Parameter Requirements (When Used Alone or in Combination):

Conformance | Parameter | Type | Example
--- | --- | --- | ---
SHALL | patient | Reference | `GET [base]/Goal?patient=[type]/[id]`
SHOULD | patient+description | Reference+Token | `GET [base]/Goal?patient=[type]/[id]&description=[system]|[code]`
SHOULD | patient+target-date | Reference+Date/DateTime | `GET [base]/Goal?patient=[type]/[id]&target-date=[dateTime]`
SHOULD | patient+lifecycle-status | Reference+Token | `GET [base]/Goal?patient=[type]/[id]&lifecycle-status=[system]|[code]`

- lifecycle-status (Token):

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

  The server SHALL support both.

- patient (Reference):

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

  The server SHALL support both.

- target-date (Date/DateTime):

  A client SHALL provide a value precise to the day.

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

#### HealthcareService

Conformance Expectation: MAY

Resource Specific Documentation:

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

FHIR RESTful Interactions

Summary:

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

Modify Criteria Details:

- A Server MAY be capable of creating a HealthcareService resource using: `POST [base]/HealthcareService {?_format=[mime-type]}`
- A Server MAY be capable of updating a existing HealthcareService resource using: `PUT [base]/HealthcareService/[id] {?_format=[mime-type]}`
- A Server MAY be capable of patching an existing HealthcareService resource using: `PATCH [base]/HealthcareService/[id] {?_format=[mime-type]}`
- A Server MAY be capable of deleting a HealthcareService resource using: `DELETE [base]/HealthcareService/[id]`

Fetch and Search Criteria Details:

- A Server MAY be capable of a `search-type` interaction returning HealthcareService resources matching a search query using: `GET [base]/HealthcareService/[id]{?[parameters]{&_format=[mime-type]}}`
- A Server SHOULD be capable of a `read` interaction returning a HealthcareService resource using: `GET [base]/HealthcareService/[id]`
- A Server SHOULD be capable of a `vread` interaction returning a HealthcareService resource using: `GET [base]/HealthcareService/[id]/_history/vid`
- A Server MAY be capable of a `history-instance` interaction returning a history of a HealthcareService using: `GET [base]/HealthcareService/[id]/_history{?[parameters]&_format=[mime-type]}`
- A Server MAY be capable of a `history-type` interaction returning the history of HealthcareService resources using: `GET [base]/HealthcareService/_history{?[parameters]&_format=[mime-type]}`

#### Immunization

Conformance Expectation: SHALL

Supported Profiles:

- SHALL support US Core Immunization Profile

FHIR RESTful Interactions

Summary:

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

Modify Criteria Details:

- A Server MAY be capable of creating a Immunization resource using: `POST [base]/Immunization {?_format=[mime-type]}`
- A Server MAY be capable of updating a existing Immunization resource using: `PUT [base]/Immunization/[id] {?_format=[mime-type]}`
- A Server MAY be capable of patching an existing Immunization resource using: `PATCH [base]/Immunization/[id] {?_format=[mime-type]}`
- A Server MAY be capable of deleting a Immunization resource using: `DELETE [base]/Immunization/[id]`

Fetch and Search Criteria Details:

- A Server SHALL be capable of a `search-type` interaction returning Immunization resources matching a search query using: `GET [base]/Immunization/[id]{?[parameters]{&_format=[mime-type]}}`
- A Server SHALL be capable of a `read` interaction returning a Immunization resource using: `GET [base]/Immunization/[id]`
- A Server SHOULD be capable of a `vread` interaction returning a Immunization resource using: `GET [base]/Immunization/[id]/_history/vid`
- A Server SHOULD be capable of a `history-instance` interaction returning a history of a Immunization using: `GET [base]/Immunization/[id]/_history{?[parameters]&_format=[mime-type]}`
- A Server MAY be capable of a `history-type` interaction returning the history of Immunization resources using: `GET [base]/Immunization/_history{?[parameters]&_format=[mime-type]}`
- A Server SHALL be capable of supporting the following _revincludes:
  - Provenance:target - `GET [base]/Immunization?[parameter=value]&_revinclude=Provenance:target`

Search Parameter Requirements (When Used Alone or in Combination):

Conformance | Parameter | Type | Example
--- | --- | --- | ---
SHALL | patient | Reference | `GET [base]/Immunization?patient=[type]/[id]`
SHOULD | patient+date | Reference+Date/DateTime | `GET [base]/Immunization?patient=[type]/[id]&date=[dateTime]`
SHOULD | patient+status | Reference+Token | `GET [base]/Immunization?patient=[type]/[id]&status=[system]|[code]`

- date (Date/DateTime):

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

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

- patient (Reference):

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

  The server SHALL support both.

- status (Token):

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

  The server SHALL support both.

#### Location

Conformance Expectation: SHALL

Supported Profiles:

- SHALL support US Core Location Profile

FHIR RESTful Interactions

Summary:

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

Modify Criteria Details:

- A Server MAY be capable of creating a Location resource using: `POST [base]/Location {?_format=[mime-type]}`
- A Server MAY be capable of updating a existing Location resource using: `PUT [base]/Location/[id] {?_format=[mime-type]}`
- A Server MAY be capable of patching an existing Location resource using: `PATCH [base]/Location/[id] {?_format=[mime-type]}`
- A Server MAY be capable of deleting a Location resource using: `DELETE [base]/Location/[id]`

Fetch and Search Criteria Details:

- A Server SHALL be capable of a `search-type` interaction returning Location resources matching a search query using: `GET [base]/Location/[id]{?[parameters]{&_format=[mime-type]}}`
- A Server SHALL be capable of a `read` interaction returning a Location resource using: `GET [base]/Location/[id]`
- A Server SHOULD be capable of a `vread` interaction returning a Location resource using: `GET [base]/Location/[id]/_history/vid`
- A Server SHOULD be capable of a `history-instance` interaction returning a history of a Location using: `GET [base]/Location/[id]/_history{?[parameters]&_format=[mime-type]}`
- A Server MAY be capable of a `history-type` interaction returning the history of Location resources using: `GET [base]/Location/_history{?[parameters]&_format=[mime-type]}`

Search Parameter Requirements (When Used Alone or in Combination):

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

#### Medication

Conformance Expectation: SHALL

Supported Profiles:

- SHALL support US Core Medication Profile

FHIR RESTful Interactions

Summary:

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

Modify Criteria Details:

- A Server MAY be capable of creating a Medication resource using: `POST [base]/Medication {?_format=[mime-type]}`
- A Server MAY be capable of updating a existing Medication resource using: `PUT [base]/Medication/[id] {?_format=[mime-type]}`
- A Server MAY be capable of patching an existing Medication resource using: `PATCH [base]/Medication/[id] {?_format=[mime-type]}`
- A Server MAY be capable of deleting a Medication resource using: `DELETE [base]/Medication/[id]`

Fetch and Search Criteria Details:

- A Server MAY be capable of a `search-type` interaction returning Medication resources matching a search query using: `GET [base]/Medication/[id]{?[parameters]{&_format=[mime-type]}}`
- A Server SHALL be capable of a `read` interaction returning a Medication resource using: `GET [base]/Medication/[id]`
- A Server SHOULD be capable of a `vread` interaction returning a Medication resource using: `GET [base]/Medication/[id]/_history/vid`
- A Server SHOULD be capable of a `history-instance` interaction returning a history of a Medication using: `GET [base]/Medication/[id]/_history{?[parameters]&_format=[mime-type]}`
- A Server MAY be capable of a `history-type` interaction returning the history of Medication resources using: `GET [base]/Medication/_history{?[parameters]&_format=[mime-type]}`

#### MedicationDispense

Conformance Expectation: SHALL

Supported Profiles:

- SHALL support US Core MedicationDispense Profile

FHIR RESTful Interactions

Summary:

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

Modify Criteria Details:

- A Server MAY be capable of creating a MedicationDispense resource using: `POST [base]/MedicationDispense {?_format=[mime-type]}`
- A Server MAY be capable of updating a existing MedicationDispense resource using: `PUT [base]/MedicationDispense/[id] {?_format=[mime-type]}`
- A Server MAY be capable of patching an existing MedicationDispense resource using: `PATCH [base]/MedicationDispense/[id] {?_format=[mime-type]}`
- A Server MAY be capable of deleting a MedicationDispense resource using: `DELETE [base]/MedicationDispense/[id]`

Fetch and Search Criteria Details:

- A Server SHALL be capable of a `search-type` interaction returning MedicationDispense resources matching a search query using: `GET [base]/MedicationDispense/[id]{?[parameters]{&_format=[mime-type]}}`
- A Server SHALL be capable of a `read` interaction returning a MedicationDispense resource using: `GET [base]/MedicationDispense/[id]`
- A Server SHOULD be capable of a `vread` interaction returning a MedicationDispense resource using: `GET [base]/MedicationDispense/[id]/_history/vid`
- A Server SHOULD be capable of a `history-instance` interaction returning a history of a MedicationDispense using: `GET [base]/MedicationDispense/[id]/_history{?[parameters]&_format=[mime-type]}`
- A Server MAY be capable of a `history-type` interaction returning the history of MedicationDispense resources using: `GET [base]/MedicationDispense/_history{?[parameters]&_format=[mime-type]}`
- A Server SHOULD be capable of supporting the following _includes:
  - MedicationDispense:medication - `GET [base]/MedicationDispense?[parameter=value]&_include=MedicationDispense:medication`
- A Server SHALL be capable of supporting the following _revincludes:
  - Provenance:target - `GET [base]/MedicationDispense?[parameter=value]&_revinclude=Provenance:target`

Search Parameter Requirements (When Used Alone or in Combination):

Conformance | Parameter | Type | Example
--- | --- | --- | ---
SHALL | patient | Reference | `GET [base]/MedicationDispense?patient=[type]/[id]`
SHOULD | patient+status+type | Reference+Token+Token | `GET [base]/MedicationDispense?patient=[type]/[id]&status=[system]|[code]&type=[system]|[code]`
SHOULD | patient+status | Reference+Token | `GET [base]/MedicationDispense?patient=[type]/[id]&status=[system]|[code]`

- patient (Reference):

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

  The server SHALL support both.

- status (Token):

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

  The server SHALL support both.

- type (Token):

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

  The server SHALL support both.

#### MedicationRequest

Conformance Expectation: SHALL

Supported Profiles:

- SHALL support US Core MedicationRequest Profile

FHIR RESTful Interactions

Summary:

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

Modify Criteria Details:

- A Server MAY be capable of creating a MedicationRequest resource using: `POST [base]/MedicationRequest {?_format=[mime-type]}`
- A Server MAY be capable of updating a existing MedicationRequest resource using: `PUT [base]/MedicationRequest/[id] {?_format=[mime-type]}`
- A Server MAY be capable of patching an existing MedicationRequest resource using: `PATCH [base]/MedicationRequest/[id] {?_format=[mime-type]}`
- A Server MAY be capable of deleting a MedicationRequest resource using: `DELETE [base]/MedicationRequest/[id]`

Fetch and Search Criteria Details:

- A Server SHALL be capable of a `search-type` interaction returning MedicationRequest resources matching a search query using: `GET [base]/MedicationRequest/[id]{?[parameters]{&_format=[mime-type]}}`
- A Server SHALL be capable of a `read` interaction returning a MedicationRequest resource using: `GET [base]/MedicationRequest/[id]`
- A Server SHOULD be capable of a `vread` interaction returning a MedicationRequest resource using: `GET [base]/MedicationRequest/[id]/_history/vid`
- A Server SHOULD be capable of a `history-instance` interaction returning a history of a MedicationRequest using: `GET [base]/MedicationRequest/[id]/_history{?[parameters]&_format=[mime-type]}`
- A Server MAY be capable of a `history-type` interaction returning the history of MedicationRequest resources using: `GET [base]/MedicationRequest/_history{?[parameters]&_format=[mime-type]}`
- 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 Requirements (When Used Alone or in Combination):

Conformance | Parameter | Type | Example
--- | --- | --- | ---
SHOULD | patient+intent+authoredon | Reference+Token+Date/DateTime | `GET [base]/MedicationRequest?patient=[type]/[id]&intent=[system]|[code]&authoredon=[dateTime]`
SHOULD | patient+intent+encounter | Reference+Token+Reference | `GET [base]/MedicationRequest?patient=[type]/[id]&intent=[system]|[code]&encounter=[type]/[id]`
SHALL | patient+intent | Reference+Token | `GET [base]/MedicationRequest?patient=[type]/[id]&intent=[system]|[code]`
SHALL | patient+intent+status | Reference+Token+Token | `GET [base]/MedicationRequest?patient=[type]/[id]&intent=[system]|[code]&status=[system]|[code]`

- authoredon (Date/DateTime):

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

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

- encounter (Reference):

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

  The server SHALL support both.

- intent (Token):

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

  The server SHALL support both.

- patient (Reference):

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

  The server SHALL support both.

- status (Token):

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

  The server SHALL support both.

#### Observation

Conformance Expectation: SHALL

Supported Profiles:

- SHALL support US Core Observation ADI Documentation Profile
- SHALL support US Core Laboratory Result Observation Profile
- SHALL support US Core Observation Pregnancy Status Profile
- SHALL support US Core Observation Pregnancy Intent Profile
- SHALL support US Core Observation Occupation Profile
- SHALL support US Core Respiratory Rate Profile
- SHALL support US Core Simple Observation Profile
- SHALL support US Core Treatment Intervention Preference Profile
- SHALL support US Core Care Experience Preference Profile
- SHALL support US Core Heart Rate Profile
- SHALL support US Core Body Temperature Profile
- SHALL support US Core Pediatric Weight for Height Observation Profile
- SHALL support US Core Pulse Oximetry Profile
- SHALL support US Core Smoking Status Observation Profile
- MAY support US Core Observation Sexual Orientation Profile
- SHALL support US Core Head Circumference Profile
- SHALL support US Core Body Height Profile
- SHALL support US Core BMI Profile
- SHALL support US Core Observation Screening Assessment Profile
- SHALL support US Core Average Blood Pressure Profile
- SHALL support US Core Blood Pressure Profile
- SHALL support US Core Observation Clinical Result Profile
- SHALL support US Core Pediatric BMI for Age Observation Profile
- SHALL support US Core Pediatric Head Occipital Frontal Circumference Percentile Profile
- SHALL support US Core Body Weight Profile
- SHALL support US Core Vital Signs Profile

FHIR RESTful Interactions

Summary:

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

Modify Criteria Details:

- A Server MAY be capable of creating a Observation resource using: `POST [base]/Observation {?_format=[mime-type]}`
- A Server MAY be capable of updating a existing Observation resource using: `PUT [base]/Observation/[id] {?_format=[mime-type]}`
- A Server MAY be capable of patching an existing Observation resource using: `PATCH [base]/Observation/[id] {?_format=[mime-type]}`
- A Server MAY be capable of deleting a Observation resource using: `DELETE [base]/Observation/[id]`

Fetch and Search Criteria Details:

- A Server SHALL be capable of a `search-type` interaction returning Observation resources matching a search query using: `GET [base]/Observation/[id]{?[parameters]{&_format=[mime-type]}}`
- A Server SHALL be capable of a `read` interaction returning a Observation resource using: `GET [base]/Observation/[id]`
- A Server SHOULD be capable of a `vread` interaction returning a Observation resource using: `GET [base]/Observation/[id]/_history/vid`
- A Server SHOULD be capable of a `history-instance` interaction returning a history of a Observation using: `GET [base]/Observation/[id]/_history{?[parameters]&_format=[mime-type]}`
- A Server MAY be capable of a `history-type` interaction returning the history of Observation resources using: `GET [base]/Observation/_history{?[parameters]&_format=[mime-type]}`
- A Server SHALL be capable of supporting the following _revincludes:
  - Provenance:target - `GET [base]/Observation?[parameter=value]&_revinclude=Provenance:target`

Search Parameter Requirements (When Used Alone or in Combination):

Conformance | Parameter | Type | Example
--- | --- | --- | ---
SHOULD | patient+code+date | Reference+Token+Date/DateTime | `GET [base]/Observation?patient=[type]/[id]&code=[system]|[code]&date=[dateTime]`
SHOULD | patient+category+_lastUpdated | Reference+Token+Date/DateTime | `GET [base]/Observation?patient=[type]/[id]&category=[system]|[code]&_lastUpdated=[dateTime]`
SHALL | patient+category+date | Reference+Token+Date/DateTime | `GET [base]/Observation?patient=[type]/[id]&category=[system]|[code]&date=[dateTime]`
SHALL | patient+category | Reference+Token | `GET [base]/Observation?patient=[type]/[id]&category=[system]|[code]`
SHOULD | patient+category+status | Reference+Token+Token | `GET [base]/Observation?patient=[type]/[id]&category=[system]|[code]&status=[system]|[code]`
SHALL | patient+code | Reference+Token | `GET [base]/Observation?patient=[type]/[id]&code=[system]|[code]`

- category (Token):

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

  The server SHALL support both.

- code (Token):

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

  The server SHALL support both.

- date (Date/DateTime):

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

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

- _lastUpdated (Date/DateTime):

  A server SHALL document the types of changes that can be detected using this parameter.

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

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

- patient (Reference):

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

  The server SHALL support both.

- status (Token):

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

  The server SHALL support both.

#### Organization

Conformance Expectation: SHALL

Supported Profiles:

- SHALL support US Core Organization Profile

FHIR RESTful Interactions

Summary:

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

Modify Criteria Details:

- A Server MAY be capable of creating a Organization resource using: `POST [base]/Organization {?_format=[mime-type]}`
- A Server MAY be capable of updating a existing Organization resource using: `PUT [base]/Organization/[id] {?_format=[mime-type]}`
- A Server MAY be capable of patching an existing Organization resource using: `PATCH [base]/Organization/[id] {?_format=[mime-type]}`
- A Server MAY be capable of deleting a Organization resource using: `DELETE [base]/Organization/[id]`

Fetch and Search Criteria Details:

- A Server SHALL be capable of a `search-type` interaction returning Organization resources matching a search query using: `GET [base]/Organization/[id]{?[parameters]{&_format=[mime-type]}}`
- A Server SHALL be capable of a `read` interaction returning a Organization resource using: `GET [base]/Organization/[id]`
- A Server SHOULD be capable of a `vread` interaction returning a Organization resource using: `GET [base]/Organization/[id]/_history/vid`
- A Server SHOULD be capable of a `history-instance` interaction returning a history of a Organization using: `GET [base]/Organization/[id]/_history{?[parameters]&_format=[mime-type]}`
- A Server MAY be capable of a `history-type` interaction returning the history of Organization resources using: `GET [base]/Organization/_history{?[parameters]&_format=[mime-type]}`

Search Parameter Requirements (When Used Alone or in Combination):

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

#### Patient

Conformance Expectation: SHALL

Supported Profiles:

- SHALL support US Core Patient Profile

FHIR RESTful Interactions

Summary:

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

Modify Criteria Details:

- A Server MAY be capable of creating a Patient resource using: `POST [base]/Patient {?_format=[mime-type]}`
- A Server MAY be capable of updating a existing Patient resource using: `PUT [base]/Patient/[id] {?_format=[mime-type]}`
- A Server MAY be capable of patching an existing Patient resource using: `PATCH [base]/Patient/[id] {?_format=[mime-type]}`
- A Server MAY be capable of deleting a Patient resource using: `DELETE [base]/Patient/[id]`

Fetch and Search Criteria Details:

- A Server SHALL be capable of a `search-type` interaction returning Patient resources matching a search query using: `GET [base]/Patient/[id]{?[parameters]{&_format=[mime-type]}}`
- A Server SHALL be capable of a `read` interaction returning a Patient resource using: `GET [base]/Patient/[id]`
- A Server SHOULD be capable of a `vread` interaction returning a Patient resource using: `GET [base]/Patient/[id]/_history/vid`
- A Server SHOULD be capable of a `history-instance` interaction returning a history of a Patient using: `GET [base]/Patient/[id]/_history{?[parameters]&_format=[mime-type]}`
- A Server MAY be capable of a `history-type` interaction returning the history of Patient resources using: `GET [base]/Patient/_history{?[parameters]&_format=[mime-type]}`
- A Server SHALL be capable of supporting the following _revincludes:
  - Provenance:target - `GET [base]/Patient?[parameter=value]&_revinclude=Provenance:target`

Search Parameter Requirements (When Used Alone or in Combination):

Conformance | Parameter | Type | Example
--- | --- | --- | ---
SHALL | _id | Token | `GET [base]/Patient?_id=[id]`
SHALL | identifier | Token | `GET [base]/Patient?identifier=[system]|[code]`
SHALL | name | String | `GET [base]/Patient?name=[name]`
SHALL | birthdate+name | Date/DateTime+String | `GET [base]/Patient?birthdate=[dateTime]&name=[name]`
SHOULD | birthdate+family | Date/DateTime+String | `GET [base]/Patient?birthdate=[dateTime]&family=[family]`
SHOULD | death-date+family | Date/DateTime+String | `GET [base]/Patient?death-date=[dateTime]&family=[family]`

- birthdate (Date/DateTime):

  A client SHALL provide a value precise to the day.

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

- death-date (Date/DateTime):

  A client SHALL provide a value precise to the day.

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

- identifier (Token):

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

  The server SHALL support both.

#### Practitioner

Conformance Expectation: SHALL

Supported Profiles:

- SHALL support US Core Practitioner Profile

FHIR RESTful Interactions

Summary:

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

Modify Criteria Details:

- A Server MAY be capable of creating a Practitioner resource using: `POST [base]/Practitioner {?_format=[mime-type]}`
- A Server MAY be capable of updating a existing Practitioner resource using: `PUT [base]/Practitioner/[id] {?_format=[mime-type]}`
- A Server MAY be capable of patching an existing Practitioner resource using: `PATCH [base]/Practitioner/[id] {?_format=[mime-type]}`
- A Server MAY be capable of deleting a Practitioner resource using: `DELETE [base]/Practitioner/[id]`

Fetch and Search Criteria Details:

- A Server SHALL be capable of a `search-type` interaction returning Practitioner resources matching a search query using: `GET [base]/Practitioner/[id]{?[parameters]{&_format=[mime-type]}}`
- A Server SHALL be capable of a `read` interaction returning a Practitioner resource using: `GET [base]/Practitioner/[id]`
- A Server SHOULD be capable of a `vread` interaction returning a Practitioner resource using: `GET [base]/Practitioner/[id]/_history/vid`
- A Server SHOULD be capable of a `history-instance` interaction returning a history of a Practitioner using: `GET [base]/Practitioner/[id]/_history{?[parameters]&_format=[mime-type]}`
- A Server MAY be capable of a `history-type` interaction returning the history of Practitioner resources using: `GET [base]/Practitioner/_history{?[parameters]&_format=[mime-type]}`

Search Parameter Requirements (When Used Alone or in Combination):

Conformance | Parameter | Type | Example
--- | --- | --- | ---
SHOULD | _id | Token | `GET [base]/Practitioner?_id=[id]`
SHALL | identifier | Token | `GET [base]/Practitioner?identifier=[system]|[code]`
SHALL | name | String | `GET [base]/Practitioner?name=[name]`

- identifier (Token):

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

  The server SHALL support both.

#### PractitionerRole

Conformance Expectation: SHALL

Supported Profiles:

- SHALL support US Core PractitionerRole Profile

FHIR RESTful Interactions

Summary:

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

Modify Criteria Details:

- A Server MAY be capable of creating a PractitionerRole resource using: `POST [base]/PractitionerRole {?_format=[mime-type]}`
- A Server MAY be capable of updating a existing PractitionerRole resource using: `PUT [base]/PractitionerRole/[id] {?_format=[mime-type]}`
- A Server MAY be capable of patching an existing PractitionerRole resource using: `PATCH [base]/PractitionerRole/[id] {?_format=[mime-type]}`
- A Server MAY be capable of deleting a PractitionerRole resource using: `DELETE [base]/PractitionerRole/[id]`

Fetch and Search Criteria Details:

- A Server SHALL be capable of a `search-type` interaction returning PractitionerRole resources matching a search query using: `GET [base]/PractitionerRole/[id]{?[parameters]{&_format=[mime-type]}}`
- A Server SHALL be capable of a `read` interaction returning a PractitionerRole resource using: `GET [base]/PractitionerRole/[id]`
- A Server SHOULD be capable of a `vread` interaction returning a PractitionerRole resource using: `GET [base]/PractitionerRole/[id]/_history/vid`
- A Server SHOULD be capable of a `history-instance` interaction returning a history of a PractitionerRole using: `GET [base]/PractitionerRole/[id]/_history{?[parameters]&_format=[mime-type]}`
- A Server MAY be capable of a `history-type` interaction returning the history of PractitionerRole resources using: `GET [base]/PractitionerRole/_history{?[parameters]&_format=[mime-type]}`
- 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 Requirements (When Used Alone or in Combination):

Conformance | Parameter | Type | Example
--- | --- | --- | ---
SHALL | practitioner | Reference | `GET [base]/PractitionerRole?practitioner=[type]/[id]`
SHALL | specialty | Token | `GET [base]/PractitionerRole?specialty=[system]|[code]`

- practitioner (Reference):

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

  The server SHALL support both.

- specialty (Token):

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

  The server SHALL support both.

#### Procedure

Conformance Expectation: SHALL

Supported Profiles:

- SHALL support US Core Procedure Profile

FHIR RESTful Interactions

Summary:

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

Modify Criteria Details:

- A Server MAY be capable of creating a Procedure resource using: `POST [base]/Procedure {?_format=[mime-type]}`
- A Server MAY be capable of updating a existing Procedure resource using: `PUT [base]/Procedure/[id] {?_format=[mime-type]}`
- A Server MAY be capable of patching an existing Procedure resource using: `PATCH [base]/Procedure/[id] {?_format=[mime-type]}`
- A Server MAY be capable of deleting a Procedure resource using: `DELETE [base]/Procedure/[id]`

Fetch and Search Criteria Details:

- A Server SHALL be capable of a `search-type` interaction returning Procedure resources matching a search query using: `GET [base]/Procedure/[id]{?[parameters]{&_format=[mime-type]}}`
- A Server SHALL be capable of a `read` interaction returning a Procedure resource using: `GET [base]/Procedure/[id]`
- A Server SHOULD be capable of a `vread` interaction returning a Procedure resource using: `GET [base]/Procedure/[id]/_history/vid`
- A Server SHOULD be capable of a `history-instance` interaction returning a history of a Procedure using: `GET [base]/Procedure/[id]/_history{?[parameters]&_format=[mime-type]}`
- A Server MAY be capable of a `history-type` interaction returning the history of Procedure resources using: `GET [base]/Procedure/_history{?[parameters]&_format=[mime-type]}`
- A Server SHALL be capable of supporting the following _revincludes:
  - Provenance:target - `GET [base]/Procedure?[parameter=value]&_revinclude=Provenance:target`

Search Parameter Requirements (When Used Alone or in Combination):

Conformance | Parameter | Type | Example
--- | --- | --- | ---
SHALL | patient | Reference | `GET [base]/Procedure?patient=[type]/[id]`
SHOULD | patient+code+date | Reference+Token+Date/DateTime | `GET [base]/Procedure?patient=[type]/[id]&code=[system]|[code]&date=[dateTime]`
SHALL | patient+date | Reference+Date/DateTime | `GET [base]/Procedure?patient=[type]/[id]&date=[dateTime]`
SHOULD | patient+status | Reference+Token | `GET [base]/Procedure?patient=[type]/[id]&status=[system]|[code]`

- code (Token):

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

  The server SHALL support both.

- date (Date/DateTime):

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

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

- patient (Reference):

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

  The server SHALL support both.

- status (Token):

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

  The server SHALL support both.

#### Provenance

Conformance Expectation: SHALL

Supported Profiles:

- SHALL support US Core Provenance Profile

FHIR RESTful Interactions

Summary:

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

Modify Criteria Details:

- A Server MAY be capable of creating a Provenance resource using: `POST [base]/Provenance {?_format=[mime-type]}`
- A Server MAY be capable of updating a existing Provenance resource using: `PUT [base]/Provenance/[id] {?_format=[mime-type]}`
- A Server MAY be capable of patching an existing Provenance resource using: `PATCH [base]/Provenance/[id] {?_format=[mime-type]}`
- A Server MAY be capable of deleting a Provenance resource using: `DELETE [base]/Provenance/[id]`

Fetch and Search Criteria Details:

- A Server MAY be capable of a `search-type` interaction returning Provenance resources matching a search query using: `GET [base]/Provenance/[id]{?[parameters]{&_format=[mime-type]}}`
- A Server SHALL be capable of a `read` interaction returning a Provenance resource using: `GET [base]/Provenance/[id]`
- A Server SHOULD be capable of a `vread` interaction returning a Provenance resource using: `GET [base]/Provenance/[id]/_history/vid`
- A Server SHOULD be capable of a `history-instance` interaction returning a history of a Provenance using: `GET [base]/Provenance/[id]/_history{?[parameters]&_format=[mime-type]}`
- A Server MAY be capable of a `history-type` interaction returning the history of Provenance resources using: `GET [base]/Provenance/_history{?[parameters]&_format=[mime-type]}`

#### Questionnaire

Conformance Expectation: SHOULD

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

Supported Profiles:

- SHALL support SDC Base Questionnaire Profile

FHIR RESTful Interactions

Summary:

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

Modify Criteria Details:

- A Server MAY be capable of creating a Questionnaire resource using: `POST [base]/Questionnaire {?_format=[mime-type]}`
- A Server MAY be capable of updating a existing Questionnaire resource using: `PUT [base]/Questionnaire/[id] {?_format=[mime-type]}`
- A Server MAY be capable of patching an existing Questionnaire resource using: `PATCH [base]/Questionnaire/[id] {?_format=[mime-type]}`
- A Server MAY be capable of deleting a Questionnaire resource using: `DELETE [base]/Questionnaire/[id]`

Fetch and Search Criteria Details:

- A Server MAY be capable of a `search-type` interaction returning Questionnaire resources matching a search query using: `GET [base]/Questionnaire/[id]{?[parameters]{&_format=[mime-type]}}`
- A Server SHOULD be capable of a `read` interaction returning a Questionnaire resource using: `GET [base]/Questionnaire/[id]`
- A Server SHOULD be capable of a `vread` interaction returning a Questionnaire resource using: `GET [base]/Questionnaire/[id]/_history/vid`
- A Server MAY be capable of a `history-instance` interaction returning a history of a Questionnaire using: `GET [base]/Questionnaire/[id]/_history{?[parameters]&_format=[mime-type]}`
- A Server MAY be capable of a `history-type` interaction returning the history of Questionnaire resources using: `GET [base]/Questionnaire/_history{?[parameters]&_format=[mime-type]}`

#### QuestionnaireResponse

Conformance Expectation: SHOULD

Supported Profiles:

- SHALL support US Core QuestionnaireResponse Profile

FHIR RESTful Interactions

Summary:

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

Modify Criteria Details:

- A Server MAY be capable of creating a QuestionnaireResponse resource using: `POST [base]/QuestionnaireResponse {?_format=[mime-type]}`
- A Server MAY be capable of updating a existing QuestionnaireResponse resource using: `PUT [base]/QuestionnaireResponse/[id] {?_format=[mime-type]}`
- A Server MAY be capable of patching an existing QuestionnaireResponse resource using: `PATCH [base]/QuestionnaireResponse/[id] {?_format=[mime-type]}`
- A Server MAY be capable of deleting a QuestionnaireResponse resource using: `DELETE [base]/QuestionnaireResponse/[id]`

Fetch and Search Criteria Details:

- A Server SHOULD be capable of a `search-type` interaction returning QuestionnaireResponse resources matching a search query using: `GET [base]/QuestionnaireResponse/[id]{?[parameters]{&_format=[mime-type]}}`
- A Server SHOULD be capable of a `read` interaction returning a QuestionnaireResponse resource using: `GET [base]/QuestionnaireResponse/[id]`
- A Server SHOULD be capable of a `vread` interaction returning a QuestionnaireResponse resource using: `GET [base]/QuestionnaireResponse/[id]/_history/vid`
- A Server SHOULD be capable of a `history-instance` interaction returning a history of a QuestionnaireResponse using: `GET [base]/QuestionnaireResponse/[id]/_history{?[parameters]&_format=[mime-type]}`
- A Server MAY be capable of a `history-type` interaction returning the history of QuestionnaireResponse resources using: `GET [base]/QuestionnaireResponse/_history{?[parameters]&_format=[mime-type]}`
- A Server SHOULD be capable of supporting the following _revincludes:
  - Provenance:target - `GET [base]/QuestionnaireResponse?[parameter=value]&_revinclude=Provenance:target`

Search Parameter Requirements (When Used Alone or in Combination):

Conformance | Parameter | Type | Example
--- | --- | --- | ---
SHALL | _id | Token | `GET [base]/QuestionnaireResponse?_id=[id]`
SHALL | patient | Reference | `GET [base]/QuestionnaireResponse?patient=[type]/[id]`
SHOULD | patient+questionnaire | Reference+Reference | `GET [base]/QuestionnaireResponse?patient=[type]/[id]&questionnaire=[type]/[id]`
SHOULD | patient+authored | Reference+Date/DateTime | `GET [base]/QuestionnaireResponse?patient=[type]/[id]&authored=[dateTime]`
SHOULD | patient+status | Reference+Token | `GET [base]/QuestionnaireResponse?patient=[type]/[id]&status=[system]|[code]`

- authored (Date/DateTime):

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

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

- patient (Reference):

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

  The server SHALL support both.

- questionnaire (Reference):

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

  The server SHALL support both.

- status (Token):

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

  The server SHALL support both.

#### RelatedPerson

Conformance Expectation: SHALL

Supported Profiles:

- SHALL support US Core RelatedPerson Profile

FHIR RESTful Interactions

Summary:

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

Modify Criteria Details:

- A Server MAY be capable of creating a RelatedPerson resource using: `POST [base]/RelatedPerson {?_format=[mime-type]}`
- A Server MAY be capable of updating a existing RelatedPerson resource using: `PUT [base]/RelatedPerson/[id] {?_format=[mime-type]}`
- A Server MAY be capable of patching an existing RelatedPerson resource using: `PATCH [base]/RelatedPerson/[id] {?_format=[mime-type]}`
- A Server MAY be capable of deleting a RelatedPerson resource using: `DELETE [base]/RelatedPerson/[id]`

Fetch and Search Criteria Details:

- A Server SHALL be capable of a `search-type` interaction returning RelatedPerson resources matching a search query using: `GET [base]/RelatedPerson/[id]{?[parameters]{&_format=[mime-type]}}`
- A Server SHALL be capable of a `read` interaction returning a RelatedPerson resource using: `GET [base]/RelatedPerson/[id]`
- A Server SHOULD be capable of a `vread` interaction returning a RelatedPerson resource using: `GET [base]/RelatedPerson/[id]/_history/vid`
- A Server SHOULD be capable of a `history-instance` interaction returning a history of a RelatedPerson using: `GET [base]/RelatedPerson/[id]/_history{?[parameters]&_format=[mime-type]}`
- A Server MAY be capable of a `history-type` interaction returning the history of RelatedPerson resources using: `GET [base]/RelatedPerson/_history{?[parameters]&_format=[mime-type]}`
- A Server SHALL be capable of supporting the following _revincludes:
  - Provenance:target - `GET [base]/RelatedPerson?[parameter=value]&_revinclude=Provenance:target`

Search Parameter Requirements (When Used Alone or in Combination):

Conformance | Parameter | Type | Example
--- | --- | --- | ---
SHALL | _id | Token | `GET [base]/RelatedPerson?_id=[id]`
SHOULD | name | String | `GET [base]/RelatedPerson?name=[name]`
SHOULD | patient | Reference | `GET [base]/RelatedPerson?patient=[type]/[id]`
SHOULD | patient+name | Reference+String | `GET [base]/RelatedPerson?patient=[type]/[id]&name=[name]`

- patient (Reference):

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

  The server SHALL support both.

#### ServiceRequest

Conformance Expectation: SHALL

Supported Profiles:

- SHALL support US Core ServiceRequest Profile

FHIR RESTful Interactions

Summary:

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

Modify Criteria Details:

- A Server MAY be capable of creating a ServiceRequest resource using: `POST [base]/ServiceRequest {?_format=[mime-type]}`
- A Server MAY be capable of updating a existing ServiceRequest resource using: `PUT [base]/ServiceRequest/[id] {?_format=[mime-type]}`
- A Server MAY be capable of patching an existing ServiceRequest resource using: `PATCH [base]/ServiceRequest/[id] {?_format=[mime-type]}`
- A Server MAY be capable of deleting a ServiceRequest resource using: `DELETE [base]/ServiceRequest/[id]`

Fetch and Search Criteria Details:

- A Server MAY be capable of a `search-type` interaction returning ServiceRequest resources matching a search query using: `GET [base]/ServiceRequest/[id]{?[parameters]{&_format=[mime-type]}}`
- A Server SHALL be capable of a `read` interaction returning a ServiceRequest resource using: `GET [base]/ServiceRequest/[id]`
- A Server SHOULD be capable of a `vread` interaction returning a ServiceRequest resource using: `GET [base]/ServiceRequest/[id]/_history/vid`
- A Server SHOULD be capable of a `history-instance` interaction returning a history of a ServiceRequest using: `GET [base]/ServiceRequest/[id]/_history{?[parameters]&_format=[mime-type]}`
- A Server MAY be capable of a `history-type` interaction returning the history of ServiceRequest resources using: `GET [base]/ServiceRequest/_history{?[parameters]&_format=[mime-type]}`
- A Server SHALL be capable of supporting the following _revincludes:
  - Provenance:target - `GET [base]/ServiceRequest?[parameter=value]&_revinclude=Provenance:target`

Search Parameter Requirements (When Used Alone or in Combination):

Conformance | Parameter | Type | Example
--- | --- | --- | ---
SHALL | _id | Token | `GET [base]/ServiceRequest?_id=[id]`
SHALL | patient | Reference | `GET [base]/ServiceRequest?patient=[type]/[id]`
SHOULD | patient+code+authored | Reference+Token+Date/DateTime | `GET [base]/ServiceRequest?patient=[type]/[id]&code=[system]|[code]&authored=[dateTime]`
SHALL | patient+category+authored | Reference+Token+Date/DateTime | `GET [base]/ServiceRequest?patient=[type]/[id]&category=[system]|[code]&authored=[dateTime]`
SHALL | patient+category | Reference+Token | `GET [base]/ServiceRequest?patient=[type]/[id]&category=[system]|[code]`
SHOULD | patient+status | Reference+Token | `GET [base]/ServiceRequest?patient=[type]/[id]&status=[system]|[code]`
SHALL | patient+code | Reference+Token | `GET [base]/ServiceRequest?patient=[type]/[id]&code=[system]|[code]`

- authored (Date/DateTime):

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

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

- category (Token):

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

  The server SHALL support both.

- code (Token):

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

  The server SHALL support both.

- patient (Reference):

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

  The server SHALL support both.

- status (Token):

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

  The server SHALL support both.

#### Specimen

Conformance Expectation: SHALL

Supported Profiles:

- SHALL support US Core Specimen Profile

FHIR RESTful Interactions

Summary:

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

Modify Criteria Details:

- A Server MAY be capable of creating a Specimen resource using: `POST [base]/Specimen {?_format=[mime-type]}`
- A Server MAY be capable of updating a existing Specimen resource using: `PUT [base]/Specimen/[id] {?_format=[mime-type]}`
- A Server MAY be capable of patching an existing Specimen resource using: `PATCH [base]/Specimen/[id] {?_format=[mime-type]}`
- A Server MAY be capable of deleting a Specimen resource using: `DELETE [base]/Specimen/[id]`

Fetch and Search Criteria Details:

- A Server MAY be capable of a `search-type` interaction returning Specimen resources matching a search query using: `GET [base]/Specimen/[id]{?[parameters]{&_format=[mime-type]}}`
- A Server SHALL be capable of a `read` interaction returning a Specimen resource using: `GET [base]/Specimen/[id]`
- A Server SHOULD be capable of a `vread` interaction returning a Specimen resource using: `GET [base]/Specimen/[id]/_history/vid`
- A Server SHOULD be capable of a `history-instance` interaction returning a history of a Specimen using: `GET [base]/Specimen/[id]/_history{?[parameters]&_format=[mime-type]}`
- A Server MAY be capable of a `history-type` interaction returning the history of Specimen resources using: `GET [base]/Specimen/_history{?[parameters]&_format=[mime-type]}`

Search Parameter Requirements (When Used Alone or in Combination):

Conformance | Parameter | Type | Example
--- | --- | --- | ---
SHALL | _id | Token | `GET [base]/Specimen?_id=[id]`
SHOULD | patient | Reference | `GET [base]/Specimen?patient=[type]/[id]`

#### ValueSet

Conformance Expectation: SHOULD

FHIR Operations:

- SHOULD support `$expand`

> `$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.