# text.div
US Core Server CapabilityStatement

Implementation Guide Version: 3.1.1

FHIR Version: 4.0.1

Supported formats: xml, json

Published: 2020-07-28

Published by: HL7 International - US Realm Steering Committee

This Section describes the expected capabilities of the US Core Server actor which is responsible for providing responses to the queries submitted by the US Core Requestors. The complete list of FHIR profiles, RESTful operations, and search parameters supported by US Core Servers are defined. Systems implementing this capability statement should meet the ONC 2015 Common Clinical Data Set (CCDS) access requirement for Patient Selection 170.315(g)(7) and Application Access - Data Category Request 170.315(g)(8) and and the ONC U.S. Core Data for Interoperability (USCDI). US Core Clients have the option of choosing from this list to access necessary data based on their local use cases and other contextual requirements.

FHIR RESTful Capabilities

The US Core Server SHALL:

Support the US Core Patient resource profile.

Support at least one additional resource profile from the list of US Core Profiles.

Implement the RESTful behavior according to the FHIR specification.

Return the following response classes:

(Status 400): invalid parameter

(Status 401/4xx): unauthorized request

(Status 403): insufficient scope

(Status 404): unknown resource

(Status 410): deleted resource.

Support json source formats for all US Core interactions.

The US Core Server SHOULD:

Support xml source formats for all US Core interactions.

Identify the US Core profiles supported as part of the FHIR meta.profile attribute for each instance.

Support xml resource formats for all Argonaut questionnaire interactions.

Security:

See the General Security Considerations section for requirements and recommendations.

A server SHALL reject any unauthorized requests by returning an HTTP 401 unauthorized response code.

Summary of System Wide Interactions

MAY support the transaction interaction.

MAY support the batch interaction.

MAY support the search-system interaction.

MAY support the history-system interaction.

RESTful Capabilities by Resource/Profile:

Summary of Search Criteria

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

AllergyIntolerance

Conformance Expectation: SHALL

Supported Profiles: US Core AllergyIntolerance Profile

Reference Policy: resolves

Profile Interaction Summary:

SHALL support search-type, read.

SHOULD support vread, history-instance.

MAY support create, update, patch, delete, history-type.

Fetch and Search Criteria:

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

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

Search Parameter Summary:

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

Search Parameter Combination Summary:

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

CarePlan

Conformance Expectation: SHALL

Supported Profiles: US Core CarePlan Profile

Reference Policy: resolves

Profile Interaction Summary:

SHALL support search-type, read.

SHOULD support vread, history-instance.

MAY support create, update, patch, delete, history-type.

Fetch and Search Criteria:

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

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

Search Parameter Summary:

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

Search Parameter Combination Summary:

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

CareTeam

Conformance Expectation: SHALL

Supported Profiles: US Core CareTeam Profile

Reference Policy: resolves

Profile Interaction Summary:

SHALL support search-type, read.

SHOULD support vread, history-instance.

MAY support create, update, patch, delete, history-type.

Fetch and Search Criteria:

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

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

Search Parameter Summary:

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

Search Parameter Combination Summary:

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

Condition

Conformance Expectation: SHALL

Supported Profiles: US Core Condition Profile

Reference Policy: resolves

Profile Interaction Summary:

SHALL support search-type, read.

SHOULD support vread, history-instance.

MAY support create, update, patch, delete, history-type.

Fetch and Search Criteria:

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

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

Search Parameter Summary:

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

Search Parameter Combination Summary:

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

Device

Conformance Expectation: SHALL

Supported Profiles: US Core Implantable Device Profile

Reference Policy: resolves

Profile Interaction Summary:

SHALL support search-type, read.

SHOULD support vread, history-instance.

MAY support create, update, patch, delete, history-type.

Fetch and Search Criteria:

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

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

Search Parameter Summary:

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

Search Parameter Combination Summary:

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

DiagnosticReport

Conformance Expectation: SHALL

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

Reference Policy: resolves

Profile Interaction Summary:

SHALL support create�, search-type, read.

SHOULD support vread, history-instance.

MAY support update, patch, delete, history-type.

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

Fetch and Search Criteria:

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

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

Search Parameter Summary:

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

Search Parameter Combination Summary:

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

DocumentReference

Conformance Expectation: SHALL

Supported Profiles: US Core DocumentReference Profile

Resource Specific Documentation:

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

Reference Policy: resolves

Profile Interaction Summary:

SHALL support create, search-type, read.

SHOULD support vread, history-instance.

MAY support update, patch, delete, history-type.

Operation Summary:

SHALL support the $docref operation

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

GET [base]/DocumentReference/$docref?patient=[id]

Fetch and Search Criteria:

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

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

Search Parameter Summary:

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

Search Parameter Combination Summary:

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

Encounter

Conformance Expectation: SHALL

Supported Profiles: US Core Encounter Profile

Reference Policy: resolves

Profile Interaction Summary:

SHALL support search-type, read.

SHOULD support vread, history-instance.

MAY support create, update, patch, delete, history-type.

Fetch and Search Criteria:

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

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

Search Parameter Summary:

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

Search Parameter Combination Summary:

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

Goal

Conformance Expectation: SHALL

Supported Profiles: US Core Goal Profile

Reference Policy: resolves

Profile Interaction Summary:

SHALL support search-type, read.

SHOULD support vread, history-instance.

MAY support create, update, patch, delete, history-type.

Fetch and Search Criteria:

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

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

Search Parameter Summary:

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

Search Parameter Combination Summary:

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

Immunization

Conformance Expectation: SHALL

Supported Profiles: US Core Immunization Profile

Reference Policy: resolves

Profile Interaction Summary:

SHALL support search-type, read.

SHOULD support vread, history-instance.

MAY support create, update, patch, delete, history-type.

Fetch and Search Criteria:

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

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

Search Parameter Summary:

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

Search Parameter Combination Summary:

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

Location

Conformance Expectation: SHALL

Supported Profiles: US Core Location Profile

Reference Policy: resolves

Profile Interaction Summary:

SHALL support search-type, read.

SHOULD support vread, history-instance.

MAY support create, update, patch, delete, history-type.

Fetch and Search Criteria:

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

Search Parameter Summary:

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

Medication

Conformance Expectation: SHALL

Supported Profiles: US Core Medication Profile

Resource Specific Documentation:

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

Reference Policy: resolves

Profile Interaction Summary:

SHALL support read.

SHOULD support vread, history-instance.

MAY support create, search-type, update, patch, delete, history-type.

Fetch and Search Criteria:

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

MedicationRequest

Conformance Expectation: SHALL

Supported Profiles: US Core MedicationRequest Profile

Resource Specific Documentation:

The MedicationRequest resources can represent a medication using either a code or refer to the Medication resource. When referencing Medication, the resource may be contained or an external resource. The server application MAY choose any one way or more than one method, but if an external reference to Medication is used, the server SHALL support the _include` parameter for searching this element. The client application must support all methods.

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

GET /MedicationRequest?patient=[id]

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

Reference Policy: resolves

Profile Interaction Summary:

SHALL support search-type, read.

SHOULD support vread, history-instance.

MAY support create, update, patch, delete, history-type.

Fetch and Search Criteria:

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

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

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

Search Parameter Summary:

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

Search Parameter Combination Summary:

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

Observation

Conformance Expectation: SHALL

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

Reference Policy: resolves

Profile Interaction Summary:

SHALL support search-type, read.

SHOULD support vread, history-instance.

MAY support create, update, patch, delete, history-type.

Fetch and Search Criteria:

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

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

Search Parameter Summary:

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

Search Parameter Combination Summary:

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

Organization

Conformance Expectation: SHALL

Supported Profiles: US Core Organization Profile

Reference Policy: resolves

Profile Interaction Summary:

SHALL support search-type, read.

SHOULD support vread, history-instance.

MAY support create, update, patch, delete, history-type.

Fetch and Search Criteria:

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

Search Parameter Summary:

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

Patient

Conformance Expectation: SHALL

Supported Profiles: US Core Patient Profile

Reference Policy: resolves

Profile Interaction Summary:

SHALL support search-type, read.

SHOULD support vread, history-instance.

MAY support create, update, patch, delete, history-type.

Fetch and Search Criteria:

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

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

Search Parameter Summary:

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

Search Parameter Combination Summary:

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

Practitioner

Conformance Expectation: SHALL

Supported Profiles: US Core Practitioner Profile

Reference Policy: resolves

Profile Interaction Summary:

SHALL support search-type, read.

SHOULD support vread, history-instance.

MAY support create, update, patch, delete, history-type.

Fetch and Search Criteria:

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

Search Parameter Summary:

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

PractitionerRole

Conformance Expectation: SHALL

Supported Profiles: US Core PractitionerRole Profile

Reference Policy: resolves

Profile Interaction Summary:

SHALL support search-type, read.

SHOULD support vread, history-instance.

MAY support create, update, patch, delete, history-type.

Fetch and Search Criteria:

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

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

Search Parameter Summary:

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

Procedure

Conformance Expectation: SHALL

Supported Profiles: US Core Procedure Profile

Reference Policy: resolves

Profile Interaction Summary:

SHALL support search-type, read.

SHOULD support vread, history-instance.

MAY support create, update, patch, delete, history-type.

Fetch and Search Criteria:

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

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

Search Parameter Summary:

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

Search Parameter Combination Summary:

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

Provenance

Conformance Expectation: SHALL

Supported Profiles: US Core Provenance Profile

Resource Specific Documentation:

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

Reference Policy: resolves

Profile Interaction Summary:

SHALL support read.

SHOULD support vread, history-instance.

MAY support create, search-type, update, patch, delete, history-type.

Fetch and Search Criteria:

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

ValueSet

Conformance Expectation: SHOULD

Operation Summary:

SHOULD support the $expand operation

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

# publisher
HL7 International - US Realm Steering Committee

# description
This Capability Statement describes the features of the US Core Server 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 this server are defined. Systems implementing this capability statement should meet the ONC 2015 Common Clinical Data Set (CCDS) access requirement for Patient Selection 170.315(g)(7) and Application Access - Data Category Request 170.315(g)(8) and and the ONC [U.S. Core Data for Interoperability (USCDI)](https://www.healthit.gov/isa/sites/isa/files/2020-03/USCDI-Version1-2020-Final-Standard.pdf).  US Core Clients have the option of choosing from this list to access necessary data based on their local use cases and other contextual requirements. In the context of the CMS Interoperability and Patient Access Rule this implementation of US Core only supports Read and Search capabilities to enable consumer applications to request data for a health plan member that has granted them access to their data.

# rest[].documentation
The US Core Server **SHALL**:

1. Support the US Core Patient resource profile.
1. Support at least one additional resource profile from the list of US Core Profiles.
1. Implement the RESTful behavior according to the FHIR specification.
1. Return the following response classes:
   - (Status 400): invalid parameter
   - (Status 401/4xx): unauthorized request
   - (Status 403): insufficient scope
   - (Status 404): unknown resource
   - (Status 410): deleted resource.
1. Support json source formats for all US Core interactions.

The US Core Server **SHOULD**:

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

# rest[].security.description
1. See the [General Security Considerations](security.html) section for requirements and recommendations.
1. A server **SHALL** reject any unauthorized requests by returning an `HTTP 401` unauthorized response code.

# rest[].resource[].interaction[].documentation
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**.

# rest[].resource[].documentation
The DocumentReference.type binding SHALL support at a minimum the [5 Common Clinical Notes](ValueSet-us-core-clinical-note-type.html) and may extend to the full US Core DocumentReference Type Value Set

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

`GET [base]/DocumentReference/$docref?patient=[id]`

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

# rest[].resource[].documentation
The MedicationRequest resources can represent a medication using either a code or refer to the Medication resource. When referencing Medication, the resource may be [contained](http://hl7.org/fhir/R4/references.html#contained) or an external resource. The server application **MAY** choose any one way or more than one method, but if an external reference to Medication is used, the server **SHALL** support the _include` parameter for searching this element. The client application must support all methods.

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

 `GET /MedicationRequest?patient=[id]`

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

# rest[].resource[].documentation
If a system receives a provider in `Provenance.agent.who` as free text they must capture who sent them the information as the organization. On request they **SHALL** provide this organization as the source and **MAY** include the free text provider.

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