# title
US Core Server Pharmacy CapabilityStatement

# 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. This instance of the Capability Statement and API provide access to Pharmacy data managed by a Health Plan's business partner. 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. Return the following response classes:
   - (Status 400): invalid parameter
   - (Status 401/4xx): unauthorized request
   - (Status 403): insufficient scope
   - (Status 404): unknown resource
   - (Status 410): deleted resource.
1. Support json source formats for all US Core interactions.

The US Core Server **SHOULD**:

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.
1. Support xml resource formats for all Argonaut questionnaire interactions.

# 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[].interaction[].documentation
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**.

# 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

# 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 encounter.  **SHOULD** document what resources, if any, are returned as included resources

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

# rest[].resource[].documentation
The  MedicationRequest resource can represent a medication, using an external reference to a Medication resource. If an external Medication Resourcse is used in a MedicationRequest, then the READ  **SHALL**  be supported.

# 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`

# rest[].resource[].documentation
If a system receives a provider in `Provenance.agent.who` as free text they must capture who sent them the information as the organization. On request they **SHALL** provide this organization as the source and **MAY** include the free text provider.

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