SHOULD Support the Following Implementation Guides:

• SMART Application Launch Framework Implementation Guide

FHIR 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.
   • The Table below summarizes the Must Support references to other US Core Profiles and FHIR resources for each US Core Profile:
2. Implement the RESTful behavior according to the FHIR specification.
3. Follow the requirements documented in the General Requirements and Must Support pages
4. Return the following response classes:
   • (Status 400): invalid parameter
   • (Status 401/4xx): unauthorized request
   • (Status 403): insufficient scopes
   • (Status 404): unknown resource
5. Support JSON source formats for all US Core interactions.

The US Core Server SHOULD:

1. Follow the guidance documented in the General Guidance page
2. Support XML source formats for all US Core interactions.
3. Identify the US Core profiles supported as part of the FHIR meta.profile attribute for each instance.

Security:

1. See the General Security Considerations section for requirements and recommendations.
2. A server SHALL reject any unauthorized requests by returning an HTTP 401 "Unauthorized", HTTP 403 "Forbidden", or HTTP 404 "Not Found"

Summary of System Wide Interactions

• 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

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+date, patient+category, patient+category+status	-	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+category+clinical-status, patient+onset-date, patient+abatement-date, patient+clinical-status, patient+asserted-date, patient+code, patient+category+encounter, patient+_lastUpdated, patient+recorded-date, patient+category	-	Provenance:target	-
Coverage	US Core Coverage Profile	patient	-	Provenance:target	-
Device	US Core Implantable Device Profile	patient, status, type patient+status, patient+type	-	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, patient+category+date, patient+code+date, patient+status, patient+category+_lastUpdated, patient+category	-	Provenance:target	-
DocumentReference	US Core DocumentReference Profile	_id, category, date, patient, period, status, type patient+type, patient+category+date, patient+type+period, patient+status, patient+category	-	Provenance:target	docref
Encounter	US Core Encounter Profile	_id, class, date, _lastUpdated, discharge-disposition, identifier, location, patient, status, type date+patient, class+patient, patient+type, patient+_lastUpdated, patient+status, patient+location, patient+discharge-disposition	-	Provenance:target	-
Endpoint	-	-	-	-	-
Goal	US Core Goal Profile	description, lifecycle-status, patient, target-date patient+target-date, patient+lifecycle-status, patient+description	-	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	-	-	-
Media	-	-	-	-	-
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+encounter, patient+intent+authoredon, patient+intent+status, patient+intent	MedicationRequest:medication	Provenance:target	-
Observation	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, patient+category+date, patient+code+date, patient+category+status, patient+category+_lastUpdated, patient+category	-	Provenance:target	-
Organization	US Core Organization Profile	address, name	-	-	-
Patient	US Core Patient Profile	_id, birthdate, death-date, family, gender, given, identifier, name birthdate+name, family+gender, birthdate+family, gender+name, 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, patient+category+authored, patient+code+authored, patient+status, patient+category	-	Provenance:target	-
Specimen	US Core Specimen Profile	_id, patient	-	-	-
ValueSet	-	-	-	-	expand

Summary of Must Support and Additional USCDI References Between Profiles

• US Core Profile: The profile that has a Must Support or Additional USCDI references to other profiles or resources (i.e., Target Profiles).
• Resource Type: The FHIR resource type of the source profile.
• Target Profile: The US Core Profile references these profiles and resources as a Must Support or Additional USCDI element. Additional USCDI-referenced profiles or resources are identified with the label "(ADDITIONAL USCDI)".
• Target Resource Type: The FHIR resource type of the Target Profile.

US Core Profile	Resource Type	Target Profile	Target Resource Type
US Core Pediatric Head Occipital Frontal Circumference Percentile Profile	Observation	US Core Patient Profile	Patient
US Core Pediatric BMI for Age Observation Profile	Observation	US Core Patient Profile	Patient
US Core Pediatric Weight for Height Observation Profile	Observation	US Core Patient Profile	Patient
US Core AllergyIntolerance Profile	AllergyIntolerance	US Core Patient Profile	Patient
US Core Average Blood Pressure Profile	Observation	US Core Patient Profile	Patient
US Core Blood Pressure Profile	Observation	US Core Patient Profile	Patient
US Core BMI Profile	Observation	US Core Patient Profile	Patient
US Core Body Height Profile	Observation	US Core Patient Profile	Patient
US Core Body Temperature Profile	Observation	US Core Patient Profile	Patient
US Core Body Weight Profile	Observation	US Core Patient Profile	Patient
US Core Care Experience Preference Profile	Observation	US Core Patient Profile	Patient
US Core CarePlan Profile	CarePlan	US Core Patient Profile	Patient
US Core CareTeam Profile	CareTeam	US Core RelatedPerson Profile US Core PractitionerRole Profile US Core Practitioner Profile US Core Patient Profile	RelatedPerson PractitionerRole Practitioner Patient
US Core Condition Encounter Diagnosis Profile	Condition	US Core Encounter Profile US Core Patient Profile	Encounter Patient
US Core Condition Problems and Health Concerns Profile	Condition	US Core Patient Profile	Patient
US Core Coverage Profile	Coverage	US Core Organization Profile US Core Patient Profile	Organization Patient
US Core DiagnosticReport Profile for Laboratory Results Reporting	DiagnosticReport	US Core Encounter Profile US Core Practitioner Profile US Core Patient Profile US Core Laboratory Result Observation Profile	Encounter Practitioner Patient Observation
US Core DiagnosticReport Profile for Report and Note Exchange	DiagnosticReport	Media US Core Practitioner Profile US Core Observation Clinical Result Profile US Core Laboratory Result Observation Profile US Core Organization Profile US Core Encounter Profile US Core Patient Profile	Media Practitioner Observation Observation Organization Encounter Patient
US Core DocumentReference Profile	DocumentReference	US Core Encounter Profile US Core Practitioner Profile US Core Patient Profile	Encounter Practitioner Patient
US Core Encounter Profile	Encounter	US Core Practitioner Profile US Core Condition Encounter Diagnosis Profile US Core Organization Profile US Core Location Profile US Core Condition Problems and Health Concerns Profile US Core Patient Profile	Practitioner Condition Organization Location Condition Patient
US Core Goal Profile	Goal	US Core Patient Profile	Patient
US Core Head Circumference Profile	Observation	US Core Patient Profile	Patient
US Core Heart Rate Profile	Observation	US Core Patient Profile	Patient
US Core Immunization Profile	Immunization	US Core Encounter Profile US Core Location Profile US Core Patient Profile	Encounter Location Patient
US Core Implantable Device Profile	Device	US Core Patient Profile	Patient
US Core Location Profile	Location	US Core Organization Profile	Organization
US Core Medication Profile	Medication	-	-
US Core MedicationDispense Profile	MedicationDispense	US Core Practitioner Profile US Core Medication Profile US Core Organization Profile US Core Encounter Profile US Core MedicationRequest Profile US Core Patient Profile	Practitioner Medication Organization Encounter MedicationRequest Patient
US Core MedicationRequest Profile	MedicationRequest	US Core Encounter Profile US Core Patient Profile US Core Practitioner Profile US Core Medication Profile Observation(ADDITIONAL USCDI) Condition(ADDITIONAL USCDI)	Encounter Patient Practitioner Medication Observation Condition
US Core Observation Clinical Result Profile	Observation	US Core Encounter Profile US Core Patient Profile	Encounter Patient
US Core Laboratory Result Observation Profile	Observation	US Core Specimen Profile US Core Encounter Profile US Core Patient Profile	Specimen Encounter Patient
US Core Observation Occupation Profile	Observation	US Core Patient Profile	Patient
US Core Observation Pregnancy Intent Profile	Observation	US Core Patient Profile	Patient
US Core Observation Pregnancy Status Profile	Observation	US Core Patient Profile	Patient
US Core Observation Screening Assessment Profile	Observation	US Core Observation Screening Assessment Profile US Core QuestionnaireResponse Profile US Core Patient Profile	Observation QuestionnaireResponse Patient
US Core Observation Sexual Orientation Profile	Observation	US Core Patient Profile	Patient
US Core Organization Profile	Organization	-	-
US Core Patient Profile	Patient	-	-
US Core Practitioner Profile	Practitioner	-	-
US Core PractitionerRole Profile	PractitionerRole	US Core Organization Profile US Core Practitioner Profile US Core Location Profile Endpoint HealthcareService(ADDITIONAL USCDI)	Organization Practitioner Location Endpoint HealthcareService
US Core Procedure Profile	Procedure	US Core Encounter Profile US Core Patient Profile Observation(ADDITIONAL USCDI) Procedure(ADDITIONAL USCDI) DocumentReference(ADDITIONAL USCDI) Condition(ADDITIONAL USCDI) DiagnosticReport(ADDITIONAL USCDI)	Encounter Patient Observation Procedure DocumentReference Condition DiagnosticReport
US Core Provenance Profile	Provenance	US Core Organization Profile Any Resource	Organization Any Resource
US Core Pulse Oximetry Profile	Observation	US Core Patient Profile	Patient
US Core QuestionnaireResponse Profile	QuestionnaireResponse	Any Resource US Core Practitioner Profile US Core Patient Profile	Any Resource Practitioner Patient
US Core RelatedPerson Profile	RelatedPerson	US Core Patient Profile	Patient
US Core Respiratory Rate Profile	Observation	US Core Patient Profile	Patient
US Core ServiceRequest Profile	ServiceRequest	US Core Encounter Profile US Core Practitioner Profile US Core Patient Profile Observation(ADDITIONAL USCDI) Condition(ADDITIONAL USCDI) DiagnosticReport(ADDITIONAL USCDI) DocumentReference(ADDITIONAL USCDI)	Encounter Practitioner Patient Observation Condition DiagnosticReport DocumentReference
US Core Simple Observation Profile	Observation	US Core Patient Profile	Patient
US Core Smoking Status Observation Profile	Observation	US Core Patient Profile	Patient
US Core Specimen Profile	Specimen	US Core Patient Profile	Patient
US Core Treatment Intervention Preference Profile	Observation	US Core Patient Profile	Patient
US Core Vital Signs Profile	Observation	US Core Patient Profile	Patient

AllergyIntolerance

Conformance Expectation: SHALL

Supported Profiles:

• SHALL support: US Core AllergyIntolerance Profile

Reference Policy

• SHOULD support 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
SHALL	patient	reference

Search Parameter Combination Summary:

Conformance	Parameter Combination	Types
SHOULD	patient+ clinical-status	reference+token

---

CarePlan

Conformance Expectation: SHALL

Resource Specific Documentation:

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

Supported Profiles:

• SHALL support: US Core CarePlan Profile

Reference Policy

• SHOULD support 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 Combination Summary:

Conformance	Parameter Combination	Types
SHOULD	patient+ category+ status+ date	reference+token+token+date
SHOULD	patient+ category+ date	reference+token+date
SHALL	patient+ category	reference+token
SHOULD	patient+ category+ status	reference+token+token

---

CareTeam

Conformance Expectation: SHALL

Resource Specific Documentation:

• In order to access care team member's names, identifiers, locations, and contact information, the CareTeam profile supports several types of care team participants. They are represented as references to other profiles and include the following four profiles which are marked as must support:
  1. US Core Practitioner Profile
  2. US Core PractitionerRole Profile
  3. US Core Patient Profile
  4. US Core RelatedPerson Profile
• Although both US Core Practitioner Profile and US Core PractitionerRole are must support, the server system is not required to support both types of references, but SHALL support at least one of them.
• The client application SHALL support all four profile references.
• Bacause the US Core PractitionerRole Profile supplies the provider's location and contact information and a reference to the Practitioner, server systems SHOULD reference it instead of the US Core Practitioner Profile.
• Servers that support only US Core Practitioner Profile and do not support the US Core PractitionerRole Profile SHALL provide implementation specific guidance how to access a provider’s location and contact information using only the Practitioner resource.

Supported Profiles:

• SHALL support: US Core CareTeam Profile

Reference Policy

• SHOULD support 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 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 Summary:

Conformance	Parameter	Type
SHOULD	role	token

Search Parameter Combination Summary:

Conformance	Parameter Combination	Types
SHALL	patient+ status	reference+token
SHOULD	patient+ role	reference+token

---

Condition

Conformance Expectation: SHALL

Resource Specific Documentation:

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

Supported Profiles:

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

Reference Policy

• SHOULD support 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
SHALL	patient	reference

Search Parameter Combination Summary:

Conformance	Parameter Combination	Types
SHOULD	patient+ category+ clinical-status	reference+token+token
SHOULD	patient+ onset-date	reference+date
SHOULD	patient+ abatement-date	reference+date
SHOULD	patient+ clinical-status	reference+token
SHOULD	patient+ asserted-date	reference+date
SHOULD	patient+ code	reference+token
SHOULD	patient+ category+ encounter	reference+token+reference
SHOULD	patient+ _lastUpdated	reference+date
SHOULD	patient+ recorded-date	reference+date
SHALL	patient+ category	reference+token

---

Coverage

Conformance Expectation: SHALL

Supported Profiles:

• SHALL support: US Core Coverage Profile

Reference Policy

• SHOULD support 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 Coverage resource using: GET [base]/Coverage/[id]
• A Server SHALL be capable of supporting the following _revincludes: Provenance:target - GET [base]/Coverage?[parameter=value]&_revinclude=Provenance:target

Search Parameter Summary:

Conformance	Parameter	Type
SHALL	patient	reference

---

Device

Conformance Expectation: SHALL

Resource Specific Documentation:

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

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

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

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

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

Supported Profiles:

• SHALL support: US Core Implantable Device Profile

Reference Policy

• SHOULD support 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
SHALL	patient	reference

Search Parameter Combination Summary:

Conformance	Parameter Combination	Types
SHOULD	patient+ status	reference+token
SHOULD	patient+ type	reference+token

---

DiagnosticReport

Conformance Expectation: SHALL

Resource Specific Documentation:

• When DiagnosticReport.category is "LAB" the encounter, Updates to Meta.lastUpdated SHOULD reflect:
  • New laboratory reports
  • Changes in the status of laboratory reports including events that trigger the same status (e.g., amended → amended).

Supported Profiles:

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

Reference Policy

• SHOULD support 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
SHALL	patient	reference

Search Parameter Combination Summary:

Conformance	Parameter Combination	Types
SHALL	patient+ code	reference+token
SHALL	patient+ category+ date	reference+token+date
SHOULD	patient+ code+ date	reference+token+date
SHOULD	patient+ status	reference+token
SHOULD	patient+ category+ _lastUpdated	reference+token+date
SHALL	patient+ category	reference+token

---

DocumentReference

Conformance Expectation: SHALL

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
• The DocumentReference resources can represent the referenced content using either an address where the document can be retrieved using DocumentReference.attachment.url or the content as inline base64 encoded data using DocumentReference.attachment.data.
  • Although both are marked as must support, the server system is not required to support an address, and inline base64 encoded data, but SHALL support at least one of these elements.
  • The client application SHALL support both elements.
  • The content.url may refer to a FHIR Binary Resource (i.e. [base]/Binary/[id]), FHIR Document Bundle (i.e [base]/Bundle/[id] or another endpoint.
    • If the endpoint is outside the FHIR base URL, it SHOULD NOT require additional authorization to access.
  • If there are multiple DocumentReference.content element repetitions, these SHALL all represent the same document in different format or attachment metadata. The content element SHALL NOT contain different versions of the same content. For version handling use multiple DocumentReferences with DocumentReference.relatesTo
• Every DocumentReference must have a responsible Organization. The organization responsible for the DocumentReference SHALL be present either in DocumentReference.custodian or accessible in the Provenance resource targeting the DocumentReference using Provenance.agent.who or Provenance.agent.onBehalfOf.

Supported Profiles:

• SHALL support: US Core DocumentReference Profile

Reference Policy

• SHOULD support 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 document(s). 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
SHALL	_id	token
SHALL	patient	reference

Search Parameter Combination Summary:

Conformance	Parameter Combination	Types
SHALL	patient+ type	reference+token
SHALL	patient+ category+ date	reference+token+date
SHOULD	patient+ type+ period	reference+token+date
SHOULD	patient+ status	reference+token
SHALL	patient+ category	reference+token

---

Encounter

Conformance Expectation: SHALL

Resource Specific Documentation:

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

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

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

  • Although both are marked as must support, the server systems are not required to support both Encounter.location.location and Encounter.serviceProvider, but they SHALL support at least one of these elements.
  • The client application SHALL support both elements.

• If the event facility/location differs from the Encounter.location, systems SHOULD reference it directly:

Supported Profiles:

• SHALL support: US Core Encounter Profile

Reference Policy

• SHOULD support 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
SHALL	_id	token
SHOULD	identifier	token
SHALL	patient	reference

Search Parameter Combination Summary:

Conformance	Parameter Combination	Types
SHALL	date+ patient	date+reference
SHOULD	class+ patient	token+reference
SHOULD	patient+ type	reference+token
SHOULD	patient+ _lastUpdated	reference+date
SHOULD	patient+ status	reference+token
SHOULD	patient+ location	reference+reference
SHOULD	patient+ discharge-disposition	reference+token

---

Endpoint

Conformance Expectation: SHALL

Resource Specific Documentation:

The Media Resource is a Must Suppot referenced resource when using the US Core PracitionerRole Profile.

Reference Policy

• SHOULD support resolves

Profile Interaction Summary:

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

Fetch and Search Criteria:

• A Server SHOULD be capable of returning a Endpoint resource using: GET [base]/Endpoint/[id]

---

Goal

Conformance Expectation: SHALL

Resource Specific Documentation:

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

Supported Profiles:

• SHALL support: US Core Goal Profile

Reference Policy

• SHOULD support 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
SHALL	patient	reference

Search Parameter Combination Summary:

Conformance	Parameter Combination	Types
SHOULD	patient+ target-date	reference+date
SHOULD	patient+ lifecycle-status	reference+token
SHOULD	patient+ description	reference+token

---

HealthcareService

Conformance Expectation: MAY

Resource Specific Documentation:

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

Reference Policy

• SHOULD support resolves

Profile Interaction Summary:

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

Fetch and Search Criteria:

• A Server SHOULD be capable of returning a HealthcareService resource using: GET [base]/HealthcareService/[id]

---

Immunization

Conformance Expectation: SHALL

Resource Specific Documentation:

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

Supported Profiles:

• SHALL support: US Core Immunization Profile

Reference Policy

• SHOULD support 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
SHALL	patient	reference

Search Parameter Combination Summary:

Conformance	Parameter Combination	Types
SHOULD	patient+ date	reference+date
SHOULD	patient+ status	reference+token

---

Location

Conformance Expectation: SHALL

Resource Specific Documentation:

• Systems SHOULD follow the Project US@ Technical Specification for Patient Addresses Final Version 1.0 as the standard style guide for Location.address.line and Location.address.city.

Supported Profiles:

• SHALL support: US Core Location Profile

Reference Policy

• SHOULD support 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
SHALL	address	string
SHOULD	address-city	string
SHOULD	address-postalcode	string
SHOULD	address-state	string
SHALL	name	string

---

Media

Conformance Expectation: SHALL

Resource Specific Documentation:

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

Reference Policy

• SHOULD support resolves

Profile Interaction Summary:

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

Fetch and Search Criteria:

• A Server SHOULD be capable of returning a Media resource using: GET [base]/Media/[id]

---

Medication

Conformance Expectation: SHALL

Resource Specific Documentation:

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

Supported Profiles:

• SHALL support: US Core Medication Profile

Reference Policy

• SHOULD support 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]

---

MedicationDispense

Conformance Expectation: SHALL

Resource Specific Documentation:

• The MedicationDispense resources can represent a medication using either a code or refer to the Medication resource. When referencing Medication, the resource may be contained or an external resource. The server application MAY choose any one way or more than one method, but if an external reference to Medication is used, the server SHALL support the _include` parameter for searching this element. The client application must support all methods.
  • For example, A server SHALL be capable of returning dispense records for all medications for a patient using one of or both:
    • GET /MedicationDispense?patient=[id]
    • GET /MedicationDispense?patient=[id]&_include=MedicationDispense:medication

Supported Profiles:

• SHALL support: US Core MedicationDispense Profile

Reference Policy

• SHOULD support 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 MedicationDispense resource using: GET [base]/MedicationDispense/[id]
• 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 Summary:

Conformance	Parameter	Type
SHALL	patient	reference

Search Parameter Combination Summary:

Conformance	Parameter Combination	Types
SHOULD	patient+ status+ type	reference+token+token
SHOULD	patient+ status	reference+token

---

MedicationRequest

Conformance Expectation: SHALL

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

• The MedicationRequest resource can represent that information is from a secondary source using either a boolean flag or reference in MedicationRequest.reportedBoolean, or a reference using MedicationRequest.reportedReference to Practitioner or other resource.

  • Although both are marked as must support, the server systems are not required to support both a boolean and a reference, but SHALL choose to support at least one of these elements.
  • The client application SHALL support both elements.

• When recording “self-prescribed” medication, requester SHOULD be used to indicate the Patient or RelatedPerson as the prescriber. (See the Medication List section for guidance on accessing a patient medications including over the counter (OTC) medication and other substances taken for medical and recreational use.)

• The MedicationRequest resource can communicate the reason or indication for treatment using either a code in MedicationRequest.reasonCode or a reference using MedicationRequest.reasonReference.

• Although both MedicationRequest.reasonCode and MedicationRequest.reasonReference are marked as Additional USCDI Requirements. The certifying server system is not required to support both but SHALL support at least one of these elements. The certifying client application SHALL support both elements.

  • when using MedicationRequest.reasonReference:
    • Servers SHALL support at least one target resource in MedicationRequest.reasonReference. Clients SHALL support all target resources.
    • The referenced resources SHOULD be a US Core Profile as documented in Referencing US Core Profiles.

Supported Profiles:

• SHALL support: US Core MedicationRequest Profile

Reference Policy

• SHOULD support 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 Combination Summary:

Conformance	Parameter Combination	Types
SHOULD	patient+ intent+ encounter	reference+token+reference
SHOULD	patient+ intent+ authoredon	reference+token+date
SHALL	patient+ intent+ status	reference+token+token
SHALL	patient+ intent	reference+token

---

Observation

Conformance Expectation: SHALL

Resource Specific Documentation:

• Systems SHOULD support Observation.effectivePeriod to accurately represent tests that are collected over a period of time (for example, a 24-Hour Urine Collection test).
• An Observation without a value, SHALL include a reason why the data is absent unless there are component observations, or references to other Observations that are grouped within it
  • Systems that never provide an observation without a value are not required to support Observation.dataAbsentReason
• An Observation.component without a value, SHALL include a reason why the data is absent.
  • Systems that never provide an component observation without a component value are not required to support Observation.component.dataAbsentReason.
• When Observation.category is "laboratory" the encounter, Updates to Meta.lastUpdated SHOULD reflect:
  • New laboratory results
  • Changes in the status of laboratory results including events that trigger the same status (e.g., amended → amended).

Supported Profiles:

• 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
• SHALL 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

Reference Policy

• SHOULD support 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 Combination Summary:

Conformance	Parameter Combination	Types
SHALL	patient+ code	reference+token
SHALL	patient+ category+ date	reference+token+date
SHOULD	patient+ code+ date	reference+token+date
SHOULD	patient+ category+ status	reference+token+token
SHOULD	patient+ category+ _lastUpdated	reference+token+date
SHALL	patient+ category	reference+token

---

Organization

Conformance Expectation: SHALL

Resource Specific Documentation:

• Systems SHALL support National Provider Identifier (NPI) for organizations and SHOULD support Clinical Laboratory Improvement Amendments (CLIA) identifiers for Organization.Identifier.
• Systems SHOULD follow the Project US@ Technical Specification for Patient Addresses Final Version 1.0 as the standard style guide for Organization.address.line and Organization.address.city.

Supported Profiles:

• SHALL support: US Core Organization Profile

Reference Policy

• SHOULD support 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
SHALL	address	string
SHALL	name	string

---

Patient

Conformance Expectation: SHALL

Resource Specific Documentation:

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

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

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

• Although Patient.deceased[x] is marked as 𝗔𝗗𝗗𝗜𝗧𝗜𝗢𝗡𝗔𝗟 𝗨𝗦𝗖𝗗𝗜, certifying systems are not required to support both choices, but SHALL support at least Patient.deceasedDateTime.

• Certifying systems SHALL and non-certifying systems SHOULD follow the Project US@ Technical Specification for Patient Addresses Final Version 1.0 as the standard style guide for Patient.address.line and Patient.address.city for new and updated records.

Supported Profiles:

• SHALL support: US Core Patient Profile

Reference Policy

• SHOULD support 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
SHALL	_id	token
SHALL	identifier	token
SHALL	name	string

Search Parameter Combination Summary:

Conformance	Parameter Combination	Types
SHALL	birthdate+ name	date+string
SHOULD	family+ gender	string+token
SHOULD	birthdate+ family	date+string
SHALL	gender+ name	token+string
SHOULD	death-date+ family	date+string

---

Practitioner

Conformance Expectation: SHALL

Resource Specific Documentation:

• Servers that support only US Core Practitioner Profile SHALL provide implementation specific guidance how to access a provider’s location and contact information using only the Practitioner resource.
  • Although Practitioner.address is marked as Must Support, the server system is not required to support it if they support the US Core PractitionerRole Profile, but SHALL support it if they do not support the US Core PractitionerRole Profile. The client application SHALL support both.
• Systems SHOULD follow the Project US@ Technical Specification for Patient Addresses Final Version 1.0 as the standard style guide for Practitioner.address.line and Practitioner.address.city.

Supported Profiles:

• SHALL support: US Core Practitioner Profile

Reference Policy

• SHOULD support 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
SHOULD	_id	token
SHALL	identifier	token
SHALL	name	string

---

PractitionerRole

Conformance Expectation: SHALL

Resource Specific Documentation:

• Due to implementer feedback, some US Core Profiles reference the PractitionerRole resource instead of the US Core PractitionerRole Profile. However the US Core PractitionerRole Profile SHOULD be used as the default profile if referenced by another US Core profile.

Supported Profiles:

• SHALL support: US Core PractitionerRole Profile

Reference Policy

• SHOULD support 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
SHALL	practitioner	reference
SHALL	specialty	token

---

Procedure

Conformance Expectation: SHALL

Resource Specific Documentation:

• Procedure codes can be taken from SNOMED-CT, CPT, HCPCS II, ICD-10-PCS, CDT. LOINC.
  • Only LOINC concepts that reflect actual procedures SHOULD be used
• A procedure including an implantable device SHOULD use Procedure.focalDevice with a reference to the US Core Implantable Device Profile.
• Servers and Clients SHALL support both US Core ServiceRequest and US Core Procedure Profiles for communicating the reason or justification for a referral as Additional USCDI Requirements. Typically, the reason or justification for a referral or consultation is communicated through Procedure.basedOn linking the Procedure to the US Core ServiceRequest Profile that includes either ServiceRequest.reasonCode or ServiceRequest.reasonReference. When the Procedure does not have an associated ServiceRequest, it is communicated through the US Core Procedure Profile's Procedure.reasonCode or Procedure.reasonReference. Depending on the procedure being documented, a server will select the appropriate Profile to use.
  • Although both Procedure.reasonCode and Procedure.reasonReference are marked as Additional USCDI Requirements. The certifying server system is not required to support both but SHALL support at least one of these elements. The certifying client application SHALL support both elements.
    • when using Procedure.reasonReference:
      • Servers SHALL support at least one target resource in Procedure.reasonReference. Clients SHALL support all target resources .
      • The referenced resources SHOULD be a US Core Profile.

Supported Profiles:

• SHALL support: US Core Procedure Profile

Reference Policy

• SHOULD support 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
SHALL	patient	reference

Search Parameter Combination Summary:

Conformance	Parameter Combination	Types
SHOULD	patient+ code+ date	reference+token+date
SHALL	patient+ date	reference+date
SHOULD	patient+ status	reference+token

---

Provenance

Conformance Expectation: SHALL

Resource Specific Documentation:

• The US Core Provenance resource SHALL be supported for these US Core resources:
  • AllergyIntolerance
  • CarePlan
  • CareTeam
  • Condition
  • Coverage
  • Device
  • DiagnosticReport
  • DocumentReference
  • Encounter
  • Goal
  • Immunization
  • MedicationDispense
  • MedicationRequest
  • Observation
  • Patient
  • Procedure
  • QuestionnaireResponse
  • RelatedPerson
  • ServiceRequest
• If a system receives a provider in Provenance.agent.who as free text they must capture who sent them the information as the organization. On request they SHALL provide this organization as the source and MAY include the free text provider.
• Systems that need to know the activity has occurred SHOULD populate the activity.

Supported Profiles:

• SHALL support: US Core Provenance Profile

Reference Policy

• SHOULD support 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]

---

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

Profile Interaction Summary:

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

Fetch and Search Criteria:

• A Server SHOULD be capable of returning a Questionnaire resource using: GET [base]/Questionnaire/[id]

---

QuestionnaireResponse

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: US Core QuestionnaireResponse Profile

Profile Interaction Summary:

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

Fetch and Search Criteria:

• A Server SHOULD be capable of returning a QuestionnaireResponse resource using: GET [base]/QuestionnaireResponse/[id]
• A Server SHALL be capable of supporting the following _revincludes: Provenance:target - GET [base]/QuestionnaireResponse?[parameter=value]&_revinclude=Provenance:target

Search Parameter Summary:

Conformance	Parameter	Type
SHALL	_id	token
SHALL	patient	reference

Search Parameter Combination Summary:

Conformance	Parameter Combination	Types
SHOULD	patient+ questionnaire	reference+reference
SHOULD	patient+ authored	reference+date
SHOULD	patient+ status	reference+token

---

RelatedPerson

Conformance Expectation: SHALL

Resource Specific Documentation:

• Systems SHOULD follow the Project US@ Technical Specification for Patient Addresses Final Version 1.0 as the standard style guide for RelatedPerson.address.line and RelatedPerson.address.city.

Supported Profiles:

• SHALL support: US Core RelatedPerson Profile

Reference Policy

• SHOULD support 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 RelatedPerson resource using: GET [base]/RelatedPerson/[id]
• A Server SHALL be capable of supporting the following _revincludes: Provenance:target - GET [base]/RelatedPerson?[parameter=value]&_revinclude=Provenance:target

Search Parameter Summary:

Conformance	Parameter	Type
SHALL	_id	token
SHOULD	name	string
SHOULD	patient	reference

Search Parameter Combination Summary:

Conformance	Parameter Combination	Types
SHOULD	patient+ name	reference+string

---

ServiceRequest

Conformance Expectation: SHALL

Resource Specific Documentation:

• Servers and Clients SHALL support both US Core ServiceRequest and US Core Procedure Profiles for communicating the reason or justification for a referral as Additional USCDI Requirements. Typically, the reason or justification for a referral or consultation is communicated through Procedure.basedOn linking the Procedure to the US Core ServiceRequest Profile that includes either ServiceRequest.reasonCode or ServiceRequest.reasonReference. When the Procedure does not have an associated ServiceRequest, it is communicated through the US Core Procedure Profile's Procedure.reasonCode or Procedure.reasonReference. Depending on the procedure being documented, a server will select the appropriate Profile to use.
  • ServiceRequest.reasonCode and ServiceRequest.reasonReference are marked as Additional USCDI Requirements. The certifying server system is not required to support both but SHALL support at least one of these elements. The certifying client application SHALL support both elements.
    • when using ServiceRequest.reasonReference:
      • Servers SHALL support at least one target resource in ServiceRequest.reasonReference. Clients SHALL support all target resources.
      • The referenced resources SHOULD be a US Core Profile.

Supported Profiles:

• SHALL support: US Core ServiceRequest Profile

Reference Policy

• SHOULD support 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 ServiceRequest resource using: GET [base]/ServiceRequest/[id]
• A Server SHALL be capable of supporting the following _revincludes: Provenance:target - GET [base]/ServiceRequest?[parameter=value]&_revinclude=Provenance:target

Search Parameter Summary:

Conformance	Parameter	Type
SHALL	_id	token
SHALL	patient	reference

Search Parameter Combination Summary:

Conformance	Parameter Combination	Types
SHALL	patient+ code	reference+token
SHALL	patient+ category+ authored	reference+token+date
SHOULD	patient+ code+ authored	reference+token+date
SHOULD	patient+ status	reference+token
SHALL	patient+ category	reference+token

---

Specimen

Conformance Expectation: SHALL

Resource Specific Documentation:

• Although both Specimen.identifier and Specimen.accessionIdentifier are marked as Must Support, the server system is not required to support both, but SHALL support at least one of these elements. The client application SHALL support both.

Supported Profiles:

• SHALL support: US Core Specimen Profile

Reference Policy

• SHOULD support 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 Specimen resource using: GET [base]/Specimen/[id]

Search Parameter Summary:

Conformance	Parameter	Type
SHALL	_id	token
SHOULD	patient	reference

---

ValueSet

Conformance Expectation: SHOULD

Operation Summary:

• SHOULD support the $expand operation

  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.

---