US Core Client CapabilityStatement

• Official URL: http://hl7.org/fhir/us/core/CapabilityStatement/us-core-client
• Implementation Guide Version: 5.0.0
• FHIR Version: 4.0.1
• Supported formats: SHALL support JSON, SHOULD support XML
• Published: 2021-11-30 04:07:12.083293-08:00
• Published by: HL7 International - US Realm Steering Committee

This Section describes the expected capabilities of the US Core Client which is responsible for creating and initiating the queries for information about an individual patient. The complete list of FHIR profiles, RESTful operations, and search parameters supported by US Core Servers are defined in the Conformance Requirements for Server. 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.

SHOULD Support the Following Implementation Guides:

• SMART Application Launch Framework Implementation Guide

• Bulk Data Access IG

SHALL Implement All Or Parts Of The Following Capability Statements:

• US Core Client CapabilityStatement

FHIR RESTful Capabilities

The US Core Client SHALL:

1. Support fetching and querying of one or more US Core profile(s), using the supported RESTful interactions and search parameters declared in the US Core Server CapabilityStatement.

Security:

1. See the [General Security Considerations] section for requirements and recommendations.

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, patient+category+status+date, patient+category+date, patient+category+status	-	Provenance:target	-
CareTeam	US Core CareTeam Profile	patient, status, role patient+status, patient+role	CareTeam:participant:PractitionerRole, CareTeam:participant:Practitioner, CareTeam:participant:Patient, CareTeam:participant:RelatedPerson	Provenance:target	-
Condition	US Core Condition Profile	category, clinical-status, patient, onset-date, asserted-date, recorded-date, abatement-date, code, encounter patient+code, patient+asserted-date, patient+onset-date, patient+category, patient+clinical-status, patient+recorded-date, patient+abatement-date, patient+category+encounter	-	Provenance:target	-
Device	US Core Implantable Device Profile	patient, type patient+type	-	Provenance:target	-
DiagnosticReport	US Core DiagnosticReport Profile for Laboratory Results Reporting, US Core DiagnosticReport Profile for Report and Note exchange	status, patient, category, code, date patient+status, patient+category, patient+code, patient+category+date, patient+code+date	-	Provenance:target	-
DocumentReference	US Core DocumentReference Profile	_id, status, patient, category, type, date, period patient+status, patient+category, patient+type+period, patient+category+date, patient+type	-	Provenance:target	docref
Encounter	US Core Encounter Profile	_id, class, date, identifier, patient, location, status, type, discharge-disposition date+patient, patient+status, patient+type, class+patient, patient+discharge-disposition, patient+location	-	Provenance:target	-
Goal	US Core Goal Profile	lifecycle-status, patient, target-date, description patient+lifecycle-status, patient+description, patient+target-date	-	Provenance:target	-
Immunization	US Core Immunization Profile	patient, status, date patient+status, patient+date	-	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+encounter, patient+intent+status, patient+intent, patient+intent+authoredon	MedicationRequest:medication	Provenance:target	-
Observation	US Core Laboratory Result Observation Profile, US Core Vital Signs Profile, US Core Blood Pressure Profile, US Core BMI Profile, US Core Head Circumference Profile, US Core Body Height Profile, US Core Body Weight Profile, US Core Body Temperature Profile, US Core Heart Rate Profile, US Core Pediatric BMI for Age Observation Profile, US Core Pediatric Head Occipital-frontal Circumference Percentile Profile, US Core Pediatric Weight for Height Observation Profile, US Core Pulse Oximetry Profile, US Core Respiratory Rate Profile, US Core Sexual Orientation Observation Profile, US Core Smoking Status Observation Profile, US Core Clinical Test Result Observation Profile, US Core Screening Response Observation Profile, US Core Social History Assessment Observation Profile, US Core Diagnostic Imaging Result Observation Profile	status, category, code, date, patient patient+category+status, patient+category, patient+code, patient+category+date, patient+code+date	-	Provenance:target	-
Organization	US Core Organization Profile	name, address	-	-	-
Patient	US Core Patient Profile	_id, birthdate, family, gender, given, identifier, name family+gender, birthdate+family, birthdate+name, gender+name	-	Provenance:target	-
Practitioner	US Core Practitioner Profile	_id, name, identifier	-	-	-
PractitionerRole	US Core PractitionerRole Profile	specialty, practitioner	PractitionerRole:endpoint, PractitionerRole:practitioner	-	-
Procedure	US Core Procedure Profile	status, patient, date, code patient+status, patient+date, patient+code+date	-	Provenance:target	-
Provenance	US Core Provenance Profile	-	-	-	-
RelatedPerson	US Core RelatedPerson Profile	_id, patient	-	Provenance:target	-
ServiceRequest	US Core ServiceRequest Profile	status, patient, category, code, authored, _id patient+code+authored, patient+status, patient+category, patient+code, patient+category+authored	-	Provenance:target	-
ValueSet	-	-	-	-	expand

AllergyIntolerance

Conformance Expectation: SHOULD

Supported Profiles:

• SHALL support: 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 Client SHALL be capable of fetching a AllergyIntolerance resource using: GET [base]/AllergyIntolerance/[id]
• A Client SHOULD 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: SHOULD

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: 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 Client SHALL be capable of fetching a CarePlan resource using: GET [base]/CarePlan/[id]
• A Client SHOULD 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
SHALL	patient+ category	reference+token
SHOULD	patient+ category+ status+ date	reference+token+token+date
SHOULD	patient+ category+ date	reference+token+date
SHOULD	patient+ category+ status	reference+token+token

---

CareTeam

Conformance Expectation: SHOULD

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 (and _include search parameters), 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. An example of how to access the practitioner name and identifier is shown in the quick start section below.
• Servers that supports only US Core Practitioner Profile SHALL provide implementation specific guidance how to access a provider's location and contact information using only the Practitioner resource.

Supported Profiles:

• SHALL support: 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 Client SHALL be capable of fetching a CareTeam resource using: GET [base]/CareTeam/[id]
• A Client 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 Client SHOULD 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: SHOULD

Resource Specific Documentation:

• To search for an encounter diagnosis, query for Conditions that reference the Encounter of interest and have a category of encounter-diagnosis.
  • When Condition.category is "encounter-diagnosis" the encounter, SHOULD be referenced in Condition.encounter.
• See SDOH Guidance for more information when exchanging Social Determinants of Health (SDOH) Conditions/Health Concerns.
• There is no single element in Condition that represents the date of diagnosis. It may be the assertedDate Extension, Condition.onsetDate, 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 [assertedDate Extension] and Condition.onsetDate. A server may support both, which means they support all 3 locations.
  • The client application SHALL support all three elements.

Supported Profiles:

• SHALL support: 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 Client SHALL be capable of fetching a Condition resource using: GET [base]/Condition/[id]
• A Client SHOULD 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+ code	reference+token
SHOULD	patient+ asserted-date	reference+date
SHOULD	patient+ onset-date	reference+date
SHOULD	patient+ category	reference+token
SHOULD	patient+ clinical-status	reference+token
SHOULD	patient+ recorded-date	reference+date
SHOULD	patient+ abatement-date	reference+date
SHOULD	patient+ category+ encounter	reference+token+reference

---

Device

Conformance Expectation: SHOULD

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:

  data element	US Core Implantable Device Profile element
  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.

• In the Quick Start section below, searching for all devices is described. Records of implanted devices MAY be queried against UDI data including:

  • UDI HRF string (udi-carrier)
  • UDI Device Identifier (udi-di)
  • Manufacturer (manufacturer)
  • Model number (model)

  Implementers MAY also adopt custom SearchParameters for searching by:

  • lot numbers
  • serial number
  • expiration date
  • manufacture date
  • distinct identifier

Supported Profiles:

• SHALL support: 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 Client SHALL be capable of fetching a Device resource using: GET [base]/Device/[id]
• A Client SHOULD 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+ type	reference+token

---

DiagnosticReport

Conformance Expectation: SHOULD

Resource Specific Documentation:

Diagnostic imaging results in visual images requiring interpretation and clinical test results/reports may also reference images as part of the report. DiagnosticReport resource can link to both DICOM imaging studies and binary images directly by referencing ImagingStudy in DocumentReference.imagingStudy, or Media inDocumentReference.media.

• Although both 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 and target resources.

Supported Profiles:

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

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 Client SHALL be capable of fetching a DiagnosticReport resource using: GET [base]/DiagnosticReport/[id]
• A Client SHOULD 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
SHOULD	patient+ status	reference+token
SHALL	patient+ category	reference+token
SHALL	patient+ code	reference+token
SHALL	patient+ category+ date	reference+token+date
SHOULD	patient+ code+ date	reference+token+date

---

DocumentReference

Conformance Expectation: SHOULD

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

Supported Profiles:

• SHALL support: US Core DocumentReference Profile

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:

• SHOULD support the $docref operation

  A client SHOULD be capable of transacting a $docref operation and capable of receiving at least a reference to a generated CCD document, and MAY be able to receive other document types, if available. SHOULD be capable of receiving documents as included resources in response to the operation.

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

Fetch and Search Criteria:

• A Client SHALL be capable of fetching a DocumentReference resource using: GET [base]/DocumentReference/[id]
• A Client SHOULD 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
SHOULD	patient+ status	reference+token
SHALL	patient+ category	reference+token
SHOULD	patient+ type+ period	reference+token+date
SHALL	patient+ category+ date	reference+token+date
SHALL	patient+ type	reference+token

---

Encounter

Conformance Expectation: SHOULD

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 intent of this profile is to support where the encounter occurred. The location address can be represented by either by the Location referenced by Encounter.location.location or indirectly through the Organization referenced by Encounter.serviceProvider.
  • Although both are marked as must support, the server systems are not required to support both Encounter.location.location and Encounter.serviceProvider, but they SHALL support at least one of these elements.
  • The client application SHALL support both elements.
  • if using Encounter.locatison.location it SHOULD conform to US Core Location. However, as a result of implementation feedback, it MAY reference the base FHIR Location resource. See this guidance on Referencing US Core Profiles

Supported Profiles:

• SHALL support: 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 Client SHALL be capable of fetching a Encounter resource using: GET [base]/Encounter/[id]
• A Client SHOULD 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	patient+ status	reference+token
SHOULD	patient+ type	reference+token
SHOULD	class+ patient	token+reference
SHOULD	patient+ discharge-disposition	reference+token
SHOULD	patient+ location	reference+reference

---

Goal

Conformance Expectation: SHOULD

Supported Profiles:

• SHALL support: 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 Client SHALL be capable of fetching a Goal resource using: GET [base]/Goal/[id]
• A Client SHOULD 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+ lifecycle-status	reference+token
SHALL	patient+ description	reference+token
SHOULD	patient+ target-date	reference+date

---

Immunization

Conformance Expectation: SHOULD

Resource Specific Documentation:

• Based upon the ONC U.S. Core Data for Interoperability (USCDI) v1 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: 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 Client SHALL be capable of fetching a Immunization resource using: GET [base]/Immunization/[id]
• A Client SHOULD 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+ status	reference+token
SHOULD	patient+ date	reference+date

---

Location

Conformance Expectation: SHOULD

Resource Specific Documentation:

• The US Core Location and PractitionerRole Profiles are not explicitly referenced in any US Core Profile. However they SHOULD be used as the default profile if referenced by another US Core profile.

Supported Profiles:

• SHALL support: 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 Client SHALL be capable of fetching a Location resource using: GET [base]/Location/[id]

Search Parameter Summary:

Conformance	Parameter	Type
SHALL	name	string
SHALL	address	string
SHOULD	address-city	string
SHOULD	address-state	string
SHOULD	address-postalcode	string

---

Medication

Conformance Expectation: SHOULD

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: 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 Client SHALL be capable of fetching a Medication resource using: GET [base]/Medication/[id]

---

MedicationRequest

Conformance Expectation: SHOULD

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.

Supported Profiles:

• SHALL support: US Core MedicationRequest 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 Client SHALL be capable of fetching a MedicationRequest resource using: GET [base]/MedicationRequest/[id]
• A Client SHOULD be capable of supporting the following _includes:
  • MedicationRequest:medication: GET [base]/MedicationRequest?[parameter=value]&_include=MedicationRequest:medication
• A Client SHOULD 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
SHALL	patient+ intent+ status	reference+token+token
SHALL	patient+ intent	reference+token
SHOULD	patient+ intent+ authoredon	reference+token+date

---

Observation

Conformance Expectation: SHOULD

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.

Supported Profiles:

• SHALL support: US Core Laboratory Result Observation Profile,
• SHALL support: US Core Vital Signs Profile,
• SHALL support: US Core Blood Pressure Profile,
• SHALL support: US Core BMI Profile,
• SHALL support: US Core Head Circumference Profile,
• SHALL support: US Core Body Height Profile,
• SHALL support: US Core Body Weight Profile,
• SHALL support: US Core Body Temperature Profile,
• SHALL support: US Core Heart Rate 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 Pediatric Weight for Height Observation Profile,
• SHALL support: US Core Pulse Oximetry Profile,
• SHALL support: US Core Respiratory Rate Profile,
• SHALL support: US Core Sexual Orientation Observation Profile,
• SHALL support: US Core Smoking Status Observation Profile,
• SHALL support: US Core Clinical Test Result Observation Profile,
• SHALL support: US Core Screening Response Observation Profile,
• SHALL support: US Core Social History Assessment Observation Profile,
• SHALL support: US Core Diagnostic Imaging Result Observation 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 Client SHALL be capable of fetching a Observation resource using: GET [base]/Observation/[id]
• A Client SHOULD 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
SHOULD	patient+ category+ status	reference+token+token
SHALL	patient+ category	reference+token
SHALL	patient+ code	reference+token
SHALL	patient+ category+ date	reference+token+date
SHOULD	patient+ code+ date	reference+token+date

---

Organization

Conformance Expectation: SHOULD

Supported Profiles:

• SHALL support: 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 Client SHALL be capable of fetching a Organization resource using: GET [base]/Organization/[id]

Search Parameter Summary:

Conformance	Parameter	Type
SHALL	name	string
SHALL	address	string

---

Patient

Conformance Expectation: SHOULD

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.

Supported Profiles:

• SHALL support: 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 Client SHALL be capable of fetching a Patient resource using: GET [base]/Patient/[id]
• A Client SHOULD 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
SHOULD	family+ gender	string+token
SHOULD	birthdate+ family	date+string
SHALL	birthdate+ name	date+string
SHALL	gender+ name	token+string

---

Practitioner

Conformance Expectation: SHOULD

Supported Profiles:

• SHALL support: 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 Client SHALL be capable of fetching a Practitioner resource using: GET [base]/Practitioner/[id]

Search Parameter Summary:

Conformance	Parameter	Type
SHOULD	_id	token
SHALL	name	string
SHALL	identifier	token

---

PractitionerRole

Conformance Expectation: SHOULD

Resource Specific Documentation:

• The US Core Location and PractitionerRole Profiles are not explicitly referenced in any US Core Profile. However they SHOULD be used as the default profile if referenced by another US Core profile.

Supported Profiles:

• SHALL support: 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 Client SHALL be capable of fetching a PractitionerRole resource using: GET [base]/PractitionerRole/[id]
• A Client 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	specialty	token
SHALL	practitioner	reference

---

Procedure

Conformance Expectation: SHOULD

Resource Specific Documentation:

• A procedure including an implantable device SHOULD use Procedure.focalDevice with a reference to the [US Core Implantable Device Profile].

Supported Profiles:

• SHALL support: 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 Client SHALL be capable of fetching a Procedure resource using: GET [base]/Procedure/[id]
• A Client SHOULD 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+ status	reference+token
SHALL	patient+ date	reference+date
SHOULD	patient+ code+ date	reference+token+date

---

Provenance

Conformance Expectation: SHOULD

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.
• Systems that need to know the activity has occurred SHOULD populate the activity.

Supported Profiles:

• SHALL support: US Core Provenance Profile

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 Client SHALL be capable of fetching a Provenance resource using: GET [base]/Provenance/[id]

---

RelatedPerson

Conformance Expectation: SHOULD

Supported Profiles:

• SHALL support: US Core RelatedPerson 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 Client SHALL be capable of fetching a RelatedPerson resource using: GET [base]/RelatedPerson/[id]
• A Client SHOULD 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	patient	reference

---

ServiceRequest

Conformance Expectation: SHOULD

Supported Profiles:

• SHALL support: US Core ServiceRequest Profile

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

Search Parameter Summary:

Conformance	Parameter	Type
SHALL	patient	reference
SHALL	_id	token

Search Parameter Combination Summary:

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

---

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.

---