# publisher
HL7 International - US Realm Steering Committee

# description
This Capability Statement describes the features of the US Core Server which is responsible for providing responses to the queries submitted by the US Core Requestors. The complete list of FHIR profiles, RESTful operations, and search parameters supported by this server are defined. Systems implementing this capability statement should meet the ONC 2015 Common Clinical Data Set (CCDS) access requirement for Patient Selection 170.315(g)(7) and Application Access - Data Category Request 170.315(g)(8) and and the ONC [U.S. Core Data for Interoperability (USCDI)](https://www.healthit.gov/isa/sites/isa/files/2020-03/USCDI-Version1-2020-Final-Standard.pdf).  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. In the context of the CMS Interoperability and Patient Access Rule this implementation of US Core only supports Read and Search capabilities to enable consumer applications to request data for a health plan member that has granted them access to their data.

# rest[].documentation
The US Core Server **SHALL**:

1. Support the US Core Patient resource profile.
1. Support at least one additional resource profile from the list of US Core Profiles.
1. Implement the RESTful behavior according to the FHIR specification.
1. Follow the requirements documented in the [General Requirements](general-requirements.html) and [Must Support](must-support.html) pages
1. Return the following response classes:
   - (Status 400): invalid parameter
   - (Status 401/4xx): unauthorized request
   - (Status 403): insufficient scopes
   - (Status 404): unknown resource
1. Support JSON source formats for all US Core interactions.

The US Core Server **SHOULD**:

1. Follow the guidance documented in the [General Guidance](general-guidance.html) page
1. Support XML source formats for all US Core interactions.
1. Identify the US Core profiles supported as part of the FHIR `meta.profile` attribute for each instance.

# rest[].security.description
1. See the [General Security Considerations](security.html) section for requirements and recommendations.
1. A server **SHALL** reject any unauthorized requests by returning an `HTTP 401` unauthorized response code.

# rest[].resource[].searchParam[].documentation
The client **SHALL** provide at least a code value and **MAY** provide both the system and code values.

The server **SHALL** support both.

# rest[].resource[].searchParam[].documentation
The client **SHALL** provide at least a id value and **MAY** provide both the Type and id values.

The server **SHALL** support both.

# rest[].resource[].documentation
* Additional considerations for systems aligning with [HL7 Consolidated (C-CDA)](http://www.hl7.org/implement/standards/product_brief.cfm?product_id=492) 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

# rest[].resource[].searchParam[].documentation
The client **SHALL** provide at least a code value and **MAY** provide both the system and code values.

The server **SHALL** support both.

# rest[].resource[].searchParam[].documentation
A client **SHALL** provide a value precise to the *second + time offset*.

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

# rest[].resource[].searchParam[].documentation
The client **SHALL** provide at least a id value and **MAY** provide both the Type and id values.

The server **SHALL** support both.

# rest[].resource[].searchParam[].documentation
The client **SHALL** provide at least a code value and **MAY** provide both the system and code values.

The server **SHALL** support both.

# rest[].resource[].documentation
In order to access care team member's names, identifiers, locations, and contact information, the CareTeam profile supports several types of care team participants. They are represented as references to other profiles and include the following four profiles which are marked as must support:
  1. US Core Practitioner Profile
  1. US Core PractitionerRole Profile
  1. US Core Patient Profile
  1. US Core RelatedPerson Profile

  * Although *both* US Core Practitioner Profile and US Core PractitionerRole are must support, the server system is not required to support both types of references (and `_include` search parameters), but **SHALL** support *at least* one of them.
  * The client application **SHALL** support all four profile references.
  * Bacause the *US Core PractitionerRole Profile* supplies the provider's location and contact information and a reference to the Practitioner, server systems **SHOULD** reference it instead of the *US Core Practitioner Profile*.
  * Servers that supports only *US Core Practitioner Profile* **SHALL** provide implementation specific guidance how to access a provider's location and contact information using only the Practitioner resource.

# rest[].resource[].searchParam[].documentation
The client **SHALL** provide at least a id value and **MAY** provide both the Type and id values.

The server **SHALL** support both.

# rest[].resource[].searchParam[].documentation
The client **SHALL** provide at least a code value and **MAY** provide both the system and code values.

The server **SHALL** support both.

# rest[].resource[].searchParam[].documentation
The client **SHALL** provide at least a code value and **MAY** provide both the system and code values.

The server **SHALL** support both.

# rest[].resource[].documentation
* For Encounter Diagnosis use the *US Core Condition Encounter Diagnosis Profile*.
    * When `Condition.category` is "encounter-diagnosis" the encounter, **SHOULD** be referenced in `Condition.encounter`.
* For Problems and Health Concerns use the *US Core Condition Problems and Health Concerns Profile*.
    * When `Condition.category` is a "problems-list-item", the `Condition.clinicalStatus **SHOULD NOT** be unknown.
* There is no single element in Condition that represents the date of diagnosis. It may be the assertedDate Extension, `Condition.onsetDate`, or `Condition.recordedDate`.
    * Although all three are marked as must support, the server is not required to support all.
	* A server **SHALL** support `Condition.recordedDate`.
    * A server **SHALL** support at least one of [assertedDate Extension] and `Condition.onsetDate`. A server may support both, which means they support all 3 locations.
    * The client application **SHALL** support all three elements.

# rest[].resource[].searchParam[].documentation
The client **SHALL** provide at least a code value and **MAY** provide both the system and code values.

The server **SHALL** support both.

# rest[].resource[].searchParam[].documentation
The client **SHALL** provide at least a code value and **MAY** provide both the system and code values.

The server **SHALL** support both.

# rest[].resource[].searchParam[].documentation
The client **SHALL** provide at least a id value and **MAY** provide both the Type and id values.

The server **SHALL** support both.

# rest[].resource[].searchParam[].documentation
A client **SHALL** provide a value precise to the *second + time offset*.

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

# rest[].resource[].searchParam[].documentation
A client **SHALL** provide a value precise to the *second + time offset*.

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

# rest[].resource[].searchParam[].documentation
A client **SHALL** provide a value precise to the *second + time offset*.

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

# rest[].resource[].searchParam[].documentation
A client **SHALL** provide a value precise to the *second + time offset*.

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

# rest[].resource[].searchParam[].documentation
The client **SHALL** provide at least a code value and **MAY** provide both the system and code values.

The server **SHALL** support both.

# rest[].resource[].searchParam[].documentation
The client **SHALL** provide at least a id value and **MAY** provide both the Type and id values.

The server **SHALL** support both.

# rest[].resource[].interaction[].documentation
Implemented per the specification (or Insert other doco here)

# rest[].resource[].interaction[].documentation
Implemented per the specification (or Insert other doco here)

# rest[].resource[].interaction[].documentation
Implemented per the specification (or Insert other doco here)

# rest[].resource[].interaction[].documentation
Implemented per the specification (or Insert other doco here)

# rest[].resource[].interaction[].documentation
Implemented per the specification (or Insert other doco here)

# rest[].resource[].searchParam[].documentation
The business identifier of the Eligibility

# rest[].resource[].searchParam[].documentation
The party who is responsible for the request

# rest[].resource[].searchParam[].documentation
Facility responsible for the goods and services

# rest[].resource[].interaction[].documentation
Implemented per the specification (or Insert other doco here)

# rest[].resource[].interaction[].documentation
Implemented per the specification (or Insert other doco here)

# rest[].resource[].interaction[].documentation
Implemented per the specification (or Insert other doco here)

# rest[].resource[].interaction[].documentation
Implemented per the specification (or Insert other doco here)

# rest[].resource[].interaction[].documentation
Implemented per the specification (or Insert other doco here)

# rest[].resource[].searchParam[].documentation
The organization which generated this resource

# rest[].resource[].documentation
* Implantable medical devices that have UDI information **SHALL** represent the UDI code in `Device.udiCarrier.carrierHRF`.
   - All of the five UDI-PI elements that are present in the UDI code **SHALL** be represented in the corresponding US Core Implantable Device Profile element.
   
   UDI may not be present in all scenarios such as historical implantable devices, patient reported implant information, payer reported devices, or improperly documented implants. If UDI is not present and the manufacturer and/or model number information is available, they **SHOULD** be included to support historical reports of implantable medical devices as follows:

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

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

# rest[].resource[].searchParam[].documentation
The client **SHALL** provide at least a id value and **MAY** provide both the Type and id values.

The server **SHALL** support both.

# rest[].resource[].searchParam[].documentation
The client **SHALL** provide at least a code value and **MAY** provide both the system and code values.

The server **SHALL** support both.

# rest[].resource[].interaction[].documentation
Implemented per the specification (or Insert other doco here)

# rest[].resource[].interaction[].documentation
Implemented per the specification (or Insert other doco here)

# rest[].resource[].interaction[].documentation
Implemented per the specification (or Insert other doco here)

# rest[].resource[].interaction[].documentation
Implemented per the specification (or Insert other doco here)

# rest[].resource[].interaction[].documentation
Implemented per the specification (or Insert other doco here)

# rest[].resource[].interaction[].documentation
Implemented per the specification (or Insert other doco here)

# rest[].resource[].interaction[].documentation
Implemented per the specification (or Insert other doco here)

# rest[].resource[].interaction[].documentation
Implemented per the specification (or Insert other doco here)

# rest[].resource[].interaction[].documentation
Implemented per the specification (or Insert other doco here)

# rest[].resource[].interaction[].documentation
Implemented per the specification (or Insert other doco here)

# rest[].resource[].interaction[].documentation
Implemented per the specification (or Insert other doco here)

# rest[].resource[].interaction[].documentation
Implemented per the specification (or Insert other doco here)

# rest[].resource[].interaction[].documentation
Implemented per the specification (or Insert other doco here)

# rest[].resource[].interaction[].documentation
Implemented per the specification (or Insert other doco here)

# rest[].resource[].interaction[].documentation
Implemented per the specification (or Insert other doco here)

# rest[].resource[].searchParam[].documentation
Code for what is being requested/ordered

# rest[].resource[].searchParam[].documentation
Instantiates FHIR protocol or definition

# rest[].resource[].searchParam[].documentation
Encounter during which request was created

# rest[].resource[].searchParam[].documentation
When the request transitioned to being actionable

# rest[].resource[].searchParam[].documentation
proposal | plan | original-order |reflex-order

# rest[].resource[].searchParam[].documentation
Plan/proposal/order fulfilled by this request

# rest[].resource[].searchParam[].documentation
Instantiates external protocol or definition

# rest[].resource[].searchParam[].documentation
Request takes the place of referenced completed or terminated requests

# rest[].resource[].searchParam[].documentation
Reference to resource that is being requested/ordered

# rest[].resource[].searchParam[].documentation
entered-in-error | draft | active |suspended | completed

# rest[].resource[].interaction[].documentation
Implemented per the specification (or Insert other doco here)

# rest[].resource[].interaction[].documentation
Implemented per the specification (or Insert other doco here)

# rest[].resource[].interaction[].documentation
Implemented per the specification (or Insert other doco here)

# rest[].resource[].interaction[].documentation
Implemented per the specification (or Insert other doco here)

# rest[].resource[].interaction[].documentation
Implemented per the specification (or Insert other doco here)

# rest[].resource[].searchParam[].documentation
The client **SHALL** provide at least a code value and **MAY** provide both the system and code values.

The server **SHALL** support both.

# rest[].resource[].searchParam[].documentation
The client **SHALL** provide at least a id value and **MAY** provide both the Type and id values.

The server **SHALL** support both.

# rest[].resource[].searchParam[].documentation
The client **SHALL** provide at least a code value and **MAY** provide both the system and code values.

The server **SHALL** support both.

# rest[].resource[].searchParam[].documentation
The client **SHALL** provide at least a code value and **MAY** provide both the system and code values.

The server **SHALL** support both.

# rest[].resource[].searchParam[].documentation
A client **SHALL** provide a value precise to the *second + time offset*.

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

# rest[].resource[].documentation
* The `DocumentReference.type` binding **SHALL** support at a minimum the [5 Common Clinical Notes](ValueSet-us-core-clinical-note-type.html) and may extend to the full US Core DocumentReference Type Value Set
* The DocumentReference resources can represent the referenced content using either an address where the document can be retrieved using `DocumentReference.attachment.url` or the content as inline base64 encoded data using `DocumentReference.attachment.data`.
    *  Although both are marked as must support, the server system is not required to support both an address and inline base64 encoded data, but **SHALL** support at least one of these elements.
    *  The client application **SHALL** support both elements.
    *  The `content.url` may refer to a FHIR Binary Resource (i.e. [base]/Binary/[id]), FHIR Document Bundle (i.e [base]/Bundle/[id] or other endpoint.
        * If the endpoint is outside of the FHIR base URL, it **SHOULD NOT** require additional authorization to access.
* The organization responsible for the DocumentReference **SHALL** be present either in `DocumentReference.custodian` or accessible in the Provenance resource targeting the DocumentReference using `Provenance.agent.who` or `Provenance.agent.onBehalfOf`.

# rest[].resource[].searchParam[].documentation
The client **SHALL** provide at least a code value and **MAY** provide both the system and code values.

The server **SHALL** support both.

# rest[].resource[].searchParam[].documentation
The client **SHALL** provide at least a id value and **MAY** provide both the Type and id values.

The server **SHALL** support both.

# rest[].resource[].searchParam[].documentation
The client **SHALL** provide at least a code value and **MAY** provide both the system and code values.

The server **SHALL** support both.

# rest[].resource[].searchParam[].documentation
The client **SHALL** provide at least a code value and **MAY** provide both the system and code values.

The server **SHALL** support both.

# rest[].resource[].searchParam[].documentation
A client **SHALL** provide a value precise to the *second + time offset*.

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

# rest[].resource[].searchParam[].documentation
A client **SHALL** provide a value precise to the *second + time offset*.

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

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

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

# rest[].resource[].documentation
* The Encounter resource can represent a reason using either a code with `Encounter.reasonCode`, or a reference with `Encounter.reasonReference` to  Condition or other resource.
   * Although both are marked as must support, the server systems are not required to support both a code and a reference, but they **SHALL** support *at least one* of these elements.
   * The client application **SHALL** support both elements.
   * if `Encounter.reasonReference` references an Observation, it **SHOULD** conform to a US Core Observation if applicable. (for example, a laboratory result should conform to the US Core Laboratory Result Observation Profile)

* The location address can be represented by either by the Location referenced by `Encounter.location.location` or indirectly through the Organization referenced by `Encounter.serviceProvider`.
   * Although both are marked as must support, the server systems are not required to support both `Encounter.location.location` and `Encounter.serviceProvider`, but they **SHALL** support *at least one* of these elements.
   * The client application **SHALL** support both elements.
   * if using `Encounter.location.location` it **SHOULD** conform to US Core Location.

# rest[].resource[].searchParam[].documentation
The client **SHALL** provide at least a code value and **MAY** provide both the system and code values.

The server **SHALL** support both.

# rest[].resource[].searchParam[].documentation
A client **SHALL** provide a value precise to the *second + time offset*.

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

# rest[].resource[].searchParam[].documentation
The client **SHALL** provide at least a code value and **MAY** provide both the system and code values.

The server **SHALL** support both.

# rest[].resource[].searchParam[].documentation
The client **SHALL** provide at least a id value and **MAY** provide both the Type and id values.

The server **SHALL** support both.

# rest[].resource[].searchParam[].documentation
The client **SHALL** provide at least a id value and **MAY** provide both the Type and id values.

The server **SHALL** support both.

# rest[].resource[].searchParam[].documentation
The client **SHALL** provide at least a code value and **MAY** provide both the system and code values.

The server **SHALL** support both.

# rest[].resource[].searchParam[].documentation
The client **SHALL** provide at least a code value and **MAY** provide both the system and code values.

The server **SHALL** support both.

# rest[].resource[].searchParam[].documentation
The client **SHALL** provide at least a code value and **MAY** provide both the system and code values.

The server **SHALL** support both.

# rest[].resource[].searchParam[].documentation
The client **SHALL** provide at least a code value and **MAY** provide both the system and code values.

The server **SHALL** support both.

# rest[].resource[].searchParam[].documentation
The client **SHALL** provide at least a id value and **MAY** provide both the Type and id values.

The server **SHALL** support both.

# rest[].resource[].searchParam[].documentation
A client **SHALL** provide a value precise to the *day*.

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

# rest[].resource[].documentation
* Based upon the ONC U.S. Core Data for Interoperability (USCDI) requirements, CVX vaccine codes are required and the NDC vaccine codes **SHOULD** be supported as translations to them.

# rest[].resource[].searchParam[].documentation
The client **SHALL** provide at least a id value and **MAY** provide both the Type and id values.

The server **SHALL** support both.

# rest[].resource[].searchParam[].documentation
The client **SHALL** provide at least a code value and **MAY** provide both the system and code values.

The server **SHALL** support both.

# rest[].resource[].searchParam[].documentation
A client **SHALL** provide a value precise to the *second + time offset*.

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

# rest[].resource[].interaction[].documentation
Implemented per the specification (or Insert other doco here)

# rest[].resource[].interaction[].documentation
Implemented per the specification (or Insert other doco here)

# rest[].resource[].interaction[].documentation
Implemented per the specification (or Insert other doco here)

# rest[].resource[].interaction[].documentation
Implemented per the specification (or Insert other doco here)

# rest[].resource[].interaction[].documentation
Implemented per the specification (or Insert other doco here)

# rest[].resource[].searchParam[].documentation
The vaccine preventable disease being evaluated against

# rest[].resource[].searchParam[].documentation
The status of the dose relative to published recommendations

# rest[].resource[].searchParam[].documentation
The vaccine administration event being evaluated

# rest[].resource[].interaction[].documentation
Implemented per the specification (or Insert other doco here)

# rest[].resource[].interaction[].documentation
Implemented per the specification (or Insert other doco here)

# rest[].resource[].interaction[].documentation
Implemented per the specification (or Insert other doco here)

# rest[].resource[].interaction[].documentation
Implemented per the specification (or Insert other doco here)

# rest[].resource[].interaction[].documentation
Implemented per the specification (or Insert other doco here)

# rest[].resource[].searchParam[].documentation
Vaccine  or vaccine group recommendation applies to

# rest[].resource[].interaction[].documentation
Implemented per the specification (or Insert other doco here)

# rest[].resource[].interaction[].documentation
Implemented per the specification (or Insert other doco here)

# rest[].resource[].interaction[].documentation
Implemented per the specification (or Insert other doco here)

# rest[].resource[].interaction[].documentation
Implemented per the specification (or Insert other doco here)

# rest[].resource[].interaction[].documentation
Implemented per the specification (or Insert other doco here)

# rest[].resource[].searchParam[].documentation
The implementation guide publication date

# rest[].resource[].searchParam[].documentation
A use context type and value assigned to the implementation guide

# rest[].resource[].searchParam[].documentation
Intended jurisdiction for the implementation guide

# rest[].resource[].searchParam[].documentation
The description of the implementation guide

# rest[].resource[].searchParam[].documentation
A type of use context assigned to the implementation guide

# rest[].resource[].searchParam[].documentation
Profile that all resources must conform to

# rest[].resource[].searchParam[].documentation
The human-friendly name of the implementation guide

# rest[].resource[].searchParam[].documentation
The business version of the implementation guide

# rest[].resource[].searchParam[].documentation
The uri that identifies the implementation guide

# rest[].resource[].searchParam[].documentation
A quantity- or range-valued use context assigned to the implementation guide

# rest[].resource[].searchParam[].documentation
Computationally friendly name of the implementation guide

# rest[].resource[].searchParam[].documentation
A use context assigned to the implementation guide

# rest[].resource[].searchParam[].documentation
Name of the publisher of the implementation guide

# rest[].resource[].searchParam[].documentation
A use context type and quantity- or range-based value assigned to the implementation guide

# rest[].resource[].searchParam[].documentation
The current status of the implementation guide

# rest[].resource[].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.

# rest[].resource[].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.

# rest[].resource[].interaction[].documentation
Implemented per the specification (or Insert other doco here)

# rest[].resource[].interaction[].documentation
Implemented per the specification (or Insert other doco here)

# rest[].resource[].interaction[].documentation
Implemented per the specification (or Insert other doco here)

# rest[].resource[].interaction[].documentation
Implemented per the specification (or Insert other doco here)

# rest[].resource[].interaction[].documentation
Implemented per the specification (or Insert other doco here)

# rest[].resource[].searchParam[].documentation
Returns dispenses with this external identifier

# rest[].resource[].searchParam[].documentation
Returns dispenses performed by a specific individual

# rest[].resource[].searchParam[].documentation
The identity of a receiver to list dispenses for

# rest[].resource[].searchParam[].documentation
The identity of a patient for whom to list dispenses

# rest[].resource[].searchParam[].documentation
Returns dispenses that should be sent to a specific destination

# rest[].resource[].searchParam[].documentation
Returns dispenses of this medicine resource

# rest[].resource[].searchParam[].documentation
Returns dispenses with the specified responsible party

# rest[].resource[].searchParam[].documentation
Returns dispenses handed over on this date

# rest[].resource[].searchParam[].documentation
The identity of a prescription to list dispenses from

# rest[].resource[].searchParam[].documentation
The identity of a patient to list dispenses  for

# rest[].resource[].searchParam[].documentation
Returns dispenses with a specific context (episode or episode of care)

# rest[].resource[].searchParam[].documentation
Returns dispenses with a specified dispense status

# rest[].resource[].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](http://hl7.org/fhir/R4/references.html#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.

# rest[].resource[].searchParam[].documentation
The client **SHALL** provide at least a code value and **MAY** provide both the system and code values.

The server **SHALL** support both.

# rest[].resource[].searchParam[].documentation
The client **SHALL** provide at least a code value and **MAY** provide both the system and code values.

The server **SHALL** support both.

# rest[].resource[].searchParam[].documentation
The client **SHALL** provide at least a id value and **MAY** provide both the Type and id values.

The server **SHALL** support both.

# rest[].resource[].searchParam[].documentation
The client **SHALL** provide at least a id value and **MAY** provide both the Type and id values.

The server **SHALL** support both.

# rest[].resource[].searchParam[].documentation
A client **SHALL** provide a value precise to the *second + time offset*.

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

# rest[].resource[].interaction[].documentation
Implemented per the specification (or Insert other doco here)

# rest[].resource[].interaction[].documentation
Implemented per the specification (or Insert other doco here)

# rest[].resource[].interaction[].documentation
Implemented per the specification (or Insert other doco here)

# rest[].resource[].interaction[].documentation
Implemented per the specification (or Insert other doco here)

# rest[].resource[].interaction[].documentation
Implemented per the specification (or Insert other doco here)

# rest[].resource[].searchParam[].documentation
Return statements with this external identifier

# rest[].resource[].searchParam[].documentation
Date when patient was taking (or not taking) the medication

# rest[].resource[].searchParam[].documentation
Return statements of this medication code

# rest[].resource[].searchParam[].documentation
The identity of a patient, animal or group to list statements for

# rest[].resource[].searchParam[].documentation
Returns statements for a specific patient.

# rest[].resource[].searchParam[].documentation
Returns statements for a specific context (episode or episode of Care).

# rest[].resource[].searchParam[].documentation
Return statements of this medication reference

# rest[].resource[].searchParam[].documentation
Returns statements that are part of another event.

# rest[].resource[].searchParam[].documentation
Who or where the information in the statement came from

# rest[].resource[].searchParam[].documentation
Returns statements of this category of medicationstatement

# rest[].resource[].searchParam[].documentation
Return statements that match the given status

# rest[].resource[].interaction[].documentation
Implemented per the specification (or Insert other doco here)

# rest[].resource[].interaction[].documentation
Implemented per the specification (or Insert other doco here)

# rest[].resource[].interaction[].documentation
Implemented per the specification (or Insert other doco here)

# rest[].resource[].interaction[].documentation
Implemented per the specification (or Insert other doco here)

# rest[].resource[].interaction[].documentation
Implemented per the specification (or Insert other doco here)

# rest[].resource[].searchParam[].documentation
Return administrations with this external identifier

# rest[].resource[].searchParam[].documentation
The identity of a request to list administrations from

# rest[].resource[].searchParam[].documentation
Return administrations of this medication code

# rest[].resource[].searchParam[].documentation
The identity of the individual who administered the medication

# rest[].resource[].searchParam[].documentation
The identity of the individual or group to list administrations for

# rest[].resource[].searchParam[].documentation
Return administrations of this medication resource

# rest[].resource[].searchParam[].documentation
Reasons for administering the medication

# rest[].resource[].searchParam[].documentation
The identity of a patient to list administrations  for

# rest[].resource[].searchParam[].documentation
Date administration happened (or did not happen)

# rest[].resource[].searchParam[].documentation
Return administrations that share this encounter or episode of care

# rest[].resource[].searchParam[].documentation
Reasons for not administering the medication

# rest[].resource[].searchParam[].documentation
Return administrations with this administration device identity

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

# rest[].resource[].searchParam[].documentation
The client **SHALL** provide at least a code value and **MAY** provide both the system and code values.

The server **SHALL** support both.

# rest[].resource[].searchParam[].documentation
The client **SHALL** provide at least a code value and **MAY** provide both the system and code values.

The server **SHALL** support both.

# rest[].resource[].searchParam[].documentation
The client **SHALL** provide at least a code value and **MAY** provide both the system and code values.

The server **SHALL** support both.

# rest[].resource[].searchParam[].documentation
A client **SHALL** provide a value precise to the *second + time offset*.

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

# rest[].resource[].searchParam[].documentation
The client **SHALL** provide at least a id value and **MAY** provide both the Type and id values.

The server **SHALL** support both.

# rest[].resource[].documentation
* Systems **SHALL** support National Provider Identifier (NPI) for organizations and **SHOULD** support Clinical Laboratory Improvement Amendments (CLIA) identifiers for `Organization.Identifier`.

# rest[].resource[].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)
  1. a communication language
  1. a race
  1. an ethnicity
  1. a birth sex*
  1. previous name
     - Previous name is represented by providing an end date in the `Patient.name.period` element for a previous name.
  1. suffix
     - Suffix is represented using the `Patient.name.suffix` element.
* The Patient's Social Security Numbers **SHOULD NOT** be used as a patient identifier in `Patient.identifier.value`.

# rest[].resource[].searchParam[].documentation
A client **SHALL** provide a value precise to the *day*.

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

# rest[].resource[].searchParam[].documentation
A server **SHALL** support a value precise to the *day*.

# rest[].resource[].searchParam[].documentation
The client **SHALL** provide at least a code value and **MAY** provide both the system and code values.

The server **SHALL** support both.

# rest[].resource[].searchParam[].documentation
The client **SHALL** provide at least a code value and **MAY** provide both the system and code values.

The server **SHALL** support both.

# rest[].resource[].searchParam[].documentation
The client **SHALL** provide at least a code value and **MAY** provide both the system and code values.

The server **SHALL** support both.

# rest[].resource[].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.

# rest[].resource[].searchParam[].documentation
The client **SHALL** provide at least a code value and **MAY** provide both the system and code values.

The server **SHALL** support both.

# rest[].resource[].searchParam[].documentation
The client **SHALL** provide at least a id value and **MAY** provide both the Type and id values.

The server **SHALL** support both.

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

# rest[].resource[].searchParam[].documentation
The client **SHALL** provide at least a code value and **MAY** provide both the system and code values.

The server **SHALL** support both.

# rest[].resource[].searchParam[].documentation
The client **SHALL** provide at least a id value and **MAY** provide both the Type and id values.

The server **SHALL** support both.

# rest[].resource[].searchParam[].documentation
A client **SHALL** provide a value precise to the *second + time offset*.

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

# rest[].resource[].searchParam[].documentation
The client **SHALL** provide at least a code value and **MAY** provide both the system and code values.

The server **SHALL** support both.

# rest[].resource[].documentation
* The US Core Provenance resource **SHALL** be supported for these US Core
resources:

  * US Core CarePlan Profile
  * US Core DiagnosticReport Profile for Laboratory Results Reporting
  * US Core Encounter Profile
  * US Core Observation Sexual Orientation Profile
  * US Core Head Circumference Profile
  * US Core ServiceRequest Profile
  * US Core Vital Signs Profile
  * US Core DiagnosticReport Profile for Report and Note Exchange
  * US Core Implantable Device Profile
  * US Core Observation Imaging Result Profile
  * US Core CareTeam Profile
  * US Core Pulse Oximetry Profile
  * US Core BMI Profile
  * US Core Blood Pressure Profile
  * US Core Body Weight Profile
  * US Core RelatedPerson Profile
  * US Core Pediatric BMI for Age Observation Profile
  * US Core MedicationRequest Profile
  * US Core Condition Encounter Diagnosis Profile
  * US Core Pediatric Head Occipital-frontal Circumference Percentile Profile
  * US Core Procedure Profile
  * US Core Laboratory Result Observation Profile
  * US Core Body Height Profile
  * US Core Observation SDOH Assessment Profile
  * US Core Observation Survey Profile
  * US Core Body Temperature Profile
  * US Core Condition Problems and Health Concerns Profile
  * US Core Pediatric Weight for Height Observation Profile
  * US Core Goal Profile
  * US Core AllergyIntolerance Profile
  * US Core Immunization Profile
  * US Core Observation Social History Profile
  * US Core Heart Rate Profile
  * US Core Smoking Status Observation Profile
  * US Core Patient Profile
  * US Core QuestionnaireResponse Profile
  * US Core Respiratory Rate Profile
  * US Core Observation Clinical Test Result Profile
  * US Core DocumentReference Profile

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

# rest[].resource[].documentation
US Core provides two ways to represent SDOH assessment screening results using: 
 
1. Observation: [US Core Observation SDOH Assessment Profile] 
1. QuestionnaireResponse: [US Core QuestionnaireResponse Profile]

US Core Servers **SHALL** support [US Core Observation SDOH Assessment Profile] for SDOH Assessments and **MAY** support the [US Core QuestionnaireResponse Profile] for SDOH Assessments.

# rest[].resource[].searchParam[].documentation
The client **SHALL** provide at least a id value and **MAY** provide both the Type and id values.

The server **SHALL** support both.

# rest[].resource[].searchParam[].documentation
The client **SHALL** provide at least a code value and **MAY** provide both the system and code values.

The server **SHALL** support both.

# rest[].resource[].searchParam[].documentation
The client **SHALL** provide at least a code value and **MAY** provide both the system and code values.

The server **SHALL** support both.

# rest[].resource[].searchParam[].documentation
A client **SHALL** provide a value precise to the *second + time offset*.

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

# rest[].resource[].searchParam[].documentation
The client **SHALL** provide at least a id value and **MAY** provide both the Type and id values.

The server **SHALL** support both.

# rest[].resource[].searchParam[].documentation
The client **SHALL** provide at least a id value and **MAY** provide both the Type and id values.

The server **SHALL** support both.

# rest[].resource[].searchParam[].documentation
The client **SHALL** provide at least a code value and **MAY** provide both the system and code values.

The server **SHALL** support both.

# rest[].resource[].searchParam[].documentation
The client **SHALL** provide at least a id value and **MAY** provide both the Type and id values.

The server **SHALL** support both.

# rest[].resource[].searchParam[].documentation
The client **SHALL** provide at least a code value and **MAY** provide both the system and code values.

The server **SHALL** support both.

# rest[].resource[].searchParam[].documentation
The client **SHALL** provide at least a code value and **MAY** provide both the system and code values.

The server **SHALL** support both.

# rest[].resource[].searchParam[].documentation
A client **SHALL** provide a value precise to the *second + time offset*.

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

# rest[].resource[].operation[].documentation
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.