US Core Implementation Guide
6.0.0 - STU6 United States of America flag

This page is part of the US Core (v6.0.0: STU6) based on FHIR R4. This is the current published version. For a full list of available versions, see the Directory of published versions

CapabilityStatement: US Core Client CapabilityStatement

Official URL: http://hl7.org/fhir/us/core/CapabilityStatement/us-core-client Version: 6.0.0
Active as of 2023-04-24 Computable Name: UsCoreClientCapabilityStatement

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

This Section describes the expected capabilities of the US Core Client which is responsible for creating and initiating the queries for information about an individual patient. The complete list of FHIR profiles, RESTful operations, and search parameters supported by US Core Servers are defined in the Conformance Requirements for Server. US Core Clients have the option of choosing from this list to access necessary data based on their local use cases and other contextual requirements.

Raw OpenAPI-Swagger Definition file | Download

SHOULD Support the Following Implementation Guides:

SHALL Implement All Or Parts Of The Following Capability Statements:

FHIR RESTful Capabilities

The US Core Client SHALL:

  1. Support fetching and querying of one or more US Core profile(s), using the supported RESTful interactions and search parameters declared in the US Core Server CapabilityStatement.
  2. Follow the requirements documented in the General Requirements and Must Support pages

Security:

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

Summary of System Wide Interactions

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

RESTful Capabilities by Resource/Profile:

Summary

Resource Type Supported Profiles Supported Searches Supported _includes Supported _revincludes Supported Operations
AllergyIntolerance US Core AllergyIntolerance Profile clinical-status, patient patient+clinical-status - Provenance:target -
CarePlan US Core CarePlan Profile category, date, patient, status patient+category+status, patient+category+status+date, patient+category, patient+category+date - 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 Encounter Diagnosis Profile, US Core Condition Problems and Health Concerns Profile category, clinical-status, patient, onset-date, asserted-date, recorded-date, abatement-date, code, encounter patient+recorded-date, patient+asserted-date, patient+category+clinical-status, patient+onset-date, patient+abatement-date, patient+clinical-status, patient+category+encounter, patient+code, patient+category - Provenance:target -
Coverage US Core Coverage Profile patient - Provenance:target -
Device US Core Implantable Device Profile patient, type, status patient+type, patient+status - Provenance:target -
DiagnosticReport US Core DiagnosticReport Profile for Report and Note exchange, US Core DiagnosticReport Profile for Laboratory Results Reporting status, patient, category, code, date patient+code+date, patient+status, patient+category+date, patient+category, patient+code - Provenance:target -
DocumentReference US Core DocumentReference Profile _id, status, patient, category, type, date, period patient+type, patient+status, patient+type+period, patient+category+date, patient+category - Provenance:target docref
Encounter US Core Encounter Profile _id, class, date, identifier, patient, location, status, type, discharge-disposition patient+type, class+patient, patient+status, date+patient, patient+location, patient+discharge-disposition - Provenance:target -
Endpoint - - - - -
Goal US Core Goal Profile lifecycle-status, patient, target-date, description patient+target-date, patient+description, patient+lifecycle-status - Provenance:target -
HealthcareService - - - - -
Immunization US Core Immunization Profile patient, status, date patient+date, patient+status - Provenance:target -
Location US Core Location Profile name, address, address-city, address-state, address-postalcode - - -
Media - - - - -
Medication US Core Medication Profile - - - -
MedicationDispense US Core MedicationDispense Profile status, type, patient patient+status+type, patient+status MedicationDispense:medication Provenance:target -
MedicationRequest US Core MedicationRequest Profile status, intent, patient, encounter, authoredon patient+intent+encounter, patient+intent+status, patient+intent+authoredon, patient+intent MedicationRequest:medication Provenance:target -
Observation US Core Laboratory Result Observation Profile, US Core Observation Pregnancy Status Profile, US Core Observation Pregnancy Intent Profile, US Core Observation Occupation Profile, US Core Respiratory Rate Profile, US Core Simple Observation Profile, US Core 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 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 status, category, code, date, patient patient+code+date, patient+category+status, patient+category+date, patient+category, patient+code - Provenance:target -
Organization US Core Organization Profile name, address - - -
Patient US Core Patient Profile _id, birthdate, death-date, family, gender, given, identifier, name birthdate+family, family+gender, birthdate+name, gender+name, death-date+family - 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+code+date, patient+status, patient+date - Provenance:target -
Provenance US Core Provenance Profile - - - -
Questionnaire SDC Base Questionnaire Profile - - - -
QuestionnaireResponse US Core QuestionnaireResponse Profile _id, patient, status, authored, questionnaire patient+questionnaire, patient+authored, patient+status - Provenance:target -
RelatedPerson US Core RelatedPerson Profile _id, patient, name patient+name - Provenance:target -
ServiceRequest US Core ServiceRequest Profile status, patient, category, code, authored, _id patient+category+authored, patient+status, patient+category, patient+code+authored, patient+code - Provenance:target -
Specimen US Core Specimen Profile _id, patient - - -
ValueSet - - - - expand

Summary of Must Support References Between Profiles

  • US Core Profile: The profile referencing another profile or resource (Target Profile).
  • Resource Type, The resource type of the source profile.
  • Target Profile: The profile or resource that is being referenced by another profile (US Core Profile).
  • Target Resource Type, The resource type of the target profile.
US Core Profile Resource Type Target Profile Target Resource Type
US Core Pediatric Head Occipital Frontal Circumference Percentile Profile Observation US Core Patient Profile Patient
US Core Pediatric BMI for Age Observation Profile Observation US Core Patient Profile Patient
US Core Pediatric Weight for Height Observation Profile Observation US Core Patient Profile Patient
US Core AllergyIntolerance Profile AllergyIntolerance US Core Patient Profile Patient
US Core Blood Pressure Profile Observation US Core Patient Profile Patient
US Core BMI Profile Observation US Core Patient Profile Patient
US Core Body Height Profile Observation US Core Patient Profile Patient
US Core Body Temperature Profile Observation US Core Patient Profile Patient
US Core Body Weight Profile Observation US Core Patient Profile Patient
US Core CarePlan Profile CarePlan US Core Patient Profile Patient
US Core CareTeam Profile CareTeam US Core Patient Profile
US Core Practitioner Profile
US Core PractitionerRole Profile
US Core RelatedPerson Profile
Patient
Practitioner
PractitionerRole
RelatedPerson
US Core Condition Encounter Diagnosis Profile Condition US Core Patient Profile
US Core Encounter Profile
Patient
Encounter
US Core Condition Problems and Health Concerns Profile Condition US Core Patient Profile Patient
US Core Coverage Profile Coverage US Core Patient Profile
US Core Organization Profile
Patient
Organization
US Core DiagnosticReport Profile for Laboratory Results Reporting DiagnosticReport US Core Laboratory Result Observation Profile
US Core Patient Profile
US Core Practitioner Profile
Observation
Patient
Practitioner
US Core DiagnosticReport Profile for Report and Note Exchange DiagnosticReport Media
US Core Practitioner Profile
US Core Observation Clinical Result Profile
US Core Encounter Profile
US Core Patient Profile
US Core Laboratory Result Observation Profile
US Core Organization Profile
Media
Practitioner
Observation
Encounter
Patient
Observation
Organization
US Core DocumentReference Profile DocumentReference US Core Patient Profile
US Core Practitioner Profile
US Core Encounter Profile
Patient
Practitioner
Encounter
US Core Encounter Profile Encounter US Core Condition Encounter Diagnosis Profile
US Core Practitioner Profile
US Core Patient Profile
Location
US Core Organization Profile
US Core Condition Problems and Health Concerns Profile
Condition
Practitioner
Patient
Location
Organization
Condition
US Core Goal Profile Goal US Core Patient Profile Patient
US Core Head Circumference Profile Observation US Core Patient Profile Patient
US Core Heart Rate Profile Observation US Core Patient Profile Patient
US Core Immunization Profile Immunization US Core Patient Profile Patient
US Core Implantable Device Profile Device US Core Patient Profile Patient
US Core Location Profile Location US Core Organization Profile Organization
US Core Medication Profile Medication - -
US Core MedicationDispense Profile MedicationDispense US Core Practitioner Profile
US Core Medication Profile
US Core Patient Profile
US Core Organization Profile
US Core MedicationRequest Profile
Practitioner
Medication
Patient
Organization
MedicationRequest
US Core MedicationRequest Profile MedicationRequest US Core Practitioner Profile
US Core Medication Profile
US Core Encounter Profile
Condition
US Core Patient Profile
Observation
Practitioner
Medication
Encounter
Condition
Patient
Observation
US Core Observation Clinical Result Profile Observation US Core Patient Profile Patient
US Core Laboratory Result Observation Profile Observation US Core Specimen Profile
US Core Patient Profile
Specimen
Patient
US Core Observation Occupation Profile Observation US Core Patient Profile Patient
US Core Observation Pregnancy Intent Profile Observation US Core Patient Profile Patient
US Core Observation Pregnancy Status Profile Observation US Core Patient Profile Patient
US Core Observation Screening Assessment Profile Observation US Core Patient Profile
US Core Observation Screening Assessment Profile
US Core QuestionnaireResponse Profile
Patient
Observation
QuestionnaireResponse
US Core Observation Sexual Orientation Profile Observation US Core Patient Profile Patient
US Core Organization Profile Organization - -
US Core Patient Profile Patient - -
US Core Practitioner Profile Practitioner - -
US Core PractitionerRole Profile PractitionerRole US Core Practitioner Profile
Endpoint
HealthcareService
Location
US Core Organization Profile
Practitioner
Endpoint
HealthcareService
Location
Organization
US Core Procedure Profile Procedure US Core CarePlan Profile
US Core Patient Profile
US Core ServiceRequest Profile
CarePlan
Patient
ServiceRequest
US Core Provenance Profile Provenance US Core Organization Profile
Any Resource
Organization
Any Resource
US Core Pulse Oximetry Profile Observation US Core Patient Profile Patient
US Core QuestionnaireResponse Profile QuestionnaireResponse US Core Patient Profile
US Core Practitioner Profile
Patient
Practitioner
US Core RelatedPerson Profile RelatedPerson US Core Patient Profile Patient
US Core Respiratory Rate Profile Observation US Core Patient Profile Patient
US Core ServiceRequest Profile ServiceRequest DiagnosticReport
DocumentReference
US Core Practitioner Profile
Condition
US Core Patient Profile
Observation
DiagnosticReport
DocumentReference
Practitioner
Condition
Patient
Observation
US Core Simple Observation Profile Observation US Core Patient Profile Patient
US Core Smoking Status Observation Profile Observation US Core Patient Profile Patient
US Core Specimen Profile Specimen - -
US Core Vital Signs Profile Observation US Core Patient Profile Patient

AllergyIntolerance

Conformance Expectation: SHOULD

Supported Profiles:

Profile Interaction Summary:

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

Fetch and Search Criteria:

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

Search Parameter Summary:

Conformance Parameter Type
SHALL patient reference

Search Parameter Combination Summary:

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

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

Resource Specific Documentation:

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

Supported Profiles:

Profile Interaction Summary:

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

Fetch and Search Criteria:

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

Search Parameter Combination Summary:

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

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

Resource Specific Documentation:

In order to access care team member's names, identifiers, locations, and contact information, the CareTeam profile supports several types of care team participants. They are represented as references to other profiles and include the following four profiles which are marked as must support:

  1. US Core Practitioner Profile
  2. US Core PractitionerRole Profile
  3. US Core Patient Profile
  4. US Core RelatedPerson Profile
  • Although both US Core Practitioner Profile and US Core PractitionerRole are must support, the server system is not required to support both types of references (and _include search parameters), but SHALL support at least one of them.
  • The client application SHALL support all four profile references.
  • Bacause the US Core PractitionerRole Profile supplies the provider's location and contact information and a reference to the Practitioner, server systems SHOULD reference it instead of the US Core Practitioner Profile.
  • 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:

Profile Interaction Summary:

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

Fetch and Search Criteria:

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

Search Parameter Summary:

Conformance Parameter Type
SHOULD role token

Search Parameter Combination Summary:

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

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

Resource Specific Documentation:

  • For Encounter Diagnosis use the US Core Condition Encounter Diagnosis Profile.
    • When Condition.category is "encounter-diagnosis" the encounter, SHOULD be referenced in Condition.encounter.
  • For Problems and Health Concerns use the US Core Condition Problems and Health Concerns Profile.
    • When Condition.category is a "problems-list-item", the `Condition.clinicalStatus SHOULD NOT be unknown.
  • There is no single element in Condition that represents the date of diagnosis. It may be the assertedDate Extension, Condition.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 the 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:

Profile Interaction Summary:

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

Fetch and Search Criteria:

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

Search Parameter Summary:

Conformance Parameter Type
SHALL patient reference

Search Parameter Combination Summary:

Conformance Parameter Combination Types
SHOULD patient+ recorded-date reference+date
SHOULD patient+ asserted-date reference+date
SHOULD patient+ category+ clinical-status reference+token+token
SHOULD patient+ onset-date reference+date
SHOULD patient+ abatement-date reference+date
SHOULD patient+ clinical-status reference+token
SHOULD patient+ category+ encounter reference+token+reference
SHOULD patient+ code reference+token
SHALL patient+ category reference+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.

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


Coverage

Conformance Expectation: SHOULD

Supported Profiles:

Profile Interaction Summary:

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

Fetch and Search Criteria:

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

Search Parameter Summary:

Conformance Parameter Type
SHALL patient reference

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.


Device

Conformance Expectation: SHOULD

Resource Specific Documentation:

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

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

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

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

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

Supported Profiles:

Profile Interaction Summary:

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

Fetch and Search Criteria:

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

Search Parameter Summary:

Conformance Parameter Type
SHALL patient reference

Search Parameter Combination Summary:

Conformance Parameter Combination Types
SHOULD patient+ type reference+token
SHOULD patient+ status 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.

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


DiagnosticReport

Conformance Expectation: SHOULD

Supported Profiles:

Profile Interaction Summary:

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

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

Fetch and Search Criteria:

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

Search Parameter Summary:

Conformance Parameter Type
SHALL patient reference

Search Parameter Combination Summary:

Conformance Parameter Combination Types
SHOULD patient+ code+ date reference+token+date
SHOULD patient+ status reference+token
SHALL patient+ category+ date reference+token+date
SHALL patient+ category reference+token
SHALL patient+ code 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.

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

Resource Specific Documentation:

  • The DocumentReference.type binding SHALL support at a minimum the 5 Common Clinical Notes and may extend to the full US Core DocumentReference Type Value Set
  • The DocumentReference resources can represent the referenced content using either an address where the document can be retrieved using DocumentReference.attachment.url or the content as inline base64 encoded data using DocumentReference.attachment.data.
    • Although both are marked as must support, the server system is not required to support an address, and inline base64 encoded data, but SHALL support at least one of these elements.
    • The client application SHALL support both elements.
    • The content.url may refer to a FHIR Binary Resource (i.e. [base]/Binary/[id]), FHIR Document Bundle (i.e [base]/Bundle/[id] or another endpoint.
      • If the endpoint is outside the FHIR base URL, it SHOULD NOT require additional authorization to access.
  • 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:

Profile Interaction Summary:

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

Operation Summary:

  • SHOULD support the $docref operation

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

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

Fetch and Search Criteria:

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

Search Parameter Summary:

Conformance Parameter Type
SHALL _id token
SHALL patient reference

Search Parameter Combination Summary:

Conformance Parameter Combination Types
SHALL patient+ type reference+token
SHOULD patient+ status reference+token
SHOULD patient+ type+ period reference+token+date
SHALL patient+ category+ date reference+token+date
SHALL patient+ category 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: SHOULD

Resource Specific Documentation:

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

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

Supported Profiles:

Profile Interaction Summary:

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

Fetch and Search Criteria:

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

Search Parameter Summary:

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

Search Parameter Combination Summary:

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

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.


Endpoint

Conformance Expectation: SHOULD

Resource Specific Documentation:

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

Reference Policy

Profile Interaction Summary:

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

Fetch and Search Criteria:

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

Goal

Conformance Expectation: SHOULD

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:

Profile Interaction Summary:

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

Fetch and Search Criteria:

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

Search Parameter Summary:

Conformance Parameter Type
SHALL patient reference

Search Parameter Combination Summary:

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

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.


HealthcareService

Conformance Expectation: MAY

Resource Specific Documentation:

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

Reference Policy

Profile Interaction Summary:

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

Fetch and Search Criteria:

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

Immunization

Conformance Expectation: SHOULD

Resource Specific Documentation:

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

Supported Profiles:

Profile Interaction Summary:

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

Fetch and Search Criteria:

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

Search Parameter Summary:

Conformance Parameter Type
SHALL patient reference

Search Parameter Combination Summary:

Conformance Parameter Combination Types
SHOULD patient+ date reference+date
SHOULD patient+ status 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.

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

Resource Specific Documentation:

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

Supported Profiles:

Profile Interaction Summary:

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

Fetch and Search Criteria:

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

Search Parameter Summary:

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

Media

Conformance Expectation: SHOULD

Resource Specific Documentation:

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

Profile Interaction Summary:

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

Fetch and Search Criteria:

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

Medication

Conformance Expectation: SHOULD

Resource Specific Documentation:

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

Supported Profiles:

Profile Interaction Summary:

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

Fetch and Search Criteria:

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

MedicationDispense

Conformance Expectation: SHOULD

Resource Specific Documentation:

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

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

GET /MedicationDispense?patient=[id]

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

Supported Profiles:

Profile Interaction Summary:

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

Fetch and Search Criteria:

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

Search Parameter Summary:

Conformance Parameter Type
SHALL patient reference

Search Parameter Combination Summary:

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

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.

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

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


MedicationRequest

Conformance Expectation: SHOULD

Resource Specific Documentation:

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

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

GET /MedicationRequest?patient=[id]

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

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

Supported Profiles:

Profile Interaction Summary:

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

Fetch and Search Criteria:

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

Search Parameter Combination Summary:

Conformance Parameter Combination Types
SHOULD patient+ intent+ encounter reference+token+reference
SHALL patient+ intent+ status reference+token+token
SHOULD patient+ intent+ authoredon reference+token+date
SHALL patient+ intent 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.

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

Resource Specific Documentation:

  • Systems SHOULD support Observation.effectivePeriod to accurately represent tests that are collected over a period of time (for example, a 24-Hour Urine Collection test).
  • An Observation without a value, SHALL include a reason why the data is absent unless there are component observations, or references to other Observations that are grouped within it
    • Systems that never provide an observation without a value are not required to support Observation.dataAbsentReason
  • An Observation.component without a value, SHALL include a reason why the data is absent.
    • Systems that never provide an component observation without a component value are not required to support Observation.component.dataAbsentReason.
  • Systems SHOULD support Observation.effectivePeriod to accurately represent procedure tests that are collected over a period of time.

Supported Profiles:

Profile Interaction Summary:

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

Fetch and Search Criteria:

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

Search Parameter Combination Summary:

Conformance Parameter Combination Types
SHOULD patient+ code+ date reference+token+date
SHOULD patient+ category+ status reference+token+token
SHALL patient+ category+ date reference+token+date
SHALL patient+ category reference+token
SHALL patient+ code 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.

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

Resource Specific Documentation:

  • Systems SHALL support National Provider Identifier (NPI) for organizations and SHOULD support Clinical Laboratory Improvement Amendments (CLIA) identifiers for Organization.Identifier.

Supported Profiles:

Profile Interaction Summary:

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

Fetch and Search Criteria:

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

Search Parameter Summary:

Conformance Parameter Type
SHALL name string
SHALL address string

Patient

Conformance Expectation: SHOULD

Resource Specific Documentation:

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

    1. contact detail (e.g. a telephone number or an email address)
    2. a communication language
    3. a race
    4. an ethnicity
    5. a birth sex*
    6. previous name
      • Previous name is represented by providing an end date in the Patient.name.period element for a previous name.
    7. suffix
      • Suffix is represented using the Patient.name.suffix element.
  • The Patient's Social Security Numbers SHOULD NOT be used as a patient identifier in Patient.identifier.value.

Supported Profiles:

Profile Interaction Summary:

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

Fetch and Search Criteria:

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

Search Parameter Summary:

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

Search Parameter Combination Summary:

Conformance Parameter Combination Types
SHOULD birthdate+ family date+string
SHOULD family+ gender string+token
SHALL birthdate+ name date+string
SHALL gender+ name token+string
SHOULD death-date+ family date+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.

  • death-date (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: SHOULD

Resource Specific Documentation:

Servers that support only US Core Practitioner Profile SHALL provide implementation specific guidance how to access a provider’s location and contact information using only the Practitioner resource.

Supported Profiles:

Profile Interaction Summary:

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

Fetch and Search Criteria:

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

Search Parameter Summary:

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

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

Resource Specific Documentation:

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

Supported Profiles:

Profile Interaction Summary:

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

Fetch and Search Criteria:

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

Search Parameter Summary:

Conformance Parameter Type
SHALL specialty token
SHALL practitioner reference

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

Resource Specific Documentation:

  • Procedure codes can be taken from SNOMED-CT, CPT, HCPCS II, ICD-10-PCS, CDT. LOINC.
    • Only LOINC concepts that reflect actual procedures SHOULD be used
  • A procedure including an implantable device SHOULD use Procedure.focalDevice with a reference to the US Core Implantable Device Profile.

Supported Profiles:

Profile Interaction Summary:

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

Fetch and Search Criteria:

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

Search Parameter Summary:

Conformance Parameter Type
SHALL patient reference

Search Parameter Combination Summary:

Conformance Parameter Combination Types
SHOULD patient+ code+ date reference+token+date
SHOULD patient+ status reference+token
SHALL patient+ date reference+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: SHOULD

Resource Specific Documentation:

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

Supported Profiles:

Profile Interaction Summary:

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

Fetch and Search Criteria:

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

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 suport US Core Observation Screening Assessment Profile and SHOULD support the SDC Base Questionnaire Profile/US Core QuestionnaireResponse Profile

Supported Profiles:

Profile Interaction Summary:

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

Fetch and Search Criteria:

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

QuestionnaireResponse

Conformance Expectation: SHOULD

Resource Specific Documentation:

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

  • Observation: US Core Observation Screening Assessment Profile
  • Questionnaire/QuestionnaireResponse: SDC Base Questionnaire/US Core QuestionnaireResponse Profile

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

Supported Profiles:

Profile Interaction Summary:

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

Fetch and Search Criteria:

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

Search Parameter Summary:

Conformance Parameter Type
SHALL _id token
SHALL patient reference

Search Parameter Combination Summary:

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

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.

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

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


RelatedPerson

Conformance Expectation: SHOULD

Supported Profiles:

Profile Interaction Summary:

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

Fetch and Search Criteria:

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

Search Parameter Summary:

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

Search Parameter Combination Summary:

Conformance Parameter Combination Types
SHOULD patient+ name reference+string

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

Supported Profiles:

Profile Interaction Summary:

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

Fetch and Search Criteria:

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

Search Parameter Summary:

Conformance Parameter Type
SHALL patient reference
SHALL _id token

Search Parameter Combination Summary:

Conformance Parameter Combination Types
SHALL patient+ category+ authored reference+token+date
SHOULD patient+ status reference+token
SHALL patient+ category reference+token
SHOULD patient+ code+ authored reference+token+date
SHALL patient+ code 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.

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


Specimen

Conformance Expectation: SHOULD

Supported Profiles:

Profile Interaction Summary:

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

Fetch and Search Criteria:

  • A Client SHALL be capable of fetching a Specimen resource using: GET [base]/Specimen/[id]

Search Parameter Summary:

Conformance Parameter Type
SHALL _id token
SHOULD patient reference

ValueSet

Conformance Expectation: SHOULD

Operation Summary:

  • SHOULD support the $expand operation

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