These requirements apply to the actor: US Core Requestor (Clients including Certifying Systems) Legend: Key: An identifier for the requirement. Context: The name and link to the narrative section that pertains to the requirement. There can be more than one narrative section that references the same requirement. Conformance: The conformance verb of the requirement: SHALL, SHOULD, MAY, SHALL-NOT, or SHOULD-NOT. Requirement: The actual requirements statement, which is a direct quote from the IG and may include helpful context in square brackets. Note that statements in the narrative section that contain multiple requirements in a single context are split into individual requirement statements. Key Context Conformance Requirement CONF-0022 •general-requirements.html#required-bindings-for-coded-elements SHALL [When populating a coded element with a required binding to a ValueSet definition] US Core Requestors SHALL be capable of processing the code [from the required binding ValueSet] CONF-0028 •general-requirements.html#extensible-binding-for-coded-elements SHALL US Core Requestors SHALL be capable of processing the code in ['DataElement.code.code' or text in 'DataElement.code.text' for a DataElement.code that has an extensible binding] CONF-0032 •general-requirements.html#modifier-elements SHALL Clients SHALL be able to process [elements that are] Mandatory or Must Support elements CONF-0035 •general-requirements.html#modifier-elements SHOULD receivers SHOULD accept instances that ... contain unexpected data elements [definition] CONF-0036 •general-requirements.html#modifier-elements SHOULD-NOT receivers SHOULD NOT accept instances that ... contain unexpected data elements … when those elements are modifier elements [definition] CONF-0037 •general-requirements.html#modifier-elements SHOULD Unless a Client determines they can process [a resource with a modifier] safely, rejection is typically the only safe action if unexpected modifier elements are present. CONF-0053 •general-requirements.html#fhir-restful-search-api-requirements SHALL When searching using the token type searchparameter (how to search by token) The Client SHALL provide at least a code value CONF-0054 •general-requirements.html#fhir-restful-search-api-requirements MAY When searching using the token type searchparameter (how to search by token) The Client … MAY provide both the system and code values. CONF-0056 •general-requirements.html#fhir-restful-search-api-requirements SHALL When searching using the reference type searchparameter (how to search by reference) The Client SHALL provide at least an id value CONF-0057 •general-requirements.html#fhir-restful-search-api-requirements MAY When searching using the reference type searchparameter (how to search by reference) The Client … MAY provide both the Type and id values. CONF-0059 •general-requirements.html#fhir-restful-search-api-requirements SHALL When searching using the date type searchparameter (how to search by date) The Client SHALL provide values precise to the day for elements of datatype date CONF-0060 •general-requirements.html#fhir-restful-search-api-requirements SHALL When searching using the date type searchparameter (how to search by date) The Client SHALL provide values precise … to the second + time offset for elements of datatype dateTime. CONF-0076 •must-support.html#must-support-elements SHALL For querying and reading US Core Profiles, Must Support on any profile data element SHALL be interpreted as follows…: US Core Requestors SHALL be capable of processing resource instances containing the data elements without generating an error or causing the application to fail. CONF-0079 •must-support.html#must-support-elements SHALL For querying and reading US Core Profiles, Must Support on any profile data element SHALL be interpreted as follows…: When querying US Core Responders, US Core Requestors SHALL interpret missing data elements within resource instances as data not present in the US Core Responder’s system. CONF-0082 •must-support.html#must-support-elements SHALL For querying and reading US Core Profiles, Must Support on any profile data element SHALL be interpreted as follows…: US Core Requestors SHALL be able to process resource instances containing data elements asserting missing information. CONF-0083 •must-support.html#additional-uscdi-requirements SHALL Implementors [US Core Requestors] seeking ONC certification [in the ONC IT Health Certification program] SHALL interpret Additional USCDI Requirements as Must Support elements as documented above and below; CONF-0085 •must-support.html#additional-uscdi-requirements SHALL Implementors [US Core Requestors] [not] seeking ONC certification [in the ONC IT Health Certification program] SHALL interpret Additional USCDI Requirements as … optional. CONF-0092 •must-support.html#must-support---primitive-elements SHALL [W]hen claiming conformance [to a profile with a must support primitive element] … US Core requestors SHALL be capable of processing the value [of the primitive element] CONF-0098 •must-support.html#must-support---complex-elements SHALL When claiming conformance [to a must support complex element with no must support sub-elements] … US Core Requestors SHALL be capable of processing a value in [the complex element] CONF-0100 •must-support.html#must-support---complex-elements SHALL When claiming conformance [to a must support complex element with one or more must support sub-elements] … US Core Requestors SHALL be capable of processing a values in [each must support sub-element] CONF-0102 •must-support.html#must-support---complex-elements MAY Systems [US Core Requestors] can support the other elements [of a complex element, not labeled as a Must Support], but this is not a requirement of US Core CONF-0106 •must-support.html#must-support---resource-references SHALL When a Reference type element is labeled as Must Support, has multiple target profiles referenced, and specific targets are labeled as Must Support," ... US Core Responders SHALL be capable of providing [such an element] with a valid reference to [all listed Must Support profile(s).] CONF-0108 •must-support.html#must-support---resource-references MAY Systems [US Core Requestors] can support other [resource] references [other than those labeled as Must Support], but this is not a requirement of US Core CONF-0110 •must-support.html#must-support---resource-references SHALL When a Reference type element is labeled as Must Support and has a single target profile referenced ... US Core Responders SHALL be capable of providing [such an element] with a valid reference to [the Must Support Profile.] CONF-0112 •must-support.html#must-support---choice-of-data-types SHALL [If a profile has] a Must Support element [with] a choice of datatypes for its content [and some of] the datatypes … are labeled as Must Support … When claiming conformance to [such a] profile: US Core Requestors SHALL be capable of processing [the Must Support data type choice] CONF-0113 •must-support.html#must-support---choice-of-data-types MAY [If a profile has] a Must Support element [with] a choice of datatypes for its content [and some of] the datatypes … are labeled as Must Support[, or a profile has] an Additional USCDI element [with] a choice of datatypes for its content [and some of] the datatypes … are labeled as Additional USCDI … [US Core Requestors] MAY support ... processing other [data type] choice elements (such as Observation.effectivePeriod), but this is not a requirement of US Core. CONF-0116 •must-support.html#must-support---choice-of-profile-elements SHALL There are several instances in this Guide where there is a choice of supporting one or another profile element to meet the Must Support or Additional USCDI requirement. In such cases, … the Client application SHALL support all elements. CONF-0122 •scopes.html#capabilities-for-implementations-supporting-backend-services SHALL Implementations [US Core Requestors] supporting Backend Services – for example, to meet US EHR certification requirements [of the ONC IT Health Certification program]- SHALL include support for the Client-confidential-asymmetric capability and system/scopes. CONF-0127 •scopes.html#smart-scopes SHOULD US Core Clients SHOULDfollow the principle of least privilege and access only the necessary resources. CONF-0172 •scopes.html#additional-us-core-requirements SHOULD US Core requires ... additional metadata [to be available through the Server's Well-Known Uniform Resource Identifier (URI)]: ... [in] scopes_supported [the] array of scopes a Client MAY request. The app SHOULD inspect the returned scopes and accommodate the differences from the scopes it asked for and registered. CONF-0194 •general-guidance.html#language-support MAY [When Clients request a resource in a specific language] Clients MAY request language/locale using the http Accept-Language header. CONF-0226 •clinical-notes.html#support-requirements MAY Systems [Clients] MAY support other [DiagnosticReport] categories as well. CONF-0232 •clinical-notes.html#support-requirements MAY a Client MAY determine the note and report types supported by a Server by invoking the standard FHIR Value Set Expansion ($expand) operation defined in the FHIR R4 specification. CONF-0251 •medication-list.html#options-for-representing-medication SHALL The Client application MUST support all methods [for referencing a medication resource: returned bundle, as an external resource, or as a contained resource] CONF-0264 •medication-list.html#de-duplication-of-data SHOULD To provide a list of a patient’s medications, it MAY be necessary to “de-duplicate” them. The de-duplication activity ... SHOULD be provided by the Client. CONF-0275 •screening-and-assessments.html#category-codes MAY API consumers MAY query by category when accessing patient information. CONF-0286 •changes-between-versions.html#no-guarantee-that-resource-ids-are-preserved SHALL Therefore, Client applications must plan on deduplication methods that rely on something other than a common identifier across FHIR versions. CONF-0292 •changes-between-versions.html#expectation-that-data-is-preserved-between-versions SHOULD The FHIR RESTful resource types supported in a DSTU2 implementation SHOULD be supported in a R4 implementation CONF-0293 •changes-between-versions.html#expectation-that-data-is-preserved-between-versions SHOULD The FHIR RESTful resource types supported in a DSTU2 implementation SHOULD be supported in a R4 implementation [with the] exception [of] MedicationStatement MAY be deprecated, and the data SHOULD be mapped to MedicationRequest. CONF-0294 •changes-between-versions.html#expectation-that-data-is-preserved-between-versions SHOULD The FHIR RESTful resource types supported in a DSTU2 implementation SHOULD be supported in a R4 implementation [with the] exception [of] Care teams as represented by CarePlan in DSTU2 SHOULD be replaced by and the data mapped to CareTeam in R4 CONF-0299 •changes-between-versions.html#expectation-that-data-is-preserved-between-versions SHOULD When updating between versions, Clients SHOULD consider the impact of any changes to data visualization on the usability for the end user and the maintenance of data integrity. CONF-0314 •StructureDefinition-us-core-careteam.html#profile-specific-implementation-guidance SHALL [C]lient application[s conforming to the US Core CareTeam profile] SHALL support [US Core Practitioner Profile] CONF-0315 •StructureDefinition-us-core-careteam.html#profile-specific-implementation-guidance SHALL [C]lient application[s conforming to the US Core CareTeam profile] SHALL support [US Core PractitionerRole Profile] CONF-0316 •StructureDefinition-us-core-careteam.html#profile-specific-implementation-guidance SHALL [C]lient application[s conforming to the US Core CareTeam profile] SHALL support [US Core RelatedPerson Profile] CONF-0369 •StructureDefinition-us-core-documentreference.html#profile-specific-implementation-guidance •StructureDefinition-us-core-adi-documentreference.html#profile-specific-implementation-guidance SHALL The Client application SHALL support [DocumentReference.attachment.url] CONF-0370 •StructureDefinition-us-core-documentreference.html#profile-specific-implementation-guidance •StructureDefinition-us-core-adi-documentreference.html#profile-specific-implementation-guidance SHALL The Client application SHALL support [DocumentReference.attachment.data] CONF-0376 •StructureDefinition-us-core-encounter.html#profile-specific-implementation-guidance SHALL The Client application SHALL support [ Encounter.reasonCode] CONF-0377 •StructureDefinition-us-core-encounter.html#profile-specific-implementation-guidance SHALL The Client application SHALL support [Encounter.reasonReference] CONF-0380 •StructureDefinition-us-core-encounter.html#profile-specific-implementation-guidance SHALL The Client application SHALL support [Encounter.location.location] CONF-0381 •StructureDefinition-us-core-encounter.html#profile-specific-implementation-guidance SHALL The Client application SHALL support [Encounter.serviceProvider] CONF-0388 •StructureDefinition-us-core-goal.html#profile-specific-implementation-guidance SHALL The Client application SHALL support ... Goal.startDate CONF-0389 •StructureDefinition-us-core-goal.html#profile-specific-implementation-guidance SHALL The Client application SHALL support ... Goal.target.dueDate CONF-0403 •StructureDefinition-us-core-medicationdispense.html#profile-specific-implementation-guidance •StructureDefinition-us-core-medicationrequest.html#profile-specific-implementation-guidance SHALL The Client application SHALL support [using a code in .medicationCodeableConcept to represent medications when supporting the US Core MedicationDispense profile] CONF-0404 •StructureDefinition-us-core-medicationdispense.html#profile-specific-implementation-guidance •StructureDefinition-us-core-medicationrequest.html#profile-specific-implementation-guidance SHALL The Client application SHALL support [referencing a Medication resource in .medicationReferencet to represent medications when supporting the US Core MedicationDispense profile] CONF-0409 •StructureDefinition-us-core-medicationrequest.html#profile-specific-implementation-guidance SHALL The Client application SHALL support [medicationRequest.reporedtBoolean] CONF-0410 •StructureDefinition-us-core-medicationrequest.html#profile-specific-implementation-guidance SHALL The Client application SHALL support [MedicationRequest.reportedReference] CONF-0412 •StructureDefinition-us-core-medicationrequest.html#profile-specific-implementation-guidance SHALL [For organizations participating in the ONC Health IT Certification program,] the certifying Client application SHALL support [MedicationRequest.reasonCode.] CONF-0413 •StructureDefinition-us-core-medicationrequest.html#profile-specific-implementation-guidance SHALL [For organizations participating in the ONC Health IT Certification program,] the certifying Client application SHALL support [MedicationRequest.reasonReference.] CONF-0415 •StructureDefinition-us-core-medicationrequest.html#profile-specific-implementation-guidance SHALL [For organizations participating in the ONC Health IT Certification program,] Clients SHALL support all target resources in MedicationRequest.reasonReference. CONF-0476 •StructureDefinition-us-core-practitioner.html#profile-specific-implementation-guidance SHALL The Client application SHALL support both [the PractitionerRole profile and the Practitioner.address element] CONF-0483 •StructureDefinition-us-core-procedure.html#profile-specific-implementation-guidance SHALL [For organizations participating in the ONC Health IT Certification program] … Clients SHALL support ... US Core Procedure Profile for communicating the reason or justification for a referral as Additional USCDI Requirements CONF-0485 •StructureDefinition-us-core-procedure.html#profile-specific-implementation-guidance SHALL [For organizations participating in the ONC Health IT Certification program,] The certifying Client application SHALL support both [Procedure.reasonCode and Procedure.reasonReference] CONF-0487 •StructureDefinition-us-core-procedure.html#profile-specific-implementation-guidance SHALL [For organizations participating in the ONC Health IT Certification program,] when using Procedure.reasonReference … Clients SHALL support all target resources in Procedure.reasonReference CONF-0517 •StructureDefinition-us-core-servicerequest.html#profile-specific-implementation-guidance SHALL [For organizations participating in the ONC Health IT Certification program] … Clients SHALL support ... US Core ServiceRequest Profile for communicating the reason or justification for a referral as Additional USCDI Requirements CONF-0519 •StructureDefinition-us-core-servicerequest.html#profile-specific-implementation-guidance SHALL [For organizations participating in the ONC Health IT Certification program,] The certifying Client application SHALL support both [ServiceRequest.reasonCode and ServiceRequest.reasonReference] CONF-0521 •StructureDefinition-us-core-servicerequest.html#profile-specific-implementation-guidance SHALL [For organizations participating in the ONC Health IT Certification program,] when using ServiceRequest.reasonReference … Clients SHALL support all target resources in ServiceRequest.reasonReference CONF-0525 •StructureDefinition-us-core-specimen.html#profile-specific-implementation-guidance SHALL The Client application SHALL support both [ Specimen.identifier and Specimen.accessionIdentifier] CONF-0551 •security.html#patient-privacy-and-security SHALL Systems SHALL establish a risk analysis and management regime that conforms with HIPAA security regulatory requirements CONF-0553 •security.html#patient-privacy-and-security SHOULD US Federal systems SHOULD conform with the risk management and mitigation requirements defined in NIST 800 series documents. CONF-0555 •security.html#patient-privacy-and-security SHOULD US Federal systems … SHOULD include security category assignment following NIST 800-60 vol. 2 Appendix D.14. CONF-0557 •security.html#patient-privacy-and-security SHOULD The coordination of risk management and the related security and privacy controls … SHOULD be defined in the Business Associate Agreement when available. CONF-0559 •security.html#patient-privacy-and-security SHALL Systems SHALL reference a single time source to establish a common time base for security auditing and clinical data records among computing systems. CONF-0561 •security.html#patient-privacy-and-security SHOULD The selected time service SHOULD be documented in the Business Associate Agreement when available. CONF-0563 •security.html#patient-privacy-and-security SHALL Systems SHALL keep audit logs of the various transactions. CONF-0565 •security.html#patient-privacy-and-security SHALL Systems SHALL use TLS version 1.2 or higher for all transmissions not taking place over a secure network connection. CONF-0567 •security.html#patient-privacy-and-security SHOULD US Federal systems SHOULD conform with FIPS PUB 140-2. CONF-0569 •security.html#patient-privacy-and-security SHALL Systems SHALL conform to FHIR Communications Security requirements. CONF-0571 •security.html#patient-privacy-and-security SHALL For Authentication and Authorization, Systems SHALL support any SMART App Launch version for Client <-> Server interactions. CONF-0573 •security.html#patient-privacy-and-security SHALL Systems SHALL implement consent requirements per their state, local, and institutional policies. CONF-0575 •security.html#patient-privacy-and-security SHOULD The Business Associate Agreements SHOULD document systems’ mutual consent requirements. CONF-0577 •security.html#patient-privacy-and-security SHOULD Systems SHOULD provide Provenance statements using the US Core Provenance Profile resource and associated requirements. CONF-0579 •security.html#patient-privacy-and-security MAY Systems MAY implement the FHIR Digital Signatures CONF-0581 •security.html#patient-privacy-and-security MAY Systems MAY protect the confidentiality of data at rest via encryption and associated access controls. CONF-0815 •general-guidance.html#client-best-practices-for-search SHOULD When the Server supports [ the _include search parameter], Clients SHOULD use the _include search parameter to retrieve referenced content instead of searching for a resource and then performing a separate search for other references (for example, Patient, Encounter, and Location) in the result set. CONF-0816 •general-guidance.html#client-best-practices-for-search SHOULD If the Server does not support the _include search parameter, Clients SHOULD consolidate duplicate searches before searching for referenced resources in the result set CONF-0817 •general-guidance.html#client-best-practices-for-search SHOULD-NOT SHOULD NOT search the same data within the time stated in the Cache-Control header. CONF-0849 •StructureDefinition-us-core-observation-screening-assessment.html#profile-specific-implementation-guidance SHALL [For the US Core Observation Screening Assessment Profile,] the Client system ... SHALL support [both] Reference(US Core Observation Screening Assessment Profile) [and] Reference(US Core QuestionnaireResponse Profile) for Observation.derivedFrom CONF-0853 •StructureDefinition-us-core-patient.html#profile-specific-implementation-guidance SHALL The certifying Client application SHALL support the [US Core Interpreter Needed Extension] on [the US Core Patient Profile] . CONF-0854 •StructureDefinition-us-core-patient.html#profile-specific-implementation-guidance SHALL The certifying Client application SHALL support the [US Core Interpreter Needed Extension] on [the US Core Encounter Profile]. CONF-0869 •StructureDefinition-us-core-simple-observation.html#profile-specific-implementation-guidance SHALL 'Observation.performer' target profiles US Core Practitioner Profile and US Core Patient Profile are labeled Must Support.... Clients SHALL support both. CONF-0882 •must-support.html#must-support---resource-references SHALL When a Reference element is labeled as Must Support has multiple target profiles referenced, but none are labeled as Must Support ... US Core Requesters SHALL be capable of processing [such an element] with a valid reference to at least one target profile. CONF-0886 •StructureDefinition-us-core-encounter.html#profile-specific-implementation-guidance SHALL Servers can use the US Core Interpreter Needed Extension on this profile or the [US Core Patient Profile] to communicate whether a patient needs an interpreter…Client application SHALL support the extension on both profiles. CONF-0888 •StructureDefinition-us-core-observation-screening-assessment.html#profile-specific-implementation-guidance SHALL 'Observation.performer' target profiles US Core Practitioner Profile and US Core Patient Profile are labeled Must Support.... Clients SHALL support both. CONF-0911 •StructureDefinition-us-core-servicerequest.html#profile-specific-implementation-guidance MAY API consumers MAY query by category when accessing patient information.
HL7 International / Cross-Group Projects
This [Requirements](https://hl7.org/fhir/R5/requirements.html) resource lists the US Core Requestor (Client) requirements defined in the US Core Implementation Guide narrative sections. These requirements represent the regulatory, business, functional, and technical specifications that design artifacts must meet to ensure interoperability.
US Core Requestor (Clients including Certifying Systems)
[When populating a coded element with a [required binding](http://hl7.org/fhir/R4/terminologies.html#required) to a ValueSet definition] US Core Requestors **SHALL** be capable of processing the code [from the required binding ValueSet]
US Core Requestors **SHALL** be capable of processing the code in ['DataElement.code.code' or text in 'DataElement.code.text' for a DataElement.code that has an extensible binding]
Clients **SHALL** be able to process [elements that are] [Mandatory](https://hl7.org/fhir/us/core/must-support.html) or [Must Support elements](https://hl7.org/fhir/us/core/must-support.html)
receivers **SHOULD** accept instances that ... contain unexpected data elements [[definition](http://hl7.org/fhir/R4/conformance-rules.html#isModifier)]
receivers **SHOULD NOT** accept instances that ... contain unexpected data elements … when those elements are modifier elements [[definition](http://hl7.org/fhir/R4/conformance-rules.html#isModifier)]
Unless a Client determines they can process [a resource with a modifier] safely, rejection is typically the only safe action if unexpected modifier elements are present.
When searching using the `token` type searchparameter [(how to search by token)](http://hl7.org/fhir/R4/search.html#token) The Client **SHALL** provide at least a code value
When searching using the `token` type searchparameter [(how to search by token)](http://hl7.org/fhir/R4/search.html#token) The Client … **MAY** provide both the system and code values.
When searching using the `reference` type searchparameter [(how to search by reference)](http://hl7.org/fhir/R4/search.html#reference) The Client **SHALL** provide at least an id value
When searching using the `reference` type searchparameter [(how to search by reference)](http://hl7.org/fhir/R4/search.html#reference) The Client … **MAY** provide both the Type and id values.
When searching using the `date` type searchparameter [(how to search by date)](http://hl7.org/fhir/R4/search.html#date) The Client **SHALL** provide values precise to the day for elements of datatype `date`
When searching using the `date` type searchparameter [(how to search by date)](http://hl7.org/fhir/R4/search.html#date) The Client **SHALL** provide values precise … to the second + time offset for elements of datatype `dateTime`.
For querying and reading US Core Profiles, Must Support on any profile data element **SHALL** be interpreted as follows…: US Core Requestors **SHALL** be capable of processing resource instances containing the data elements without generating an error or causing the application to fail.
For querying and reading US Core Profiles, Must Support on any profile data element **SHALL** be interpreted as follows…: When querying US Core Responders, US Core Requestors **SHALL** interpret missing data elements within resource instances as data not present in the US Core Responder’s system.
For querying and reading US Core Profiles, Must Support on any profile data element **SHALL** be interpreted as follows…: US Core Requestors **SHALL** be able to process resource instances containing data elements asserting missing information.
Implementors [US Core Requestors] seeking ONC certification [in the ONC IT Health Certification program] **SHALL** interpret Additional USCDI Requirements as Must Support elements as documented above and below;
Implementors [US Core Requestors] [not] seeking ONC certification [in the ONC IT Health Certification program] **SHALL** interpret Additional USCDI Requirements as … optional.
[W]hen claiming conformance [to a profile with a must support primitive element] … US Core requestors **SHALL** be capable of processing the value [of the primitive element]
When claiming conformance [to a must support complex element with no must support sub-elements] … US Core Requestors **SHALL** be capable of processing a value in [the complex element]
When claiming conformance [to a must support complex element with one or more must support sub-elements] … US Core Requestors **SHALL** be capable of processing a values in [each must support sub-element]
Systems [US Core Requestors] can support the other elements [of a complex element, not labeled as a Must Support], but this is not a requirement of US Core
When a Reference type element is labeled as *Must Support*, has multiple target profiles referenced, and specific targets are labeled as *Must Support*," ... - US Core Responders **SHALL** be capable of providing [such an element] with a valid reference to [all listed Must Support profile(s).]
Systems [US Core Requestors] can support other [resource] references [other than those labeled as Must Support], but this is not a requirement of US Core
When a Reference type element is labeled as *Must Support* and has a single target profile referenced ... - US Core Responders **SHALL** be capable of providing [such an element] with a valid reference to [the Must Support Profile.]
[If a profile has] a Must Support element [with] a choice of datatypes for its content [and some of] the datatypes … are labeled as Must Support … When claiming conformance to [such a] profile: - US Core Requestors **SHALL** be capable of processing [the Must Support data type choice]
[If a profile has] a Must Support element [with] a choice of datatypes for its content [and some of] the datatypes … are labeled as Must Support[, or a profile has] an Additional USCDI element [with] a choice of datatypes for its content [and some of] the datatypes … are labeled as Additional USCDI … [US Core Requestors] **MAY** support ... processing other [data type] choice elements (such as Observation.effectivePeriod), but this is not a requirement of US Core.
There are several instances in this Guide where there is a choice of supporting one or another profile element to meet the Must Support or Additional USCDI requirement. In such cases, … the Client application **SHALL** support all elements.
Implementations [US Core Requestors] supporting Backend Services – for example, to meet US EHR certification requirements [of the ONC IT Health Certification program]- **SHALL** include support for the Client-confidential-asymmetric capability and system/scopes.
US Core Clients **SHOULD**follow the [principle of least privilege](https://en.wikipedia.org/wiki/Principle_of_least_privilege) and access only the necessary resources.
US Core requires ... additional metadata [to be available through the Server's [Well-Known Uniform Resource Identifier (URI)](https://hl7.org/fhir/smart-app-launch/STU2/conformance.html#using-well-known)]: ... [in] `scopes_supported` [the] array of scopes a Client **MAY** request. The app **SHOULD** inspect the returned scopes and accommodate the differences from the scopes it asked for and registered.
[When Clients request a resource in a specific language] Clients **MAY** request language/locale using the http [Accept-Language](https://www.ietf.org/rfc/rfc2616.txt) header.
Systems [Clients] **MAY** support other [DiagnosticReport] categories as well.
a Client **MAY** determine the note and report types supported by a Server by invoking the standard FHIR Value Set Expansion ([$expand](http://hl7.org/fhir/R4/valueset-operation-expand.html)) operation defined in the FHIR R4 specification.
The Client application MUST support all methods [for referencing a medication resource: returned bundle, as an external resource, or as a [contained](http://hl7.org/fhir/R4/references.html#contained) resource]
To provide a list of a patient’s medications, it **MAY** be necessary to “de-duplicate” them. The de-duplication activity ... **SHOULD** be provided by the Client.
API consumers **MAY** query by category when accessing patient information.
Therefore, Client applications must plan on deduplication methods that rely on something other than a common identifier across FHIR versions.
The FHIR RESTful resource types supported in a DSTU2 implementation **SHOULD** be supported in a R4 implementation
The FHIR RESTful resource types supported in a DSTU2 implementation **SHOULD** be supported in a R4 implementation [with the] exception [of] MedicationStatement **MAY** be deprecated, and the data **SHOULD** be mapped to MedicationRequest.
The FHIR RESTful resource types supported in a DSTU2 implementation **SHOULD** be supported in a R4 implementation [with the] exception [of] Care teams as represented by CarePlan in DSTU2 **SHOULD** be replaced by and the data mapped to CareTeam in R4
When updating between versions, Clients **SHOULD** consider the impact of any changes to data visualization on the usability for the end user and the maintenance of data integrity.
[C]lient application[s conforming to the US Core CareTeam profile] **SHALL** support [US Core Practitioner Profile]
[C]lient application[s conforming to the US Core CareTeam profile] **SHALL** support [US Core PractitionerRole Profile]
[C]lient application[s conforming to the US Core CareTeam profile] **SHALL** support [US Core RelatedPerson Profile]
The Client application **SHALL** support [DocumentReference.attachment.url]
The Client application **SHALL** support [DocumentReference.attachment.data]
The Client application **SHALL** support [ Encounter.reasonCode]
The Client application **SHALL** support [Encounter.reasonReference]
The Client application **SHALL** support [Encounter.location.location]
The Client application **SHALL** support [Encounter.serviceProvider]
The Client application **SHALL** support ... Goal.startDate
The Client application **SHALL** support ... Goal.target.dueDate
The Client application **SHALL** support [using a code in .medicationCodeableConcept to represent medications when supporting the US Core MedicationDispense profile]
The Client application **SHALL** support [referencing a Medication resource in .medicationReferencet to represent medications when supporting the US Core MedicationDispense profile]
The Client application **SHALL** support [medicationRequest.reporedtBoolean]
The Client application **SHALL** support [MedicationRequest.reportedReference]
[For organizations participating in the ONC Health IT Certification program,] the certifying Client application **SHALL** support [MedicationRequest.reasonCode.]
[For organizations participating in the ONC Health IT Certification program,] the certifying Client application **SHALL** support [MedicationRequest.reasonReference.]
[For organizations participating in the ONC Health IT Certification program,] Clients **SHALL** support all target resources in MedicationRequest.reasonReference.
The Client application **SHALL** support both [the PractitionerRole profile and the Practitioner.address element]
[For organizations participating in the ONC Health IT Certification program] … Clients **SHALL** support ... US Core Procedure Profile for communicating the reason or justification for a referral as Additional USCDI Requirements
[For organizations participating in the ONC Health IT Certification program,] The certifying Client application **SHALL** support both [Procedure.reasonCode and Procedure.reasonReference]
[For organizations participating in the ONC Health IT Certification program,] when using Procedure.reasonReference … Clients **SHALL** support all target resources in Procedure.reasonReference
[For organizations participating in the ONC Health IT Certification program] … Clients **SHALL** support ... US Core ServiceRequest Profile for communicating the reason or justification for a referral as Additional USCDI Requirements
[For organizations participating in the ONC Health IT Certification program,] The certifying Client application **SHALL** support both [ServiceRequest.reasonCode and ServiceRequest.reasonReference]
[For organizations participating in the ONC Health IT Certification program,] when using ServiceRequest.reasonReference … Clients **SHALL** support all target resources in ServiceRequest.reasonReference
The Client application **SHALL** support both [ Specimen.identifier and Specimen.accessionIdentifier]
Systems **SHALL** establish a risk analysis and management regime that conforms with HIPAA security regulatory requirements
US Federal systems **SHOULD** conform with the risk management and mitigation requirements defined in NIST 800 series documents.
US Federal systems … **SHOULD** include security category assignment following NIST 800-60 vol. 2 Appendix D.14.
The coordination of risk management and the related security and privacy controls … **SHOULD** be defined in the Business Associate Agreement when available.
Systems **SHALL** reference a single time source to establish a common time base for security auditing and clinical data records among computing systems.
The selected time service **SHOULD** be documented in the Business Associate Agreement when available.
Systems **SHALL** keep audit logs of the various transactions.
Systems **SHALL** use TLS version 1.2 or higher for all transmissions not taking place over a secure network connection.
US Federal systems **SHOULD** conform with FIPS PUB 140-2.
Systems **SHALL** conform to [FHIR Communications Security](http://hl7.org/fhir/R4/security.html#http) requirements.
For Authentication and Authorization, Systems **SHALL** support any [SMART App Launch version](http://hl7.org/fhir/smart-app-launch/history.html) for Client <-> Server interactions.
Systems **SHALL** implement consent requirements per their state, local, and institutional policies.
The Business Associate Agreements **SHOULD** document systems’ mutual consent requirements.
Systems **SHOULD** provide Provenance statements using the [US Core Provenance Profile](https://hl7.org/fhir/us/core/STU8/StructureDefinition-us-core-provenance.html) resource and associated requirements.
Systems **MAY** implement the [FHIR Digital Signatures](http://hl7.org/fhir/R4/security.html#digital%20signatures)
Systems **MAY** protect the confidentiality of data at rest via encryption and associated access controls.
When the Server supports [ the _include search parameter], Clients **SHOULD** use the _include search parameter to retrieve referenced content instead of searching for a resource and then performing a separate search for other references (for example, Patient, Encounter, and Location) in the result set.
If the Server does not support the _include search parameter, Clients **SHOULD** consolidate duplicate searches before searching for referenced resources in the result set
**SHOULD NOT** search the same data within the time stated in the `Cache-Control` header.
[For the US Core Observation Screening Assessment Profile,] the Client system ... **SHALL** support [both] Reference(US Core Observation Screening Assessment Profile) [and] Reference(US Core QuestionnaireResponse Profile) for Observation.derivedFrom
The certifying Client application **SHALL** support the [[US Core Interpreter Needed Extension](https://hl7.org/fhir/us/core/STU8/StructureDefinition-us-core-interpreter-needed.html)] on [the [US Core Patient Profile](https://hl7.org/fhir/us/core/STU8/StructureDefinition-us-core-patient.html)] .
The certifying Client application **SHALL** support the [[US Core Interpreter Needed Extension](https://hl7.org/fhir/us/core/STU8/StructureDefinition-us-core-interpreter-needed.html)] on [the [US Core Encounter Profile](https://hl7.org/fhir/us/core/STU8/StructureDefinition-us-core-encounter.html)].
'Observation.performer' target profiles [US Core Practitioner Profile](https://hl7.org/fhir/us/core/STU8/StructureDefinition-us-core-practitioner.html) and [US Core Patient Profile](https://hl7.org/fhir/us/core/STU8/StructureDefinition-us-core-patient.html) are labeled Must Support.... Clients **SHALL** support both.
When a Reference element is labeled as *Must Support* has multiple target profiles referenced, but none are labeled as *Must Support* ... - US Core Requesters **SHALL** be capable of processing [such an element] with a valid reference to *at least one* target profile.
Servers can use the US Core Interpreter Needed Extension on this profile or the [US Core Patient Profile] to communicate whether a patient needs an interpreter…Client application **SHALL** support the extension on both profiles.