US Core Implementation Guide
9.0.0 - STU 9 United States of America flag

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

CapabilityStatement: US Core Client CapabilityStatement

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

This CapabilityStatement 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 US Core CapabilityStatement. 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

Support and Requirements for Other Artifacts

Supports other guides:

FHIR Client 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 narrative requirements documented in the:

    • Conformance pages
    • Guidance pages
    • Profile Specific Implementation Guidance for each Profile that the US Core Client supports.

    The Client Requirements Table and US Core Client Requirements Resource list the requirements defined in these pages and sections.

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

  • multipleAnd
  • multipleOr
  • comparator
  • modifier
  • chain

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


Security:

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

System-wide Client Capabilities

Interactions

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

Summary of Resource/Profile Capabilities

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

RESTful Client Capabilities by Resource/Profile:

AllergyIntolerance

Conformance Expectation: SHOULD

Supported Profiles:

FHIR RESTful Interactions

Summary:

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

Modify Criteria Details:

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

Fetch and Search Criteria Details:

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

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

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

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

  • patient (Reference):

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

CarePlan

Conformance Expectation: SHOULD

Supported Profiles:

FHIR RESTful Interactions

Summary:

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

Modify Criteria Details:

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

Fetch and Search Criteria Details:

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

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

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

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

    The server SHALL support both.

  • date (Date/DateTime):

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

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

  • patient (Reference):

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

    The server SHALL support both.

  • status (Token):

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

    The server SHALL support both.

CareTeam

Conformance Expectation: SHOULD

Supported Profiles:

FHIR RESTful Interactions

Summary:

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

Modify Criteria Details:

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

Fetch and Search Criteria Details:

  • A Client SHALL be capable of a search-type interaction fetching CareTeam resources matching a search query using: GET [base]/CareTeam/[id]{?[parameters]{&_format=[mime-type]}}
  • A Client SHALL be capable of a read interaction fetching a CareTeam resource using: GET [base]/CareTeam/[id]
  • A Client SHOULD be capable of a vread interaction fetching a CareTeam resource using: GET [base]/CareTeam/[id]/_history/vid
  • A Client SHOULD be capable of a history-instance interaction fetching a history of a CareTeam using: GET [base]/CareTeam/[id]/_history{?[parameters]&_format=[mime-type]}
  • A Client MAY be capable of a history-type interaction fetching the history of CareTeam resources using: GET [base]/CareTeam/_history{?[parameters]&_format=[mime-type]}
  • 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 Requirements (When Used Alone or in Combination):

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

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

    The server SHALL support both.

  • role (Token):

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

    The server SHALL support both.

  • status (Token):

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

    The server SHALL support both.

Condition

Conformance Expectation: SHOULD

Supported Profiles:

FHIR RESTful Interactions

Summary:

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

Modify Criteria Details:

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

Fetch and Search Criteria Details:

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

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

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

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

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

  • asserted-date (Date/DateTime):

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

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

  • category (Token):

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

    The server SHALL support both.

  • clinical-status (Token):

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

    The server SHALL support both.

  • code (Token):

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

    The server SHALL support both.

  • encounter (Reference):

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

    The server SHALL support both.

  • onset-date (Date/DateTime):

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

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

  • patient (Reference):

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

    The server SHALL support both.

  • recorded-date (Date/DateTime):

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

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

  • _lastUpdated (Date/DateTime):

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

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

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

Coverage

Conformance Expectation: SHOULD

Supported Profiles:

FHIR RESTful Interactions

Summary:

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

Modify Criteria Details:

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

Fetch and Search Criteria Details:

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

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

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

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

    The server SHALL support both.

Device

Conformance Expectation: SHOULD

Supported Profiles:

FHIR RESTful Interactions

Summary:

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

Modify Criteria Details:

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

Fetch and Search Criteria Details:

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

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

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

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

    The server SHALL support both.

  • status (Token):

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

    The server SHALL support both.

  • type (Token):

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

    The server SHALL support both.

DiagnosticReport

Conformance Expectation: SHOULD

Supported Profiles:

FHIR RESTful Interactions

Summary:

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

Modify Criteria Details:

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

Fetch and Search Criteria Details:

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

create

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


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

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

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

    The server SHALL support both.

  • code (Token):

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

    The server SHALL support both.

  • date (Date/DateTime):

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

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

  • _lastUpdated (Date/DateTime):

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

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

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

  • patient (Reference):

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

    The server SHALL support both.

  • status (Token):

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

    The server SHALL support both.

DocumentReference

Conformance Expectation: SHOULD

Supported Profiles:

FHIR RESTful Interactions

Summary:

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

Modify Criteria Details:

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

Fetch and Search Criteria Details:

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

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

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

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

    The server SHALL support both.

  • date (Date/DateTime):

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

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

  • patient (Reference):

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

    The server SHALL support both.

  • period (Date/DateTime):

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

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

  • status (Token):

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

    The server SHALL support both.

  • type (Token):

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

    The server SHALL support both.

FHIR Operations:

$docref:

A 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]

Encounter

Conformance Expectation: SHOULD

Supported Profiles:

FHIR RESTful Interactions

Summary:

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

Modify Criteria Details:

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

Fetch and Search Criteria Details:

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

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

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

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

    The server SHALL support both.

  • date (Date/DateTime):

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

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

  • _lastUpdated (Date/DateTime):

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

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

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

  • discharge-disposition (Token):

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

    The server SHALL support both.

  • identifier (Token):

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

    The server SHALL support both.

  • location (Reference):

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

    The server SHALL support both.

  • patient (Reference):

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

    The server SHALL support both.

  • status (Token):

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

    The server SHALL support both.

  • type (Token):

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

    The server SHALL support both.

Endpoint

Conformance Expectation: SHOULD

Resource Specific Documentation:

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

FHIR RESTful Interactions

Summary:

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

Modify Criteria Details:

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

Fetch and Search Criteria Details:

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

FamilyMemberHistory

Conformance Expectation: SHOULD

Supported Profiles:

FHIR RESTful Interactions

Summary:

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

Modify Criteria Details:

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

Fetch and Search Criteria Details:

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

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

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

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

    The server SHALL support both.

  • code (Token):

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

    The server SHALL support both.

Goal

Conformance Expectation: SHOULD

Supported Profiles:

FHIR RESTful Interactions

Summary:

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

Modify Criteria Details:

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

Fetch and Search Criteria Details:

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

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

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

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

    The server SHALL support both.

  • patient (Reference):

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

    The server SHALL support both.

  • target-date (Date/DateTime):

    A client SHALL provide a value precise to the day.

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

HealthcareService

Conformance Expectation: MAY

Resource Specific Documentation:

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

FHIR RESTful Interactions

Summary:

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

Modify Criteria Details:

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

Fetch and Search Criteria Details:

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

Immunization

Conformance Expectation: SHOULD

Supported Profiles:

FHIR RESTful Interactions

Summary:

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

Modify Criteria Details:

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

Fetch and Search Criteria Details:

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

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

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

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

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

  • patient (Reference):

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

    The server SHALL support both.

  • status (Token):

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

    The server SHALL support both.

Location

Conformance Expectation: SHOULD

Supported Profiles:

FHIR RESTful Interactions

Summary:

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

Modify Criteria Details:

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

Fetch and Search Criteria Details:

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

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

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

Medication

Conformance Expectation: SHOULD

Supported Profiles:

FHIR RESTful Interactions

Summary:

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

Modify Criteria Details:

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

Fetch and Search Criteria Details:

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

MedicationDispense

Conformance Expectation: SHOULD

Supported Profiles:

FHIR RESTful Interactions

Summary:

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

Modify Criteria Details:

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

Fetch and Search Criteria Details:

  • A Client SHALL be capable of a search-type interaction fetching MedicationDispense resources matching a search query using: GET [base]/MedicationDispense/[id]{?[parameters]{&_format=[mime-type]}}
  • A Client SHALL be capable of a read interaction fetching a MedicationDispense resource using: GET [base]/MedicationDispense/[id]
  • A Client SHOULD be capable of a vread interaction fetching a MedicationDispense resource using: GET [base]/MedicationDispense/[id]/_history/vid
  • A Client SHOULD be capable of a history-instance interaction fetching a history of a MedicationDispense using: GET [base]/MedicationDispense/[id]/_history{?[parameters]&_format=[mime-type]}
  • A Client MAY be capable of a history-type interaction fetching the history of MedicationDispense resources using: GET [base]/MedicationDispense/_history{?[parameters]&_format=[mime-type]}
  • 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 Requirements (When Used Alone or in Combination):

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

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

    The server SHALL support both.

  • status (Token):

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

    The server SHALL support both.

  • type (Token):

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

    The server SHALL support both.

MedicationRequest

Conformance Expectation: SHOULD

Supported Profiles:

FHIR RESTful Interactions

Summary:

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

Modify Criteria Details:

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

Fetch and Search Criteria Details:

  • A Client SHALL be capable of a search-type interaction fetching MedicationRequest resources matching a search query using: GET [base]/MedicationRequest/[id]{?[parameters]{&_format=[mime-type]}}
  • A Client SHALL be capable of a read interaction fetching a MedicationRequest resource using: GET [base]/MedicationRequest/[id]
  • A Client SHOULD be capable of a vread interaction fetching a MedicationRequest resource using: GET [base]/MedicationRequest/[id]/_history/vid
  • A Client SHOULD be capable of a history-instance interaction fetching a history of a MedicationRequest using: GET [base]/MedicationRequest/[id]/_history{?[parameters]&_format=[mime-type]}
  • A Client MAY be capable of a history-type interaction fetching the history of MedicationRequest resources using: GET [base]/MedicationRequest/_history{?[parameters]&_format=[mime-type]}
  • 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 Requirements (When Used Alone or in Combination):

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

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

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

  • encounter (Reference):

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

    The server SHALL support both.

  • intent (Token):

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

    The server SHALL support both.

  • patient (Reference):

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

    The server SHALL support both.

  • status (Token):

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

    The server SHALL support both.

Observation

Conformance Expectation: SHOULD

Supported Profiles:

FHIR RESTful Interactions

Summary:

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

Modify Criteria Details:

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

Fetch and Search Criteria Details:

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

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

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

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

    The server SHALL support both.

  • code (Token):

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

    The server SHALL support both.

  • date (Date/DateTime):

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

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

  • _lastUpdated (Date/DateTime):

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

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

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

  • patient (Reference):

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

    The server SHALL support both.

  • status (Token):

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

    The server SHALL support both.

Organization

Conformance Expectation: SHOULD

Supported Profiles:

FHIR RESTful Interactions

Summary:

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

Modify Criteria Details:

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

Fetch and Search Criteria Details:

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

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

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

Patient

Conformance Expectation: SHOULD

Supported Profiles:

FHIR RESTful Interactions

Summary:

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

Modify Criteria Details:

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

Fetch and Search Criteria Details:

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

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

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

    A client SHALL provide a value precise to the day.

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

  • death-date (Date/DateTime):

    A client SHALL provide a value precise to the day.

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

  • identifier (Token):

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

    The server SHALL support both.

Practitioner

Conformance Expectation: SHOULD

Supported Profiles:

FHIR RESTful Interactions

Summary:

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

Modify Criteria Details:

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

Fetch and Search Criteria Details:

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

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

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

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

    The server SHALL support both.

PractitionerRole

Conformance Expectation: SHOULD

Supported Profiles:

FHIR RESTful Interactions

Summary:

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

Modify Criteria Details:

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

Fetch and Search Criteria Details:

  • A Client SHALL be capable of a search-type interaction fetching PractitionerRole resources matching a search query using: GET [base]/PractitionerRole/[id]{?[parameters]{&_format=[mime-type]}}
  • A Client SHALL be capable of a read interaction fetching a PractitionerRole resource using: GET [base]/PractitionerRole/[id]
  • A Client SHOULD be capable of a vread interaction fetching a PractitionerRole resource using: GET [base]/PractitionerRole/[id]/_history/vid
  • A Client SHOULD be capable of a history-instance interaction fetching a history of a PractitionerRole using: GET [base]/PractitionerRole/[id]/_history{?[parameters]&_format=[mime-type]}
  • A Client MAY be capable of a history-type interaction fetching the history of PractitionerRole resources using: GET [base]/PractitionerRole/_history{?[parameters]&_format=[mime-type]}
  • 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 Requirements (When Used Alone or in Combination):

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

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

    The server SHALL support both.

  • specialty (Token):

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

    The server SHALL support both.

Procedure

Conformance Expectation: SHOULD

Supported Profiles:

FHIR RESTful Interactions

Summary:

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

Modify Criteria Details:

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

Fetch and Search Criteria Details:

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

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

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

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

    The server SHALL support both.

  • date (Date/DateTime):

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

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

  • patient (Reference):

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

    The server SHALL support both.

  • status (Token):

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

    The server SHALL support both.

Provenance

Conformance Expectation: SHOULD

Supported Profiles:

FHIR RESTful Interactions

Summary:

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

Modify Criteria Details:

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

Fetch and Search Criteria Details:

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

Questionnaire

Conformance Expectation: SHOULD

Resource Specific Documentation:

  • US Core defines two ways to represent the questions and responses to screening and assessment instruments:
    • Observation: US Core Observation Screening Assessment Profile
    • Questionnaire/QuestionnaireResponse: SDC Base Questionnaire/US Core QuestionnaireResponse Profile
  • US Core Servers SHALL support US Core Observation Screening Assessment Profile and SHOULD support the SDC Base Questionnaire Profile/US Core QuestionnaireResponse Profile

Supported Profiles:

FHIR RESTful Interactions

Summary:

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

Modify Criteria Details:

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

Fetch and Search Criteria Details:

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

QuestionnaireResponse

Conformance Expectation: SHOULD

Supported Profiles:

FHIR RESTful Interactions

Summary:

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

Modify Criteria Details:

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

Fetch and Search Criteria Details:

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

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

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

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

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

  • patient (Reference):

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

    The server SHALL support both.

  • questionnaire (Reference):

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

    The server SHALL support both.

  • status (Token):

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

    The server SHALL support both.

RelatedPerson

Conformance Expectation: SHOULD

Supported Profiles:

FHIR RESTful Interactions

Summary:

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

Modify Criteria Details:

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

Fetch and Search Criteria Details:

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

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

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

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

    The server SHALL support both.

ServiceRequest

Conformance Expectation: SHOULD

Supported Profiles:

FHIR RESTful Interactions

Summary:

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

Modify Criteria Details:

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

Fetch and Search Criteria Details:

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

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

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

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

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

  • category (Token):

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

    The server SHALL support both.

  • code (Token):

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

    The server SHALL support both.

  • patient (Reference):

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

    The server SHALL support both.

  • status (Token):

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

    The server SHALL support both.

Specimen

Conformance Expectation: SHOULD

Supported Profiles:

FHIR RESTful Interactions

Summary:

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

Modify Criteria Details:

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

Fetch and Search Criteria Details:

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

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

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

ValueSet

Conformance Expectation: SHOULD

FHIR Operations:

$expand:

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