US Core Implementation Guide
3.2.0 - ballot

This page is part of the US Core (v3.2.0: STU4 Ballot 1) based on FHIR R4. The current version which supercedes this version is 5.0.1. For a full list of available versions, see the Directory of published versions

CapabilityStatement: US Core Client CapabilityStatement

Raw OpenAPI-Swagger Definition file | Download

US Core Client CapabilityStatement

  • Implementation Guide Version: 3.1.1
  • FHIR Version: 4.0.1
  • Supported formats: xml, json
  • Published: 2020-11-20
  • Published by: HL7 International - US Realm Steering Committee

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

FHIR RESTful Capabilities

The US Core Client SHALL:

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

Security:

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

Summary of System Wide Interactions

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

RESTful Capabilities by Resource/Profile:

Summary of Search Criteria

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, patient+category+date, patient+category+status+date Provenance:target
CareTeam US Core CareTeam Profile patient, status patient+status Provenance:target
Condition US Core Condition Profile category, clinical-status, patient, onset-date, code patient+category, patient+code, patient+clinical-status, patient+onset-date 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+category, patient+status, patient+code+date, patient+code, patient+category+date Provenance:target
DocumentReference US Core DocumentReference Profile _id, status, patient, category, type, date, period patient+type, patient+type+period, patient+category, patient+status, patient+category+date Provenance:target docref
Encounter US Core Encounter Profile _id, class, date, identifier, patient, status, type date+patient, class+patient, patient+status, patient+type Provenance:target
Goal US Core Goal Profile lifecycle-status, patient, target-date patient+target-date, patient+lifecycle-status Provenance:target
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
Medication US Core Medication Profile
MedicationRequest US Core MedicationRequest Profile status, intent, patient, encounter, authoredon patient+intent+encounter, patient+intent+authoredon, patient+intent+status, patient+intent 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 Smoking Status Observation Profile status, category, code, date, patient patient+category, patient+category+status, patient+code+date, patient+code, patient+category+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+name, gender+name, birthdate+family Provenance:target
Practitioner US Core Practitioner Profile 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+code+date, patient+date Provenance:target
Provenance US Core Provenance Profile
ValueSet expand

AllergyIntolerance

Conformance Expectation: SHOULD

Supported Profiles: US Core AllergyIntolerance Profile

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 Documentation
SHOULD clinical-status token

TheTheThe server SHALL support both.
SHOULD patient reference

TheTheThe server SHALL support both.

Search Parameter Combination Summary:

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

CarePlan

Conformance Expectation: SHOULD

Supported Profiles: US Core CarePlan Profile

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

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

Conformance Parameter Type Documentation
SHOULD category token

TheTheThe server SHALL support both.
SHOULD date date

TheThe second + time offset.
SHOULD patient reference

TheTheThe server SHALL support both.
SHOULD status token

TheTheThe server SHALL support both.

Search Parameter Combination Summary:

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

CareTeam

Conformance Expectation: SHOULD

Supported Profiles: US Core CareTeam Profile

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 _revincludes: Provenance:target - GET [base]/CareTeam?[parameter=value]&_revinclude=Provenance:target

Search Parameter Summary:

Conformance Parameter Type Documentation
SHOULD patient reference

TheTheThe server SHALL support both.
SHOULD status token

TheTheThe server SHALL support both.

Search Parameter Combination Summary:

Conformance Parameter Combination Types
SHOULD patient+status reference+token

Condition

Conformance Expectation: SHOULD

Supported Profiles: US Core Condition Profile

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 Documentation
SHOULD category token

TheTheThe server SHALL support both.
SHOULD clinical-status token

TheTheThe server SHALL support both.
SHOULD patient reference

TheTheThe server SHALL support both.
SHOULD onset-date date

TheThe second + time offset.
SHOULD code token

TheTheThe server SHALL support both.

Search Parameter Combination Summary:

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

Device

Conformance Expectation: SHOULD

Supported Profiles: US Core Implantable Device Profile

Resource Specific Documentation:

  • Implantable medical devices that have UDI information SHALL represent this information in either carrierAIDC or carrierHRF.

    • UDI may not be present in all scenarios such as historical implantable devices, patient reported implant information, payer reported devices, or improperly documented implants.
    • Servers are not required to support both carrierAIDC and carrierHR.

  • For Implantable medical devices that have UDI information, at least one of the Production Identifiers (UDI-PI) SHALL be present.

  • 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

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 Documentation
SHOULD patient reference

TheTheThe server SHALL support both.
SHOULD type token

TheTheThe server SHALL support both.

Search Parameter Combination Summary:

Conformance Parameter Combination Types
SHOULD patient+type reference+token

DiagnosticReport

Conformance Expectation: SHOULD

Supported Profiles: US Core DiagnosticReport Profile for Laboratory Results Reporting, US Core DiagnosticReport Profile for Report and Note exchange

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 Documentation
SHOULD status token

TheTheThe server SHALL support both.
SHOULD patient reference

TheTheThe server SHALL support both.
SHOULD category token

TheTheThe server SHALL support both.
SHOULD code token

TheTheThe server SHALL support both.
SHOULD date date

TheThe second + time offset.

Search Parameter Combination Summary:

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

DocumentReference

Conformance Expectation: SHOULD

Supported Profiles: US Core DocumentReference Profile

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

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 Documentation
SHOULD _id token -
SHOULD status token

TheTheThe server SHALL support both.
SHOULD patient reference

TheTheThe server SHALL support both.
SHOULD category token

TheTheThe server SHALL support both.
SHOULD type token

TheTheThe server SHALL support both.
SHOULD date date

TheThe second + time offset.
SHOULD period date

TheThe second + time offset.

Search Parameter Combination Summary:

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

Encounter

Conformance Expectation: SHOULD

Supported Profiles: US Core Encounter Profile

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]

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 Documentation
SHOULD _id token -
SHOULD class token

TheTheThe server SHALL support both.
SHOULD date date

TheThe second + time offset.
SHOULD identifier token

TheTheThe server SHALL support both.
SHOULD patient reference

TheTheThe server SHALL support both.
SHOULD status token

TheTheThe server SHALL support both.
SHOULD type token

TheTheThe server SHALL support both.

Search Parameter Combination Summary:

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

Goal

Conformance Expectation: SHOULD

Supported Profiles: US Core Goal Profile

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 Documentation
SHOULD lifecycle-status token

TheTheThe server SHALL support both.
SHOULD patient reference

TheTheThe server SHALL support both.
SHOULD target-date date

TheThe second + time offset.

Search Parameter Combination Summary:

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

Immunization

Conformance Expectation: SHOULD

Supported Profiles: US Core Immunization Profile

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.

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 Documentation
SHOULD patient reference

TheTheThe server SHALL support both.
SHOULD status token

TheTheThe server SHALL support both.
SHOULD date date

TheThe second + time offset.

Search Parameter Combination Summary:

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

Location

Conformance Expectation: SHOULD

Supported Profiles: US Core Location Profile

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.

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 Documentation
SHOULD name string -
SHOULD address string -
SHOULD address-city string -
SHOULD address-state string -
SHOULD address-postalcode string -

Medication

Conformance Expectation: SHOULD

Supported Profiles: US Core Medication Profile

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.

Profile Interaction Summary:

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

Fetch and Search Criteria:

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

MedicationRequest

Conformance Expectation: SHOULD

Supported Profiles: US Core MedicationRequest Profile

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.

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

Conformance Parameter Type Documentation
SHOULD status token

TheTheThe server SHALL support both.
SHOULD intent token

TheTheThe server SHALL support both.
SHOULD patient reference

TheTheThe server SHALL support both.
SHOULD encounter reference

TheTheThe server SHALL support both.
SHOULD authoredon date

TheThe second + time offset.

Search Parameter Combination Summary:

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

Observation

Conformance Expectation: SHOULD

Supported Profiles: 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 Smoking Status Observation Profile

Resource Specific Documentation:

  • Systems SHOULD support Observation.effectivePeriod to accurately represent laboratory 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.

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

Conformance Parameter Type Documentation
SHOULD status token

TheTheThe server SHALL support both.
SHOULD category token

TheTheThe server SHALL support both.
SHOULD code token

TheTheThe server SHALL support both.
SHOULD date date

TheThe second + time offset.
SHOULD patient reference

TheTheThe server SHALL support both.

Search Parameter Combination Summary:

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

Organization

Conformance Expectation: SHOULD

Supported Profiles: US Core Organization Profile

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 Documentation
SHOULD name string -
SHOULD address string -

Patient

Conformance Expectation: SHOULD

Supported Profiles: US Core Patient Profile

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.

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 Documentation
SHOULD _id token -
SHOULD birthdate date

The day.
SHOULD family string

The day.
SHOULD gender token

TheTheThe server SHALL support both.
SHOULD given string -
SHOULD identifier token

TheTheThe server SHALL support both.
SHOULD name string -

Search Parameter Combination Summary:

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

Practitioner

Conformance Expectation: SHOULD

Supported Profiles: US Core Practitioner Profile

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 Documentation
SHOULD name string -
SHOULD identifier token

TheTheThe server SHALL support both.

PractitionerRole

Conformance Expectation: SHOULD

Supported Profiles: US Core PractitionerRole Profile

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.

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 Documentation
SHOULD specialty token

TheTheThe server SHALL support both.
SHOULD practitioner reference

TheTheThe server SHALL support both.

Procedure

Conformance Expectation: SHOULD

Supported Profiles: US Core Procedure Profile

Resource Specific Documentation:

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

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 Documentation
SHOULD status token

TheTheThe server SHALL support both.
SHOULD patient reference

TheTheThe server SHALL support both.
SHOULD date date

TheThe second + time offset.
SHOULD code token

TheTheThe server SHALL support both.

Search Parameter Combination Summary:

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

Provenance

Conformance Expectation: SHOULD

Supported Profiles: US Core Provenance Profile

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.

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]

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.