These requirements apply to the actor: US Core Requestor (Server) 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-0001 •general-requirements.html#profile-only-support SHALL To support a US Core Profile, a Server: SHALL Be able to populate all profile data elements that are mandatory and/or flagged as Must Support as defined by that profile’s StructureDefinition. CONF-0002 •general-requirements.html#profile-only-support SHOULD To support a US Core Profile, a Server: SHOULD declare support for a US Core Profile by including its official URL in the Server’s CapabilityStatement.rest.resource.supportedProfile element. CONF-0003 •general-requirements.html#profile-support--interaction-support MAY Servers MAY deploy and support one or more US Core Profiles to represent clinical information CONF-0004 •general-requirements.html#profile-support--interaction-support MAY Server MAY deploy and support ... the following US Core interaction: “Quick Start” defined for each Profile CONF-0005 •general-requirements.html#profile-support--interaction-support MAY Server MAY deploy and support ... the following US Core interaction: Clinical Notes CONF-0006 •general-requirements.html#profile-support--interaction-support MAY Server MAY deploy and support ... the following US Core interaction: Medication List CONF-0007 •general-requirements.html#profile-support--interaction-support MAY Server MAY deploy and support ... the following US Core interaction: Basic Provenance CONF-0008 •general-requirements.html#profile-support--interaction-support MAY Server MAY deploy and support ... the following US Core interaction: Screening and Assessments CONF-0009 •general-requirements.html#profile-support--interaction-support MAY Servers implementing ... [clinical information representation] can claim conformance to the US Core Profile content structure ... by implementing all or parts of the US Core CapabilityStatement into their capabilities. CONF-0010 •general-requirements.html#profile-support--interaction-support MAY Servers implementing ... [interactions] can claim conformance to the ... RESTful interactions defined by implementing all or parts of the US Core CapabilityStatement into their capabilities CONF-0013 •general-requirements.html#claiming-conformance-to-a-us-core-profile SHALL [To claim conformance to a US Core Profile] a conformant Server: SHALL Be able to populate all profile data elements that are mandatory and/or flagged as Must Support as defined by that profile’s StructureDefinition. CONF-0014 •general-requirements.html#claiming-conformance-to-a-us-core-profile SHOULD [To claim conformance to a US Core Profile] a conformant Server: SHOULD declare conformance with the US Core Server Capability Statement by including its official URL in the Server’s CapabilityStatement.instantiates element: http://hl7.org/fhir/us/core/CapabilityStatement/us-core-Server CONF-0015 •general-requirements.html#claiming-conformance-to-a-us-core-profile SHALL [To claim conformance to a US Core Profile] a conformant Server: SHALL specify the full capability details from the US Core CapabilityStatement it claims to implement. CONF-0016 •general-requirements.html#claiming-conformance-to-a-us-core-profile SHALL [To claim conformance to a US Core Profile] a conformant Server: SHALL… Declare support for the US Core Profile by including its official URL in the Server’s CapabilityStatement.rest.resource.supportedProfile element. CONF-0017 •general-requirements.html#claiming-conformance-to-a-us-core-profile SHALL [To claim conformance to a US Core Profile] a conformant Server: SHALL… Declare support for the US Core Profile’s FHIR RESTful transactions. CONF-0018 •general-requirements.html#required-bindings-for-coded-elements SHALL Required binding to a ValueSet definition means that one of the codes from the specified ValueSet SHALL be used. CONF-0019 •general-requirements.html#required-bindings-for-coded-elements SHALL For CodeableConcept, which permits multiple codings and a text element, this [Required binding to a ValueSet definition] rule applies to at least one of the codings CONF-0020 •general-requirements.html#required-bindings-for-coded-elements SHALL-NOT For a [required binding to a ValueSet definition], a CodeableConceptwhich permits multiple codings and a text element … [using] only text is not valid. CONF-0021 •general-requirements.html#required-bindings-for-coded-elements SHALL [When populating a coded element with a [required binding](http://hl7.org/fhir/R4/terminologies.html#required] to a ValueSet definition] US Core Responders SHALL provide a code exclusively from [the required binding] ValueSet CONF-0023 •general-requirements.html#extensible-binding-for-coded-elements SHALL [Extensible binding] (http://hl7.org/fhir/R4/terminologies.html#extensible) means that one of the codes from the specified value set SHALL be used when an appropriate concept exists;… CONF-0024 •general-requirements.html#extensible-binding-for-coded-elements MAY [When using an [extensible Binding] (http://hl7.org/fhir/R4/terminologies.html#extensible)] If no suitable code exists in the [extensible] ValueSet, alternate code(s) MAY be used.. CONF-0026 •general-requirements.html#extensible-binding-for-coded-elements SHOULD-NOT For CodeableConcept [with an [extensible binding] (http://hl7.org/fhir/R4/terminologies.html#extensible) … Text-only representation SHOULD NOT be used - coded values are expected whenever possible to support interoperability. CONF-0027 •general-requirements.html#extensible-binding-for-coded-elements SHALL When claiming conformance to ... [to a US Core profile extensible binding rule, a] US Core Responders SHALL provide: A code from … [the] valueset 'DataElement.code.code' if the concept exists in the valueset [for a DataElement.code that has an extensible binding] Or an alternative code if the concept does not exist in the valueset [for a DataElement.code that has an extensible binding] Or text in ... `[DataElement.code.text]’ if only text is available [for a DataElement.code that has an extensible binding] CONF-0029 •general-requirements.html#translations MAY Alternate codes MAY be provided in addition to the standard codes defined in required or extensible ValueSets. These alternate codes are called "additional codings". CONF-0030 •general-requirements.html#translations MAY [The additional codings] MAY be equivalent to or narrower in meaning than the standard concept code. CONF-0033 •general-requirements.html#modifier-elements MAY Not all modifier elements are Mandatory or Must Support, and there is no requirement for supporting them CONF-0034 •general-requirements.html#modifier-elements MAY Servers MAY communicate a system-wide profile in their CapabilityStatement to identify which additional elements, including modifier elements, they support CONF-0039 •general-requirements.html#missing-data SHALL If the source system does not have data for an element with a minimum cardinality = 0 (including elements labeled Must Support), the data element SHALL be omitted from the resource. CONF-0040 •general-requirements.html#missing-data SHALL If the data element is a Mandatory element (in other words, where the minimum cardinality is > 0), it SHALL be present even if the source system does not have data. CONF-0041 •general-requirements.html#missing-data SHALL For [mandatory] non-coded data elements [where data is not available], use the DataAbsentReason Extension in the data type ... [with] the code unknown - The value is expected to exist but is not known. CONF-0042 •general-requirements.html#missing-data SHALL [In situations where data is not available] for [mandatory] coded data elements … [with] example, preferred, or extensible binding strengths (CodeableConcept or Coding datatypes) If the source system has text but no coded data, only the text element is used. CONF-0043 •general-requirements.html#missing-data SHALL [In situations where data is not available] for [mandatory] coded data elements… [with] example, preferred, or extensible binding strengths (CodeableConcept or Coding datatypes): For Coding datatypes, the text-only data is represented as a display element CONF-0044 •general-requirements.html#missing-data SHALL [In situations where data is not available] for [mandatory] coded data elements… [with] example, preferred, or extensible binding strengths (CodeableConcept or Coding datatypes): … If there is neither text nor coded data ... [then] use the appropriate “unknown” concept code from the ValueSet if available. CONF-0045 •general-requirements.html#missing-data SHALL [In situations where data is not available] for [mandatory] coded data elements… [with] example, preferred, or extensible binding strengths (CodeableConcept or Coding datatypes): … If there is neither text nor coded data ... [then] if the ValueSet does not have the appropriate “unknown” concept code, use unknown from the DataAbsentReason Code System. CONF-0046 •general-requirements.html#missing-data SHALL [In situations where data is not available] for [mandatory] coded data elements… [with] required binding strength (CodeableConcept or code datatypes): use the appropriate “unknown” concept code from the ValueSet if available CONF-0047 •general-requirements.html#missing-data SHALL [In situations where data is not available] for [mandatory] coded data elements… [with] required binding strength (CodeableConcept or code datatypes): If the ValueSet does not have the appropriate “unknown” concept code, you must use a concept from the ValueSet. Otherwise, the instance will not be conformant CONF-0048 •general-requirements.html#missing-data SHALL [If the source system does not have data for a Mandatory element for a coded data element with required binding strength] If any of these status codes is missing [meaning it lacks an "unknown" or otherwise appropriate concept code from the ValueSet, a] 404 HTTP error code and an OperationOutcome SHALL be returned in response to a read transaction on the resource. CONF-0049 •general-requirements.html#missing-data SHALL [If the source system does not have data for a Mandatory element for a coded data element with required binding strength, and the ValueSet does not have the appropriate "unknown" concept code, then] if returning a response to a search, the problematic resource SHALL be excluded from the search set CONF-0050 •general-requirements.html#missing-data SHOULD [If the source system does not have data for a Mandatory element for a coded data element with required binding strength, and the ValueSet does not have the appropriate "unknown" concept code, then] if returning a response to a search, … a warning OperationOutcome SHOULD be included indicating that other search results were found but could not be compliantly expressed and have been suppressed. CONF-0051 •general-requirements.html#fhir-restful-search-api-requirements SHALL The FHIR RESTful Search API requires that Servers that support search SHALL support the HTTP POST-based search. CONF-0052 •general-requirements.html#fhir-restful-search-api-requirements SHALL For all the supported search interactions in this guide, Servers SHALL also support the GET-based search. CONF-0055 •general-requirements.html#fhir-restful-search-api-requirements SHALL When searching using the token type searchparameter (how to search by token) The Server SHALL support both [system and code values] CONF-0058 •general-requirements.html#fhir-restful-search-api-requirements SHALL When searching using the reference type searchparameter (how to search by reference) The Server SHALL support both [id and Type values] CONF-0061 •general-requirements.html#fhir-restful-search-api-requirements SHALL When searching using the date type searchparameter (how to search by date) The Server SHALL support values precise to the day for elements of datatype date CONF-0062 •general-requirements.html#fhir-restful-search-api-requirements SHALL When searching using the date type searchparameter (how to search by date) The Server SHALL support values precise … to the second + time offset for elements of datatype dateTime CONF-0063 •general-requirements.html#search-for-Servers-requiring-status SHOULD Servers SHOULD support a query for resources without requiring a status parameter. CONF-0064 •general-requirements.html#search-for-Servers-requiring-status SHALL If business requirements prohibit [querying a resource without a status parameter], they SHALL follow the guidelines here. CONF-0065 •general-requirements.html#search-for-Servers-requiring-status MAY For searches where the Client does not supply a status parameter, an implementation’s business rules MAY override the FHIR RESTful search expectations and require a status parameter to be provided CONF-0066 •general-requirements.html#search-for-Servers-requiring-status SHALL For searches where the Client does not supply a status parameter, … systems [that require a status parameter to be provided] are allowed to reject such requests as follows: SHALL return an HTTP 400 status CONF-0067 •general-requirements.html#search-for-Servers-requiring-status SHALL For searches where the Client does not supply a status parameter, … systems [that require a status parameter to be provided] are allowed to reject such requests as follows: SHALL return an OperationOutcome specifying that status(es) must be present. CONF-0068 •general-requirements.html#search-for-Servers-requiring-status SHALL For searches where the Client does not supply a status parameter, … systems [that require a status parameter to be provided] are allowed to reject such requests as follows: SHALL support search with status if status required CONF-0069 •general-requirements.html#search-for-Servers-requiring-status SHALL-NOT SHALL NOT restrict search results ( i.e., apply ‘hidden’ filters) when a Client includes status parameters in the query. CONF-0070 •general-requirements.html#search-for-Servers-requiring-status SHOULD [For systems that require a status parameter to be provided,] if a system doesn’t support a specific status code value that is queried, it SHOULD return an HTTP 200 status with a search bundle. CONF-0071 •general-requirements.html#search-for-Servers-requiring-status SHOULD [For systems that require a status parameter to be provided,] if a system doesn’t support a specific status code value that is queried [and returns a search bundle],... [t]he search bundle SHOULD contain resources matching the search criteria CONF-0072 •general-requirements.html#search-for-Servers-requiring-status SHOULD [For systems that require a status parameter to be provided,] if a system doesn’t support a specific status code value that is queried [and returns a search bundle],... [t]he search bundle SHOULD contain ... an OperationOutcome warning the Client which status code value is not supported. CONF-0073 •general-requirements.html#search-for-Servers-requiring-status SHALL For searches where the Client does not supply a status parameter, … systems [that require a status parameter to be provided] are allowed to reject such requests as follows:... SHALL document this behavior in its CapabilityStatement for the “search-type” interaction in CapabilityStatement.rest.resource.interaction.documentation. CONF-0075 •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 Responders SHALL be capable of populating all data elements as part of the query results specified by the US Core Server Capability Statement. CONF-0078 •must-support.html#must-support-elements SHALL-NOT SHALL NOT include the data elements in the resource instance returned as part of the query results. CONF-0080 •must-support.html#must-support-el+D647ements SHOULD For querying and reading US Core Profiles, Must Support on any profile data element SHALL be interpreted as follows…: In cases where information on a specific data element is missing, and the US Core Responder knows the precise reason for the absence of data (other than suppressed data), US Core Responders SHOULD send the reason for the missing information. CONF-0081 •must-support.html#must-support-elements SHOULD [When sending reason for missing information, follow] the same methdology outlined in the Missing Data section but using the appropriate reason code instead of unknown [reason code]. CONF-0084 •must-support.html#additional-uscdi-requirements SHALL Implementors [US Core Responders] 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-0086 •must-support.html#additional-uscdi-requirements SHALL Implementors [US Core Responders] [not] seeking ONC certification [in the ONC IT Health Certification program] SHALL interpret Additional USCDI Requirements as … optional. CONF-0087 •must-support.html#defined-pattern-elements SHALL If an element is marked as Must Support and defined by a pattern [as described by ElementDefinition.pattern], then the pattern defines the elements and element values that the Server SHALL be capable of providing. CONF-0090 •must-support.html#must-support---primitive-elements SHALL Primitive elements are single elements with a primitive value. If they are marked as Must Support, then the Server SHALL be capable of providing the element value to meet the Must Support requirement. CONF-0091 •must-support.html#must-support---primitive-elements SHALL [W]hen claiming conformance [to a profile with a must support primitive element] … US Core responders SHALL be capable of providing the value [of the primitive element] CONF-0093 •must-support.html#must-support---complex-elements SHALL For any complex element marked as Must Support, the Server SHALL be capable of providing at least one of the sub-element values. CONF-0094 •must-support.html#must-support---complex-elements SHALL If any sub-element is marked as Must Support [for a complex element], it SHALL also meet the Must Support requirements and satisfy the Must Support requirements for the parent element. CONF-0095 •must-support.html#must-support---complex-elements MAY [I]f any sub-element is marked as Must Support or Additional USCDI [for a complex element] and the parent element is not, there is no expectation that you must support the parent. CONF-0096 •must-support.html#must-support---complex-elements SHALL [I]f any sub-element is marked as Must Support [for a complex element] and the parent element is not… [and] the parent element is present in an instance, Servers SHALL support the sub-element(s) marked as Must Support. CONF-0097 •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 Responders SHALL be capable of providing a value in [the] sub-element CONF-0099 •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 Responders SHALL be capable of providing a value in [each must support sub-element] CONF-0101 •must-support.html#must-support---complex-elements MAY Systems [US Core Responders] 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-0105 •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-0107 •must-support.html#must-support---resource-references MAY Systems [US Core Responders] can support other [resource] references [other than those labeled as Must Support], but this is not a requirement of US Core CONF-0109 •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-0111 •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 Responders SHALL be capable of populating [the Must Support data type choice] CONF-0114 •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 Responders] MAY support populating ... other [data type] choice elements (such as Observation.effectivePeriod), but this is not a requirement of US Core. CONF-0115 •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 Server or Certifying System SHALL support at least one element. CONF-0117 •scopes.html#capability-sets MAY An individual SMART Server will publish a granular list of its capabilities, and a set of these capabilities is combined to support a specific use, a Capability Set. See SMART App Launch’s FHIR OAuth authorization Endpoints and Capabilities for more details. Servers MAY support ... [any] SMART on FHIR Capability Sets and capabilities [(see FHIR OAuth authorization Endpoints and Capabilities)] CONF-0118 •scopes.html#capabilities-for-implementations-supporting-user-facing-applications SHOULD At least one of the following SMART on FHIR Capability Sets SHOULD be supported for US Core Servers that support User-Facing Applications ... Patient Access Standalone Apps Clinician Access for EHR Launch CONF-0119 •scopes.html#capabilities-for-implementations-supporting-user-facing-applications SHALL For certified systems[, those participating in the ONC IT Health Certification program], both SHALL be supported: Patient Access Standalone Apps Clinician Access for EHR Launch CONF-0120 •scopes.html#capabilities-for-implementations-supporting-backend-services SHALL Implementations [US Core Responders] supporting Backend Services ... SHALL include support for the Client-confidential-asymmetric capability. CONF-0121 •scopes.html#capabilities-for-implementations-supporting-backend-services SHALL Implementations [US Core Responders] supporting Backend Services ... SHALL include support for the ... system/scopes. CONF-0123 •scopes.html#us-core-Servers-shall-support-token-introspection SHALL US Core Server[s] SHALL support token introspection defined by the SMART App Launch Guide. For more details and additional consideration, see SMART App Launch’s Token Introspection. CONF-0125 •scopes.html#smart-scopes MAY Other systems MAY support scopes for the US Core APIs they support [instead of all US Core's required scopes] CONF-0126 •scopes.html#smart-scopes MAY Servers MAY support other scopes in addition to those listed below and in the Quick Start sections. CONF-0128 •scopes.html#us-core-scopes SHALL For “User-Facing Applications”, a system’s support for patient-level (patient) or user-level (user) scopes depends on its published list of SMART on FHIR capabilities (see the capability sets above). For example, if a Server lists permission-patient and permission-user in its capabilities, it SHALL support both patient-level and user-level required scopes CONF-0129 •scopes.html#us-core-scopes SHOULD For “User-Facing Applications”, a system’s support for patient-level (patient) or user-level (user) scopes depends on its published list of SMART on FHIR capabilities (see the capability sets above). For example, if a Server lists permission-patient and permission-user in its capabilities, it ... SHOULD support both patient-level and user-level recommended best-practice scopes CONF-0130 •scopes.html#us-core-scopes SHALL For “Backend-Services”, System-level scopes (system) describe data that a Client system is directly authorized to access. Systems that support system-level (system) scopes SHALL support the required US Core scopes CONF-0131 •scopes.html#us-core-scopes SHOULD For “Backend-Services”, System-level scopes (system) describe data that a Client system is directly authorized to access. Systems that support system-level (system) scopes SHOULD support the recommended US Core scopes CONF-0132 •scopes.html#scopes-for-requesting-fhir-resources-by-type •StructureDefinition-us-core-allergyintolerance.html#us-core-scopes SHALL The following scopes that correspond directly to FHIR resource types SHALL be supported ... [For] AllergyIntolerance [the] <patient|user|system>/AllergyIntolerance.rs [see SMART Clinical Scope Syntax for details on clinical data scopes] CONF-0133 •scopes.html#scopes-for-requesting-fhir-resources-by-type SHALL The following scopes that correspond directly to FHIR resource types SHALL be supported ... [For] CarePlan [the] <patient|user|system>/CarePlan.rs [see SMART Clinical Scope Syntax for details on clinical data scopes] CONF-0134 •scopes.html#scopes-for-requesting-fhir-resources-by-type SHALL The following scopes that correspond directly to FHIR resource types SHALL be supported ... [For] CareTeam [the] <patient|user|system>/CareTeam.rs [see SMART Clinical Scope Syntax for details on clinical data scopes] CONF-0135 •scopes.html#scopes-for-requesting-fhir-resources-by-type SHALL The following scopes that correspond directly to FHIR resource types SHALL be supported ... [For] Condition [the] <patient|user|system>/Condition.rs [see SMART Clinical Scope Syntax for details on clinical data scopes] CONF-0136 •scopes.html#scopes-for-requesting-fhir-resources-by-type SHALL The following scopes that correspond directly to FHIR resource types SHALL be supported ... [For] Coverage [the] <patient|user|system>/Coverage.rs [see SMART Clinical Scope Syntax for details on clinical data scopes] CONF-0137 •scopes.html#scopes-for-requesting-fhir-resources-by-type SHALL The following scopes that correspond directly to FHIR resource types SHALL be supported ... [For] Device [the] <patient|user|system>/Device.rs [see SMART Clinical Scope Syntax for details on clinical data scopes] CONF-0138 •scopes.html#scopes-for-requesting-fhir-resources-by-type SHALL The following scopes that correspond directly to FHIR resource types SHALL be supported ... [For] DiagnosticReport [the] <patient|user|system>/DiagnosticReport.rs [see SMART Clinical Scope Syntax for details on clinical data scopes] CONF-0139 •scopes.html#scopes-for-requesting-fhir-resources-by-type SHALL The following scopes that correspond directly to FHIR resource types SHALL be supported ... [For] DocumentReference [the] <patient|user|system>/DocumentReference.rs [see SMART Clinical Scope Syntax for details on clinical data scopes] CONF-0140 •scopes.html#scopes-for-requesting-fhir-resources-by-type SHALL The following scopes that correspond directly to FHIR resource types SHALL be supported ... [For] Encounter [the] <patient|user|system>/Encounter.rs [see SMART Clinical Scope Syntax for details on clinical data scopes] CONF-0141 •scopes.html#scopes-for-requesting-fhir-resources-by-type SHALL The following scopes that correspond directly to FHIR resource types SHALL be supported ... [For] Goal [the] <patient|user|system>/Goal.rs [see SMART Clinical Scope Syntax for details on clinical data scopes] CONF-0142 •scopes.html#scopes-for-requesting-fhir-resources-by-type SHALL The following scopes that correspond directly to FHIR resource types SHALL be supported ... [For] Immunization [the] <patient|user|system>/Immunization.rs [see SMART Clinical Scope Syntax for details on clinical data scopes] CONF-0143 •scopes.html#scopes-for-requesting-fhir-resources-by-type SHALL The following scopes that correspond directly to FHIR resource types SHALL be supported ... [For] MedicationDispense [the] <patient|user|system>/MedicationDispense.rs [see SMART Clinical Scope Syntax for details on clinical data scopes] CONF-0144 •scopes.html#scopes-for-requesting-fhir-resources-by-type SHALL The following scopes that correspond directly to FHIR resource types SHALL be supported ... [For] MedicationRequest [the] <patient|user|system>/MedicationRequest.rs [see SMART Clinical Scope Syntax for details on clinical data scopes] CONF-0145 •scopes.html#scopes-for-requesting-fhir-resources-by-type SHALL The following scopes that correspond directly to FHIR resource types SHALL be supported ... [For] Observation [the] <patient|user|system>/Observation.rs [see SMART Clinical Scope Syntax for details on clinical data scopes] CONF-0146 •scopes.html#scopes-for-requesting-fhir-resources-by-type SHALL The following scopes that correspond directly to FHIR resource types SHALL be supported ... [For] Organization [the] <patient|user|system>/Organization.rs [see SMART Clinical Scope Syntax for details on clinical data scopes] CONF-0147 •scopes.html#scopes-for-requesting-fhir-resources-by-type SHALL The following scopes that correspond directly to FHIR resource types SHALL be supported ... [For] Patient [the] <patient|user|system>/Patient.rs [see SMART Clinical Scope Syntax for details on clinical data scopes] CONF-0148 •scopes.html#scopes-for-requesting-fhir-resources-by-type SHALL The following scopes that correspond directly to FHIR resource types SHALL be supported ... [For] Practitioner [the] <patient|user|system>/Practitioner.rs [see SMART Clinical Scope Syntax for details on clinical data scopes] CONF-0149 •scopes.html#scopes-for-requesting-fhir-resources-by-type SHALL The following scopes that correspond directly to FHIR resource types SHALL be supported ... [For] PractitionerRole [the] <patient|user|system>/PractitionerRole.rs [see SMART Clinical Scope Syntax for details on clinical data scopes] CONF-0150 •scopes.html#scopes-for-requesting-fhir-resources-by-type SHALL The following scopes that correspond directly to FHIR resource types SHALL be supported ... [For] Procedure [the] <patient|user|system>/Procedure.rs [see SMART Clinical Scope Syntax for details on clinical data scopes] CONF-0151 •scopes.html#scopes-for-requesting-fhir-resources-by-type SHALL The following scopes that correspond directly to FHIR resource types SHALL be supported ... [For] Provenance [the] <patient|user|system>/Provenance.rs [see SMART Clinical Scope Syntax for details on clinical data scopes] CONF-0152 •scopes.html#scopes-for-requesting-fhir-resources-by-type SHALL The following scopes that correspond directly to FHIR resource types SHALL be supported ... [For] QuestionnaireResponse [the] <patient|user|system>/QuestionnaireResponse.rs [see SMART Clinical Scope Syntax for details on clinical data scopes] CONF-0153 •scopes.html#scopes-for-requesting-fhir-resources-by-type SHALL The following scopes that correspond directly to FHIR resource types SHALL be supported ... [For] RelatedPerson [the] <patient|user|system>/RelatedPerson.rs [see SMART Clinical Scope Syntax for details on clinical data scopes] CONF-0154 •scopes.html#scopes-for-requesting-fhir-resources-by-type SHALL The following scopes that correspond directly to FHIR resource types SHALL be supported ... [For] ServiceRequest [the] <patient|user|system>/ServiceRequest.rs [see SMART Clinical Scope Syntax for details on clinical data scopes] CONF-0155 •scopes.html#scopes-for-requesting-fhir-resources-by-type SHALL The following scopes that correspond directly to FHIR resource types SHALL be supported ... [For] Specimen [the] <patient|user|system>/Specimen.rs [see SMART Clinical Scope Syntax for details on clinical data scopes] CONF-0156 •scopes.html#scopes-for-requesting-fhir-resources-by-type MAY The following scopes that correspond directly to FHIR resource types MAY be supported ... [For] Location [the] <patient|user|system>/Location.rs [see SMART Clinical Scope Syntax for details on clinical data scopes] CONF-0157 •scopes.html#scopes-for-requesting-fhir-resources-by-type MAY The following scopes that correspond directly to FHIR resource types MAY be supported ... [For] Medication [the] <patient|user|system>/Medication.rs [see SMART Clinical Scope Syntax for details on clinical data scopes] CONF-0158 •scopes.html#granular-scopes-for-requesting-fhir-resources SHALL The following granular scopes SHALL be supported ... [For] Condition [the] <patient|user|system>/Condition.rs?category=http://hl7.org/fhir/us/core/CodeSystem/condition-category|health-concern [see SMART Clinical Scope Syntax for details on clinical data scopes] CONF-0159 •scopes.html#granular-scopes-for-requesting-fhir-resources SHALL The following granular scopes SHALL be supported ... [For] Condition [the] <patient|user|system>/Condition.rs?category=http://terminology.hl7.org/CodeSystem/condition-category|encounter-diagnosis [see SMART Clinical Scope Syntax for details on clinical data scopes] CONF-0160 •scopes.html#granular-scopes-for-requesting-fhir-resources SHALL The following granular scopes SHALL be supported ... [For] Condition [the] <patient|user|system>/Condition.rs?category=http://terminology.hl7.org/CodeSystem/condition-category|problem-list-item [see SMART Clinical Scope Syntax for details on clinical data scopes] CONF-0161 •scopes.html#granular-scopes-for-requesting-fhir-resources SHALL The following granular scopes SHALL be supported ... [For] Observation [the] <patient|user|system>/Observation.rs?category=http://hl7.org/fhir/us/core/CodeSystem/us-core-category|sdoh [see SMART Clinical Scope Syntax for details on clinical data scopes] CONF-0162 •scopes.html#granular-scopes-for-requesting-fhir-resources SHALL The following granular scopes SHALL be supported ... [For] Observation [the] <patient|user|system>/Observation.rs?category=http://terminology.hl7.org//CodeSystem-observation-category|social-history [see SMART Clinical Scope Syntax for details on clinical data scopes] CONF-0163 •scopes.html#granular-scopes-for-requesting-fhir-resources SHALL The following granular scopes SHALL be supported ... [For] Observation [the] <patient|user|system>/Observation.rs?category=http://terminology.hl7.org/CodeSystem/observation-category|laboratory [see SMART Clinical Scope Syntax for details on clinical data scopes] CONF-0164 •scopes.html#granular-scopes-for-requesting-fhir-resources SHALL The following granular scopes SHALL be supported ... [For] Observation [the] <patient|user|system>/Observation.rs?category=http://terminology.hl7.org/CodeSystem/observation-category|survey [see SMART Clinical Scope Syntax for details on clinical data scopes] CONF-0165 •scopes.html#granular-scopes-for-requesting-fhir-resources SHALL The following granular scopes SHALL be supported ... [For] Observation [the] <patient|user|system>/Observation.rs?category=http://terminology.hl7.org/CodeSystem/observation-category|vital-signs [see SMART Clinical Scope Syntax for details on clinical data scopes] CONF-0166 •scopes.html#granular-scopes-for-requesting-fhir-resources SHOULD The following granular scopes SHOULD be supported ... [For] DocumentReference [the] <patient|user|system>/DocumentReference.rs?category=http://hl7.org/fhir/us/core/CodeSystem/us-core-documentreference-category|clinical-note [see SMART Clinical Scope Syntax for details on clinical data scopes] CONF-0167 •scopes.html#Servers-shall-support-the-following-metadata-in-their-well-knownsmart-configuration SHALL In addition to the capabilities defined in the Server’s CapabilityStatement, Servers SHALL document their SMART capabilities in their Well-Known Uniform Resource Identifiers (URIs) JSON file. CONF-0168 •scopes.html#additional-us-core-requirements SHALL 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 Server SHALL list all the required US Core Scopes for the US Core Profiles they support in the scopes_supported array CONF-0169 •scopes.html#additional-us-core-requirements MAY 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 Server [MAY support] additional scopes (so Clients SHOULDnot consider … [the required scopes] an exhaustive list). CONF-0170 •scopes.html#additional-us-core-requirements MAY 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. Servers MAY limit Clients’ scopes to those configured at registration time. CONF-0171 •scopes.html#additional-us-core-requirements SHALL 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. … Servers SHALL allow users to select a subset of the requested scopes at the approval time. CONF-0173 •scopes.html#additional-us-core-requirements SHALL US Core requires ... additional metadata [to be available through the Server's Well-Known Uniform Resource Identifier (URI)]: ... [in] introspection_endpoint the URL to a Server’s introspection endpoint. ... Servers SHALL document this endpoint in the file CONF-0174 •general-guidance.html#referencing-us-core-profiles SHOULD Therefore, a reference to a US Core resource SHOULD include a logical id (Reference.reference), not an identifier (Reference.identifier). CONF-0175 •general-guidance.html#referencing-us-core-profiles SHOULD For all references, US Core Responders SHOULD return resources that conform to a US Core profile if a US Core profile exists for the resource type. CONF-0176 •general-guidance.html#contained-resources SHOULD-NOT When responding to a query, Servers SHOULD not use inline contained resources to represent the returned data. CONF-0177 •general-guidance.html#contained-resources SHOULD [I]f referencing a contained resource in a US Core Profile, the contained resource SHOULD be a US Core Profile if a US Core Profile exists for the resource type. CONF-0178 •general-guidance.html#contained-resources SHOULD [M]asking data [where a specific piece of data is hidden for security and privacy reasons] SHOULD be handled based on implemented policies. CONF-0179 •general-guidance.html#contained-resources SHOULD [When masking data] elements with a minimum cardinality = 0 (including elements labeled Must Support) [for security and privacy reasons], the element SHOULD be omitted from the resource. CONF-0180 •general-guidance.html#contained-resources SHOULD [When masking] Mandatory elements (in other words, where the minimum cardinality is > 0) [for security and privacy reasons, use the code “unknown” following the guidance on Missing Data in the Conformance Sections. CONF-0181 •general-guidance.html#snomed-ct-united-states-edition MAY [When using SNOMED codes in US Core Profiles I]mplementers MAY use the default system URI [of SNOMED CT], which refers to an unspecified edition/version [of SNOMED] CONF-0182 •general-guidance.html#snomed-ct-united-states-edition SHOULD [To enable] terminology Servers to be able to validate US Edition-only codes [of SNOMED CT], implementers SHOULD provide the accompanying system URI to describe the edition [see example 2 on US Core general guidance] CONF-0183 •general-guidance.html#using-ucum-codes-in-the-quantity-datatype SHOULD [If a] US Core Profiles binds the Quantity.code element in the Quantity datatype to the UCUM code system, [then] systems SHOULDalso use UCUM for the optional valueRange and valueRatio datatypes (which are complex datatypes with Quantity elements) CONF-0184 •general-guidance.html#using-ucum-codes-in-the-quantity-datatype SHOULD [If a] US Core Profiles binds the Quantity.code element in the Quantity datatype to the UCUM code system, [when] UCUM code [is] provided [it SHOULD be indicated in the Quantity.unit and Quantity.code elements with Quantity.system = "http://unitsofmeasure.org"] CONF-0185 •general-guidance.html#using-ucum-codes-in-the-quantity-datatype SHOULD [If a] US Core Profiles binds the Quantity.code element in the Quantity datatype to the UCUM code system, [then] if UCUM units are unavailable, represent units in the unit element CONF-0186 •general-guidance.html#using-ucum-codes-in-the-quantity-datatype SHOULD-NOT SHOULD NOT supply the unit field] CONF-0187 •general-guidance.html#representing-deleted-and-entered-in-error-information SHOULD-NOT A FHIR Server SHOULD not delete records. CONF-0188 •general-guidance.html#representing-deleted-and-entered-in-error-information SHOULD A FHIR Server SHOULD update the appropriate resource status to entered-in-error or inactive [when requested to delete records] CONF-0189 •general-guidance.html#representing-deleted-and-entered-in-error-information SHOULD If a system supports the deletion of records, they SHOULD refer to the Deletion Safety Checks in the FHIR specification. CONF-0190 •general-guidance.html#representing-deleted-and-entered-in-error-information SHOULD A FHIR Server SHOULD allow these resources [those entered in error] to be searchable by Client applications. CONF-0191 •general-guidance.html#representing-deleted-and-entered-in-error-information SHOULD If the FHIR Server has updated the resource status to entered-in-error: For patient facing applications, A FHIR Server SHOULD remove the resource’s contents, leaving only an id and status. Note that this typically will not conform to the US Core or FHIR StructureDefinitions. CONF-0192 •general-guidance.html#representing-deleted-and-entered-in-error-information MAY If the FHIR Server has updated the resource status to entered-in-error: ... For provider-facing applications, the content MAY be supplied with content and additional detail (such as the reason for the status change) that the patient viewing system would typically not have access to. CONF-0193 •general-guidance.html#language-support SHOULD the data provider SHOULD do their best to translate (safely) to the requested language [when accessing records in a native or requested language] CONF-0195 •general-guidance.html#language-support SHOULD [When Clients request a resource in a specific language] Servers SHOULD make reasonable efforts to translate what can be safely translated. CONF-0196 •general-guidance.html#language-support SHOULD [When Clients request a resource in a specific language] Servers SHOULD populate the Resource’s language element with a code based on the underlying language of record, not the requested language. CONF-0197 •general-guidance.html#language-support SHOULD [When Clients request a resource in a specific language] Servers SHOULD … [use] the Human Language Extension when the language of a display, etc, is known to differ from the stated (or inferred) language. CONF-0198 •general-guidance.html#language-support SHOULD [When Clients request a resource in a specific language] [Servers SHOULD use] the Translation Extension when the Server provides additional translations by its own choice or in response to a different Accept-Language than what the resource is stored in. CONF-0199 •general-guidance.html#language-support SHOULD [When Clients request a resource in a specific language] Servers SHOULD make it known what languages are supported in their CapabilityStatement(s) using this extension: http://hl7.org/fhir/5.0/StructureDefinition/extension-CapablilityStatement.acceptLanguage [definition] CONF-0200 •general-guidance.html#searching-using-lastupdated SHOULD Servers SHOULD support the _lastUpdated search parameter for US Core Profiles CONF-0201 •general-guidance.html#searching-using-lastupdated SHOULD Servers ... SHOULD populate Resource.meta.lastUpdated for US Core Profiles as accurately as possible. CONF-0202 •general-guidance.html#searching-using-lastupdated SHALL Servers SHALL document in CapabilityStatement.rest.resource.searchParam.documentation the types of changes that can be detected using the _lastUpdated search parameter CONF-0203 •general-guidance.html#compartment-based-search MAY US Core Servers [MAY support compartment based searchs, but] are not required to support patient compartment based searches. CONF-0204 •general-guidance.html#across-platform-searches MAY US Core Servers [MAY resolve absolute URLs, but] are not required to resolve absolute URLs external to their environment. CONF-0205 •general-guidance.html#limiting-the-number-of-search-results MAY Servers can [MAY] choose to return the results in a series of pages to manage the number of search results returned. CONF-0206 •clinical-notes.html#clinical-notes •clinical-notes.html#support-requirements SHALL Servers SHALL support, at minimum, these … "Common Clinical Notes": Consultation Note (11488-4) CONF-0207 •clinical-notes.html#clinical-notes •clinical-notes.html#support-requirements SHALL Servers SHALL support, at minimum, these … "Common Clinical Notes": Discharge Summary (18842-5) CONF-0208 •clinical-notes.html#clinical-notes •clinical-notes.html#support-requirements SHALL Servers SHALL support, at minimum, these … "Common Clinical Notes": History & Physical Note (34117-2) CONF-0209 •clinical-notes.html#clinical-notes •clinical-notes.html#support-requirements SHALL Servers SHALL support, at minimum, these … "Common Clinical Notes": Procedures Note (28570-0) CONF-0210 •clinical-notes.html#clinical-notes •clinical-notes.html#support-requirements SHALL Servers SHALL support, at minimum, these … "Common Clinical Notes": Progress Note (11506-3) CONF-0211 •clinical-notes.html#clinical-notes •clinical-notes.html#support-requirements SHALL Servers SHALL support, at minimum, these … "Common Clinical Notes": Imaging Narrative (18748-4) CONF-0212 •clinical-notes.html#clinical-notes •clinical-notes.html#support-requirements SHALL Servers SHALL support, at minimum, these … "Common Clinical Notes": Laboratory Report Narrative (11502-2) CONF-0213 •clinical-notes.html#clinical-notes •clinical-notes.html#support-requirements SHALL Servers SHALL support, at minimum, these … "Common Clinical Notes": Pathology Report Narrative (11526-1) CONF-0214 •clinical-notes.html#clinical-notes •clinical-notes.html#support-requirements SHALL Servers SHALL support, at minimum, these … DiagnosticReport categories: Cardiology (LP29708-2) CONF-0215 •clinical-notes.html#clinical-notes •clinical-notes.html#support-requirements SHALL Servers SHALL support, at minimum, these … DiagnosticReport categories: Pathology (LP7839-6) CONF-0216 •clinical-notes.html#clinical-notes •clinical-notes.html#support-requirements SHALL Servers SHALL support, at minimum, these … DiagnosticReport categories: Radiology (LP29684-5) CONF-0217 •clinical-notes.html#clinical-notes SHOULD systems are encouraged to support other common notes types, such as: Referral Note (57133-1) CONF-0219 •clinical-notes.html#clinical-notes SHOULD systems are encouraged to support other common notes types, such as: Nurse Note (34746-8) CONF-0220 •clinical-notes.html#fhir-resources-to-exchange-clinical-notes SHALL To enable consistent access to scanned DiagnosticReport clinical reports, the FHIR Server SHALL expose these overlapping scanned or narrative-only reports through both DiagnosticReport and DocumentReference by representing the same attachment URL [as] DocumentReference.content.attachment.url [and] DiagnosticReport.presentedForm.url CONF-0221 •clinical-notes.html#fhir-resources-to-exchange-clinical-notes SHALL when DiagnosticReport.presentedForm.url references a Scan (PDF), that Attachment SHALL also be accessible through DocumentReference.content.attachment.url CONF-0222 •clinical-notes.html#support-requirements MAY Systems [Servers] MAY extend their capabilities [around types of clinical notes] to the complete US Core DocumentReference Type Value Set. CONF-0223 •clinical-notes.html#support-requirements SHALL Systems SHALL implement the US Core DocumentReference Profile CONF-0224 •clinical-notes.html#support-requirements SHALL Systems SHALL implement the US Core DiagnosticReport Profile for Report and Note exchange CONF-0225 •clinical-notes.html#support-requirements MAY Systems [Servers] MAY support other [DiagnosticReport] categories as well. CONF-0227 •clinical-notes.html#support-requirements SHOULD The following SHOULD be exposed via DiagnosticReport: Imaging Narrative CONF-0228 •clinical-notes.html#support-requirements SHOULD The following SHOULD be exposed via DiagnosticReport: Laboratory Report Narrative CONF-0229 •clinical-notes.html#support-requirements SHOULD The following SHOULD be exposed via DiagnosticReport: Pathology Report Narrative CONF-0230 •clinical-notes.html#support-requirements SHOULD The following SHOULD be exposed via DiagnosticReport: Procedure Note CONF-0231 •clinical-notes.html#support-requirements SHALL Servers that support DiagnosticReport SHALL include the clinical note narrative content in DiagnosticReport.presentedForm CONF-0233 •clinical-notes.html#using-expand SHOULD FHIR Server claiming support to this guide SHOULD support the $expand operation [operation link to provide information to Clients requesting information on the note and report types the Server supports] CONF-0234 •clinical-notes.html#using-expand SHOULD [If Servers support the $expand operation for discovering note and report types, then Servers SHALL support] the #expand operation as follows: GET [base]/ValueSet/$expand?context=http://hl7.org/fhir/us/core/StructureDefinition/us-core-diagnosticreport-note#DiagnosticReport.category&contextDirection=outgoing for DiagnosticReport report category discovery [for read operations] CONF-0235 •clinical-notes.html#using-expand SHOULD [If Servers support the $expand operation for discovering note and report types, then Servers SHALL support] the #expand operation as follows: GET [base]/ValueSet/$expand?context=http://hl7.org/fhir/us/core/StructureDefinition/us-core-diagnosticreport-note#DiagnosticReport.category&contextDirection=incoming for DiagnosticReport report category discovery [for write operations] CONF-0236 •clinical-notes.html#using-expand SHOULD [If Servers support the $expand operation for discovering note and report types, then Servers SHALL support] the #expand operation as follows: GET [base]/ValueSet/$expand?context=http://hl7.org/fhir/us/core/StructureDefinition/us-core-diagnosticreport-note#DiagnosticReport.code&contextDirection=outgoing for DiagnosticReport report type discovery [for read operations] CONF-0237 •clinical-notes.html#using-expand SHOULD [If Servers support the $expand operation for discovering note and report types, then Servers SHALL support] the #expand operation as follows: GET [base]/ValueSet/$expand?context=http://hl7.org/fhir/us/core/StructureDefinition/us-core-diagnosticreport-note#DiagnosticReport.code&contextDirection=incoming for DiagnosticReport report type discovery [for write operations] CONF-0238 •clinical-notes.html#using-expand SHOULD [If Servers support the $expand operation for discovering note and report types, then Servers SHALL support] the #expand operation as follows: GET [base]/ValueSet/$expand?context=http://hl7.org/fhir/us/core/StructureDefinition/us-core-documentreference#DocumentReference.category&contextDirection=outgoing for DocumentReference note category discovery [for read operations] CONF-0239 •clinical-notes.html#using-expand SHOULD [If Servers support the $expand operation for discovering note and report types, then Servers SHALL support] the #expand operation as follows: GET [base]/ValueSet/$expand?context=http://hl7.org/fhir/us/core/StructureDefinition/us-core-documentreference#DocumentReference.category&contextDirection=incoming for DocumentReference note category discovery [for write operations] CONF-0240 •clinical-notes.html#using-expand SHOULD [If Servers support the $expand operation for discovering note and report types, then Servers SHALL support] the #expand operation as follows: GET [base]/ValueSet/$expand?context=http://hl7.org/fhir/us/core/StructureDefinition/us-core-documentreference#DocumentReference.type&contextDirection=outgoing for DocumentReference note type discovery [for read operations] CONF-0241 •clinical-notes.html#using-expand SHOULD [If Servers support the $expand operation for discovering note and report types, then Servers SHALL support] the #expand operation as follows: GET [base]/ValueSet/$expand?context=http://hl7.org/fhir/us/core/StructureDefinition/us-core-documentreference#DocumentReference.type&contextDirection=incoming for DocumentReference note type discovery [for write operations] CONF-0242 •clinical-notes.html#discovering-Server-read-and-write-formats SHOULD [If Servers support the $expand operation then] the note and report types for a particular Server [SHOULD be] discovered by invoking the #expand operation as follows: GET [base]/ValueSet/$expand?context=http://hl7.org/fhir/us/core/StructureDefinition/us-core-diagnosticreport-note#DiagnosticReport.presentedForm.contentType&contextDirection=outgoing for DiagnosticReport report content type discovery [for read operations] CONF-0243 •clinical-notes.html#discovering-Server-read-and-write-formats SHOULD [If Servers support the $expand operation then] the note and report types for a particular Server [SHOULD be] discovered by invoking the #expand operation as follows: GET [base]/ValueSet/$expand?context=http://hl7.org/fhir/us/core/StructureDefinition/us-core-diagnosticreport-note#DiagnosticReport.presentedForm.contentType&contextDirection=incoming for DiagnosticReport report content type discovery [for write operations] CONF-0244 •clinical-notes.html#discovering-Server-read-and-write-formats SHOULD [If Servers support the $expand operation then] the note and report types for a particular Server [SHOULD be] discovered by invoking the #expand operation as follows: GET [base]/ValueSet/$expand?context=http://hl7.org/fhir/us/core/StructureDefinition/us-core-documentreference#DocumentReference.content.attachment.contentType&contextDirection=outgoing for DocumentReference note content type discovery [for read operations] CONF-0245 •clinical-notes.html#discovering-Server-read-and-write-formats SHOULD [If Servers support the $expand operation then] the note and report types for a particular Server [SHOULD be] discovered by invoking the #expand operation as follows: GET [base]/ValueSet/$expand?context=http://hl7.org/fhir/us/core/StructureDefinition/us-core-documentreference#DocumentReference.content.attachment.contentType&contextDirection=incoming for DocumentReference note content type discovery [for write operations] CONF-0247 •medication-list.html#options-for-representing-medication SHALL When using a code [to represent a medication][, the code SHALL follow the extensible binding rules to Medication Clinical Drug (RxNorm) - i.e., unless RxNorm does not cover the concept, the RxNorm code SHALL be used. CONF-0248 •medication-list.html#options-for-representing-medication •StructureDefinition-us-core-medicationdispense.html#profile-specific-implementation-guidance •StructureDefinition-us-core-medicationrequest.html#profile-specific-implementation-guidance •StructureDefinition-us-core-medication.html#profile-specific-implementation-guidance MAY USCDI recommends the National Drug Codes (NDC) as an optional medication terminology. They MAY be supplied as an additional coding element [when representing a medication] CONF-0249 •medication-list.html#options-for-representing-medication MAY When referencing the Medication resource, the resource MAY be included in the returned bundle, as an external resource, or as a contained resource if it can’t stand alone. … The Server application MAY choose any combination of these methods CONF-0250 •medication-list.html#options-for-representing-medication SHALL if an external reference to Medication is used, the Server SHALL support the _include parameter for searching this element CONF-0252 •medication-list.html#fetching-all-medications-active-medications-and-all-medications-for-an-encounter SHALL Requirements to access “all medications” [all historical, active, and future prescribed medications and medications entered in error and whose status is unknown.] and “all active medications” [all medications with an active status. Active medications do not include past, future, unknown status, and entered-in-error medications.] for a patient: A MedicationRequest resource query SHALL be all that is required to access "all medications" or "all active medications" for a patient. (In other words, no other medication resource type needs to be fetched) CONF-0253 •medication-list.html#fetching-all-medications-active-medications-and-all-medications-for-an-encounter SHALL Requirements to access “all medications” [all historical, active, and future prescribed medications and medications entered in error and whose status is unknown.] and “all active medications” [all medications with an active status. Active medications do not include past, future, unknown status, and entered-in-error medications.] for a patient: The [MedicationRequest resource] query result SHALL include all MedicationRequest resources with a MedicationRequest.intent = "order" representing authorized medication orders directly derived from the system's orders. CONF-0254 •medication-list.html#fetching-all-medications-active-medications-and-all-medications-for-an-encounter SHALL Requirements to access “all medications” [all historical, active, and future prescribed medications and medications entered in error and whose status is unknown.] and “all active medications” [all medications with an active status. Active medications do not include past, future, unknown status, and entered-in-error medications.] for a patient: The [MedicationRequest resource] query result SHALL include all prescribed and "self-prescribed" MedicationRequest resources with a MedicationRequest.intent = "plan" representing reported medications. CONF-0256 •medication-list.html#fetching-all-medications-active-medications-and-all-medications-for-an-encounter SHALL Requirements to access “all medications” [all historical, active, and future prescribed medications and medications entered in error and whose status is unknown.] and “all active medications” [all medications with an active status. Active medications do not include past, future, unknown status, and entered-in-error medications.] for a patient: Servers SHALL use the MedicationRequest.reported[x] element to indicate that the MedicationRequest record was captured as a secondary "reported" record rather than an original primary source-of-truth record. CONF-0258 •medication-list.html#fetching-all-medications-active-medications-and-all-medications-for-an-encounter SHOULD Requirements to access “all medications” [all historical, active, and future prescribed medications and medications entered in error and whose status is unknown.] and “all active medications” [all medications with an active status. Active medications do not include past, future, unknown status, and entered-in-error medications.] for a patient: When recording "self-prescribed" medication, Servers SHOULD use the MedicationRequest.requester element to indicate the Patient or RelatedPerson is the prescriber. CONF-0259 •medication-list.html#fetching-all-medications-active-medications-and-all-medications-for-an-encounter SHOULD Requirements to access “all medications” [all historical, active, and future prescribed medications and medications entered in error and whose status is unknown.] and “all active medications” [all medications with an active status. Active medications do not include past, future, unknown status, and entered-in-error medications.] for a patient: Servers SHOULD support the encounter search parameter. CONF-0260 •medication-list.html#fetching-all-medications-active-medications-and-all-medications-for-an-encounter SHOULD Requirements to access “all medications” [all historical, active, and future prescribed medications and medications entered in error and whose status is unknown.] and “all active medications” [all medications with an active status. Active medications do not include past, future, unknown status, and entered-in-error medications.] for a patient: [If Servers support the encounter search parameter, s]earching by encounter will return all medications ordered during that encounter, including medications administered in the hospital and prescribed or discharge medications intended to be taken at home. CONF-0262 •medication-list.html#fetching-all-medications-active-medications-and-all-medications-for-an-encounter MAY Requirements to access “all medications” [all historical, active, and future prescribed medications and medications entered in error and whose status is unknown.] and “all active medications” [all medications with an active status. Active medications do not include past, future, unknown status, and entered-in-error medications.] for a patient: Servers MAY support the search parameters categoryand encounter. This search will return all medications ordered during an encounter for a given MedicationRequest.category such as "inpatient". CONF-0263 •medication-list.html#de-duplication-of-data MAY To provide a list of a patient’s medications, it MAY be necessary to “de-duplicate” them. The de-duplication activity MAY be supplied by the Server CONF-0267 •basic-provenance.html#hie-transformation MAY An agent.type=”assembler”, agent.type=”transmitter”, or other agents from Provenance Agent Type value set MAY also be included. CONF-0268 •screening-and-assessments.html#introduction SHOULD implementers [of US Core's framework of Screening and Assessments] SHOULD consider more constrained, domain-specific profiles derived from the US Core Profiles to meet the needs of their respective use cases. CONF-0269 •screening-and-assessments.html#clinical-judgments SHALL Every Server that supports the USDCI Data Class “Health Status/Assessments”: SHALL support representing clinical judgments using US Core Condition Problems and Health Concerns Profile or US Core Simple Observation Profile. CONF-0270 •screening-and-assessments.html#clinical-judgments SHOULD Every Server that supports the USDCI Data Class “Health Status/Assessments”: ... The US Core Simple Observation Profile's Observation.derivedFrom element SHOULD reference the Structured Screening and Assessment upon which clinical judgment observations are made CONF-0271 •screening-and-assessments.html#clinical-judgments SHOULD Every Server that supports the USDCI Data Class “Health Status/Assessments”: ... the US Core Condition Profile's Condition.evidence.detail element SHOULD reference the Structured Screening and Assessment which assist in diagnosing problems or health concerns. CONF-0272 •screening-and-assessments.html#choosing-between-questionnaireresponse-and-observation SHOULD For API developers using US Core, it’s important to understand when to use the QuestionnaireResponse versus Observation to represent structured assessments and surveys. Here are some guidelines to help choose the appropriate profile: Observations represent specific point-in-time facts that need to be searched, trended, the subject of statistical analysis, and directly referenced in support of other actions ... anything that meets one of the preceding criteria SHOULD be surfaced as an Observation. CONF-0280 •screening-and-assessments.html#uscdi-health-assessments-data-element-value-sets SHOULD Implementers SHOULD treat these [USCDI Health Status Assessments Data Element] value sets as having an extensible binding. CONF-0281 •screening-and-assessments.html#uscdi-health-assessments-data-element-value-sets SHOULD when recording SDOH data [with] US Core Profiles, Servers SHOULD use … Social Determinants of Health Conditions Value Set, Social Determinants of Health Procedures Value Set, Social Determinants of Health Goals Value Set, [and] Social Determinants of Health Service Requests Value Set CONF-0287 •changes-between-versions.html#no-guarantee-that-resource-ids-are-preserved SHOULD Servers SHOULD maintain a stable common identifier for a resource across [FHIR] versions. CONF-0288 •changes-between-versions.html#expectation-that-data-is-preserved-between-versions SHOULD In an upgraded R4 endpoint, any data in FHIR DSTU2 SHOULD be in FHIR R4. CONF-0289 •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-0290 •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-0291 •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-0295 •changes-between-versions.html#expectation-that-data-is-preserved-between-versions SHOULD Servers SHOULD make available the same information in DSTU2 and R4 where the more recent standard allows. CONF-0296 •changes-between-versions.html#expectation-that-data-is-preserved-between-versions SHOULD Servers SHOULD make available the same information in DSTU2 and R4 where the more recent standard allows … [with the] exception [of] MedicationStatement data [should be] mapped to MedicationRequest CONF-0297 •changes-between-versions.html#expectation-that-data-is-preserved-between-versions SHOULD Servers SHOULD make available the same information in DSTU2 and R4 where the more recent standard allows … [with the] exception [of] care teams, as represented by CarePlan, SHOULD be mapped to CareTeam in R4 CONF-0298 •changes-between-versions.html#expectation-that-data-is-preserved-between-versions SHOULD Data SHOULD be maintained between [FHIR] versions (i.e., not be degraded). CONF-0300 •changes-between-versions.html#authorization-across-versions SHOULD To allow Clients to use a single authorization token when accessing resources from multiple version-specific endpoints, Servers SHOULD use the same base authorization endpoint across versions. CONF-0302 •StructureDefinition-us-core-allergyintolerance.html#profile-specific-implementation-guidance SHALL [The clinical status of the allergy] SHALL be present if verification status is not “entered-in-error” CONF-0303 •StructureDefinition-us-core-allergyintolerance.html#profile-specific-implementation-guidance SHALL-NOT [The clinical status of the allergy] SHALL NOT be present if verification Status is “entered-in-error” CONF-0305 •StructureDefinition-us-core-allergyintolerance.html#profile-specific-implementation-guidance MAY No Known Allergies MAY be represented using the US Core-AllergyIntolerance profile CONF-0306 •StructureDefinition-us-core-allergyintolerance.html#profile-specific-implementation-guidance SHALL [When No Known Allergies is documented the system SHALL use an] appropriate negation code in AllergyIntolerance.code CONF-0307 •StructureDefinition-us-core-allergyintolerance.html#profile-specific-implementation-guidance SHALL [When No Known Allergies is documented the system SHALL use an] verification status in AllergyIntolerance.verificationStatus CONF-0308 •StructureDefinition-us-core-allergyintolerance.html#profile-specific-implementation-guidance SHOULD If a patient has not been asked about their allergies, this would be represented as: AllergyIntolerance.code = “1631000175102” (Patient not asked (contextual qualifier) (qualifier value)) AllergyIntolerance.verificationStatus = “unconfirmed” or empty (in other words, the element omitted) CONF-0309 •StructureDefinition-us-core-allergyintolerance.html#profile-specific-implementation-guidance SHOULD If a patient has been asked, but has indicated they have no known allergies, this would be represented as: AllergyIntolerance.code = “716186003” (No known allergy (situation)) AllergyIntolerance.verificationStatus = “confirmed” CONF-0310 •StructureDefinition-us-core-careplan.html#profile-specific-implementation-guidance SHOULD Considerations for systems aligning with HL7 Consolidated (C-CDA) Care Plan requirements: US Core Goal SHOULD be present in CarePlan.goal CONF-0311 •StructureDefinition-us-core-careplan.html#profile-specific-implementation-guidance SHOULD Considerations for systems aligning with [HL7 Consolidated (C-CDA)] (http://www.hl7.org/implement/standards/product_brief.cfm?product_id=492) Care Plan requirements: ... US Core Condition SHOULD be present in CarePlan.addresses CONF-0312 •StructureDefinition-us-core-careplan.html#profile-specific-implementation-guidance MAY Considerations for systems aligning with [HL7 Consolidated (C-CDA)] (http://www.hl7.org/implement/standards/product_brief.cfm?product_id=492) Care Plan requirements: Assessment and Plan MAY be included as narrative in CarePlan.text CONF-0313 •StructureDefinition-us-core-careteam.html#profile-specific-implementation-guidance SHALL Although both US Core Practitioner Profile and US Core PractitionerRole are Must Support, ... Server system[s conforming to the US Core CareTeam profile are] ... not required to support references to both, but SHALL support at least one of them CONF-0317 •StructureDefinition-us-core-careteam.html#profile-specific-implementation-guidance SHOULD [When conforming to the US Core CareTeam profile] Because the US Core PractitionerRole Profile supplies the provider’s location and contact information and a reference to the Practitioner, Server systems [conforming to the US Core CareTeam profile] SHOULD reference it instead of the US Core Practitioner Profile [when conforming to the US Core CareTeam profile] . CONF-0318 •StructureDefinition-us-core-careteam.html#profile-specific-implementation-guidance SHALL Servers [conforming to the US Core CareTeam profile] that support only US Core Practitioner Profile and do not support the US Core PractitionerRole Profile SHALL provide implementation-specific guidance on how to access a provider’s location ... information using only the Practitioner resource. CONF-0319 •StructureDefinition-us-core-careteam.html#profile-specific-implementation-guidance SHALL Servers [conforming to the US Core CareTeam profile] that support only US Core Practitioner Profile and do not support the US Core PractitionerRole Profile SHALL provide implementation-specific guidance on how to access a provider’s ... contact information using only the Practitioner resource. CONF-0323 •StructureDefinition-us-core-condition-encounter-diagnosis.html#profile-specific-implementation-guidance •StructureDefinition-us-core-condition-problems-health-concerns.html#profile-specific-implementation-guidance SHOULD USCDI’s applicable vocabulary standards for Encounter Diagnosis are SNOMED CT and ICD-10-CM. The US Core Condition Codes only supports ICD-9-CM for historical purposes. When using ICD codes, only non-header ICD-10-CM codes SHOULD be used as the primary code for current encounter diagnoses. CONF-0324 •StructureDefinition-us-core-condition-encounter-diagnosis.html#profile-specific-implementation-guidance SHOULD [A US Core Condition Encounter Diagnosis] encounter SHOULD always be referenced in Condition.encounter. CONF-0331 •StructureDefinition-us-core-condition-problems-health-concerns.html#profile-specific-implementation-guidance SHOULD If the category is "problem-list-item", Condition.clinicalStatus SHOULD be present. CONF-0332 •StructureDefinition-us-core-condition-problems-health-concerns.html#profile-specific-implementation-guidance SHOULD Updates to .meta.lastUpdated SHOULD reflect: New problems and health concerns CONF-0333 •StructureDefinition-us-core-condition-problems-health-concerns.html#profile-specific-implementation-guidance SHOULD Updates to .meta.lastUpdated SHOULD reflect: Changes in the clinical status or verification status of problems or health concerns. CONF-0334 •StructureDefinition-us-core-coverage.html#profile-specific-implementation-guidance MAY A coverage.type of “81” (Self-pay) MAY be used to imply that the patient has no coverage or that an individual or organization other than an insurer is taking responsibility for payment for a portion of the health care costs. CONF-0336 •StructureDefinition-us-core-coverage.html#profile-specific-implementation-guidance SHOULD To differentiate Medicare Parts A, B, C, and D systems SHOULD use the following codes [when sending Coverage.type]: [For] Part A and B [use] 121 (Medicare Fee For Service) CONF-0337 •StructureDefinition-us-core-coverage.html#profile-specific-implementation-guidance SHOULD To differentiate Medicare Parts A, B, C, and D systems SHOULD use the following codes: [For] Part C (Medicare Advantage Plan) [use] 111 (Medicare HMO), 112 (Medicare PPO), 113 (Medicare POS) CONF-0338 •StructureDefinition-us-core-coverage.html#profile-specific-implementation-guidance SHOULD To differentiate Medicare Parts A, B, C, and D systems SHOULD use the following codes: [For] Part D [use] 122 (Medicare Drug Benefit) CONF-0339 •StructureDefinition-us-core-coverage.html#profile-specific-implementation-guidance SHOULD If Insurers issue unique member IDs for dependents, then the memberId Coverage.identifier SHOULDbe used [with the unique dependent ID] instead of Coverage.dependent to uniquely refer to the dependent with respect to their insurance. CONF-0341 •StructureDefinition-us-core-device.html#profile-specific-implementation-guidance SHOULD Implementers SHOULD use the FDA Global UDI Database (GUDID) and associated APIs to parse and validate the [unique device ID] UDI CONF-0342 •StructureDefinition-us-core-device.html#profile-specific-implementation-guidance SHALL Medical devices with UDI information SHALL represent the UDI code in Device.udiCarrier.carrierHRF CONF-0343 •StructureDefinition-us-core-device.html#profile-specific-implementation-guidance SHALL UDI-PI elements present [in Device.udiCarrier.carrierHRF] SHALL be represented in the corresponding US Core Device Profile elements CONF-0344 •StructureDefinition-us-core-device.html#profile-specific-implementation-guidance SHOULD If UDI is not present and the manufacturer … is available, … [it] SHOULD be included to support historical reports of implantable medical devices [where] manufacturer [is sent in] Device.manufacturer CONF-0345 •StructureDefinition-us-core-device.html#profile-specific-implementation-guidance SHOULD If UDI is not present and the ... model number information is available, … [it] SHOULD be included to support historical reports of implantable medical devices [where] model [is sent in] Device.model CONF-0347 •StructureDefinition-us-core-device.html#profile-specific-implementation-guidance MAY Records of implanted devices MAY be queried against UDI data, including: UDI HRF string (udi-carrier) CONF-0348 •StructureDefinition-us-core-device.html#profile-specific-implementation-guidance MAY Records of implanted devices MAY be queried against UDI data, including:UDI Device Identifier (udi-di) CONF-0349 •StructureDefinition-us-core-device.html#profile-specific-implementation-guidance MAY Records of implanted devices MAY be queried against UDI data, including: Manufacturer (manufacturer) CONF-0350 •StructureDefinition-us-core-device.html#profile-specific-implementation-guidance MAY Records of implanted devices MAY be queried against UDI data, including: Model number (model) CONF-0351 •StructureDefinition-us-core-device.html#profile-specific-implementation-guidance MAY Implementers MAY also adopt custom SearchParameters for searching by lot numbers CONF-0352 •StructureDefinition-us-core-device.html#profile-specific-implementation-guidance MAY Implementers MAY also adopt custom SearchParameters for searching by serial number CONF-0353 •StructureDefinition-us-core-device.html#profile-specific-implementation-guidance MAY Implementers MAY also adopt custom SearchParameters for searching by expiration date CONF-0354 •StructureDefinition-us-core-device.html#profile-specific-implementation-guidance MAY Implementers MAY also adopt custom SearchParameters for searching by manufacture date CONF-0355 •StructureDefinition-us-core-device.html#profile-specific-implementation-guidance MAY Implementers MAY also adopt custom SearchParameters for searching by distinct identifier CONF-0356 •StructureDefinition-us-core-diagnosticreport-lab.html#profile-specific-implementation-guidance •StructureDefinition-us-core-diagnosticreport-note.html#profile-specific-implementation-guidance SHALL The diagnostically relevant time (known as the “effective time” and typically the time of specimen collection) … SHALL be present if status [of the diagnostic report] is ‘partial’, ‘preliminary’, ‘final’, ‘amended’, ‘corrected’, or ‘appended’. CONF-0357 •StructureDefinition-us-core-diagnosticreport-lab.html#profile-specific-implementation-guidance SHALL When the report was released … SHALL be present if status [of the diagnostic report] is ‘partial’, ‘preliminary’, ‘final’, ‘amended’, ‘corrected’, or ‘appended’. CONF-0358 •StructureDefinition-us-core-diagnosticreport-lab.html#profile-specific-implementation-guidance SHOULD Updates to .meta.lastUpdated SHOULD reflect New laboratory reports. CONF-0359 •StructureDefinition-us-core-diagnosticreport-lab.html#profile-specific-implementation-guidance SHOULD Updates to .meta.lastUpdated SHOULD reflect changes in the status of laboratory reports, including events that trigger the same status (e.g., amended → amended). CONF-0361 •StructureDefinition-us-core-diagnosticreport-note.html#profile-specific-implementation-guidance MAY Other [diagnostic report] categories MAY be supported [when using US Core DiagnosticReport Profile for Report and Note Exchange] CONF-0364 •StructureDefinition-us-core-diagnosticreport-note.html#profile-specific-implementation-guidance SHOULD For Diagnostic Imaging Reports systems SHOULD support using the subset of LOINC codes listed in Table 4: LOINC® Document Type Codes in HL7 Standard for CDA® Release 2: Imaging Integration; Basic Imaging Reports in CDA and DICOM, Release 1 CONF-0366 •StructureDefinition-us-core-documentreference.html#profile-specific-implementation-guidance MAY The DocumentReference.type binding MAY extend to the whole US Core DocumentReference Type Value Set CONF-0367 •StructureDefinition-us-core-documentreference.html#profile-specific-implementation-guidance MAY [DocumentReference.type MAY also use] other category schemes such as the LOINC-based Document Class Value Set and IHE XDSclassCode CONF-0368 •StructureDefinition-us-core-documentreference.html#profile-specific-implementation-guidance •StructureDefinition-us-core-adi-documentreference.html#profile-specific-implementation-guidance SHALL Although both [DocumentReference.attachment.url and DocumentReference.attachment.data] are marked as Must Support, the Server system is not required to support an address and inline base64 encoded data, but SHALL support at least one of these elements. CONF-0372 •StructureDefinition-us-core-documentreference.html#profile-specific-implementation-guidance •StructureDefinition-us-core-adi-documentreference.html#profile-specific-implementation-guidance SHALL If there are multiple DocumentReference.content element repetitions, these SHALL all represent the same document in different formats or attachment metadata CONF-0373 •StructureDefinition-us-core-documentreference.html#profile-specific-implementation-guidance •StructureDefinition-us-core-adi-documentreference.html#profile-specific-implementation-guidance SHALL-NOT The [documentReference.content] element SHALL NOT contain different versions of the same content. CONF-0374 •StructureDefinition-us-core-documentreference.html#profile-specific-implementation-guidance •StructureDefinition-us-core-adi-documentreference.html#profile-specific-implementation-guidance SHALL The organization responsible for the DocumentReference SHALL be present either in DocumentReference.custodian or accessible in the Provenance resource targeting the DocumentReference using Provenance.agent.who or Provenance.agent.onBehalfOf CONF-0375 •StructureDefinition-us-core-encounter.html#profile-specific-implementation-guidance SHALL Although ... marked as Must Support, Servers are not required to support both [an Encounter.reasonCode or a reference with Encounter.reasonReference], but they SHALL support at least one of these elements. CONF-0378 •StructureDefinition-us-core-encounter.html#profile-specific-implementation-guidance SHOULD If Encounter.reasonReference references an Observation, it SHOULD conform to a US Core Observation [profile applicable to the observation being made] CONF-0379 •StructureDefinition-us-core-encounter.html#profile-specific-implementation-guidance SHALL Although … marked as Must Support, Servers are not required to support both Encounter.location.location and Encounter.serviceProvider, but they SHALL support at least one of these elements. CONF-0382 •StructureDefinition-us-core-encounter.html#profile-specific-implementation-guidance •StructureDefinition-us-core-location.html#profile-specific-implementation-guidance SHOULD If the event facility/location differs from the Encounter.location, systems SHOULD reference it directly CONF-0383 •StructureDefinition-us-core-encounter.html#profile-specific-implementation-guidance •StructureDefinition-us-core-location.html#profile-specific-implementation-guidance SHALL If the event facility/location differs from the Encounter.location, … systems SHALL use the location element for all resources where the element is available. CONF-0384 •StructureDefinition-us-core-encounter.html#profile-specific-implementation-guidance •StructureDefinition-us-core-location.html#profile-specific-implementation-guidance MAY If the event facility/location differs from the Encounter.location … systems MAY use the standard Event Location Extension for US Core DiagnosticReport Profile for Laboratory Results Reporting and US Core Observation Clinical Result Profile. CONF-0385 •StructureDefinition-us-core-encounter.html#profile-specific-implementation-guidance SHOULD Updates to .meta.lastUpdated SHOULD reflect New encounters/visits CONF-0386 •StructureDefinition-us-core-encounter.html#profile-specific-implementation-guidance SHOULD Updates to .meta.lastUpdated SHOULD reflect changes in the status of encounters, including events that trigger the same status (e.g., in-progress → in-progress). CONF-0387 •StructureDefinition-us-core-goal.html#profile-specific-implementation-guidance SHALL Although both Goal.startDate and Goal.target.dueDate are marked as Must Support, the Server system is not required to support both, but SHALL support at least one of these elements. CONF-0390 •StructureDefinition-us-core-immunization.html#profile-specific-implementation-guidance SHALL Servers SHALL use the status code: not-done to represent that an immunization was not given. CONF-0399 •StructureDefinition-us-core-medicationdispense.html#profile-specific-implementation-guidance •StructureDefinition-us-core-medicationrequest.html#profile-specific-implementation-guidance MAY When referencing a Medication resource in .medicationReference, the resource MAY be contained CONF-0400 •StructureDefinition-us-core-medicationdispense.html#profile-specific-implementation-guidance •StructureDefinition-us-core-medicationrequest.html#profile-specific-implementation-guidance MAY When referencing a Medication resource in .medicationReference, the resource MAY be an external resource CONF-0401 •StructureDefinition-us-core-medicationdispense.html#profile-specific-implementation-guidance •StructureDefinition-us-core-medicationrequest.html#profile-specific-implementation-guidance SHALL The Server systems are not required to support both a [medication] code and a reference [when sending medicationDispense], but SHALL support at least one of these methods CONF-0402 •StructureDefinition-us-core-medicationdispense.html#profile-specific-implementation-guidance •StructureDefinition-us-core-medicationrequest.html#profile-specific-implementation-guidance SHALL If an external reference to a Medication resource is used, the Server SHALL support the _include parameter for searching this element. CONF-0407 •StructureDefinition-us-core-medicationrequest.html#profile-specific-implementation-guidance SHOULD When recording “self-prescribed” medication, requester SHOULD be used to indicate the Patient or RelatedPerson as the prescriber CONF-0408 •StructureDefinition-us-core-medicationrequest.html#profile-specific-implementation-guidance SHALL Although [medicationRequest.reportedBoolean and MedicationRequest.reportedReference] are both marked as Must Support, the Server system is not required to support both, but SHALL support at least one of these elements CONF-0416 •StructureDefinition-us-core-medicationrequest.html#profile-specific-implementation-guidance SHOULD [For organizations participating in the ONC Health IT Certification program,] the referenced resources SHOULD be a US Core Profile as documented in Referencing US Core Profiles. CONF-0417 •StructureDefinition-us-core-medicationrequest.html#profile-specific-implementation-guidance SHOULD Source EHR identifiers SHOULD be included to support deduplication across MedicationRequest resources. CONF-0419 •StructureDefinition-us-core-average-blood-pressure.html#profile-specific-implementation-guidance •StructureDefinition-us-core-vital-signs.html#profile-specific-implementation-guidance •StructureDefinition-us-core-treatment-intervention-preference.html#profile-specific-implementation-guidance MAY The observations MAY have additional codes that translate or map to the Observation code or category codes [such as] … local system-specific codes [and] …more specific codes CONF-0420 •StructureDefinition-us-core-average-blood-pressure.html#profile-specific-implementation-guidance •StructureDefinition-us-core-vital-signs.html#profile-specific-implementation-guidance •StructureDefinition-us-core-treatment-intervention-preference.html#profile-specific-implementation-guidance SHOULD [For an Observation a] code system value SHOULD be supplied for each additional code CONF-0421 •StructureDefinition-us-core-average-blood-pressure.html#profile-specific-implementation-guidance SHALL Because the blood pressure values are communicated in the mandatory systolic and diastolic components [when using the US Core Average Blood Pressure Profile,] the Observation.value[x] element SHALL be omitted CONF-0422 •StructureDefinition-us-core-care-experience-preference.html#profile-specific-implementation-guidance •StructureDefinition-us-core-treatment-intervention-preference.html#profile-specific-implementation-guidance SHOULD The context or precondition of a patient’s [care experience] preference SHOULD be supplied in the Observation.valueString or in an extension CONF-0423 •StructureDefinition-us-core-observation-clinical-result.html#profile-specific-implementation-guidance SHOULD Servers SHOULD use the base FHIR [Observation Category Codes] (http://hl7.org/fhir/R4/valueset-observation-category.html) [in Observation.category] CONF-0424 •StructureDefinition-us-core-observation-clinical-result.html#profile-specific-implementation-guidance •StructureDefinition-us-core-observation-lab.html#profile-specific-implementation-guidance SHOULD Systems SHOULD support Observation.effectivePeriod to accurately represent measurements over time CONF-0425 •StructureDefinition-us-core-observation-clinical-result.html#profile-specific-implementation-guidance •StructureDefinition-us-core-observation-lab.html#profile-specific-implementation-guidance •StructureDefinition-us-core-observation-screening-assessment.html#profile-specific-implementation-guidance •StructureDefinition-us-core-observation-lab.html#profile-specific-implementation-guidance SHALL An Observation.component without a value, SHALL include a reason why the data is absent CONF-0426 •StructureDefinition-us-core-observation-clinical-result.html#profile-specific-implementation-guidance •StructureDefinition-us-core-observation-lab.html#profile-specific-implementation-guidance •StructureDefinition-us-core-observation-screening-assessment.html#profile-specific-implementation-guidance •StructureDefinition-us-core-vital-signs.html#profile-specific-implementation-guidance MAY Systems that never provide a component observation without a component value MAY choose not to support Observation.component.dataAbsentReason CONF-0427 •StructureDefinition-us-core-observation-clinical-result.html#profile-specific-implementation-guidance •StructureDefinition-us-core-observation-lab.html#profile-specific-implementation-guidance •StructureDefinition-us-core-observation-screening-assessment.html#profile-specific-implementation-guidance •StructureDefinition-us-core-vital-signs.html#profile-specific-implementation-guidance SHALL An Observation without a value, SHALL include a reason why the data is absent CONF-0428 •StructureDefinition-us-core-observation-clinical-result.html#profile-specific-implementation-guidance •StructureDefinition-us-core-observation-lab.html#profile-specific-implementation-guidance •StructureDefinition-us-core-observation-screening-assessment.html#profile-specific-implementation-guidance •StructureDefinition-us-core-vital-signs.html#profile-specific-implementation-guidance MAY [For] an Observation without a value … [Systems MAY choose not to] include a reason why the data is absent … [if] there are component observations or … reporting panel observations using Observation.hasMember CONF-0429 •StructureDefinition-us-core-observation-clinical-result.html#profile-specific-implementation-guidance •StructureDefinition-us-core-observation-lab.html#profile-specific-implementation-guidance •StructureDefinition-us-core-observation-screening-assessment.html#profile-specific-implementation-guidance •StructureDefinition-us-core-vital-signs.html#profile-specific-implementation-guidance MAY Systems that never provide an observation without a value MAY choose not to support Observation.dataAbsentReason CONF-0430 •StructureDefinition-us-core-observation-lab.html#profile-specific-implementation-guidance SHOULD [When sending US Core Laboratory Results Observation Profile] updates to .meta.lastUpdated SHOULD reflect new laboratory observations CONF-0431 •StructureDefinition-us-core-observation-lab.html#profile-specific-implementation-guidance SHOULD [When sending US Core Laboratory Results Observation Profile] updates to .meta.lastUpdated SHOULD reflect changes in the status of laboratory observations, including events that trigger the same status (e.g., amended → amended) CONF-0432 •StructureDefinition-us-core-observation-occupation.html#profile-specific-implementation-guidance SHALL [When sending US Core Observation Occupation Profile] for … [a] current job ,systems SHALL omit observation.effectivePeriod.end to indicate it is ongoing. CONF-0433 •StructureDefinition-us-core-observation-occupation.html#profile-specific-implementation-guidance SHALL When the industry is known, but the occupation is not, systems SHALL use the value “unknown” from the DataAbsentReason Code System CONF-0434 •StructureDefinition-us-core-observation-occupation.html#profile-specific-implementation-guidance SHALL when the occupation is known but the industry is not, systems SHALL omit the industry Observation.component CONF-0437 •StructureDefinition-us-core-observation-screening-assessment.html#profile-specific-implementation-guidance SHOULD [For] multi-question surveys or assessments Observation.code is an overarching assessment or screening code, and the Observation.value element SHOULD be empty CONF-0438 •StructureDefinition-us-core-observation-screening-assessment.html#profile-specific-implementation-guidance SHOULD A practitioner’s clinical observation or assertion about a patient’s health status, which is not a response to a screening or assessment question, SHOULD use the US Core Simple Observation Profile instead [of the US Core Observation Screening Assessment Profile] CONF-0439 •StructureDefinition-us-core-observation-screening-assessment.html#profile-specific-implementation-guidance SHALL the Server system ... SHALL support [either] Reference(US Core Observation Screening Assessment Profile) or Reference(US Core QuestionnaireResponse Profile) for Observation.derivedFrom CONF-0441 •StructureDefinition-us-core-simple-observation.html#profile-specific-implementation-guidance SHOULD Observations formally part of an assessment tool or survey SHOULD use the US Core Observation Screening Assessment Profile. CONF-0442 •StructureDefinition-us-core-simple-observation.html#profile-specific-implementation-guidance SHOULD An assertion or determination derived from screening and assessment tools SHOULD reference them using Observation.derivedFrom CONF-0443 •StructureDefinition-us-core-simple-observation.html#profile-specific-implementation-guidance SHOULD When using `Observation.derivedFrom’ to reference an Observation, the referenced Observation SHOULD be a US Core Observation CONF-0447 •StructureDefinition-us-core-vital-signs.html#profile-specific-implementation-guidance MAY [US Core Vital Signs] observations MAY have component observations … [see] FHIR core specification vital signs table for examples CONF-0448 •StructureDefinition-pediatric-bmi-for-age.html#profile-specific-implementation-guidance •StructureDefinition-pediatric-weight-for-height.html#profile-specific-implementation-guidance •StructureDefinition-head-occipital-frontal-circumference-percentile.html#profile-specific-implementation-guidance SHOULD Information about the growth chart tables used to determine percentiles SHOULD be supplied in Observation.note.text CONF-0449 •StructureDefinition-us-core-blood-pressure.html#profile-specific-implementation-guidance SHOULD [In the US Core Blood Pressure Profile] because the blood pressure values are communicated in the mandatory systolic and diastolic components[,] the Observation.value[x] element SHOULD be omitted CONF-0450 •StructureDefinition-us-core-blood-pressure.html#profile-specific-implementation-guidance SHALL [In the US Core Blood Pressure Profile] because the blood pressure values are communicated in the mandatory systolic and diastolic components[,] an Observation without a systolic or diastolic result value, SHALL include a reason why the data is absent in Observation.component.dataAbsentReason CONF-0451 •StructureDefinition-us-core-blood-pressure.html#profile-specific-implementation-guidance SHALL [In the US Core Blood Pressure Profile] because the blood pressure values are communicated in the mandatory systolic and diastolic components[,] All Server systems - including those that never provide a component observation without a value - SHALL support Observation.component.dataAbsentReason for the components. CONF-0452 •StructureDefinition-us-core-pulse-oximetry.html#profile-specific-implementation-guidance MAY Inspired oxygen therapy MAY be represented with component observations when measured at the same time as the pulse oximetry measurements [in the US Core Pulse Oximetry profile] CONF-0453 •StructureDefinition-us-core-pulse-oximetry.html#profile-specific-implementation-guidance SHOULD Many pulse oximetry readings are taken while the patient is breathing room air. The concept of “room air” (unmodified, ambient air) SHOULD be represented as an inhaled oxygen flow rate of 0 liters/min CONF-0454 •StructureDefinition-us-core-pulse-oximetry.html#profile-specific-implementation-guidance SHOULD A pulse oximetry reading without inspired oxygen component observations MAY imply that the measurement was performed while the patient was breathing room air or that the inspired oxygen reading was omitted. To remove this uncertainty, the inspired oxygen component observations SHOULD be used [when using the US Core Pulse Oximetry profile.] CONF-0455 •StructureDefinition-us-core-organization.html#profile-specific-implementation-guidance SHALL Systems SHALL support National Provider Identifier (NPI) for organizations CONF-0456 •StructureDefinition-us-core-organization.html#profile-specific-implementation-guidance SHOULD Systems … SHOULD the National Association of Insurance Commissioners NAIC Company code (sometimes called “NAIC Number” or “cocode”) for payers. CONF-0457 •StructureDefinition-us-core-organization.html#profile-specific-implementation-guidance SHOULD Systems … SHOULD support Clinical Laboratory Improvement Amendments (CLIA) for laboratories CONF-0461 •StructureDefinition-us-core-patient.html#profile-specific-implementation-guidance MAY The Complex [Extension] for Race ... allow[s] for one or more codes of which MAY include additional codes from the detailed ethnicity ... value sets drawn from the Race & Ethnicity - CDC (CDCREC) code system [when using the [US Core Race Extension] (https://hl7.org/fhir/us/core/STU8/StructureDefinition-us-core-race.html)] CONF-0462 •StructureDefinition-us-core-patient.html#profile-specific-implementation-guidance SHALL The Complex [Extension] for Race ... allow[s] for one or more codes of which SHALL include a text description [of category codes when using the [US Core Race Extension] (https://hl7.org/fhir/us/core/STU8/StructureDefinition-us-core-race.html)] CONF-0463 •StructureDefinition-us-core-patient.html#profile-specific-implementation-guidance MAY The Complex [Extension] for ... Ethnicity allow[s] for one or more codes of which MAY include additional codes from the detailed ... race value sets drawn from the Race & Ethnicity - CDC (CDCREC) code system [when using the [US Core Race Extension] (https://hl7.org/fhir/us/core/STU8/StructureDefinition-us-core-race.html)] CONF-0464 •StructureDefinition-us-core-patient.html#profile-specific-implementation-guidance SHALL The Complex [Extension] for ... Ethnicity allow[s] for one or more codes of which SHALL include a text description [of category codes when using the [US Core Ethnicity Extension] (https://hl7.org/fhir/us/core/STU8/StructureDefinition-us-core-ethnicity.html)] CONF-0466 •StructureDefinition-us-core-patient.html#profile-specific-implementation-guidance SHALL Systems SHALL represent Previous name by setting Patient.name.use to "old" or providing an end date in Patient.name.period or doing both. CONF-0467 •StructureDefinition-us-core-patient.html#profile-specific-implementation-guidance SHALL Systems SHALL represent Previous Address by setting Patient.address.use to "old" or providing an end date in Patient.address.period or doing both. CONF-0470 •StructureDefinition-us-core-patient.html#profile-specific-implementation-guidance SHOULD Non-certifying systems[, systems that are not participating in the ONC Health IT certification program,] SHOULD follow the Project US@ Technical Specification for Patient Addresses Final Version 1.0 as the standard style guide for Patient.address.line and Patient.address.city for new and updated records. CONF-0471 •StructureDefinition-us-core-patient.html#profile-specific-implementation-guidance MAY [For systems participating in the ONC Health IT certification program,] this requirement [to follow the Project US@ Technical Specification for Patient Addresses Final Version 1.0 for Patient.address.line and Patient.address.city]. Both certifying and non-certifying systems MAY choose not to use Project US@ for historical records or documents that are not exposed through FHIR-based APIs. CONF-0472 •StructureDefinition-us-core-patient.html#profile-specific-implementation-guidance SHOULD-NOT SHOULD NOT be used as a patient identifier in Patient.identifier.value CONF-0473 •StructureDefinition-us-core-practitioner.html#profile-specific-implementation-guidance SHALL Servers that support only the US Core Practitioner Profile and do not support the US Core PractitionerRole Profile SHALL provide implementation-specific guidance on how to access a provider’s location and contact information using only the Practitioner resource. CONF-0474 •StructureDefinition-us-core-practitioner.html#profile-specific-implementation-guidance MAY Although Practitioner.address is marked as Must Support, the Server system MAY choose not to support it if they support the US Core PractitionerRole Profile CONF-0475 •StructureDefinition-us-core-practitioner.html#profile-specific-implementation-guidance SHALL [When using the US Core Practitioner Profile] Practitioner.address … SHALL[be supported] if … [the Server does] not support the US Core PractitionerRole Profile CONF-0477 •StructureDefinition-us-core-practitioner.html#profile-specific-implementation-guidance SHOULD Only professional/work contact information about the practitioner SHOULD be available to the patient CONF-0480 •StructureDefinition-us-core-procedure.html#profile-specific-implementation-guidance SHOULD [If using LOINC codes in procedure.code] only LOINC concepts that reflect actual procedures SHOULD be used CONF-0486 •StructureDefinition-us-core-procedure.html#profile-specific-implementation-guidance SHALL [For organizations participating in the ONC Health IT Certification program,] when using Procedure.reasonReference Servers SHALL support at least one target resource in Procedure.reasonReference CONF-0488 •StructureDefinition-us-core-procedure.html#profile-specific-implementation-guidance SHOULD [For organizations participating in the ONC Health IT Certification program,] when using Procedure.reasonReference …The referenced resources SHOULD be a US Core Profile as documented in Referencing US Core Profiles CONF-0489 •StructureDefinition-us-core-provenance.html#profile-specific-implementation-guidance SHALL The US Core Provenance resource SHALL be supported for these US Core resource types: AllergyIntolerance, CarePlan, CareTeam, Condition, Coverage, Device, DiagnosticReport, DocumentReference, Encounter, Goal, Immunization, MedicationDispense, MedicationRequest, Observation, Patient, Procedure, QuestionnaireResponse, RelatedPerson, ServiceRequest CONF-0508 •StructureDefinition-us-core-provenance.html#profile-specific-implementation-guidance SHALL If a system receives a provider in Provenance.agent.who as free text, they must capture [the organization] who sent them the information [and upon] request ... SHALL provide this organization as the source CONF-0509 •StructureDefinition-us-core-provenance.html#profile-specific-implementation-guidance MAY If a system receives a provider in Provenance.agent.who as free text, … [upon request they] MAY include the free text provider. CONF-0514 •StructureDefinition-us-core-servicerequest.html#profile-specific-implementation-guidance MAY The Must Support ServiceRequest.category is bound, at a minimum, to the US Core ServiceRequest Category Codes, and other category codes MAY be used. CONF-0515 •StructureDefinition-us-core-servicerequest.html#profile-specific-implementation-guidance SHOULD The ServiceRequest.code value ... SHOULD be constrained to a subset for a particular use case or domain CONF-0523 •StructureDefinition-us-core-specimen.html#profile-specific-implementation-guidance •StructureDefinition-us-core-medication.html#profile-specific-implementation-guidance MAY Since the binding [for Specimen.type and additional USCDI elements] is extensible when a code is unavailable, servers MAY use text. CONF-0524 •StructureDefinition-us-core-specimen.html#profile-specific-implementation-guidance SHALL Although both Specimen.identifier and Specimen.accessionIdentifier are marked as Must Support, the Server system is not required to support both, but SHALL support at least one of these elements. CONF-0550 •security.html#patient-privacy-and-security SHALL Systems SHALL establish a risk analysis and management regime that conforms with HIPAA security regulatory requirements CONF-0552 •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-0554 •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-0556 •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-0558 •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-0560 •security.html#patient-privacy-and-security SHOULD The selected time service SHOULD be documented in the Business Associate Agreement when available. CONF-0562 •security.html#patient-privacy-and-security SHALL Systems SHALL keep audit logs of the various transactions. CONF-0564 •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-0566 •security.html#patient-privacy-and-security SHOULD US Federal systems SHOULD conform with FIPS PUB 140-2. CONF-0568 •security.html#patient-privacy-and-security SHALL Systems SHALL conform to FHIR Communications Security requirements. CONF-0570 •security.html#patient-privacy-and-security SHALL For Authentication and Authorization, Systems SHALL support any SMART App Launch Version 2.0.0 and later for Client <-> Server interactions. CONF-0572 •security.html#patient-privacy-and-security SHALL Systems SHALL implement consent requirements per their state, local, and institutional policies. CONF-0574 •security.html#patient-privacy-and-security SHOULD The Business Associate Agreements SHOULD document systems’ mutual consent requirements. CONF-0576 •security.html#patient-privacy-and-security SHOULD Systems SHOULD provide Provenance statements using the US Core Provenance Profile resource and associated requirements. CONF-0578 •security.html#patient-privacy-and-security MAY Systems MAY implement the FHIR Digital Signatures CONF-0580 •security.html#patient-privacy-and-security MAY Systems MAY protect the confidentiality of data at rest via encryption and associated access controls. CONF-0804 •must-support.html#must-support---complex-elements SHALL If any sub-element is marked as Additional USCDI [for a complex element], it must also meet the Additional USCDI requirements and satisfy the Additional USCDI requirements for the parent element. CONF-0808 •must-support.html#must-support-targets-for-us-core-profiles SHALL When a Reference type element is labeled as Must Support and has a single target profile referenced, the target profile SHALL be supported. CONF-0810 •must-support.html#must-support-targets-for-us-core-profiles SHALL When a Reference type element is labeled as Must Support, has multiple target profiles referenced, and specific targets are labeled as Must Support, the Must Support target profile(s) SHALL be supported. CONF-0813 •must-support.html#must-support---slices MAY [If a] slicer's Must Support property only defines the element level Must Support...[, i.e.,] no Must Support... property is defined for the slice, then support for that slice's definition is optional. CONF-0818 •clinical-notes.html#clinical-notes SHALL Servers SHALL support, at minimum, these … "Common Clinical Notes": Surgical Operation Note (11504-8) CONF-0819 •clinical-notes.html#clinical-notes SHALL Servers SHALL support, at minimum, these … "Common Clinical Notes": Emergency Department Note (34111-5) CONF-0821 •screening-and-assessments.html#structured-screening-and-assessments SHOULD Servers that support the USCDI Health Status/Assessments Data Class ... SHOULD support the SDC Base Questionnaire and the US Core QuestionnaireResponse Profile." CONF-0822 •screening-and-assessments.html#category-codes SHALL For the US Core Simple Observation Profile, Servers SHALL support all the category codes listed. CONF-0823 •screening-and-assessments.html#category-codes SHALL For the … US Core Observation Screening Assessment Profiles, Servers SHALL support all the category codes listed. CONF-0824 •screening-and-assessments.html#category-codes SHALL For the US Core Condition Problems and Health Concerns Profile, Servers SHALL support the code ,"sdoh" CONF-0825 •screening-and-assessments.html#category-codes SHOULD For the US Core Condition Problems and Health Concerns Profile, Servers SHOULD support the other category codes listed. CONF-0826 •screening-and-assessments.html#category-codes SHOULD For the US Core ServiceRequest Profile, Servers SHOULD support all the [listed] category codes. CONF-0836 •StructureDefinition-us-core-diagnosticreport-note.html#profile-specific-implementation-guidance SHOULD The DiagnosticReport.basedOn element connects the DiagnosticReport to the originating order in the EHR. Systems that initiate the order SHOULD use this element when reporting the results. CONF-0837 •StructureDefinition-us-core-diagnosticreport-note.html#profile-specific-implementation-guidance SHOULD The DiagnosticReport.media.link element SHOULD be used to support links to various patient-friendly content, such as jpg images of x-rays (see the DiagnosticReport Chest X-ray Report Example). CONF-0838 •StructureDefinition-us-core-diagnosticreport-note.html#profile-specific-implementation-guidance SHOULD The DiagnosticReport.imagingStudy element SHOULD be used to support exchange with systems that can view DICOM (Digital Imaging and Communications in Medicine) studies, series, and SOP (Service-Object Pair) instances referenced in the -ImagingStudy resource. CONF-0839 •StructureDefinition-us-core-documentreference.html •StructureDefinition-us-core-adi-documentreference.html#profile-specific-implementation-guidance SHOULD If the referenced document or file [referenced by DocumentReference.content.attachment.url] is hosted on a Server outside the FHIR Server, it SHOULDbe securely accessible using the same authorization credentials that were used to access the FHIR Server. This reduces complexity for the Client and improves the user experience. CONF-0840 •StructureDefinition-us-core-encounter.html#profile-specific-implementation-guidance SHALL Although the [US Core Interpreter Needed] extension is marked as an Additional USCDI Requirements on both US Core Patient and US Core Encounter Profiles, the certifying Server system is not required to support the extension on both profiles, but SHALL support the extension on at least one. CONF-0841 •StructureDefinition-us-core-immunization.html#profile-specific-implementation-guidance MAY There is no guarantee that vaccine lot numbers are globally unique, and they are not recommended for matching or de-duplication across systems unless used with other data elements such as a vaccine product code, manufacturer code, or date of administration. Implementers MAY communicate the Immunization.manufacturer to ensure global uniqueness to lot numbers. CONF-0842 •StructureDefinition-us-core-medicationrequest.html#profile-specific-implementation-guidance SHALL Servers SHALL return all active medications following the Get All Active Medications guidance. CONF-0843 •StructureDefinition-us-core-observation-lab.html#profile-specific-implementation-guidance SHOULD [For US Core Laboratory Result Observation Profile, even] when the specimen type is already implied by the LOINC code used in Observation.code (e.g., a LOINC code for Blood Glucose), the Observation.specimen element SHOULD also be populated with the referenced Specimen resource to explicitly communicate the collected specimen type. CONF-0844 •StructureDefinition-us-core-observation-lab.html#profile-specific-implementation-guidance SHOULD [For US Core Laboratory Result Observation Profile, the] type of specimen [in Observation.specimen] SHOULD not conflict with the LOINC code [in Observation.code]. CONF-0845 •StructureDefinition-us-core-observation-screening-assessment.html#profile-specific-implementation-guidance SHALL [For the US Core Observation Screening Assessment Profile, the] category type "survey" is required. CONF-0850 •StructureDefinition-us-core-observation-screening-assessment.html#profile-specific-implementation-guidance SHOULD [For the US Core Observation Screening Assessment Profile,] when using Observation.derivedFrom to reference an Observation, the referenced Observation SHOULD be a US Core Observation. CONF-0851 •StructureDefinition-us-core-patient.html#profile-specific-implementation-guidance •StructureDefinition-us-core-encounter.html#profile-specific-implementation-guidance SHOULD Servers SHOULD use the US Core Interpreter Needed Extension on [the US Core Patient Profile] or the US Core Encounter Profile to communicate whether a patient needs an interpreter. CONF-0855 •StructureDefinition-us-core-patient.html#profile-specific-implementation-guidance •StructureDefinition-us-core-encounter.html#profile-specific-implementation-guidance SHOULD Systems SHOULD designate the patient's preferred language in the Patient.communication.preferred element. CONF-0857 •StructureDefinition-us-core-servicerequest.html#root SHOULD For the USCDI Laboratory Order, Imaging Order, Clinical Test Order, and Procedure Order Data Elements, implementers SHOULD use the corresponding category codes listed in the table CONF-0868 •StructureDefinition-us-core-simple-observation.html#profile-specific-implementation-guidance SHALL Although 'Observation.performer' target profiles US Core Practitioner Profile and US Core Patient Profile are labeled Must Support. Servers are not required to support both, but SHALL support at least one. CONF-0871 •must-support.html#must-support---slices MAY [If a] slicer's Additional USCDI property only defines the element level Additional USCDI...[, i.e.,] no Additional USCDI... property is defined for the slice, then support for that slice's definition is optional. CONF-0881 •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 Responders SHALL be capable of providing [such an element] with a valid reference to at least one target profile. CONF-0885 •basic-provenance.html#individual-level-provenance SHOULD The author is communicated by the elements and the author's role by the referenced target resource (for example, Patient, Practitioner/PractitionerRole, RelatedPerson, Device). Details about the author's role are contained in the target resource's contents. Many of these elements are labeled Must Support or Additional USCDI Requirements. However,[even if they are not labeled Must Support or Additional USCDI Requirements] all of these elements and target resources SHOULD be supported in the profiles if the system captures the data. CONF-0887 •StructureDefinition-us-core-observation-screening-assessment.html#profile-specific-implementation-guidance SHALL Although 'Observation.performer' target profiles US Core Practitioner Profile and US Core Patient Profile are labeled Must Support. Servers are not required to support both, but SHALL support at least one. CONF-0889 •StructureDefinition-us-core-practitioner.html#profile-specific-implementation-guidance •StructureDefinition-us-core-organization.html#profile-specific-implementation-guidance •StructureDefinition-us-core-patient.html#profile-specific-implementation-guidance •StructureDefinition-us-core-relatedperson.html#profile-specific-implementation-guidance SHOULD … this profile uses USPS Two Letter Alphabetic Codes for US states. When encoding addresses outside the US, systems SHOULD use the ISO 3166 subdivision codes. CONF-0890 •StructureDefinition-us-core-practitionerrole.html#profile-specific-implementation-guidance SHOULD Due to implementer feedback, some US Core Profiles reference the base FHIR PractitionerRole resource instead of the US Core PractitionerRole Profile. However, the US Core PractitionerRole Profile SHOULD be used as the default profile if referenced by another US Core profile. CONF-0891 •StructureDefinition-us-core-practitionerrole.html#profile-specific-implementation-guidance SHOULD When selecting role codes...implementers SHOULD choose the code that reflects the specific duties performed within that role rather than the specialty unless the individual's professional specialization characterizes the role. CONF-0892 •StructureDefinition-us-core-procedure.html#profile-specific-implementation-guidance SHOULD A procedure including an implantable device SHOULD use Procedure.focalDevice referencing the US Core Device Profile CONF-0894 •StructureDefinition-us-core-practitionerrole.html#profile-specific-implementation-guidance SHOULD Unless exchanging legacy or text-only data, medical specialty codes SHOULD be taken from NUCC or SNOMED CT. CONF-0895 •StructureDefinition-us-core-procedure.html#profile-specific-implementation-guidance SHOULD Unless exchanging legacy or text-only data, procedure codes SHOULD be taken from SNOMED-CT, CPT, HCPCS II, ICD-10-PCS, CDT, or LOINC*. CONF-0896 •general-requirements.html#extensible-binding-for-coded-elements SHOULD US Core guidance provides more flexibility for situations where implementers cannot fully comply with the FHIR guidance. This flexibility is sometimes necessary and expected for legacy and text-only data. However, for newly recorded, non-legacy data, a system SHOULD adhere to the extensible binding rules. CONF-0897 •general-requirements.html#extensible-binding-for-coded-elements SHOULD For data not captured by the system transmitting the information, the coded data SHOULD be automatically converted to fine-grained codes from the specified ValueSet. CONF-0898 •general-requirements.html#extensible-binding-for-coded-elements MAY For data not captured by the system transmitting the information, ....the system MAY provide the existing code or the free text, and a high-level abstract code, such as the SNOMED CT code "71388002"(Procedure), to remain conformant with the extensible binding. CONF-0899 •StructureDefinition-us-core-adi-documentreference.html#profile-specific-implementation-guidance SHOULD To represent the patient and provider attestation metadata, the optional DocumentReference Attestor R5 Extension defined in the US Core DocumentReference Profile SHOULD be used CONF-0900 •StructureDefinition-us-core-condition-problems-health-concerns.html#profile-specific-implementation-guidance •StructureDefinition-us-core-condition-encounter-diagnosis.html#profile-specific-implementation-guidance SHOULD Unless exchanging legacy or text-only data, condition codes SHOULD be taken from SNOMED CT and ICD-10-CM, USCDI's applicable vocabulary standards for the Problem Data Element. CONF-0901 •StructureDefinition-us-core-location.html#profile-specific-implementation-guidance MAY The Service Delivery Location Role Type value set is inherited from the base resource, and, although its binding strength is extensible in the base resource, US Core implementers MAY treat it as preferred. CONF-0903 •StructureDefinition-us-core-goal.html#profile-specific-implementation-guidance SHOULD When exchanging Social Determinants of Health (SDOH) data, implementers SHOULD use the Social Determinants of Health Goals set which is curated by the Gravity Project to represent goals for all SDOH Domains. CONF-0904 •StructureDefinition-us-core-servicerequest.html#profile-specific-implementation-guidance SHOULD Implementers SHOULD conform to the binding strengths listed for each USCDI Order context...Laboratory Order|[LOINC Common Laboratory Orders Value Set]|extensible, Imaging Order|[LOINC Radiology Codes]|preferred, Clinical Test Order|[LOINC Clinical Test Codes]|preferred CONF-0905 •StructureDefinition-us-core-servicerequest.html#profile-specific-implementation-guidance MAY the US Core ServiceRequest Profile MAY be used to represent a derived "actionable" order based on a portable Medical Order(PMO). CONF-0906 •StructureDefinition-us-core-servicerequest.html#profile-specific-implementation-guidance SHOULD [When] used to represent a derived "actionable" order based on a PMO...The ServiceRequest.category SHOULD be bound to Portable Medical Order Categories CONF-0907 •StructureDefinition-us-core-servicerequest.html#profile-specific-implementation-guidance SHOULD [When] used to represent a derived "actionable" order based on a PMO...ServiceRequest.code` SHOULD be aligned with the appropriate Category CONF-0908 •StructureDefinition-us-core-servicerequest.html#profile-specific-implementation-guidance SHOULD The ServiceReqest.reasonReference SHOULD be used to reference the US Core ADI DocumentReference Profile that indexes the PMO. CONF-0909 •scopes.html#scopes-for-requesting-fhir-resources-by-type SHALL The following scopes that correspond directly to FHIR resource types SHALL be supported ... [For] RelatedPerson [the] <patient|user|system>/FamilyMemberHistory.rs [see SMART Clinical Scope Syntax for details on clinical data scopes] CONF-0912 •terminology.html#us-core-valueset-and-codesystem-versions SHOULD When implementing US Core, implementers SHOULD use the published versions or later versions of the value sets and code systems. CONF-0913 •terminology.html#us-core-valueset-and-codesystem-versions MAY In some cases, [when implementing US Core] implementers MAY need to use terminology from earlier versions to preserve legacy data. CONF-0914 •StructureDefinition-us-core-patient.html#profile-specific-implementation-guidance SHALL Systems SHALL represent Suffix using the Patient.name.suffix element. CONF-0915 •general-requirements.html#conforming-to-us-core MAY Profile Only Support: Systems MAY support only the US Core Profiles to represent clinical information. CONF-0916 •general-requirements.html#conforming-to-us-core MAY Profile Support + Interaction Support: Systems MAY support both the US Core Profile content structure and the RESTful interactions defined for a resource.
HL7 International / Cross-Group Projects
This [Requirements](https://hl7.org/fhir/R5/requirements.html) resource lists the US Core Responder (Server) 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. See the [US Core Certifying System Requirements](Requirements-us-core-certifying-system.html) for the *additional requirements* for systems certifying for Office of the National Coordinator for Health Information Technology (ONC) Health IT Certification (g)(10) certification.
To support a US Core Profile, a Server: **SHALL** Be able to populate all profile data elements that are mandatory and/or flagged as Must Support as defined by that profile’s StructureDefinition.
To support a US Core Profile, a Server: **SHOULD** declare support for a US Core Profile by including its official URL in the Server’s `CapabilityStatement.rest.resource.supportedProfile` element.
Servers **MAY** deploy and support one or more US Core Profiles to represent clinical information
Server **MAY** deploy and support ... the following US Core interaction: “Quick Start” defined for each Profile
Server **MAY** deploy and support ... the following US Core interaction: [Clinical Notes](https://hl7.org/fhir/us/core/clinical-notes.html)
Server **MAY** deploy and support ... the following US Core interaction: [Medication List](https://hl7.org/fhir/us/core/medication-list.html)
Server **MAY** deploy and support ... the following US Core interaction: [Basic Provenance](https://hl7.org/fhir/us/core/basic-provenance.html)
Server **MAY** deploy and support ... the following US Core interaction: [Screening and Assessments](https://hl7.org/fhir/us/core/screening-and-assessments.html)
Servers implementing ... [clinical information representation] can claim conformance to the US Core Profile content structure ... by implementing all or parts of the US Core CapabilityStatement into their capabilities.
Servers implementing ... [interactions] can claim conformance to the ... RESTful interactions defined by implementing all or parts of the US Core CapabilityStatement into their capabilities
[To claim conformance to a US Core Profile] a conformant Server: **SHALL** Be able to populate all profile data elements that are mandatory and/or flagged as Must Support as defined by that profile’s StructureDefinition.
[To claim conformance to a US Core Profile] a conformant Server: **SHOULD** declare conformance with the US [Core Server Capability Statement](https://hl7.org/fhir/us/core/CapabilityStatement-us-core-Server.html) by including its official URL in the Server’s `CapabilityStatement.instantiates` element: `http://hl7.org/fhir/us/core/CapabilityStatement/us-core-Server`
[To claim conformance to a US Core Profile] a conformant Server: **SHALL** specify the full capability details from the US Core CapabilityStatement it claims to implement.
[To claim conformance to a US Core Profile] a conformant Server: **SHALL**… Declare support for the US Core Profile by including its official URL in the Server’s CapabilityStatement.rest.resource.supportedProfile element.
[To claim conformance to a US Core Profile] a conformant Server: **SHALL**… Declare support for the US Core Profile’s FHIR RESTful transactions.
[Required binding](http://hl7.org/fhir/R4/terminologies.html#required) to a ValueSet definition means that one of the codes from the specified ValueSet **SHALL** be used.
For `CodeableConcept`, which permits multiple codings and a text element, this [[Required binding](http://hl7.org/fhir/R4/terminologies.html#required) to a ValueSet definition] rule applies to at least one of the codings
For a [[required binding](http://hl7.org/fhir/R4/terminologies.html#required) to a ValueSet definition], a `CodeableConcept`which permits multiple codings and a text element … [using] only text is not valid.
[When populating a coded element with a [required binding](http://hl7.org/fhir/R4/terminologies.html#required] to a ValueSet definition] US Core Responders **SHALL** provide a code exclusively from [the required binding] ValueSet
[Extensible binding] (http://hl7.org/fhir/R4/terminologies.html#extensible) means that one of the codes from the specified value set **SHALL** be used when an appropriate concept exists;…
[When using an [extensible Binding] (http://hl7.org/fhir/R4/terminologies.html#extensible)] If no suitable code exists in the [extensible] ValueSet, alternate code(s) **MAY** be used..
For `CodeableConcept` [with an [extensible binding] (http://hl7.org/fhir/R4/terminologies.html#extensible) … Text-only representation **SHOULD NOT** be used - coded values are expected whenever possible to support interoperability.
When claiming conformance to ... [to a US Core profile extensible binding rule, a] US Core Responders **SHALL** provide: A code from … [the] valueset 'DataElement.code.code' if the concept exists in the valueset [for a DataElement.code that has an extensible binding] Or an alternative code if the concept does not exist in the valueset [for a DataElement.code that has an extensible binding] Or text in ... `[DataElement.code.text]’ if only text is available [for a DataElement.code that has an extensible binding]
Alternate codes **MAY** be provided in addition to the standard codes defined in required or extensible ValueSets. These alternate codes are called "additional codings".
[The additional codings] **MAY** be equivalent to or narrower in meaning than the standard concept code.
Not all modifier elements are Mandatory or Must Support, and there is no requirement for supporting them
Servers **MAY** communicate a system-wide profile in their CapabilityStatement to identify which additional elements, including modifier elements, they support
If the source system does not have data for an element with a minimum cardinality = 0 (including elements labeled Must Support), the data element **SHALL** be omitted from the resource.
If the data element is a Mandatory element (in other words, where the minimum cardinality is > 0), it **SHALL** be present even if the source system does not have data.
For [mandatory] non-coded data elements [where data is not available], use the [DataAbsentReason Extension](http://hl7.org/fhir/R4/extension-data-absent-reason.html) in the data type ... [with] the code `unknown` - The value is expected to exist but is not known.
[In situations where data is not available] for [mandatory] coded data elements … [with] *example*, *preferred*, or *extensible* binding strengths (CodeableConcept or Coding datatypes) If the source system has text but no coded data, only the text element is used.
[In situations where data is not available] for [mandatory] coded data elements… [with] *example*, *preferred*, or *extensible* binding strengths (CodeableConcept or Coding datatypes): For Coding datatypes, the text-only data is represented as a display element
[In situations where data is not available] for [mandatory] coded data elements… [with] *example*, *preferred*, or *extensible* binding strengths (CodeableConcept or Coding datatypes): … If there is neither text nor coded data ... [then] use the appropriate “unknown” concept code from the ValueSet if available.
[In situations where data is not available] for [mandatory] coded data elements… [with] *example*, *preferred*, or *extensible* binding strengths (CodeableConcept or Coding datatypes): … If there is neither text nor coded data ... [then] if the ValueSet does not have the appropriate “unknown” concept code, use unknown from the [DataAbsentReason Code System](http://hl7.org/fhir/R4/codesystem-data-absent-reason.html).
[In situations where data is not available] for [mandatory] coded data elements… [with] *required* binding strength (CodeableConcept or code datatypes): use the appropriate “unknown” concept code from the ValueSet if available
[In situations where data is not available] for [mandatory] coded data elements… [with] *required* binding strength (CodeableConcept or code datatypes): If the ValueSet does not have the appropriate “unknown” concept code, you must use a concept from the ValueSet. Otherwise, the instance will not be conformant
[If the source system does not have data for a Mandatory element for a coded data element with *required* binding strength] If any of these status codes is missing [meaning it lacks an "unknown" or otherwise appropriate concept code from the ValueSet, a] 404 HTTP error code and an OperationOutcome **SHALL** be returned in response to a read transaction on the resource.
[If the source system does not have data for a Mandatory element for a coded data element with *required* binding strength, and the ValueSet does not have the appropriate "unknown" concept code, then] if returning a response to a search, the problematic resource **SHALL** be excluded from the search set
[If the source system does not have data for a Mandatory element for a coded data element with *required* binding strength, and the ValueSet does not have the appropriate "unknown" concept code, then] if returning a response to a search, … a *warning* OperationOutcome **SHOULD** be included indicating that other search results were found but could not be compliantly expressed and have been suppressed.
The [FHIR RESTful Search API](http://hl7.org/fhir/R4/http.html#search) requires that Servers that support search **SHALL** support the HTTP `POST`-based search.
For all the supported search interactions in this guide, Servers **SHALL** also support the `GET`-based search.
When searching using the `token` type searchparameter [(how to search by token)](http://hl7.org/fhir/R4/search.html#token) The Server **SHALL** support both [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 Server **SHALL** support both [id and Type values]
When searching using the `date` type searchparameter [(how to search by date)](http://hl7.org/fhir/R4/search.html#date) The Server **SHALL** support 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 Server **SHALL** support values precise … to the second + time offset for elements of `datatype` dateTime
Servers **SHOULD** support a query for resources without requiring a status parameter.
If business requirements prohibit [querying a resource without a status parameter], they **SHALL** follow the guidelines here.
For searches where the Client does not supply a status parameter, an implementation’s business rules **MAY** override the FHIR RESTful search expectations and require a status parameter to be provided
For searches where the Client does not supply a status parameter, … systems [that require a status parameter to be provided] are allowed to reject such requests as follows: **SHALL** return an HTTP 400 status
For searches where the Client does not supply a status parameter, … systems [that require a status parameter to be provided] are allowed to reject such requests as follows: **SHALL** return an [OperationOutcome](http://hl7.org/fhir/R4/operationoutcome.html) specifying that status(es) must be present.
For searches where the Client does not supply a status parameter, … systems [that require a status parameter to be provided] are allowed to reject such requests as follows: **SHALL** support search with status if status required
**SHALL NOT** restrict search results ( i.e., apply ‘hidden’ filters) when a Client includes status parameters in the query.
[For systems that require a status parameter to be provided,] if a system doesn’t support a specific status code value that is queried, it **SHOULD** return an HTTP 200 status with a search bundle.
[For systems that require a status parameter to be provided,] if a system doesn’t support a specific status code value that is queried [and returns a search bundle],... [t]he search bundle **SHOULD** contain resources matching the search criteria
[For systems that require a status parameter to be provided,] if a system doesn’t support a specific status code value that is queried [and returns a search bundle],... [t]he search bundle **SHOULD** contain ... an OperationOutcome warning the Client which status code value is not supported.
For searches where the Client does not supply a status parameter, … systems [that require a status parameter to be provided] are allowed to reject such requests as follows:... **SHALL** document this behavior in its CapabilityStatement for the “search-type” interaction in `CapabilityStatement.rest.resource.interaction.documentation.`
For querying and reading US Core Profiles, Must Support on any profile data element **SHALL** be interpreted as follows…: US Core Responders **SHALL** be capable of populating all data elements as part of the query results specified by the [US Core Server Capability Statement](https://hl7.org/fhir/us/core/STU8/CapabilityStatement-us-core-Server.html).
**SHALL NOT** include the data elements in the resource instance returned as part of the query results.
For querying and reading US Core Profiles, Must Support on any profile data element **SHALL** be interpreted as follows…: In cases where information on a specific data element is missing, and the US Core Responder knows the precise reason for the absence of data (other than suppressed data), US Core Responders **SHOULD** send the reason for the missing information.
[When sending reason for missing information, follow] the same methdology outlined in the [Missing Data](https://hl7.org/fhir/us/core/STU8/general-requirements.html#missing-data) section but using the appropriate reason code instead of unknown [reason code].
Implementors [US Core Responders] 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 Responders] [not] seeking ONC certification [in the ONC IT Health Certification program] **SHALL** interpret Additional USCDI Requirements as … optional.
If an element is marked as Must Support and defined by a pattern [as described by [ElementDefinition.pattern](http://hl7.org/fhir/R4/elementdefinition-definitions.html#ElementDefinition.pattern_x_)], then the pattern defines the elements and element values that the Server **SHALL** be capable of providing.
Primitive elements are single elements with a primitive value. If they are marked as Must Support, then the Server **SHALL** be capable of providing the element value to meet the Must Support requirement.
[W]hen claiming conformance [to a profile with a must support primitive element] … US Core responders **SHALL** be capable of providing the value [of the primitive element]
For any complex element marked as Must Support, the Server **SHALL** be capable of providing at least one of the sub-element values.
If any sub-element is marked as Must Support [for a complex element], it **SHALL** also meet the Must Support requirements and satisfy the Must Support requirements for the parent element.
[I]f any sub-element is marked as Must Support or Additional USCDI [for a complex element] and the parent element is not, there is no expectation that you must support the parent.
[I]f any sub-element is marked as Must Support [for a complex element] and the parent element is not… [and] the parent element is present in an instance, Servers **SHALL** support the sub-element(s) marked as Must Support.
When claiming conformance [to a must support complex element with no must support sub-elements] … US Core Responders **SHALL** be capable of providing a value in [the] sub-element
When claiming conformance [to a must support complex element with one or more must support sub-elements] … US Core Responders **SHALL** be capable of providing a value in [each must support sub-element]
Systems [US Core Responders] 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 Responders] 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 Responders **SHALL** be capable of populating [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 Responders] **MAY** support populating ... 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 Server or Certifying System **SHALL** support at least one element.
An individual SMART Server will publish a granular list of its capabilities, and a set of these capabilities is combined to support a specific use, a Capability Set. See SMART App Launch’s [FHIR OAuth authorization Endpoints and Capabilities](https://hl7.org/fhir/smart-app-launch/STU2/conformance.html#smart-on-fhir-oauth-authorization-endpoints-and-capabilities) for more details. Servers **MAY** support ... [any] SMART on FHIR Capability Sets and capabilities [(see [FHIR OAuth authorization Endpoints and Capabilities](https://hl7.org/fhir/smart-app-launch/STU2/conformance.html#smart-on-fhir-oauth-authorization-endpoints-and-capabilities))]
At least one of the following SMART on FHIR Capability Sets **SHOULD** be supported for US Core Servers that support User-Facing Applications ... [Patient Access Standalone Apps](https://hl7.org/fhir/smart-app-launch/STU2/conformance.html#patient-access-for-standalone-apps) [Clinician Access for EHR Launch](https://hl7.org/fhir/smart-app-launch/STU2/conformance.html#clinician-access-for-standalone)
For certified systems[, those participating in the ONC IT Health Certification program], both **SHALL** be supported: [Patient Access Standalone Apps](https://hl7.org/fhir/smart-app-launch/STU2/conformance.html#patient-access-for-standalone-apps) [Clinician Access for EHR Launch](https://hl7.org/fhir/smart-app-launch/STU2/conformance.html#clinician-access-for-standalone)
Implementations [US Core Responders] supporting Backend Services ... **SHALL** include support for the Client-confidential-asymmetric capability.
Implementations [US Core Responders] supporting Backend Services ... **SHALL** include support for the ... system/scopes.
US Core Server[s] **SHALL** support token introspection defined by the SMART App Launch Guide. For more details and additional consideration, see SMART App Launch’s [Token Introspection](https://hl7.org/fhir/smart-app-launch/STU2/token-introspection.html#token-introspection).
Other systems **MAY** support scopes for the US Core APIs they support [instead of all US Core's required scopes]
Servers **MAY** support other scopes in addition to those listed below and in the Quick Start sections.
For “User-Facing Applications”, a system’s support for patient-level (patient) or user-level (user) scopes depends on its published list of SMART on FHIR capabilities (see the [capability sets](https://hl7.org/fhir/us/core/STU8/scopes.html#capability-sets) above). For example, if a Server lists permission-patient and permission-user in its capabilities, it **SHALL** support both patient-level and user-level required scopes
For “User-Facing Applications”, a system’s support for patient-level (patient) or user-level (user) scopes depends on its published list of SMART on FHIR capabilities (see the [capability sets](https://hl7.org/fhir/us/core/STU8/scopes.html#capability-sets) above). For example, if a Server lists permission-patient and permission-user in its capabilities, it ... **SHOULD** support both patient-level and user-level recommended best-practice scopes
For “Backend-Services”, System-level scopes (system) describe data that a Client system is directly authorized to access. Systems that support system-level (system) scopes **SHALL** support the required US Core scopes
For “Backend-Services”, System-level scopes (system) describe data that a Client system is directly authorized to access. Systems that support system-level (system) scopes **SHOULD** support the recommended US Core scopes
The following scopes that correspond directly to FHIR resource types **SHALL** be supported ... [For] AllergyIntolerance [the] <patient|user|system>/AllergyIntolerance.rs [see [SMART Clinical Scope Syntax](https://hl7.org/fhir/smart-app-launch/STU2/scopes-and-launch-context.html#clinical-scope-syntax) for details on clinical data scopes]
The following scopes that correspond directly to FHIR resource types **SHALL** be supported ... [For] CarePlan [the] <patient|user|system>/CarePlan.rs [see [SMART Clinical Scope Syntax](https://hl7.org/fhir/smart-app-launch/STU2/scopes-and-launch-context.html#clinical-scope-syntax) for details on clinical data scopes]
The following scopes that correspond directly to FHIR resource types **SHALL** be supported ... [For] CareTeam [the] <patient|user|system>/CareTeam.rs [see [SMART Clinical Scope Syntax](https://hl7.org/fhir/smart-app-launch/STU2/scopes-and-launch-context.html#clinical-scope-syntax) for details on clinical data scopes]
The following scopes that correspond directly to FHIR resource types **SHALL** be supported ... [For] Condition [the] <patient|user|system>/Condition.rs [see [SMART Clinical Scope Syntax](https://hl7.org/fhir/smart-app-launch/STU2/scopes-and-launch-context.html#clinical-scope-syntax) for details on clinical data scopes]
The following scopes that correspond directly to FHIR resource types **SHALL** be supported ... [For] Coverage [the] <patient|user|system>/Coverage.rs [see [SMART Clinical Scope Syntax](https://hl7.org/fhir/smart-app-launch/STU2/scopes-and-launch-context.html#clinical-scope-syntax) for details on clinical data scopes]
The following scopes that correspond directly to FHIR resource types **SHALL** be supported ... [For] Device [the] <patient|user|system>/Device.rs [see [SMART Clinical Scope Syntax](https://hl7.org/fhir/smart-app-launch/STU2/scopes-and-launch-context.html#clinical-scope-syntax) for details on clinical data scopes]
The following scopes that correspond directly to FHIR resource types **SHALL** be supported ... [For] DiagnosticReport [the] <patient|user|system>/DiagnosticReport.rs [see [SMART Clinical Scope Syntax](https://hl7.org/fhir/smart-app-launch/STU2/scopes-and-launch-context.html#clinical-scope-syntax) for details on clinical data scopes]
The following scopes that correspond directly to FHIR resource types **SHALL** be supported ... [For] DocumentReference [the] <patient|user|system>/DocumentReference.rs [see [SMART Clinical Scope Syntax](https://hl7.org/fhir/smart-app-launch/STU2/scopes-and-launch-context.html#clinical-scope-syntax) for details on clinical data scopes]
The following scopes that correspond directly to FHIR resource types **SHALL** be supported ... [For] Encounter [the] <patient|user|system>/Encounter.rs [see [SMART Clinical Scope Syntax](https://hl7.org/fhir/smart-app-launch/STU2/scopes-and-launch-context.html#clinical-scope-syntax) for details on clinical data scopes]
The following scopes that correspond directly to FHIR resource types **SHALL** be supported ... [For] Goal [the] <patient|user|system>/Goal.rs [see [SMART Clinical Scope Syntax](https://hl7.org/fhir/smart-app-launch/STU2/scopes-and-launch-context.html#clinical-scope-syntax) for details on clinical data scopes]
The following scopes that correspond directly to FHIR resource types **SHALL** be supported ... [For] Immunization [the] <patient|user|system>/Immunization.rs [see [SMART Clinical Scope Syntax](https://hl7.org/fhir/smart-app-launch/STU2/scopes-and-launch-context.html#clinical-scope-syntax) for details on clinical data scopes]
The following scopes that correspond directly to FHIR resource types **SHALL** be supported ... [For] MedicationDispense [the] <patient|user|system>/MedicationDispense.rs [see [SMART Clinical Scope Syntax](https://hl7.org/fhir/smart-app-launch/STU2/scopes-and-launch-context.html#clinical-scope-syntax) for details on clinical data scopes]
The following scopes that correspond directly to FHIR resource types **SHALL** be supported ... [For] MedicationRequest [the] <patient|user|system>/MedicationRequest.rs [see [SMART Clinical Scope Syntax](https://hl7.org/fhir/smart-app-launch/STU2/scopes-and-launch-context.html#clinical-scope-syntax) for details on clinical data scopes]
The following scopes that correspond directly to FHIR resource types **SHALL** be supported ... [For] Observation [the] <patient|user|system>/Observation.rs [see [SMART Clinical Scope Syntax](https://hl7.org/fhir/smart-app-launch/STU2/scopes-and-launch-context.html#clinical-scope-syntax) for details on clinical data scopes]
The following scopes that correspond directly to FHIR resource types **SHALL** be supported ... [For] Organization [the] <patient|user|system>/Organization.rs [see [SMART Clinical Scope Syntax](https://hl7.org/fhir/smart-app-launch/STU2/scopes-and-launch-context.html#clinical-scope-syntax) for details on clinical data scopes]
The following scopes that correspond directly to FHIR resource types **SHALL** be supported ... [For] Patient [the] <patient|user|system>/Patient.rs [see [SMART Clinical Scope Syntax](https://hl7.org/fhir/smart-app-launch/STU2/scopes-and-launch-context.html#clinical-scope-syntax) for details on clinical data scopes]
The following scopes that correspond directly to FHIR resource types **SHALL** be supported ... [For] Practitioner [the] <patient|user|system>/Practitioner.rs [see [SMART Clinical Scope Syntax](https://hl7.org/fhir/smart-app-launch/STU2/scopes-and-launch-context.html#clinical-scope-syntax) for details on clinical data scopes]
The following scopes that correspond directly to FHIR resource types **SHALL** be supported ... [For] PractitionerRole [the] <patient|user|system>/PractitionerRole.rs [see [SMART Clinical Scope Syntax](https://hl7.org/fhir/smart-app-launch/STU2/scopes-and-launch-context.html#clinical-scope-syntax) for details on clinical data scopes]
The following scopes that correspond directly to FHIR resource types **SHALL** be supported ... [For] Procedure [the] <patient|user|system>/Procedure.rs [see [SMART Clinical Scope Syntax](https://hl7.org/fhir/smart-app-launch/STU2/scopes-and-launch-context.html#clinical-scope-syntax) for details on clinical data scopes]
The following scopes that correspond directly to FHIR resource types **SHALL** be supported ... [For] Provenance [the] <patient|user|system>/Provenance.rs [see [SMART Clinical Scope Syntax](https://hl7.org/fhir/smart-app-launch/STU2/scopes-and-launch-context.html#clinical-scope-syntax) for details on clinical data scopes]
The following scopes that correspond directly to FHIR resource types **SHALL** be supported ... [For] QuestionnaireResponse [the] <patient|user|system>/QuestionnaireResponse.rs [see [SMART Clinical Scope Syntax](https://hl7.org/fhir/smart-app-launch/STU2/scopes-and-launch-context.html#clinical-scope-syntax) for details on clinical data scopes]
The following scopes that correspond directly to FHIR resource types **SHALL** be supported ... [For] RelatedPerson [the] <patient|user|system>/RelatedPerson.rs [see [SMART Clinical Scope Syntax](https://hl7.org/fhir/smart-app-launch/STU2/scopes-and-launch-context.html#clinical-scope-syntax) for details on clinical data scopes]
The following scopes that correspond directly to FHIR resource types **SHALL** be supported ... [For] ServiceRequest [the] <patient|user|system>/ServiceRequest.rs [see [SMART Clinical Scope Syntax](https://hl7.org/fhir/smart-app-launch/STU2/scopes-and-launch-context.html#clinical-scope-syntax) for details on clinical data scopes]
The following scopes that correspond directly to FHIR resource types **SHALL** be supported ... [For] Specimen [the] <patient|user|system>/Specimen.rs [see [SMART Clinical Scope Syntax](https://hl7.org/fhir/smart-app-launch/STU2/scopes-and-launch-context.html#clinical-scope-syntax) for details on clinical data scopes]
The following scopes that correspond directly to FHIR resource types **MAY** be supported ... [For] Location [the] <patient|user|system>/Location.rs [see [SMART Clinical Scope Syntax](https://hl7.org/fhir/smart-app-launch/STU2/scopes-and-launch-context.html#clinical-scope-syntax) for details on clinical data scopes]
The following scopes that correspond directly to FHIR resource types **MAY** be supported ... [For] Medication [the] <patient|user|system>/Medication.rs [see [SMART Clinical Scope Syntax](https://hl7.org/fhir/smart-app-launch/STU2/scopes-and-launch-context.html#clinical-scope-syntax) for details on clinical data scopes]
The following granular scopes **SHALL** be supported ... [For] Condition [the] <patient|user|system>/Condition.rs?category=http://hl7.org/fhir/us/core/CodeSystem/condition-category|health-concern [see [SMART Clinical Scope Syntax](https://hl7.org/fhir/smart-app-launch/STU2/scopes-and-launch-context.html#clinical-scope-syntax) for details on clinical data scopes]
The following granular scopes **SHALL** be supported ... [For] Condition [the] <patient|user|system>/Condition.rs?category=http://terminology.hl7.org/CodeSystem/condition-category|encounter-diagnosis [see [SMART Clinical Scope Syntax](https://hl7.org/fhir/smart-app-launch/STU2/scopes-and-launch-context.html#clinical-scope-syntax) for details on clinical data scopes]
The following granular scopes **SHALL** be supported ... [For] Condition [the] <patient|user|system>/Condition.rs?category=http://terminology.hl7.org/CodeSystem/condition-category|problem-list-item [see [SMART Clinical Scope Syntax](https://hl7.org/fhir/smart-app-launch/STU2/scopes-and-launch-context.html#clinical-scope-syntax) for details on clinical data scopes]
The following granular scopes **SHALL** be supported ... [For] Observation [the] <patient|user|system>/Observation.rs?category=http://hl7.org/fhir/us/core/CodeSystem/us-core-category|sdoh [see [SMART Clinical Scope Syntax](https://hl7.org/fhir/smart-app-launch/STU2/scopes-and-launch-context.html#clinical-scope-syntax) for details on clinical data scopes]
The following granular scopes **SHALL** be supported ... [For] Observation [the] <patient|user|system>/Observation.rs?category=http://terminology.hl7.org//CodeSystem-observation-category|social-history [see [SMART Clinical Scope Syntax](https://hl7.org/fhir/smart-app-launch/STU2/scopes-and-launch-context.html#clinical-scope-syntax) for details on clinical data scopes]
The following granular scopes **SHALL** be supported ... [For] Observation [the] <patient|user|system>/Observation.rs?category=http://terminology.hl7.org/CodeSystem/observation-category|laboratory [see [SMART Clinical Scope Syntax](https://hl7.org/fhir/smart-app-launch/STU2/scopes-and-launch-context.html#clinical-scope-syntax) for details on clinical data scopes]
The following granular scopes **SHALL** be supported ... [For] Observation [the] <patient|user|system>/Observation.rs?category=http://terminology.hl7.org/CodeSystem/observation-category|survey [see [SMART Clinical Scope Syntax](https://hl7.org/fhir/smart-app-launch/STU2/scopes-and-launch-context.html#clinical-scope-syntax) for details on clinical data scopes]
The following granular scopes **SHALL** be supported ... [For] Observation [the] <patient|user|system>/Observation.rs?category=http://terminology.hl7.org/CodeSystem/observation-category|vital-signs [see [SMART Clinical Scope Syntax](https://hl7.org/fhir/smart-app-launch/STU2/scopes-and-launch-context.html#clinical-scope-syntax) for details on clinical data scopes]
The following granular scopes **SHOULD** be supported ... [For] DocumentReference [the] <patient|user|system>/DocumentReference.rs?category=http://hl7.org/fhir/us/core/CodeSystem/us-core-documentreference-category|clinical-note [see [SMART Clinical Scope Syntax](https://hl7.org/fhir/smart-app-launch/STU2/scopes-and-launch-context.html#clinical-scope-syntax) for details on clinical data scopes]
In addition to the capabilities defined in the Server’s CapabilityStatement, Servers **SHALL** document their SMART capabilities in their [Well-Known Uniform Resource Identifiers (URIs)](https://hl7.org/fhir/smart-app-launch/STU2/conformance.html#using-well-known) JSON file.
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 Server **SHALL** list all the required US Core Scopes for the US Core Profiles they support in the scopes_supported array
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 Server [MAY support] additional scopes (so Clients **SHOULD**not consider … [the required scopes] an exhaustive list).
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. Servers **MAY** limit Clients’ scopes to those configured at registration time.
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. … Servers **SHALL** allow users to select a subset of the requested scopes at the approval time.
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] `introspection_endpoint` the URL to a Server’s introspection endpoint. ... Servers **SHALL** document this endpoint in the file
Therefore, a [reference](http://hl7.org/fhir/R4/references.html) to a US Core resource **SHOULD** include a logical id (Reference.reference), not an identifier (Reference.identifier).
For all references, US Core Responders **SHOULD** return resources that conform to a US Core profile if a US Core profile exists for the resource type.
When responding to a query, Servers **SHOULD** not use inline [contained](http://hl7.org/fhir/R4/references.html#contained) resources to represent the returned data.
[I]f referencing a contained resource in a US Core Profile, the contained resource **SHOULD** be a US Core Profile if a US Core Profile exists for the resource type.
[M]asking data [where a specific piece of data is hidden for security and privacy reasons] **SHOULD** be handled based on implemented policies.
[When masking data] elements with a minimum cardinality = 0 (including elements labeled Must Support) [for security and privacy reasons], the element **SHOULD** be omitted from the resource.
[When masking] Mandatory elements (in other words, where the minimum cardinality is > 0) [for security and privacy reasons, use the code “unknown” following the guidance on Missing Data in the Conformance Sections.
[When using SNOMED codes in US Core Profiles I]mplementers **MAY** use the default system URI [of [SNOMED CT](http://snomed.info/sct)], which refers to an unspecified edition/version [of SNOMED]
[To enable] terminology Servers to be able to validate US Edition-only codes [of [SNOMED CT](http://snomed.info/sct)], implementers **SHOULD** provide the accompanying system URI to describe the edition [see example 2 on [US Core general guidance](https://hl7.org/fhir/us/core/STU8/general-guidance.html#snomed-ct-united-states-edition)]
[If a] US Core Profiles binds the Quantity.code element in the Quantity datatype to the [UCUM](http://unitsofmeasure.org/) code system, [then] systems **SHOULD**also use UCUM for the optional valueRange and valueRatio datatypes (which are complex datatypes with Quantity elements)
[If a] US Core Profiles binds the Quantity.code element in the Quantity datatype to the [UCUM](http://unitsofmeasure.org/) code system, [when] UCUM code [is] provided [it **SHOULD** be indicated in the Quantity.unit and Quantity.code elements with Quantity.system = "http://unitsofmeasure.org"]
[If a] US Core Profiles binds the Quantity.code element in the Quantity datatype to the [UCUM](http://unitsofmeasure.org/) code system, [then] if UCUM units are unavailable, represent units in the unit element
A FHIR Server **SHOULD** not delete records.
A FHIR Server **SHOULD** update the appropriate resource status to entered-in-error or inactive [when requested to delete records]
If a system supports the deletion of records, they **SHOULD** refer to the [Deletion Safety Checks](http://hl7.org/fhir/R4/safety.html#conformance) in the FHIR specification.
A FHIR Server **SHOULD** allow these resources [those entered in error] to be searchable by Client applications.
If the FHIR Server has updated the resource status to entered-in-error: For patient facing applications, A FHIR Server **SHOULD** remove the resource’s contents, leaving only an id and status. Note that this typically will not conform to the US Core or FHIR StructureDefinitions.
If the FHIR Server has updated the resource status to entered-in-error: ... For provider-facing applications, the content **MAY** be supplied with content and additional detail (such as the reason for the status change) that the patient viewing system would typically not have access to.
the data provider **SHOULD** do their best to translate (safely) to the requested language [when accessing records in a native or requested language]
[When Clients request a resource in a specific language] Servers **SHOULD** make reasonable efforts to translate what can be safely translated.
[When Clients request a resource in a specific language] Servers **SHOULD** populate the Resource’s language element with a code based on the underlying language of record, not the requested language.
[When Clients request a resource in a specific language] Servers **SHOULD** … [use] the [Human Language](http://hl7.org/fhir/R4/extension-language.html) Extension when the language of a display, etc, is known to differ from the stated (or inferred) language.
[When Clients request a resource in a specific language] [Servers **SHOULD** use] the [Translation](http://hl7.org/fhir/R4/extension-translation.html) Extension when the Server provides additional translations by its own choice or in response to a different Accept-Language than what the resource is stored in.
[When Clients request a resource in a specific language] Servers **SHOULD** make it known what languages are supported in their CapabilityStatement(s) using this extension: http://hl7.org/fhir/5.0/StructureDefinition/extension-CapablilityStatement.acceptLanguage [[definition](https://hl7.org/fhir/R5/capabilitystatement-definitions.html#CapabilityStatement.acceptLanguage)]
Servers **SHOULD** support the [_lastUpdated](http://hl7.org/fhir/R4/search.html#lastUpdated) search parameter for US Core Profiles
Servers ... **SHOULD** populate [Resource.meta.lastUpdated](http://hl7.org/fhir/R4/resource.html#Meta) for US Core Profiles as accurately as possible.
Servers **SHALL** document in CapabilityStatement.rest.resource.searchParam.documentation the types of changes that can be detected using the _lastUpdated search parameter
US Core Servers [MAY support compartment based searchs, but] are not required to support patient [compartment](http://hl7.org/fhir/R4/compartmentdefinition.html) based searches.
US Core Servers [MAY resolve absolute URLs, but] are not required to resolve absolute URLs external to their environment.
Servers can [MAY] choose to return the results in a series of pages to manage the number of search results returned.
Servers **SHALL** support, at minimum, these … "Common Clinical Notes": [Consultation Note (11488-4)](https://loinc.org/11488-4.html)
Servers **SHALL** support, at minimum, these … "Common Clinical Notes": [Discharge Summary (18842-5)](https://loinc.org/18842-5.html)
Servers **SHALL** support, at minimum, these … "Common Clinical Notes": [History & Physical Note (34117-2)](https://loinc.org/34117-2.html)
Servers **SHALL** support, at minimum, these … "Common Clinical Notes": [Procedures Note (28570-0)](https://loinc.org/28570-0.html)
Servers **SHALL** support, at minimum, these … "Common Clinical Notes": [Progress Note (11506-3)](https://loinc.org/11506-3.html)
Servers **SHALL** support, at minimum, these … "Common Clinical Notes": [Imaging Narrative (18748-4)](https://loinc.org/18748-4.html)
Servers **SHALL** support, at minimum, these … "Common Clinical Notes": [Laboratory Report Narrative (11502-2)](https://loinc.org/11502-2.html)
Servers **SHALL** support, at minimum, these … "Common Clinical Notes": [Pathology Report Narrative (11526-1)](https://loinc.org/11526-1.html)
Servers **SHALL** support, at minimum, these … DiagnosticReport categories: [Cardiology (LP29708-2)](https://loinc.org/LP29708-2)
Servers **SHALL** support, at minimum, these … DiagnosticReport categories: [Pathology (LP7839-6)](https://loinc.org/LP7839-6)
Servers **SHALL** support, at minimum, these … DiagnosticReport categories: [Radiology (LP29684-5)](https://loinc.org/LP29684-5)
systems are encouraged to support other common notes types, such as: [Referral Note (57133-1)](https://loinc.org/57133-1.html)
systems are encouraged to support other common notes types, such as: [Nurse Note (34746-8)](https://loinc.org/34746-8.html)
To enable consistent access to scanned DiagnosticReport clinical reports, the FHIR Server **SHALL** expose these overlapping scanned or narrative-only reports through both DiagnosticReport and DocumentReference by representing the same attachment URL [as] DocumentReference.content.attachment.url [and] DiagnosticReport.presentedForm.url
when DiagnosticReport.presentedForm.url references a Scan (PDF), that Attachment **SHALL** also be accessible through DocumentReference.content.attachment.url
Systems [Servers] **MAY** extend their capabilities [around types of clinical notes] to the complete US Core DocumentReference Type Value Set.
Systems **SHALL** implement the [US Core DocumentReference Profile](https://hl7.org/fhir/us/core/STU8/StructureDefinition-us-core-documentreference.html)
Systems **SHALL** implement the [US Core DiagnosticReport Profile for Report and Note exchange](https://hl7.org/fhir/us/core/STU8/StructureDefinition-us-core-diagnosticreport-note.html)
Systems [Servers] **MAY** support other [DiagnosticReport] categories as well.
The following **SHOULD** be exposed via DiagnosticReport: Imaging Narrative
The following **SHOULD** be exposed via DiagnosticReport: Laboratory Report Narrative
The following **SHOULD** be exposed via DiagnosticReport: Pathology Report Narrative
The following **SHOULD** be exposed via DiagnosticReport: Procedure Note
Servers that support DiagnosticReport **SHALL** include the clinical note narrative content in `DiagnosticReport.presentedForm`
FHIR Server claiming support to this guide **SHOULD** support the $expand operation [[operation link](http://hl7.org/fhir/R4/valueset-operation-expand.html) to provide information to Clients requesting information on the note and report types the Server supports]
[If Servers support the [$expand](http://hl7.org/fhir/R4/valueset-operation-expand.html) operation for discovering note and report types, then Servers **SHALL** support] the #expand operation as follows: GET [base]/ValueSet/$expand?context=http://hl7.org/fhir/us/core/StructureDefinition/us-core-diagnosticreport-note#DiagnosticReport.category&contextDirection=outgoing for DiagnosticReport report category discovery [for read operations]
[If Servers support the [$expand](http://hl7.org/fhir/R4/valueset-operation-expand.html) operation for discovering note and report types, then Servers **SHALL** support] the #expand operation as follows: GET [base]/ValueSet/$expand?context=http://hl7.org/fhir/us/core/StructureDefinition/us-core-diagnosticreport-note#DiagnosticReport.category&contextDirection=incoming for DiagnosticReport report category discovery [for write operations]
[If Servers support the [$expand](http://hl7.org/fhir/R4/valueset-operation-expand.html) operation for discovering note and report types, then Servers **SHALL** support] the #expand operation as follows: GET [base]/ValueSet/$expand?context=http://hl7.org/fhir/us/core/StructureDefinition/us-core-diagnosticreport-note#DiagnosticReport.code&contextDirection=outgoing for DiagnosticReport report type discovery [for read operations]
[If Servers support the [$expand](http://hl7.org/fhir/R4/valueset-operation-expand.html) operation for discovering note and report types, then Servers **SHALL** support] the #expand operation as follows: GET [base]/ValueSet/$expand?context=http://hl7.org/fhir/us/core/StructureDefinition/us-core-diagnosticreport-note#DiagnosticReport.code&contextDirection=incoming for DiagnosticReport report type discovery [for write operations]
[If Servers support the [$expand](http://hl7.org/fhir/R4/valueset-operation-expand.html) operation for discovering note and report types, then Servers **SHALL** support] the #expand operation as follows: GET [base]/ValueSet/$expand?context=http://hl7.org/fhir/us/core/StructureDefinition/us-core-documentreference#DocumentReference.category&contextDirection=outgoing for DocumentReference note category discovery [for read operations]
[If Servers support the [$expand](http://hl7.org/fhir/R4/valueset-operation-expand.html) operation for discovering note and report types, then Servers **SHALL** support] the #expand operation as follows: GET [base]/ValueSet/$expand?context=http://hl7.org/fhir/us/core/StructureDefinition/us-core-documentreference#DocumentReference.category&contextDirection=incoming for DocumentReference note category discovery [for write operations]
[If Servers support the [$expand](http://hl7.org/fhir/R4/valueset-operation-expand.html) operation for discovering note and report types, then Servers **SHALL** support] the #expand operation as follows: GET [base]/ValueSet/$expand?context=http://hl7.org/fhir/us/core/StructureDefinition/us-core-documentreference#DocumentReference.type&contextDirection=outgoing for DocumentReference note type discovery [for read operations]
[If Servers support the [$expand](http://hl7.org/fhir/R4/valueset-operation-expand.html) operation for discovering note and report types, then Servers **SHALL** support] the #expand operation as follows: GET [base]/ValueSet/$expand?context=http://hl7.org/fhir/us/core/StructureDefinition/us-core-documentreference#DocumentReference.type&contextDirection=incoming for DocumentReference note type discovery [for write operations]
[If Servers support the [$expand](http://hl7.org/fhir/R4/valueset-operation-expand.html) operation then] the note and report types for a particular Server [SHOULD be] discovered by invoking the #expand operation as follows: GET [base]/ValueSet/$expand?context=http://hl7.org/fhir/us/core/StructureDefinition/us-core-diagnosticreport-note#DiagnosticReport.presentedForm.contentType&contextDirection=outgoing for DiagnosticReport report content type discovery [for read operations]
[If Servers support the [$expand](http://hl7.org/fhir/R4/valueset-operation-expand.html) operation then] the note and report types for a particular Server [SHOULD be] discovered by invoking the #expand operation as follows: GET [base]/ValueSet/$expand?context=http://hl7.org/fhir/us/core/StructureDefinition/us-core-diagnosticreport-note#DiagnosticReport.presentedForm.contentType&contextDirection=incoming for DiagnosticReport report content type discovery [for write operations]
[If Servers support the [$expand](http://hl7.org/fhir/R4/valueset-operation-expand.html) operation then] the note and report types for a particular Server [SHOULD be] discovered by invoking the #expand operation as follows: GET [base]/ValueSet/$expand?context=http://hl7.org/fhir/us/core/StructureDefinition/us-core-documentreference#DocumentReference.content.attachment.contentType&contextDirection=outgoing for DocumentReference note content type discovery [for read operations]
[If Servers support the [$expand](http://hl7.org/fhir/R4/valueset-operation-expand.html) operation then] the note and report types for a particular Server [SHOULD be] discovered by invoking the #expand operation as follows: GET [base]/ValueSet/$expand?context=http://hl7.org/fhir/us/core/StructureDefinition/us-core-documentreference#DocumentReference.content.attachment.contentType&contextDirection=incoming for DocumentReference note content type discovery [for write operations]
When using a code [to represent a medication][, the code **SHALL** follow the [extensible](http://hl7.org/fhir/R4/terminologies.html#extensible) binding rules to [Medication Clinical Drug (RxNorm)](https://vsac.nlm.nih.gov/valueset/2.16.840.1.113762.1.4.1010.4/expansion) - i.e., unless RxNorm does not cover the concept, the RxNorm code **SHALL** be used.
USCDI recommends the [National Drug Codes (NDC)](https://www.fda.gov/drugs/drug-approvals-and-databases/national-drug-code-directory) as an optional medication terminology. They **MAY** be supplied as an additional coding element [when representing a medication]
When referencing the Medication resource, the resource **MAY** be included in the returned bundle, as an external resource, or as a [contained](http://hl7.org/fhir/R4/references.html#contained) resource if it can’t stand alone. … The Server application **MAY** choose any combination of these methods
if an external reference to Medication is used, the Server **SHALL** support the [_include](http://hl7.org/fhir/R4/search.html#include) parameter for searching this element
Requirements to access “all medications” [all historical, active, and future prescribed medications and medications entered in error and whose status is unknown.] and “all active medications” [all medications with an active status. Active medications do not include past, future, unknown status, and entered-in-error medications.] for a patient: A MedicationRequest resource query **SHALL** be all that is required to access "all medications" or "all active medications" for a patient. (In other words, no other medication resource type needs to be fetched)
Requirements to access “all medications” [all historical, active, and future prescribed medications and medications entered in error and whose status is unknown.] and “all active medications” [all medications with an active status. Active medications do not include past, future, unknown status, and entered-in-error medications.] for a patient: The [MedicationRequest resource] query result **SHALL** include all MedicationRequest resources with a `MedicationRequest.intent` = "order" representing authorized medication orders directly derived from the system's orders.
Requirements to access “all medications” [all historical, active, and future prescribed medications and medications entered in error and whose status is unknown.] and “all active medications” [all medications with an active status. Active medications do not include past, future, unknown status, and entered-in-error medications.] for a patient: The [MedicationRequest resource] query result **SHALL** include all prescribed and "self-prescribed" MedicationRequest resources with a `MedicationRequest.intent` = "plan" representing reported medications.
Requirements to access “all medications” [all historical, active, and future prescribed medications and medications entered in error and whose status is unknown.] and “all active medications” [all medications with an active status. Active medications do not include past, future, unknown status, and entered-in-error medications.] for a patient: Servers **SHALL** use the `MedicationRequest.reported[x]` element to indicate that the MedicationRequest record was captured as a secondary "reported" record rather than an original primary source-of-truth record.
Requirements to access “all medications” [all historical, active, and future prescribed medications and medications entered in error and whose status is unknown.] and “all active medications” [all medications with an active status. Active medications do not include past, future, unknown status, and entered-in-error medications.] for a patient: When recording "self-prescribed" medication, Servers **SHOULD** use the `MedicationRequest.requester` element to indicate the Patient or RelatedPerson is the prescriber.
Requirements to access “all medications” [all historical, active, and future prescribed medications and medications entered in error and whose status is unknown.] and “all active medications” [all medications with an active status. Active medications do not include past, future, unknown status, and entered-in-error medications.] for a patient: Servers **SHOULD** support the encounter search parameter.
Requirements to access “all medications” [all historical, active, and future prescribed medications and medications entered in error and whose status is unknown.] and “all active medications” [all medications with an active status. Active medications do not include past, future, unknown status, and entered-in-error medications.] for a patient: [If Servers support the encounter search parameter, s]earching by encounter will return all medications ordered during that encounter, including medications administered in the hospital and prescribed or discharge medications intended to be taken at home.
Requirements to access “all medications” [all historical, active, and future prescribed medications and medications entered in error and whose status is unknown.] and “all active medications” [all medications with an active status. Active medications do not include past, future, unknown status, and entered-in-error medications.] for a patient: Servers **MAY** support the search parameters `category`and `encounter`. This search will return all medications ordered during an encounter for a given MedicationRequest.category such as "inpatient".
To provide a list of a patient’s medications, it **MAY** be necessary to “de-duplicate” them. The de-duplication activity **MAY** be supplied by the Server
An agent.type=”assembler”, agent.type=”transmitter”, or other agents from [Provenance Agent Type](https://hl7.org/fhir/us/core/STU8/ValueSet-us-core-provenance-participant-type.html) value set **MAY** also be included.
implementers [of US Core's framework of Screening and Assessments] **SHOULD** consider more constrained, domain-specific profiles derived from the US Core Profiles to meet the needs of their respective use cases.
Every Server that supports the USDCI Data Class “Health Status/Assessments”: **SHALL** support representing clinical judgments using [US Core Condition Problems and Health Concerns Profile](https://hl7.org/fhir/us/core/STU8/StructureDefinition-us-core-condition-problems-health-concerns.html) or [US Core Simple Observation Profile](https://hl7.org/fhir/us/core/STU8/StructureDefinition-us-core-simple-observation.html).
Every Server that supports the USDCI Data Class “Health Status/Assessments”: ... The US Core Simple Observation Profile's Observation.derivedFrom element **SHOULD** reference the [Structured Screening and Assessment](https://hl7.org/fhir/us/core/STU8/screening-and-assessments.html#structured-screening-and-assessments) upon which clinical judgment observations are made
Every Server that supports the USDCI Data Class “Health Status/Assessments”: ... the US Core Condition Profile's Condition.evidence.detail element **SHOULD** reference the [Structured Screening and Assessment](https://hl7.org/fhir/us/core/STU8/screening-and-assessments.html#structured-screening-and-assessments) which assist in diagnosing problems or health concerns.
For API developers using US Core, it’s important to understand when to use the QuestionnaireResponse versus Observation to represent structured assessments and surveys. Here are some guidelines to help choose the appropriate profile: Observations represent specific point-in-time facts that need to be searched, trended, the subject of statistical analysis, and directly referenced in support of other actions ... anything that meets one of the preceding criteria **SHOULD** be surfaced as an Observation.
Implementers **SHOULD** treat these [USCDI Health Status Assessments Data Element] value sets as having an [extensible](http://hl7.org/fhir/R4/terminologies.html#extensible) binding.
when recording SDOH data [with] US Core Profiles, Servers **SHOULD** use … [Social Determinants of Health Conditions Value Set](https://vsac.nlm.nih.gov/valueset/2.16.840.1.113762.1.4.1196.788/expansion), [Social Determinants of Health Procedures Value Set](https://vsac.nlm.nih.gov/valueset/2.16.840.1.113762.1.4.1196.789/expansion), [Social Determinants of Health Goals Value Set](https://vsac.nlm.nih.gov/valueset/2.16.840.1.113762.1.4.1247.71/expansion), [and] [Social Determinants of Health Service Requests Value Set](https://vsac.nlm.nih.gov/valueset/2.16.840.1.113762.1.4.1196.790/expansion)
Servers **SHOULD** maintain a stable common identifier for a resource across [FHIR] versions.
In an upgraded R4 endpoint, any data in FHIR DSTU2 **SHOULD** be in FHIR R4.
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
Servers **SHOULD** make available the same information in DSTU2 and R4 where the more recent standard allows.
Servers **SHOULD** make available the same information in DSTU2 and R4 where the more recent standard allows … [with the] exception [of] MedicationStatement data [should be] mapped to MedicationRequest
Servers **SHOULD** make available the same information in DSTU2 and R4 where the more recent standard allows … [with the] exception [of] care teams, as represented by CarePlan, **SHOULD** be mapped to CareTeam in R4
Data **SHOULD** be maintained between [FHIR] versions (i.e., not be degraded).
To allow Clients to use a single authorization token when accessing resources from multiple version-specific endpoints, Servers **SHOULD** use the same base authorization endpoint across versions.
[The clinical status of the allergy] **SHALL** be present if verification status is not “entered-in-error”
[The clinical status of the allergy] **SHALL NOT** be present if verification Status is “entered-in-error”
No Known Allergies **MAY** be represented using the US Core-AllergyIntolerance profile
[When No Known Allergies is documented the system **SHALL** use an] appropriate negation code in AllergyIntolerance.code
[When No Known Allergies is documented the system **SHALL** use an] verification status in AllergyIntolerance.verificationStatus
If a patient has not been asked about their allergies, this would be represented as: AllergyIntolerance.code = “1631000175102” (Patient not asked (contextual qualifier) (qualifier value)) AllergyIntolerance.verificationStatus = “unconfirmed” or empty (in other words, the element omitted)
If a patient has been asked, but has indicated they have no known allergies, this would be represented as: AllergyIntolerance.code = “716186003” (No known allergy (situation)) AllergyIntolerance.verificationStatus = “confirmed”
Considerations for systems aligning with [HL7 Consolidated (C-CDA)](http://www.hl7.org/implement/standards/product_brief.cfm?product_id=492) Care Plan requirements: US Core Goal **SHOULD** be present in CarePlan.goal
Considerations for systems aligning with [HL7 Consolidated (C-CDA)] (http://www.hl7.org/implement/standards/product_brief.cfm?product_id=492) Care Plan requirements: ... US Core Condition **SHOULD** be present in CarePlan.addresses
Considerations for systems aligning with [HL7 Consolidated (C-CDA)] (http://www.hl7.org/implement/standards/product_brief.cfm?product_id=492) Care Plan requirements: Assessment and Plan **MAY** be included as narrative in CarePlan.text
Although both US Core Practitioner Profile and US Core PractitionerRole are Must Support, ... Server system[s conforming to the US Core CareTeam profile are] ... not required to support references to both, but **SHALL** support at least one of them
[When conforming to the US Core CareTeam profile] Because the US Core PractitionerRole Profile supplies the provider’s location and contact information and a reference to the Practitioner, Server systems [conforming to the US Core CareTeam profile] **SHOULD** reference it instead of the US Core Practitioner Profile [when conforming to the US Core CareTeam profile] .
Servers [conforming to the US Core CareTeam profile] that support only US Core Practitioner Profile and do not support the US Core PractitionerRole Profile **SHALL** provide implementation-specific guidance on how to access a provider’s location ... information using only the Practitioner resource.
Servers [conforming to the US Core CareTeam profile] that support only US Core Practitioner Profile and do not support the US Core PractitionerRole Profile **SHALL** provide implementation-specific guidance on how to access a provider’s ... contact information using only the Practitioner resource.
USCDI’s applicable vocabulary standards for Encounter Diagnosis are SNOMED CT and ICD-10-CM. The US Core Condition Codes only supports ICD-9-CM for historical purposes. When using ICD codes, only non-header ICD-10-CM codes **SHOULD** be used as the primary code for current encounter diagnoses.
[A US Core Condition Encounter Diagnosis] encounter **SHOULD** always be referenced in Condition.encounter.
If the category is "problem-list-item", Condition.clinicalStatus **SHOULD** be present.
Updates to .meta.lastUpdated **SHOULD** reflect: New problems and health concerns
Updates to .meta.lastUpdated **SHOULD** reflect: Changes in the clinical status or verification status of problems or health concerns.
A coverage.type of “81” (Self-pay) **MAY** be used to imply that the patient has no coverage or that an individual or organization other than an insurer is taking responsibility for payment for a portion of the health care costs.
To differentiate Medicare Parts A, B, C, and D systems **SHOULD** use the following codes [when sending Coverage.type]: [For] Part A and B [use] 121 (Medicare Fee For Service)
To differentiate Medicare Parts A, B, C, and D systems **SHOULD** use the following codes: [For] Part C (Medicare Advantage Plan) [use] 111 (Medicare HMO), 112 (Medicare PPO), 113 (Medicare POS)
To differentiate Medicare Parts A, B, C, and D systems **SHOULD** use the following codes: [For] Part D [use] 122 (Medicare Drug Benefit)
If Insurers issue unique member IDs for dependents, then the memberId Coverage.identifier **SHOULD**be used [with the unique dependent ID] instead of Coverage.dependent to uniquely refer to the dependent with respect to their insurance.
Implementers **SHOULD** use the FDA Global UDI Database (GUDID) and associated APIs to parse and validate the [unique device ID] UDI
Medical devices with UDI information **SHALL** represent the UDI code in Device.udiCarrier.carrierHRF
UDI-PI elements present [in Device.udiCarrier.carrierHRF] **SHALL** be represented in the corresponding US Core Device Profile elements
If UDI is not present and the manufacturer … is available, … [it] **SHOULD** be included to support historical reports of implantable medical devices [where] manufacturer [is sent in] Device.manufacturer
If UDI is not present and the ... model number information is available, … [it] **SHOULD** be included to support historical reports of implantable medical devices [where] model [is sent in] Device.model
Records of implanted devices **MAY** be queried against UDI data, including: UDI HRF string (udi-carrier)
Records of implanted devices **MAY** be queried against UDI data, including:UDI Device Identifier (udi-di)
Records of implanted devices **MAY** be queried against UDI data, including: Manufacturer (manufacturer)
Records of implanted devices **MAY** be queried against UDI data, including: Model number (model)
Implementers **MAY** also adopt custom SearchParameters for searching by lot numbers
Implementers **MAY** also adopt custom SearchParameters for searching by serial number
Implementers **MAY** also adopt custom SearchParameters for searching by expiration date
Implementers **MAY** also adopt custom SearchParameters for searching by manufacture date
Implementers **MAY** also adopt custom SearchParameters for searching by distinct identifier
The diagnostically relevant time (known as the “effective time” and typically the time of specimen collection) … **SHALL** be present if status [of the diagnostic report] is ‘partial’, ‘preliminary’, ‘final’, ‘amended’, ‘corrected’, or ‘appended’.
When the report was released … **SHALL** be present if status [of the diagnostic report] is ‘partial’, ‘preliminary’, ‘final’, ‘amended’, ‘corrected’, or ‘appended’.
Updates to .meta.lastUpdated **SHOULD** reflect New laboratory reports.
Updates to .meta.lastUpdated **SHOULD** reflect changes in the status of laboratory reports, including events that trigger the same status (e.g., amended → amended).
Other [diagnostic report] categories **MAY** be supported [when using US Core DiagnosticReport Profile for Report and Note Exchange]
For Diagnostic Imaging Reports systems **SHOULD** support using the subset of LOINC codes listed in Table 4: LOINC® Document Type Codes in *HL7 Standard for CDA® Release 2: Imaging Integration; Basic Imaging Reports in CDA and DICOM, Release 1*
The DocumentReference.type binding **MAY** extend to the whole [US Core DocumentReference Type Value Set](https://hl7.org/fhir/us/core/STU8/ValueSet-us-core-documentreference-type.html)
[DocumentReference.type **MAY** also use] other category schemes such as the LOINC-based [Document Class Value Set](http://hl7.org/fhir/R4/valueset-document-classcodes.html) and [IHE XDSclassCode](https://wiki.ihe.net/index.php/XDS_classCode_Metadata_Coding_System)
Although both [DocumentReference.attachment.url and DocumentReference.attachment.data] are marked as Must Support, the Server system is not required to support an address and inline base64 encoded data, but **SHALL** support at least one of these elements.
If there are multiple DocumentReference.content element repetitions, these **SHALL** all represent the same document in different formats or attachment metadata
The [documentReference.content] element **SHALL NOT** contain different versions of the same content.
The organization responsible for the DocumentReference **SHALL** be present either in DocumentReference.custodian or accessible in the Provenance resource targeting the DocumentReference using Provenance.agent.who or Provenance.agent.onBehalfOf
Although ... marked as Must Support, Servers are not required to support both [an Encounter.reasonCode or a reference with Encounter.reasonReference], but they **SHALL** support at least one of these elements.
If Encounter.reasonReference references an Observation, it **SHOULD** conform to a US Core Observation [profile applicable to the observation being made]
Although … marked as Must Support, Servers are not required to support both Encounter.location.location and Encounter.serviceProvider, but they **SHALL** support at least one of these elements.
If the event facility/location differs from the Encounter.location, systems **SHOULD** reference it directly
If the event facility/location differs from the Encounter.location, … systems **SHALL** use the location element for all resources where the element is available.
If the event facility/location differs from the Encounter.location … systems **MAY** use the standard [Event Location Extension](http://hl7.org/fhir/StructureDefinition/event-location) for US Core DiagnosticReport Profile for Laboratory Results Reporting and US Core Observation Clinical Result Profile.
Updates to .meta.lastUpdated **SHOULD** reflect New encounters/visits
Updates to .meta.lastUpdated **SHOULD** reflect changes in the status of encounters, including events that trigger the same status (e.g., in-progress → in-progress).
Although both Goal.startDate and Goal.target.dueDate are marked as Must Support, the Server system is not required to support both, but **SHALL** support at least one of these elements.
Servers **SHALL** use the status code: not-done to represent that an immunization was not given.
When referencing a Medication resource in .medicationReference, the resource **MAY** be [contained](http://hl7.org/fhir/R4/references.html#contained)
When referencing a Medication resource in .medicationReference, the resource **MAY** be an external resource
The Server systems are not required to support both a [medication] code and a reference [when sending medicationDispense], but **SHALL** support at least one of these methods
If an external reference to a Medication resource is used, the Server **SHALL** support the [_include](http://hl7.org/fhir/R4/search.html#include) parameter for searching this element.
When recording “self-prescribed” medication, requester **SHOULD** be used to indicate the Patient or RelatedPerson as the prescriber
Although [medicationRequest.reportedBoolean and MedicationRequest.reportedReference] are both marked as Must Support, the Server system is not required to support both, but **SHALL** support at least one of these elements
[For organizations participating in the ONC Health IT Certification program,] the referenced resources **SHOULD** be a US Core Profile as documented in [Referencing US Core Profiles](https://hl7.org/fhir/us/core/STU8/general-guidance.html#referencing-us-core-profiles).
Source EHR identifiers **SHOULD** be included to support deduplication across MedicationRequest resources.
The observations **MAY** have additional codes that translate or map to the Observation code or category codes [such as] … local system-specific codes [and] …more specific codes
[For an Observation a] code system value **SHOULD** be supplied for each additional code
Because the blood pressure values are communicated in the mandatory systolic and diastolic components [when using the US Core Average Blood Pressure Profile,] the Observation.value[x] element **SHALL** be omitted
The context or precondition of a patient’s [care experience] preference **SHOULD** be supplied in the Observation.valueString or in an extension
Servers **SHOULD** use the base FHIR [Observation Category Codes] (http://hl7.org/fhir/R4/valueset-observation-category.html) [in Observation.category]
Systems **SHOULD** support Observation.effectivePeriod to accurately represent measurements over time
An Observation.component without a value, **SHALL** include a reason why the data is absent
Systems that never provide a component observation without a component value **MAY** choose not to support Observation.component.dataAbsentReason
An Observation without a value, **SHALL** include a reason why the data is absent
[For] an Observation without a value … [Systems **MAY** choose not to] include a reason why the data is absent … [if] there are component observations or … reporting panel observations using Observation.hasMember
Systems that never provide an observation without a value **MAY** choose not to support Observation.dataAbsentReason
[When sending US Core Laboratory Results Observation Profile] updates to .meta.lastUpdated **SHOULD** reflect new laboratory observations
[When sending US Core Laboratory Results Observation Profile] updates to .meta.lastUpdated **SHOULD** reflect changes in the status of laboratory observations, including events that trigger the same status (e.g., amended → amended)
[When sending US Core Observation Occupation Profile] for … [a] current job ,systems **SHALL** omit observation.effectivePeriod.end to indicate it is ongoing.
When the industry is known, but the occupation is not, systems **SHALL** use the value “unknown” from the [DataAbsentReason Code System](http://hl7.org/fhir/R4/codesystem-data-absent-reason.html)
when the occupation is known but the industry is not, systems **SHALL** omit the industry Observation.component
[For] multi-question surveys or assessments Observation.code is an overarching assessment or screening code, and the Observation.value element **SHOULD** be empty
A practitioner’s clinical observation or assertion about a patient’s health status, which is not a response to a screening or assessment question, **SHOULD** use the [US Core Simple Observation Profile](https://hl7.org/fhir/us/core/StructureDefinition-us-core-simple-observation.html) instead [of the US Core Observation Screening Assessment Profile]
the Server system ... **SHALL** support [either] Reference(US Core Observation Screening Assessment Profile) or Reference(US Core QuestionnaireResponse Profile) for Observation.derivedFrom
Observations formally part of an assessment tool or survey **SHOULD** use the [US Core Observation Screening Assessment Profile](https://hl7.org/fhir/us/core/STU8/StructureDefinition-us-core-observation-screening-assessment.html).
An assertion or determination derived from screening and assessment tools **SHOULD** reference them using Observation.derivedFrom
When using `Observation.derivedFrom’ to reference an Observation, the referenced Observation **SHOULD** be a US Core Observation
[US Core Vital Signs] observations **MAY** have [component](http://hl7.org/fhir/R4/observation.html#gr-comp) observations … [see] FHIR core specification [vital signs table](http://hl7.org/fhir/R4/observation-vitalsigns.html#vitals-table) for examples
Information about the growth chart tables used to determine percentiles **SHOULD** be supplied in Observation.note.text
[In the US Core Blood Pressure Profile] because the blood pressure values are communicated in the mandatory systolic and diastolic components[,] the Observation.value[x] element **SHOULD** be omitted
[In the US Core Blood Pressure Profile] because the blood pressure values are communicated in the mandatory systolic and diastolic components[,] an Observation without a systolic or diastolic result value, **SHALL** include a reason why the data is absent in Observation.component.dataAbsentReason
[In the US Core Blood Pressure Profile] because the blood pressure values are communicated in the mandatory systolic and diastolic components[,] All Server systems - including those that never provide a component observation without a value - **SHALL** support Observation.component.dataAbsentReason for the components.
Inspired oxygen therapy **MAY** be represented with [component](http://hl7.org/fhir/R4/observation.html#gr-comp) observations when measured at the same time as the pulse oximetry measurements [in the US Core Pulse Oximetry profile]
Many pulse oximetry readings are taken while the patient is breathing room air. The concept of “room air” (unmodified, ambient air) **SHOULD** be represented as an inhaled oxygen flow rate of 0 liters/min
A pulse oximetry reading without inspired oxygen component observations **MAY** imply that the measurement was performed while the patient was breathing room air or that the inspired oxygen reading was omitted. To remove this uncertainty, the inspired oxygen [component](http://hl7.org/fhir/R4/observation.html#gr-comp) observations **SHOULD** be used [when using the US Core Pulse Oximetry profile.]
Systems **SHALL** support National Provider Identifier (NPI) for organizations
Systems … **SHOULD** the National Association of Insurance Commissioners NAIC Company code (sometimes called “NAIC Number” or “cocode”) for payers.
Systems … **SHOULD** support Clinical Laboratory Improvement Amendments (CLIA) for laboratories
The Complex [Extension] for Race ... allow[s] for one or more codes of which **MAY** include additional codes from the detailed ethnicity ... value sets drawn from the [Race & Ethnicity - CDC (CDCREC)](https://phinvads.cdc.gov/vads/ViewCodeSystem.action?id=2.16.840.1.113883.6.238) code system [when using the [US Core Race Extension] (https://hl7.org/fhir/us/core/STU8/StructureDefinition-us-core-race.html)]
The Complex [Extension] for Race ... allow[s] for one or more codes of which **SHALL** include a text description [of category codes when using the [US Core Race Extension] (https://hl7.org/fhir/us/core/STU8/StructureDefinition-us-core-race.html)]
The Complex [Extension] for ... Ethnicity allow[s] for one or more codes of which **MAY** include additional codes from the detailed ... race value sets drawn from the [Race & Ethnicity - CDC (CDCREC)](https://phinvads.cdc.gov/vads/ViewCodeSystem.action?id=2.16.840.1.113883.6.238) code system [when using the [US Core Race Extension] (https://hl7.org/fhir/us/core/STU8/StructureDefinition-us-core-race.html)]
The Complex [Extension] for ... Ethnicity allow[s] for one or more codes of which **SHALL** include a text description [of category codes when using the [US Core Ethnicity Extension] (https://hl7.org/fhir/us/core/STU8/StructureDefinition-us-core-ethnicity.html)]
Systems **SHALL** represent *Previous name* by setting `Patient.name.use` to "old" or providing an end date in `Patient.name.period` or doing both.
Systems **SHALL** represent *Previous Address* by setting `Patient.address.use` to "old" or providing an end date in `Patient.address.period` or doing both.
Non-certifying systems[, systems that are not participating in the ONC Health IT certification program,] **SHOULD** follow the [Project US@ Technical Specification for Patient Addresses Final Version 1.0](https://asapnet.org/wp-content/uploads/2022/03/Project_US_FINAL_Technical_Specification_Version_1.0.pdf) as the standard style guide for Patient.address.line and Patient.address.city for new and updated records.
[For systems participating in the ONC Health IT certification program,] this requirement [to follow the [Project US@ Technical Specification for Patient Addresses Final Version 1.0](https://asapnet.org/wp-content/uploads/2022/03/Project_US_FINAL_Technical_Specification_Version_1.0.pdf) for Patient.address.line and Patient.address.city]. Both certifying and non-certifying systems **MAY** choose not to use Project US@ for historical records or documents that are not exposed through FHIR-based APIs.
**SHOULD NOT** be used as a patient identifier in Patient.identifier.value
Servers that support only the US Core Practitioner Profile and do not support the [US Core PractitionerRole Profile](https://hl7.org/fhir/us/core/STU8/StructureDefinition-us-core-practitionerrole.html) **SHALL** provide implementation-specific guidance on how to access a provider’s location and contact information using only the Practitioner resource.
Although Practitioner.address is marked as Must Support, the Server system **MAY** choose not to support it if they support the US Core PractitionerRole Profile
[When using the US Core Practitioner Profile] Practitioner.address … **SHALL**[be supported] if … [the Server does] not support the US Core PractitionerRole Profile
Only professional/work contact information about the practitioner **SHOULD** be available to the patient
[If using LOINC codes in procedure.code] only LOINC concepts that reflect actual procedures **SHOULD** be used
[For organizations participating in the ONC Health IT Certification program,] when using Procedure.reasonReference Servers **SHALL** support at least one target resource in Procedure.reasonReference
[For organizations participating in the ONC Health IT Certification program,] when using Procedure.reasonReference …The referenced resources **SHOULD** be a US Core Profile as documented in [Referencing US Core Profiles](https://hl7.org/fhir/us/core/STU8/general-guidance.html#referencing-us-core-profiles)
The US Core Provenance resource **SHALL** be supported for these US Core resource types: AllergyIntolerance, CarePlan, CareTeam, Condition, Coverage, Device, DiagnosticReport, DocumentReference, Encounter, Goal, Immunization, MedicationDispense, MedicationRequest, Observation, Patient, Procedure, QuestionnaireResponse, RelatedPerson, ServiceRequest
If a system receives a provider in Provenance.agent.who as free text, they must capture [the organization] who sent them the information [and upon] request ... **SHALL** provide this organization as the source
If a system receives a provider in Provenance.agent.who as free text, … [upon request they] **MAY** include the free text provider.
The Must Support `ServiceRequest.category` is bound, at a minimum, to the [US Core ServiceRequest Category Codes](https://hl7.org/fhir/us/core/STU8/ValueSet-us-core-servicerequest-category.html), and other category codes **MAY** be used.
The ServiceRequest.code value ... **SHOULD** be constrained to a subset for a particular use case or domain
Since the binding [for Specimen.type and additional USCDI elements] is [extensible](http://hl7.org/fhir/R4/terminologies.html#extensible) when a code is unavailable, servers **MAY** use text.
Although both Specimen.identifier and Specimen.accessionIdentifier are marked as Must Support, the Server system is not required to support both, but **SHALL** support at least one of these elements.
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 2.0.0](http://hl7.org/fhir/smart-app-launch/history.html) and later 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.
If any sub-element is marked as *Additional USCDI* [for a complex element], it must also meet the *Additional USCDI* requirements and satisfy the *Additional USCDI* requirements for the parent element.
When a Reference type element is labeled as Must Support and has a single target profile referenced, the target profile **SHALL** be supported.
When a Reference type element is labeled as Must Support, has multiple target profiles referenced, and specific targets are labeled as Must Support, the Must Support target profile(s) **SHALL** be supported.
[If a] slicer's Must Support property only defines the element level Must Support...[, i.e.,] no Must Support... property is defined for the slice, then support for that slice's definition is optional.
Servers **SHALL** support, at minimum, these … "Common Clinical Notes": [Surgical Operation Note (11504-8)](https://loinc.org/11504-8.html)
Servers **SHALL** support, at minimum, these … "Common Clinical Notes": [Emergency Department Note (34111-5)](https://loinc.org/34111-5.html)
Servers that support the USCDI Health Status/Assessments Data Class ... **SHOULD** support the SDC Base Questionnaire and the US Core QuestionnaireResponse Profile."
For the US Core Simple Observation Profile, Servers **SHALL** support all the category codes [listed](https://hl7.org/fhir/us/core/STU8/screening-and-assessments.html#category-codes).
For the … US Core Observation Screening Assessment Profiles, Servers **SHALL** support all the category codes [listed](https://hl7.org/fhir/us/core/STU8/screening-and-assessments.html#category-codes).
For the US Core Condition Problems and Health Concerns Profile, Servers **SHALL** support the code ,"sdoh"
For the US Core Condition Problems and Health Concerns Profile, Servers **SHOULD** support the other category codes [listed](https://hl7.org/fhir/us/core/STU8/screening-and-assessments.html#category-codes).
For the US Core ServiceRequest Profile, Servers **SHOULD** support all the [[listed](https://hl7.org/fhir/us/core/STU8/screening-and-assessments.html#category-codes)] category codes.
The `DiagnosticReport.basedOn` element connects the DiagnosticReport to the originating order in the EHR. Systems that initiate the order **SHOULD** use this element when reporting the results.
The `DiagnosticReport.media.link` element **SHOULD** be used to support links to various patient-friendly content, such as jpg images of x-rays (see the DiagnosticReport Chest X-ray Report Example).
The `DiagnosticReport.imagingStudy` element **SHOULD** be used to support exchange with systems that can view DICOM (Digital Imaging and Communications in Medicine) studies, series, and SOP (Service-Object Pair) instances referenced in the -[ImagingStudy](http://hl7.org/fhir/R4/imagingstudy.html) resource.
If the referenced document or file [referenced by `DocumentReference.content.attachment.url`] is hosted on a Server outside the FHIR Server, it **SHOULD**be securely accessible using the same authorization credentials that were used to access the FHIR Server. This reduces complexity for the Client and improves the user experience.
Although the [US Core Interpreter Needed] extension is marked as an Additional USCDI Requirements on both US Core Patient and US Core Encounter Profiles, the certifying Server system is not required to support the extension on both profiles, but **SHALL** support the extension on at least one.
There is no guarantee that vaccine lot numbers are globally unique, and they are not recommended for matching or de-duplication across systems unless used with other data elements such as a vaccine product code, manufacturer code, or date of administration. Implementers **MAY** communicate the `Immunization.manufacturer` to ensure global uniqueness to lot numbers.
Servers **SHALL** return all active medications following the [Get All Active Medications](https://hl7.org/fhir/us/core/STU8/medication-list.html#get-all-active-medications) guidance.
[For US Core Laboratory Result Observation Profile, even] when the specimen type is already implied by the LOINC code used in `Observation.code` (e.g., a LOINC code for Blood Glucose), the `Observation.specimen` element **SHOULD** also be populated with the referenced Specimen resource to explicitly communicate the collected specimen type.
[For US Core Laboratory Result Observation Profile, the] type of specimen [in `Observation.specimen`] **SHOULD** not conflict with the LOINC code [in `Observation.code`].
[For the US Core Observation Screening Assessment Profile, the] category type "survey" is required.
[For the US Core Observation Screening Assessment Profile,] when using Observation.derivedFrom to reference an Observation, the referenced Observation **SHOULD** be a US Core Observation.
Servers **SHOULD** use 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)] or the [US Core Encounter Profile](https://hl7.org/fhir/us/core/STU8/StructureDefinition-us-core-encounter.html) to communicate whether a patient needs an interpreter.
Systems **SHOULD** designate the patient's preferred language in the Patient.communication.preferred element.
For the USCDI *Laboratory Order*, *Imaging Order*, *Clinical Test Order*, and *Procedure Order* Data Elements, implementers **SHOULD** use the corresponding category codes listed in the table
Although '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. Servers are not required to support both, but **SHALL** support at least one.
[If a] slicer's Additional USCDI property only defines the element level Additional USCDI...[, i.e.,] no Additional USCDI... property is defined for the slice, then support for that slice's definition is optional.
When a Reference element is labeled as *Must Support* has multiple target profiles referenced, but none are labeled as *Must Support* ... - US Core Responders **SHALL** be capable of providing [such an element] with a valid reference to *at least one* target profile.
The author is communicated by the elements and the author's role by the referenced target resource (for example, Patient, Practitioner/PractitionerRole, RelatedPerson, Device). Details about the author's role are contained in the target resource's contents. Many of these elements are labeled Must Support or Additional USCDI Requirements. However,[even if they are not labeled Must Support or Additional USCDI Requirements] all of these elements and target resources **SHOULD** be supported in the profiles if the system captures the data.
… this profile uses USPS Two Letter Alphabetic Codes for US states. When encoding addresses outside the US, systems **SHOULD** use the [ISO 3166 subdivision codes](https://www.iso.org/iso-3166-country-codes.html).
Due to implementer feedback, some US Core Profiles reference the base FHIR PractitionerRole resource instead of the US Core PractitionerRole Profile. However, the US Core PractitionerRole Profile **SHOULD** be used as the default profile if referenced by another US Core profile.
When selecting role codes...implementers **SHOULD** choose the code that reflects the specific duties performed within that role rather than the specialty unless the individual's professional specialization characterizes the role.
A procedure including an implantable device **SHOULD** use `Procedure.focalDevice` referencing the US Core Device Profile
Unless exchanging legacy or text-only data, medical specialty codes **SHOULD** be taken from NUCC or SNOMED CT.
Unless exchanging legacy or text-only data, procedure codes **SHOULD** be taken from SNOMED-CT, CPT, HCPCS II, ICD-10-PCS, CDT, or LOINC*.
US Core guidance provides more flexibility for situations where implementers cannot fully comply with the FHIR guidance. This flexibility is sometimes necessary and expected for legacy and text-only data. However, for newly recorded, non-legacy data, a system **SHOULD** adhere to the extensible binding rules.
For data not captured by the system transmitting the information, the coded data **SHOULD** be automatically converted to fine-grained codes from the specified ValueSet.
For data not captured by the system transmitting the information, ....the system **MAY** provide the existing code or the free text, and a high-level abstract code, such as the SNOMED CT code "71388002"(Procedure), to remain conformant with the extensible binding.
To represent the patient and provider attestation metadata, the optional DocumentReference Attestor R5 Extension defined in the US Core DocumentReference Profile **SHOULD** be used
Unless exchanging legacy or text-only data, condition codes **SHOULD** be taken from SNOMED CT and ICD-10-CM, USCDI's applicable vocabulary standards for the Problem Data Element.
The Service Delivery Location Role Type value set is inherited from the base resource, and, although its binding strength is [extensible](http://hl7.org/fhir/R4/terminologies.html#extensible) in the base resource, US Core implementers **MAY** treat it as [preferred](http://hl7.org/fhir/R4/terminologies.html#preferred).
When exchanging Social Determinants of Health (SDOH) data, implementers **SHOULD** use the [Social Determinants of Health Goals](https://vsac.nlm.nih.gov/valueset/2.16.840.1.113762.1.4.1247.71/expansion) set which is curated by the Gravity Project to represent goals for all SDOH Domains.
Implementers **SHOULD** conform to the binding strengths listed for each USCDI Order context...Laboratory Order|[LOINC Common Laboratory Orders Value Set]|extensible, Imaging Order|[LOINC Radiology Codes]|preferred, Clinical Test Order|[LOINC Clinical Test Codes]|preferred
the US Core ServiceRequest Profile **MAY** be used to represent a derived "actionable" order based on a portable Medical Order(PMO).
[When] used to represent a derived "actionable" order based on a PMO...The `ServiceRequest.category` **SHOULD** be bound to [Portable Medical Order Categories](https://vsac.nlm.nih.gov/valueset/2.16.840.1.113762.1.4.1267.34/Expansion)
[When] used to represent a derived "actionable" order based on a PMO...ServiceRequest.code` **SHOULD** be aligned with the appropriate Category
The `ServiceReqest.reasonReference` **SHOULD** be used to reference the US Core ADI DocumentReference Profile that indexes the PMO.
The following scopes that correspond directly to FHIR resource types **SHALL** be supported ... [For] RelatedPerson [the] <patient|user|system>/FamilyMemberHistory.rs [see [SMART Clinical Scope Syntax](https://hl7.org/fhir/smart-app-launch/STU2/scopes-and-launch-context.html#clinical-scope-syntax) for details on clinical data scopes]
When implementing US Core, implementers **SHOULD** use the published versions or later versions of the value sets and code systems.
In some cases, [when implementing US Core] implementers **MAY** need to use terminology from earlier versions to preserve legacy data.
Systems **SHALL** represent *Suffix* using the `Patient.name.suffix` element.
Profile Only Support: Systems **MAY** support *only* the US Core Profiles to represent clinical information.
Profile Support + Interaction Support: Systems **MAY** support *both* the US Core Profile content structure *and* the RESTful interactions defined for a resource.