US Core Implementation Guide
4.1.0 - STU4 Ballot

This page is part of the US Core (v4.1.0: STU5 Ballot 1) based on FHIR R4. The current version which supercedes this version is 6.1.0. For a full list of available versions, see the Directory of published versions. Page versions: STU6.1 STU6 STU5 STU4 STU3 STU2

CapabilityStatement: US Core Server CapabilityStatement

Raw OpenAPI-Swagger Definition file | Download

US Core Server CapabilityStatement

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

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

SHOULD Support the Following Implementation Guides:

SHALL Implement All Or Parts Of The Following Capability Statements:

FHIR RESTful Capabilities

The US Core Server SHALL:

  1. Support the US Core Patient resource profile.
  2. Support at least one additional resource profile from the list of US Core Profiles.
  3. Implement the RESTful behavior according to the FHIR specification.
  4. For all the supported search interactions in this guide, support the GET based search.
  5. Return the following response classes:
    • (Status 400): invalid parameter
    • (Status 401/4xx): unauthorized request
    • (Status 403): insufficient scopes
    • (Status 404): unknown resource
  6. Support json source formats for all US Core interactions.

The US Core Server SHOULD:

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

Security:

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

Summary of System Wide Interactions

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

RESTful Capabilities by Resource/Profile:

Summary

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

AllergyIntolerance

Conformance Expectation: SHALL

Supported Profiles:

Reference Policy: resolves

Profile Interaction Summary:

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

Fetch and Search Criteria:

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

Search Parameter Summary:

Conformance Parameter Type
SHALL patient reference

Search Parameter Combination Summary:

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

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

  • 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
    • Assement and Plan MAY be included as narrative text

Supported Profiles:

Reference Policy: resolves

Profile Interaction Summary:

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

Fetch and Search Criteria:

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

Search Parameter Combination Summary:

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

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

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

    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 (and _include search parameters), but SHALL support at least one of them.
  • The client application SHALL support all four profile references.
  • Bacause the US Core PractitionerRole Profile supplies the provider's location and contact information and a reference to the Practitioner, server systems SHOULD reference it instead of the US Core Practitioner Profile. An example of how to access the practitioner name and identifier is shown in the quick start section below.
  • Servers that supports only US Core Practitioner Profile SHALL provide implementation specific guidance how to access a provider's location and contact information using only the Practitioner resource.

Supported Profiles:

Reference Policy: resolves

Profile Interaction Summary:

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

Fetch and Search Criteria:

  • A Server SHALL be capable of returning a CareTeam resource using: GET [base]/CareTeam/[id]
  • A Server SHOULD be capable of supporting the following _includes:
    • CareTeam:participant:PractitionerRole: GET [base]/CareTeam?[parameter=value]&_include=CareTeam:participant:PractitionerRole
    • CareTeam:participant:Practitioner: GET [base]/CareTeam?[parameter=value]&_include=CareTeam:participant:Practitioner
    • CareTeam:participant:Patient: GET [base]/CareTeam?[parameter=value]&_include=CareTeam:participant:Patient
    • CareTeam:participant:RelatedPerson: GET [base]/CareTeam?[parameter=value]&_include=CareTeam:participant:RelatedPerson
  • A Server SHALL be capable of supporting the following _revincludes: Provenance:target - GET [base]/CareTeam?[parameter=value]&_revinclude=Provenance:target

Search Parameter Summary:

Conformance Parameter Type
SHOULD role token

Search Parameter Combination Summary:

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

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

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

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


Condition

Conformance Expectation: SHALL

Resource Specific Documentation:

  • To search for an encounter diagnosis, query for Conditions that reference the Encounter of interest and have a category of encounter-diagnosis.
    • When Condition.category is "encounter-diagnosis" the encounter, SHOULD be referenced in Condition.encounter.
  • See SDOH Guidance for more information when exchanging Social Determinants of Health (SDOH) Conditions/Health Concerns.
  • There is no single element in Condition that represents the date of diagnosis. It may be the assertedDate Extension, Condition.onsetDate, or Condition.recordedDate.
    • Although all three are marked as must support, the server is not required to support all.
    • A server SHALL support Condition.recordedDate.
    • A server SHALL support at least one of [assertedDate Extension] and Condition.onsetDate. A server may support both, which means they support all 3 locations.
    • The client application SHALL support all three elements.

Supported Profiles:

Reference Policy: resolves

Profile Interaction Summary:

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

Fetch and Search Criteria:

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

Search Parameter Summary:

Conformance Parameter Type
SHALL patient reference

Search Parameter Combination Summary:

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

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

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

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

  • onset-date (date):

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

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

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

  • recorded-date (date):

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

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

  • abatement-date (date):

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

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

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


Device

Conformance Expectation: SHALL

Resource Specific Documentation:

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

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

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

    data element US Core Implantable Device Profile element
    manufacturer Device.manufacturer
    model Device.model
  • Servers SHOULD support query by Device.type to allow clients to request the patient's devices by a specific type. Note: The Device.type is too granular to differentiate implantable vs. non-implantable devices.

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

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

    Implementers MAY also adopt custom SearchParameters for searching by:

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

Supported Profiles:

Reference Policy: resolves

Profile Interaction Summary:

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

Fetch and Search Criteria:

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

Search Parameter Summary:

Conformance Parameter Type
SHALL patient reference

Search Parameter Combination Summary:

Conformance Parameter Combination Types
SHOULD patient+ type reference+token

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

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

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

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

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

Supported Profiles:

Reference Policy: resolves

Profile Interaction Summary:

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

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

Fetch and Search Criteria:

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

Search Parameter Summary:

Conformance Parameter Type
SHALL patient reference

Search Parameter Combination Summary:

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

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

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

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

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

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


DocumentReference

Conformance Expectation: SHALL

Resource Specific Documentation:

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

Supported Profiles:

Reference Policy: resolves

Profile Interaction Summary:

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

Operation Summary:

  • SHALL support the $docref operation

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

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

Fetch and Search Criteria:

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

Search Parameter Summary:

Conformance Parameter Type
SHALL _id token
SHALL patient reference

Search Parameter Combination Summary:

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

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

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

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

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

  • date (date):

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

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

  • period (date):

    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

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

Supported Profiles:

Reference Policy: resolves

Profile Interaction Summary:

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

Fetch and Search Criteria:

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

Search Parameter Summary:

Conformance Parameter Type
SHALL _id token
SHOULD identifier token
SHALL patient reference

Search Parameter Combination Summary:

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

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

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

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

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

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

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

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

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

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


Goal

Conformance Expectation: SHALL

Supported Profiles:

Reference Policy: resolves

Profile Interaction Summary:

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

Fetch and Search Criteria:

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

Search Parameter Summary:

Conformance Parameter Type
SHALL patient reference

Search Parameter Combination Summary:

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

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

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

    A client SHALL provide a value precise to the day.

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


Immunization

Conformance Expectation: SHALL

Resource Specific Documentation:

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

Supported Profiles:

Reference Policy: resolves

Profile Interaction Summary:

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

Fetch and Search Criteria:

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

Search Parameter Summary:

Conformance Parameter Type
SHALL patient reference

Search Parameter Combination Summary:

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

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

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

  • date (date):

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

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


Location

Conformance Expectation: SHALL

Resource Specific Documentation:

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

Supported Profiles:

Reference Policy: resolves

Profile Interaction Summary:

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

Fetch and Search Criteria:

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

Search Parameter Summary:

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

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:

Reference Policy: resolves

Profile Interaction Summary:

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

Fetch and Search Criteria:

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

MedicationRequest

Conformance Expectation: SHALL

Resource Specific Documentation:

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

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

GET /MedicationRequest?patient=[id]

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

  • The MedicationRequest resource can represent that information is from a secondary source using either a boolean flag or reference in MedicationRequest.reportedBoolean, or a reference using MedicationRequest.reportedReference to Practitioner or other resource.
    • Although both are marked as must support, the server systems are not required to support both a boolean and a reference, but SHALL choose to support at least one of these elements.
    • The client application SHALL support both elements.

Supported Profiles:

Reference Policy: resolves

Profile Interaction Summary:

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

Fetch and Search Criteria:

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

Search Parameter Combination Summary:

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

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

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

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

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

  • authoredon (date):

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

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


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.

Supported Profiles:

Reference Policy: resolves

Profile Interaction Summary:

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

Fetch and Search Criteria:

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

Search Parameter Combination Summary:

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

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

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

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

    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.


Organization

Conformance Expectation: SHALL

Supported Profiles:

Reference Policy: resolves

Profile Interaction Summary:

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

Fetch and Search Criteria:

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

Search Parameter Summary:

Conformance Parameter Type
SHALL name string
SHALL address string

Patient

Conformance Expectation: SHALL

Resource Specific Documentation:

  • For ONC's USCDI requirements, each Patient must support the following additional elements. These elements are included in the formal definition of the profile. The patient examples include all of these elements.
  1. contact detail (e.g. a telephone number or an email address)
  2. a communication language
  3. a race
  4. an ethnicity
  5. a birth sex*
  6. previous name
    • Previous name is represented by providing an end date in the Patient.name.period element for a previous name.
  7. suffix
    • Suffix is represented using the Patient.name.suffix element.

Supported Profiles:

Reference Policy: resolves

Profile Interaction Summary:

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

Fetch and Search Criteria:

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

Search Parameter Summary:

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

Search Parameter Combination Summary:

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

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

  • birthdate (date):

    A client SHALL provide a value precise to the day.

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

  • family (string):

    A server SHALL support a value precise to the day.

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


Practitioner

Conformance Expectation: SHALL

Supported Profiles:

Reference Policy: resolves

Profile Interaction Summary:

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

Fetch and Search Criteria:

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

Search Parameter Summary:

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

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

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

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

Supported Profiles:

Reference Policy: resolves

Profile Interaction Summary:

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

Fetch and Search Criteria:

  • A Server SHALL be capable of returning a PractitionerRole resource using: GET [base]/PractitionerRole/[id]
  • A Server SHOULD be capable of supporting the following _includes:
    • PractitionerRole:endpoint: GET [base]/PractitionerRole?[parameter=value]&_include=PractitionerRole:endpoint
    • PractitionerRole:practitioner: GET [base]/PractitionerRole?[parameter=value]&_include=PractitionerRole:practitioner

Search Parameter Summary:

Conformance Parameter Type
SHALL specialty token
SHALL practitioner reference

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

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

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


Procedure

Conformance Expectation: SHALL

Resource Specific Documentation:

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

Supported Profiles:

Reference Policy: resolves

Profile Interaction Summary:

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

Fetch and Search Criteria:

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

Search Parameter Summary:

Conformance Parameter Type
SHALL patient reference

Search Parameter Combination Summary:

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

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

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

  • date (date):

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

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

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


Provenance

Conformance Expectation: SHALL

Resource Specific Documentation:

  • If a system receives a provider in Provenance.agent.who as free text they must capture who sent them the information as the organization. On request they SHALL provide this organization as the source and MAY include the free text provider.
  • Systems that need to know the activity has occurred SHOULD populate the activity.

Supported Profiles:

Reference Policy: resolves

Profile Interaction Summary:

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

Fetch and Search Criteria:

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

RelatedPerson

Conformance Expectation: SHALL

Supported Profiles:

Reference Policy: resolves

Profile Interaction Summary:

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

Fetch and Search Criteria:

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

Search Parameter Summary:

Conformance Parameter Type
SHALL _id token
SHOULD patient reference

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

  • patient (reference):

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

    The server SHALL support both.


ServiceRequest

Conformance Expectation: SHALL

Supported Profiles:

Reference Policy: resolves

Profile Interaction Summary:

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

Fetch and Search Criteria:

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

Search Parameter Summary:

Conformance Parameter Type
SHALL patient reference
SHALL _id token

Search Parameter Combination Summary:

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

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

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

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

  • authored (date):

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

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


ValueSet

Conformance Expectation: SHOULD

Operation Summary:

  • SHOULD support the $expand operation

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