US Core Implementation Guide TEST
9.0.0 - CI Build United States of America flag

US Core Implementation Guide TEST, published by HL7 International / Cross-Group Projects. This guide is not an authorized publication; it is the continuous build for version 9.0.0 built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/HL7/US-Core/ and changes regularly. See the Directory of published versions

CapabilityStatement: US Core Server CapabilityStatement

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

Copyright/Legal: Used by permission of HL7 International, all rights reserved Creative Commons License

This Section describes the expected capabilities of the US Core Server actor which is responsible for providing responses to the queries submitted by the US Core Requestors. The complete list of FHIR profiles, RESTful operations, and search parameters supported by US Core Servers are defined. Systems implementing this capability statement should meet the ASTP 2015 Common Clinical Data Set (CCDS) access requirement for Patient Selection 170.315(g)(7) and Application Access - Data Category Request 170.315(g)(8) and the ASTP U.S. Core Data for Interoperability (USCDI) Version 6 July 2025.

Raw OpenAPI-Swagger Definition file | Download

Support and Requirements for Other Artifacts

Supports other guides:

FHIR Server RESTful Capabilities

The US Core Server SHALL:

  1. Support the US Core Patient resource profile AND at least one additional resource profile from the list of US Core Profiles AND and all Must Support US Core Profiles and resources it references.
    • A summary table listing all the Must Support references to other US Core Profiles and FHIR resources for each US Core Profile is located in the Must Support - Resource References section of the guide.
  2. Follow the requirements documented in the General Requirements and Must Support pages
  3. Return the following response classes:
    • (Status 400): invalid parameter
    • (Status 401/4xx): unauthorized request
    • (Status 403): insufficient scopes
    • (Status 404): unknown resource
  4. Support JSON source formats for all US Core interactions.

The US Core Server SHOULD:

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

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

  • multipleAnd
  • multipleOr
  • comparator
  • modifier
  • chain

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


Security:

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

System-wide Server Capabilities

Interactions

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

Summary of Resource/Profile Capabilities

Resource Type Supported Profiles Supported Searches Supported _includes Supported _revincludes Supported Operations
AllergyIntolerance •US Core AllergyIntolerance Profile
 exist clinical-status, patient , patient+clinical-status - Provenance:target -
CarePlan •US Core CarePlan Profile
 exist category, date, patient, status , patient+category+status, patient+category, patient+category+date, patient+category+status+date - Provenance:target -
CareTeam •US Core CareTeam Profile
 exist 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
 exist abatement-date, asserted-date, category, clinical-status, code, encounter, onset-date, patient, recorded-date, _lastUpdated , patient+clinical-status, patient+code, patient+category, patient+abatement-date, patient+recorded-date, patient+_lastUpdated, patient+asserted-date, patient+category+clinical-status, patient+onset-date, patient+category+encounter - Provenance:target -
Coverage •US Core Coverage Profile
 exist patient - Provenance:target -
Device •US Core Device Profile
 exist patient, status, type , patient+type, patient+status - Provenance:target -
DiagnosticReport •US Core DiagnosticReport Profile for Report and Note exchange
•US Core DiagnosticReport Profile for Laboratory Results Reporting
 exist category, code, date, _lastUpdated, patient, status , patient+code+date, patient+category+_lastUpdated, patient+category+date, patient+category, patient+status, patient+code - Provenance:target -
DocumentReference •US Core DocumentReference Profile
•US Core ADI DocumentReference Profile
 exist _id, category, date, patient, period, status, type , patient+type, patient+category+date, patient+category, patient+type+period, patient+status - Provenance:target $docref
Encounter •US Core Encounter Profile
 exist _id, class, date, _lastUpdated, discharge-disposition, identifier, location, patient, status, type , patient+type, class+patient, patient+status, patient+_lastUpdated, patient+location, date+patient, patient+discharge-disposition - Provenance:target -
Endpoint - exist - - - -
FamilyMemberHistory •US Core FamilyMemberHistory Profile
 exist patient, code , patient+code - Provenance:target -
Goal •US Core Goal Profile
 exist description, lifecycle-status, patient, target-date , patient+description, patient+target-date, patient+lifecycle-status - Provenance:target -
HealthcareService - exist - - - -
Immunization •US Core Immunization Profile
 exist date, patient, status , patient+date, patient+status - Provenance:target -
Location •US Core Location Profile
 exist address, address-city, address-postalcode, address-state, name - - -
Media - exist - - - -
Medication •US Core Medication Profile
 exist - - - -
MedicationDispense •US Core MedicationDispense Profile
 exist patient, status, type , patient+status+type, patient+status MedicationDispense:medication Provenance:target -
MedicationRequest •US Core MedicationRequest Profile
 exist authoredon, encounter, intent, patient, status , patient+intent+authoredon, patient+intent+encounter, patient+intent, patient+intent+status MedicationRequest:medication Provenance:target -
Observation •US Core Observation ADI Documentation Profile
•US Core Laboratory Result Observation Profile
•US Core Observation Pregnancy Status Profile
•US Core Observation Pregnancy Intent Profile
•US Core Observation Occupation Profile
•US Core Respiratory Rate Profile
•US Core Simple Observation Profile
•US Core Treatment Intervention Preference Profile
•US Core Care Experience Preference Profile
•US Core Heart Rate Profile
•US Core Body Temperature Profile
•US Core Pediatric Weight for Height Observation Profile
•US Core Pulse Oximetry Profile
•US Core Smoking Status Observation Profile
•US Core Observation Sexual Orientation Profile
•US Core Head Circumference Profile
•US Core Body Height Profile
•US Core BMI Profile
•US Core Observation Screening Assessment Profile
•US Core Average Blood Pressure Profile
•US Core Blood Pressure Profile
•US Core Observation Clinical Result Profile
•US Core Pediatric BMI for Age Observation Profile
•US Core Pediatric Head Occipital Frontal Circumference Percentile Profile
•US Core Body Weight Profile
•US Core Vital Signs Profile
 exist category, code, date, _lastUpdated, patient, status , patient+code+date, patient+category+_lastUpdated, patient+category+date, patient+category, patient+category+status, patient+code - Provenance:target -
Organization •US Core Organization Profile
 exist address, name - - -
Patient •US Core Patient Profile
 exist _id, birthdate, death-date, family, given, identifier, name , birthdate+name, birthdate+family, death-date+family - Provenance:target -
Practitioner •US Core Practitioner Profile
 exist _id, identifier, name - - -
PractitionerRole •US Core PractitionerRole Profile
 exist practitioner, specialty PractitionerRole:endpoint PractitionerRole:practitioner - -
Procedure •US Core Procedure Profile
 exist code, date, patient, status , patient+code+date, patient+date, patient+status - Provenance:target -
Provenance •US Core Provenance Profile
 exist - - - -
Questionnaire •SDC Base Questionnaire Profile
 exist - - - -
QuestionnaireResponse •US Core QuestionnaireResponse Profile
 exist _id, authored, patient, questionnaire, status , patient+questionnaire, patient+authored, patient+status - Provenance:target -
RelatedPerson •US Core RelatedPerson Profile
 exist _id, name, patient , patient+name - Provenance:target -
ServiceRequest •US Core PMO ServiceRequest Profile
•US Core ServiceRequest Profile
 exist _id, authored, category, code, patient, status , patient+code+authored, patient+category+authored, patient+category, patient+status, patient+code - Provenance:target -
Specimen •US Core Specimen Profile
 exist _id, patient - - -
ValueSet - exist - - - $expand

RESTful Server Capabilities by Resource/Profile:

AllergyIntolerance

Conformance Expectation: SHALL

Supported Profiles:

FHIR RESTful Interactions

Summary:

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

Modify Criteria Details:

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

Fetch and Search Criteria Details:

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

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

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

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

    The server SHALL support both.

  • patient (Reference):

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

    The server SHALL support both.

CarePlan

Conformance Expectation: SHALL

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

    • Assessment and Plan MAY be included as narrative text

Supported Profiles:

FHIR RESTful Interactions

Summary:

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

Modify Criteria Details:

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

Fetch and Search Criteria Details:

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

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

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

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

    The server SHALL support both.

  • date (Date/DateTime):

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

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

  • patient (Reference):

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

    The server SHALL support both.

  • status (Token):

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

    The server SHALL support both.

CareTeam

Conformance Expectation: SHALL

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:

FHIR RESTful Interactions

Summary:

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

Modify Criteria Details:

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

Fetch and Search Criteria Details:

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

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

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

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

    The server SHALL support both.

  • role (Token):

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

    The server SHALL support both.

  • status (Token):

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

    The server SHALL support both.

Condition

Conformance Expectation: SHALL

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

  • See the US Core General Guidance page for Searching Using lastUpdated. Updates to Condition.meta.lastUpdated SHOULD reflect:

    • New problems and health concerns

    • Changes in the clinical status or verifications status of problems or health concern

Supported Profiles:

FHIR RESTful Interactions

Summary:

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

Modify Criteria Details:

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

Fetch and Search Criteria Details:

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

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

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

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

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

  • asserted-date (Date/DateTime):

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

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

  • category (Token):

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

    The server SHALL support both.

  • clinical-status (Token):

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

    The server SHALL support both.

  • code (Token):

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

    The server SHALL support both.

  • encounter (Reference):

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

    The server SHALL support both.

  • onset-date (Date/DateTime):

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

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

  • patient (Reference):

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

    The server SHALL support both.

  • recorded-date (Date/DateTime):

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

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

  • _lastUpdated (Date/DateTime):

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

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

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

Coverage

Conformance Expectation: SHALL

Supported Profiles:

FHIR RESTful Interactions

Summary:

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

Modify Criteria Details:

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

Fetch and Search Criteria Details:

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

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

Conformance Parameter Type Example
SHALL patient Reference GET [base]/Coverage?patient=[type]/[id]
  • patient (Reference):

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

    The server SHALL support both.

Device

Conformance Expectation: SHALL

Resource Specific Documentation:

  • Medical devices with UDI information SHALL represent the UDI code in Device.udiCarrier.carrierHRF. All five UDI-PI elements defined in the UDI code may not always be present in every UDI instance. However, those UDI-PI elements present SHALL be represented in the corresponding *US Core Device Profile elements.

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

    medical device data element US Core Device Profile element
    manufacturer Device.manufacturer
    model Device.model

Supported Profiles:

FHIR RESTful Interactions

Summary:

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

Modify Criteria Details:

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

Fetch and Search Criteria Details:

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

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

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

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

    The server SHALL support both.

  • status (Token):

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

    The server SHALL support both.

  • type (Token):

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

    The server SHALL support both.

DiagnosticReport

Conformance Expectation: SHALL

Resource Specific Documentation:

  • For laboratory result reports use the US Core DiagnosticReport Profile for Laboratory Results Reporting Profile.

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

  • For imaging and non-laboratory clinical test result reports use the US Core DiagnosticReport Profile for Report and Note Exchange Profile.

    • Diagnostic imaging results in visual images requiring interpretation and clinical test results/reports may also reference images as part of the report. There is no single approach for accessing imaging studies alongside clinical data using a single authorization flow to give patients and providers access to the images.

      • The DiagnosticReport.media.link element SHOULD be used to support links to various patient-friendly content, such as jpg images of x-rays (see the DiagnosticReport Chest X-ray Report Example).

      • The DiagnosticReport.imagingStudy element SHOULD be used to support exchange with systems that can view DICOM (Digital Imaging and Communications in Medicine) studies, series, and SOP (Service-Object Pair) instances referenced in the [ImagingStudy] resource.

      • Alternatively, systems can use business identifiers such as accession numbers in the identifier element to access the source images from external sources.

  • The DiagnosticRequest.basedOn element connects the DiagnosticReport to the originating order in the EHR. Systems that initiate the lab order SHOULD use this element when reporting the results.

Supported Profiles:

FHIR RESTful Interactions

Summary:

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

Modify Criteria Details:

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

Fetch and Search Criteria Details:

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

create

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


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

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

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

    The server SHALL support both.

  • code (Token):

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

    The server SHALL support both.

  • date (Date/DateTime):

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

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

  • _lastUpdated (Date/DateTime):

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

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

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

  • patient (Reference):

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

    The server SHALL support both.

  • status (Token):

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

    The server SHALL support both.

DocumentReference

Conformance Expectation: SHALL

Resource Specific Documentation:

  • For Advance Directive Information (ADI) documents use the US Core ADI DocumentReference Profile.

  • For other clinical documents use the US Core DiagnosticReport Profile for Report and Note Exchange.

    • See the Clinical Notes page for important definitions, requirements, and guidance on creating, using, and sharing Clinical Notes.

    • The DocumentReference.type binding Must Support at a minimum the 10 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.attachment.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 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:

FHIR RESTful Interactions

Summary:

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

Modify Criteria Details:

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

Fetch and Search Criteria Details:

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

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

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

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

    The server SHALL support both.

  • date (Date/DateTime):

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

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

  • patient (Reference):

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

    The server SHALL support both.

  • period (Date/DateTime):

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

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

  • status (Token):

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

    The server SHALL support both.

  • type (Token):

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

    The server SHALL support both.

FHIR Operations:

$docref:

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

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

Encounter

Conformance Expectation: SHALL

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:

  • Servers can use the US Core Interpreter Needed Extension on this profile or the [US Core Patient Profile] to communicate whether a patient needs an interpreter. Although the extension is marked as an Additional USCDI Requirements on both US Core Patient and US Core Encounter Profiles, the certifying Server system is not required to support the extension on both profiles, but SHALL support the extension on at least one. The certifying Client application SHALL support the extension on both profiles.

    • Systems SHOULD designate the patient's preferred language in the Patient.communication.preferred element.

  • Updates to .meta.lastUpdated SHOULD reflect:

    • New encounters/visits

    • Changes in the status of encounters, including events that trigger the same status (e.g., in-progress → in-progress). These status changes correspond to events that can initiate [HL7 V2] ADT messages.

Supported Profiles:

FHIR RESTful Interactions

Summary:

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

Modify Criteria Details:

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

Fetch and Search Criteria Details:

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

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

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

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

    The server SHALL support both.

  • date (Date/DateTime):

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

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

  • _lastUpdated (Date/DateTime):

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

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

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

  • discharge-disposition (Token):

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

    The server SHALL support both.

  • identifier (Token):

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

    The server SHALL support both.

  • location (Reference):

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

    The server SHALL support both.

  • patient (Reference):

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

    The server SHALL support both.

  • status (Token):

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

    The server SHALL support both.

  • type (Token):

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

    The server SHALL support both.

Endpoint

Conformance Expectation: SHALL

Resource Specific Documentation:

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

FHIR RESTful Interactions

Summary:

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

Modify Criteria Details:

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

Fetch and Search Criteria Details:

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

FamilyMemberHistory

Conformance Expectation: SHALL

Supported Profiles:

FHIR RESTful Interactions

Summary:

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

Modify Criteria Details:

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

Fetch and Search Criteria Details:

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

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

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

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

    The server SHALL support both.

  • code (Token):

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

    The server SHALL support both.

Goal

Conformance Expectation: SHALL

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:

FHIR RESTful Interactions

Summary:

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

Modify Criteria Details:

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

Fetch and Search Criteria Details:

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

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

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

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

    The server SHALL support both.

  • patient (Reference):

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

    The server SHALL support both.

  • target-date (Date/DateTime):

    A client SHALL provide a value precise to the day.

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

HealthcareService

Conformance Expectation: MAY

Resource Specific Documentation:

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

FHIR RESTful Interactions

Summary:

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

Modify Criteria Details:

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

Fetch and Search Criteria Details:

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

Immunization

Conformance Expectation: SHALL

Resource Specific Documentation:

  • Based upon the ASTP U.S. Core Data for Interoperability (USCDI) requirements, CVX vaccine codes are required and the NDC vaccine codes SHOULD be supported as an additional code.

Supported Profiles:

FHIR RESTful Interactions

Summary:

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

Modify Criteria Details:

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

Fetch and Search Criteria Details:

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

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

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

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

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

  • patient (Reference):

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

    The server SHALL support both.

  • status (Token):

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

    The server SHALL support both.

Location

Conformance Expectation: SHALL

Resource Specific Documentation:

  • Systems SHOULD enable the user who enters the address to 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:

FHIR RESTful Interactions

Summary:

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

Modify Criteria Details:

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

Fetch and Search Criteria Details:

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

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

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

Media

Conformance Expectation: SHALL

Resource Specific Documentation:

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

FHIR RESTful Interactions

Summary:

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

Modify Criteria Details:

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

Fetch and Search Criteria Details:

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

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:

FHIR RESTful Interactions

Summary:

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

Modify Criteria Details:

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

Fetch and Search Criteria Details:

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

MedicationDispense

Conformance Expectation: SHALL

Resource Specific Documentation:

  • This Profile can represent a medication using a code or reference a Medication resource.

    • The Server systems are not required to support both a code and a reference, but SHALL support at least one of these methods.

    • The Client application SHALL support all methods.

    • Systems that primarily rely on NDC codes instead of RxNorm to represent medications can use the National Library of Medicine's (NLM) NDC to RxNorm mappings to aid in additional codings.

    • When referencing a Medication resource in .medicationReference, the resource may be contained or an external resource. If an external reference to a Medication resource is used, the Server SHALL support the _include parameter for searching this element.

Supported Profiles:

FHIR RESTful Interactions

Summary:

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

Modify Criteria Details:

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

Fetch and Search Criteria Details:

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

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

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

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

    The server SHALL support both.

  • status (Token):

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

    The server SHALL support both.

  • type (Token):

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

    The server SHALL support both.

MedicationRequest

Conformance Expectation: SHALL

Resource Specific Documentation:

  • This Profile can represent a medication using a code or reference a Medication resource.

    • The Server systems are not required to support both a code and a reference, but SHALL support at least one of these methods.
    • The Client application SHALL support all methods.
    • Systems that primarily rely on NDC codes instead of RxNorm to represent medications can use the National Library of Medicine's (NLM) NDC to RxNorm mappings to aid in additional codings.
    • When referencing a Medication resource in .medicationReference, the resource may be contained or an external resource. If an external reference to a Medication resource is used, the Server SHALL support the _include parameter for searching this element.

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

FHIR RESTful Interactions

Summary:

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

Modify Criteria Details:

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

Fetch and Search Criteria Details:

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

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

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

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

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

  • encounter (Reference):

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

    The server SHALL support both.

  • intent (Token):

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

    The server SHALL support both.

  • patient (Reference):

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

    The server SHALL support both.

  • status (Token):

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

    The server SHALL support both.

Observation

Conformance Expectation: SHALL

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.
  • There are multiple Observation profiles. Refer to the specific profile page for profile specific conformance rules and guidance

Supported Profiles:

FHIR RESTful Interactions

Summary:

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

Modify Criteria Details:

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

Fetch and Search Criteria Details:

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

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

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

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

    The server SHALL support both.

  • code (Token):

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

    The server SHALL support both.

  • date (Date/DateTime):

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

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

  • _lastUpdated (Date/DateTime):

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

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

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

  • patient (Reference):

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

    The server SHALL support both.

  • status (Token):

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

    The server SHALL support both.

Organization

Conformance Expectation: SHALL

Resource Specific Documentation:

  • Systems SHALL support National Provider Identifier (NPI) for organizations and SHOULD support Clinical Laboratory Improvement Amendments (CLIA) and the National Association of Insurance Commissioners NAIC Company code (sometimes called "NAIC Number" or "cocode") for Organization.Identifier.
  • Systems SHOULD enable the user who enters the address to 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:

FHIR RESTful Interactions

Summary:

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

Modify Criteria Details:

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

Fetch and Search Criteria Details:

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

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

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

Patient

Conformance Expectation: SHALL

Resource Specific Documentation:

  • The Patient's Social Security Numbers SHOULD NOT be used as a patient identifier in Patient.identifier.value.
  • The Complex Extensions for Race and Ethnicity allow for one or more codes of which: Must Support at least one category code from the OMB Race and Ethnicity Category Value Sets that draw from the Race & Ethnicity - CDC (CDCREC] code system.
    • MAY include additional codes from the detailed ethnicity and detailed race value sets drawn from the Race & Ethnicity - CDC (CDCREC) code system
    • SHALL include a text description
  • Although Patient.deceased[x] is marked as Additional USCDI Requirement, certifying systems are not required to support both choices, but SHALL support at least Patient.deceasedDateTime.
  • Servers can use the US Core Interpreter Needed Extension on this profile or the US Core Encounter Profile to communicate whether a patient needs an interpreter. Although the extension is marked as an Additional USCDI Requirement on both US Core Patient and US Core Encounter Profiles, the certifying Server system is not required to support the extension on both profiles but SHALL support the extension on at least one. The certifying Client application SHALL support the extension on both profiles.
    • Systems SHOULD designate the patient's preferred language in the Patient.communication.preferred element.
  • Certifying systems SHALL and non-certifying systems SHOULD enable the user who enters the address to 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:

FHIR RESTful Interactions

Summary:

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

Modify Criteria Details:

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

Fetch and Search Criteria Details:

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

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

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

    A client SHALL provide a value precise to the day.

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

  • death-date (Date/DateTime):

    A client SHALL provide a value precise to the day.

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

  • identifier (Token):

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

    The server SHALL support both.

Practitioner

Conformance Expectation: SHALL

Resource Specific Documentation:

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

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

  • To balance the privacy of healthcare workers with the patient's right to access information. Only professional/work contact information about the practitioner SHOULD be available to the patient (such as a work address or office telephone number).

  • Systems SHOULD enable the user who enters the address to 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:

FHIR RESTful Interactions

Summary:

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

Modify Criteria Details:

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

Fetch and Search Criteria Details:

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

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

Conformance Parameter Type Example
SHOULD _id Token GET [base]/Practitioner?_id=[id]
SHALL identifier Token GET [base]/Practitioner?identifier=[system]|[code]
SHALL name String GET [base]/Practitioner?name=[name]
  • identifier (Token):

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

    The server SHALL support both.

PractitionerRole

Conformance Expectation: SHALL

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:

FHIR RESTful Interactions

Summary:

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

Modify Criteria Details:

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

Fetch and Search Criteria Details:

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

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

Conformance Parameter Type Example
SHALL practitioner Reference GET [base]/PractitionerRole?practitioner=[type]/[id]
SHALL specialty Token GET [base]/PractitionerRole?specialty=[system]|[code]
  • practitioner (Reference):

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

    The server SHALL support both.

  • specialty (Token):

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

    The server SHALL support both.

Procedure

Conformance Expectation: SHALL

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 a medical device SHOULD use Procedure.focalDevice with a reference to the US Core 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:

FHIR RESTful Interactions

Summary:

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

Modify Criteria Details:

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

Fetch and Search Criteria Details:

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

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

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

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

    The server SHALL support both.

  • date (Date/DateTime):

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

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

  • patient (Reference):

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

    The server SHALL support both.

  • status (Token):

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

    The server SHALL support both.

Provenance

Conformance Expectation: SHALL

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

    • FamilyMemberHistory

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

FHIR RESTful Interactions

Summary:

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

Modify Criteria Details:

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

Fetch and Search Criteria Details:

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

Questionnaire

Conformance Expectation: SHOULD

Resource Specific Documentation:

  • US Core defines two ways to represent the questions and responses to screening and assessment instruments:

    • Observation: US Core Observation Screening Assessment Profile

    • Questionnaire/QuestionnaireResponse: SDC Base Questionnaire/US Core QuestionnaireResponse Profile

  • US Core Servers SHALL support US Core Observation Screening Assessment Profile and SHOULD support the SDC Base Questionnaire Profile/US Core QuestionnaireResponse Profile

Supported Profiles:

FHIR RESTful Interactions

Summary:

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

Modify Criteria Details:

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

Fetch and Search Criteria Details:

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

QuestionnaireResponse

Conformance Expectation: SHOULD

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:

FHIR RESTful Interactions

Summary:

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

Modify Criteria Details:

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

Fetch and Search Criteria Details:

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

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

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

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

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

  • patient (Reference):

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

    The server SHALL support both.

  • questionnaire (Reference):

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

    The server SHALL support both.

  • status (Token):

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

    The server SHALL support both.

RelatedPerson

Conformance Expectation: SHALL

Resource Specific Documentation:

  • Systems SHOULD enable the user who enters the address to 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:

FHIR RESTful Interactions

Summary:

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

Modify Criteria Details:

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

Fetch and Search Criteria Details:

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

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

Conformance Parameter Type Example
SHALL _id Token GET [base]/RelatedPerson?_id=[id]
SHOULD name String GET [base]/RelatedPerson?name=[name]
SHOULD patient Reference GET [base]/RelatedPerson?patient=[type]/[id]
SHOULD patient+name Reference+String GET [base]/RelatedPerson?patient=[type]/[id]&name=[name]
  • patient (Reference):

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

    The server SHALL support both.

ServiceRequest

Conformance Expectation: SHALL

Resource Specific Documentation:

  • The Must Support ServiceRequest.category is bound, at a minimum, to the US Core ServiceRequest Category Codes, and other category codes can be used. API consumers can query by category when accessing patient information. For the USCDI Laboratory Order, Imaging Order, Clinical Test Order, and Procedure Order Data Elements, implementers SHOULD use the corresponding category codes listed in the table on the US Core ServiceRequest Profile page. For example, laboratory orders would have the category code "108252007" (Laboratory procedure).

  • The ServiceRequest.code value set is broad to accommodate a wide variety of use cases and SHOULD be constrained to a subset for a particular use case or domain. These value sets contain concepts that span many use cases and are not bound to any USCDI Data Element. However, the table on the US Core ServiceRequest Profile page identifies additional value set bindings for the USCDI Laboratory Order, Imaging Order and Clinical Test Order Data Elements. Implementers SHOULD conform to the binding strengths for each USCDI Order context listed in the table. For example, laboratory orders are extensibly bound to the LOINC Common Laboratory Orders Value Set. Note that the USCDI Class Procedure Order Data Element has no additional binding.

  • 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 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 as documented in Referencing US Core Profiles.

Supported Profiles:

FHIR RESTful Interactions

Summary:

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

Modify Criteria Details:

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

Fetch and Search Criteria Details:

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

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

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

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

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

  • category (Token):

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

    The server SHALL support both.

  • code (Token):

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

    The server SHALL support both.

  • patient (Reference):

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

    The server SHALL support both.

  • status (Token):

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

    The server SHALL support both.

Specimen

Conformance Expectation: SHALL

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:

FHIR RESTful Interactions

Summary:

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

Modify Criteria Details:

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

Fetch and Search Criteria Details:

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

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

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

ValueSet

Conformance Expectation: SHOULD

FHIR Operations:

$expand:

If a server supports DocumentReference for creating, using, and sharing clinical notes, it SHOULD also support the context and contextdirection parameters of the $expand operation to enable clients to determine the supported note and report types, as well as the supported read/write formats for notes on the server.