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

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 or Must Support elements

receivers SHOULD accept instances that ... contain unexpected data elements  [definition]

receivers SHOULD [NOT] accept instances that ... contain unexpected data elements … when those elements are modifier elements [definition]

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) The Client SHALL provide at least a code value

When searching using the token type searchparameter (how to search by token) The Client … MAY provide both the system and code values.

When searching using the reference type searchparameter (how to search by reference) The Client SHALL provide at least an id value

When searching using the reference type searchparameter (how to search by reference) The Client … MAY provide both the Type and id values.

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

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.

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 and access only the necessary resources.

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.

[When Clients request a resource in a specific language] Clients MAY request language/locale using the http Accept-Language 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) 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 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

[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 requirements.

For Authentication and Authorization, Systems SHALL support any SMART App Launch version 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 resource and associated requirements.

Systems MAY implement the FHIR Digital Signatures

Systems MAY protect the confidentiality of data at rest via encryption and associated access controls.

The [additional] current binding [FHIR R5 link] 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 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] on [the US Core Patient Profile] .

The certifying Client application SHALL support the [US Core Interpreter Needed Extension] on [the US Core Encounter Profile].

'Observation.performer' target profiles US Core Practitioner Profile and US Core Patient Profile 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.