These requirements apply to the actor: US Core Requestor (Clients including Certifying Systems) Key Conformance Requirement CONF-0022 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 SHALL (conditional) 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 SHALL (conditional) Clients SHALL be able to process [elements that are] Mandatory or Must Support elements CONF-0035 SHOULD (conditional) receivers SHOULD accept instances that ... contain unexpected data elements [definition] CONF-0036 SHOULD-NOT (conditional) receivers SHOULD [NOT] accept instances that ... contain unexpected data elements … when those elements are modifier elements [definition] CONF-0037 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 SHALL When searching using the token type searchparameter (how to search by token) The Client SHALL provide at least a code value CONF-0054 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 SHALL When searching using the reference type searchparameter (how to search by reference) The Client SHALL provide at least an id value CONF-0057 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 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 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 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 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 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 SHALL (conditional) 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 SHALL (conditional) Implementors [US Core Requestors] [not] seeking ONC certification [in the ONC IT Health Certification program] SHALL interpret Additional USCDI Requirements as … optional. CONF-0092 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 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 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 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-0104 MAY The U.S. Core Data for Interoperability (USCDI) may require additional elements, [which is a requirement for certification in the ONC IT Health Certification program, but not a requirement of US Core conformance for US Core Requestors] CONF-0106 SHALL In certain profiles, only specific resource references are labeled as Must Support. ... US Core Requestors SHALL be capable of processing [such an element] with a valid reference to [all listed Must Support profile(s).] CONF-0108 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 SHALL In specific profiles, only a single resource reference is present on an element labeled Must Support. … US Core Requestors SHALL be capable of processing [such an element] with a valid reference to [the Must Support Profile.] CONF-0112 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 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 SHALL (conditional) 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 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 SHOULD US Core Clients should follow the principle of least privilege and access only the necessary resources. CONF-0172 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 MAY (conditional) [When Clients request a resource in a specific language] Clients MAY request language/locale using the http Accept-Language header. CONF-0226 MAY Systems [Clients] may support other [DiagnosticReport] categories as well. CONF-0232 MAY a Client can 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 SHALL (conditional) 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 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 MAY API consumers can query by category when accessing patient information. CONF-0286 SHALL Therefore, Client applications must plan on deduplication methods that rely on something other than a common identifier across FHIR versions. CONF-0292 SHOULD (conditional) The FHIR RESTful resource types supported in a DSTU2 implementation SHOULD be supported in a R4 implementation CONF-0293 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 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 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-0301 SHALL Separate authorization is required [between different versions of FHIR] CONF-0314 SHALL [C]lient application[s conforming to the US Core CareTeam profile] SHALL support [US Core Practitioner Profile] CONF-0315 SHALL [C]lient application[s conforming to the US Core CareTeam profile] SHALL support [US Core PractitionerRole Profile] CONF-0316 SHALL [C]lient application[s conforming to the US Core CareTeam profile] SHALL support [US Core RelatedPerson Profile] CONF-0369 SHALL The Client application SHALL support [DocumentReference.attachment.url] CONF-0370 SHALL The Client application SHALL support [DocumentReference.attachment.data] CONF-0376 SHALL The Client application SHALL support [ Encounter.reasonCode] CONF-0377 SHALL The Client application SHALL support [Encounter.reasonReference] CONF-0380 SHALL The Client application SHALL support [Encounter.location.location] CONF-0381 SHALL The Client application SHALL support [Encounter.serviceProvider] CONF-0388 SHALL The Client application SHALL support ... Goal.startDate CONF-0389 SHALL The Client application SHALL support ... Goal.target.dueDate CONF-0403 SHALL The Client application SHALL support [using a code in .medicationCodeableConcept to represent medications when supporting the US Core MedicationDispense profile] CONF-0404 SHALL The Client application SHALL support [referencing a Medication resource in .medicationReferencet to represent medications when supporting the US Core MedicationDispense profile] CONF-0409 SHALL The Client application SHALL support [medicationRequest.reporedtBoolean] CONF-0410 SHALL The Client application SHALL support [MedicationRequest.reportedReference] CONF-0412 SHALL (conditional) [For organizations participating in the ONC Health IT Certification program,] the certifying Client application SHALL support [MedicationRequest.reasonCode.] CONF-0413 SHALL (conditional) [For organizations participating in the ONC Health IT Certification program,] the certifying Client application SHALL support [MedicationRequest.reasonReference.] CONF-0415 SHALL (conditional) [For organizations participating in the ONC Health IT Certification program,] Clients SHALL support all target resources in MedicationRequest.reasonReference. CONF-0476 SHALL The Client application SHALL support both [the PractionerRole profile and the Practioner.address element] CONF-0483 SHALL (conditional) [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 SHALL (conditional) [For organizations participating in the ONC Health IT Certification program,] The certifying Client application SHALL support both [Procedure.reasonCode and Procedure.reasonReference] CONF-0487 SHALL (conditional) [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 SHALL (conditional) [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 SHALL (conditional) [For organizations participating in the ONC Health IT Certification program,] The certifying Client application SHALL support both [ServiceRequest.reasonCode and ServiceRequest.reasonReference] CONF-0521 SHALL (conditional) [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 SHALL (conditional) The Client application SHALL support both [ Specimen.identifier and Specimen.accessionIdentifier] CONF-0526 MAY Clients may request Specimen resources be included with the Observation or DiagnosticReport resource query. CONF-0527 SHOULD [Clients] SHOULD Support the Following Implementation Guide SMART App Launch version 2.0.0 and later CONF-0528 MAY [Clients] MAY support the transaction interaction CONF-0529 MAY [Clients] MAY support the batch interaction CONF-0530 MAY [Clients] MAY support the search-system interaction CONF-0531 MAY [Clients] MAY support the history-system interaction CONF-0544 MAY [Server] MAY support the transaction interaction CONF-0545 MAY [Server] MAY support the batch interaction CONF-0546 MAY [Server] MAY support the search-system interaction CONF-0547 MAY [Server] MAY support the history-system interaction CONF-0551 SHALL Systems SHALL establish a risk analysis and management regime that conforms with HIPAA security regulatory requirements CONF-0553 SHOULD US Federal systems SHOULD conform with the risk management and mitigation requirements defined in NIST 800 series documents. CONF-0555 SHOULD US Federal systems … SHOULD include security category assignment following NIST 800-60 vol. 2 Appendix D.14. CONF-0557 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 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 SHOULD The selected time service SHOULD be documented in the Business Associate Agreement when available. CONF-0563 SHALL Systems SHALL keep audit logs of the various transactions. CONF-0565 SHALL Systems SHALL use TLS version 1.2 or higher for all transmissions not taking place over a secure network connection. CONF-0567 SHOULD US Federal systems SHOULD conform with FIPS PUB 140-2. CONF-0569 SHALL Systems SHALL conform to FHIR Communications Security requirements. CONF-0571 SHALL For Authentication and Authorization, Systems SHALL support any SMART App Launch version for Client <-> Server interactions. CONF-0573 SHALL Systems SHALL implement consent requirements per their state, local, and institutional policies. CONF-0575 SHOULD The Business Associate Agreements SHOULD document systems’ mutual consent requirements. CONF-0577 SHOULD Systems SHOULD provide Provenance statements using the US Core Provenance Profile resource and associated requirements. CONF-0579 MAY Systems MAY implement the FHIR Digital Signatures CONF-0581 MAY Systems MAY protect the confidentiality of data at rest via encryption and associated access controls. CONF-0582 SHALL (conditional) The [additional] current binding [FHIR R5 link] requires newly recorded, non-legacy data to be drawn from the [bound] value set. CONF-0800 MAY For querying and reading US Core Profiles, Must Support on any profile data element SHALL be interpreted as follows…: [The US Core Requesters processing of the resource instances] may result in a determination not to use the resource if the resource content does not meet business requirements. CONF-0815 SHOULD (conditional) 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 SHOULD (conditional) 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 SHOULD-NOT (conditional) The HTTP Cache-Control response header stores a response associated with a request and reuses the stored response for subsequent requests. If a Cache-Control header is present in the Server response headers, the Clients SHOULD NOT search the same data within the time stated in the Cache-Control header. CONF-0829 SHALL-NOT US Core SearchParameters referenced in [the US Core Client] CapabilityStatement that are derived from standard FHIR SearchParameters are only defined to document ... Client expectations. They specify additional expectations for the following SearchParameter elements:B7 multipleAnd multipleOr comparator modifier chain They SHALL NOT be interpreted as search parameters for search. CONF-0830 SHOULD Clients SHOULD use the standard FHIR SearchParameters. CONF-0849 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 SHALL (conditional) The certifying Client application SHALL support the [US Core Interpreter Needed Extension] on [the US Core Patient Profile] . CONF-0854 SHALL (conditional) The certifying Client application SHALL support the [US Core Interpreter Needed Extension] on [the US Core Encounter Profile]. CONF-0869 SHALL 'Observation.performer' target profiles US Core Practitioner Profile and US Core Patient Profile are labeled Must Support.... Clients SHALL support both. CONF-0882 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.
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.
Used by permission of HL7 International, all rights reserved Creative Commons License
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
The U.S. Core Data for Interoperability (USCDI) may require additional elements, [which is a requirement for certification in the ONC IT Health Certification program, but not a requirement of US Core conformance for US Core Requestors]
In certain profiles, only specific resource references are labeled as Must Support. ... - US Core Requestors **SHALL** be capable of processing [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
In specific profiles, only a single resource reference is present on an element labeled Must Support. … - US Core Requestors **SHALL** be capable of processing [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 can 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 can 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.
Separate authorization is required [between different versions of FHIR]
[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 PractionerRole profile and the Practioner.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]
Clients may request Specimen resources be included with the Observation or DiagnosticReport resource query.
[Clients] SHOULD Support the Following Implementation Guide [SMART App Launch version 2.0.0 and later](http://hl7.org/fhir/smart-app-launch/history.html)
[Clients] MAY support the transaction interaction
[Clients] MAY support the batch interaction
[Clients] MAY support the search-system interaction
[Clients] MAY support the history-system interaction
[Server] MAY support the transaction interaction
[Server] MAY support the batch interaction
[Server] MAY support the search-system interaction
[Server] MAY support the history-system interaction
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.
The [additional] current binding [[FHIR R5 link](https://hl7.org/fhir/R5/terminologies.html#binding)] requires newly recorded, non-legacy data to be drawn from the [bound] value set.
For querying and reading US Core Profiles, Must Support on any profile data element **SHALL** be interpreted as follows…: [The US Core Requesters processing of the resource instances] may result in a determination not to use the resource if the resource content does not meet business requirements.
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
The [HTTP Cache-Control](https://httpwg.org/specs/rfc9111.html) response header stores a response associated with a request and reuses the stored response for subsequent requests. If a `Cache-Control` header is present in the Server response headers, the Clients **SHOULD NOT** search the same data within the time stated in the `Cache-Control` header.
US Core SearchParameters referenced in [the US Core Client] CapabilityStatement that are derived from standard FHIR SearchParameters are only defined to document ... Client expectations. They specify additional expectations for the following SearchParameter elements:B7 - multipleAnd - multipleOr - comparator - modifier - chain They **SHALL NOT** be interpreted as search parameters for search.
Clients **SHOULD** use the standard FHIR SearchParameters.
[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.