These requirements apply to the actor: US Core Requestor (Server) Key Conformance Requirement CONF-0001 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 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 MAY (conditional) Servers may deploy and support one or more US Core Profiles to represent clinical information CONF-0004 MAY (conditional) Server may deploy and support ... the following US Core interaction: “Quick Start” defined for each Profile CONF-0005 MAY (conditional) Server may deploy and support ... the following US Core interaction: Clinical Notes CONF-0006 MAY (conditional) Server may deploy and support ... the following US Core interaction: Medication List CONF-0007 MAY (conditional) Server may deploy and support ... the following US Core interaction: Basic Provenance CONF-0008 MAY (conditional) Server may deploy and support ... the following US Core interaction: Screening and Assessments CONF-0009 MAY (conditional) 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 MAY (conditional) 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 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 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 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 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 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 SHALL Required binding to a ValueSet definition means that one of the codes from the specified ValueSet SHALL be used. CONF-0019 SHALL (conditional) 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 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 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 SHALL (conditional) [Extensible binding] (http://hl7.org/fhir/R4/terminologies.html#extensible) means that one of the codes from the specified ValueSet SHALL be used if an applicable concept is present. CONF-0024 MAY (conditional) [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 provided. CONF-0026 MAY (conditional) For CodeableConcept [with an [extensible binding] (http://hl7.org/fhir/R4/terminologies.html#extensible) … If only text is available and it has no conceptual overlap with the bound coded values, then just text may be used. CONF-0027 SHALL (conditional) 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 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 MAY [The additional codings] may be equivalent to or narrower in meaning than the standard concept code. CONF-0033 MAY Not all modifier elements are Mandatory or Must Support, and there is no requirement for supporting them CONF-0034 MAY Servers MAY communicate a system-wide profile in their CapabilityStatement to identify which additional elements, including modifier elements, they support CONF-0039 SHALL (conditional) 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 SHALL (conditional) 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 SHALL (conditional) 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 SHALL (conditional) [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 SHALL (conditional) [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 SHALL (conditional) [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 SHALL (conditional) [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 SHALL (conditional) [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 SHALL (conditional) [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 SHALL (conditional) [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 SHALL (conditional) [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 SHOULD (conditional) [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 SHALL The FHIR RESTful Search API requires that Servers that support search SHALL support the HTTP POST-based search. CONF-0052 SHALL For all the supported search interactions in this guide, Servers SHALL also support the GET-based search. CONF-0055 SHALL When searching using the token type searchparameter (how to search by token) The Server SHALL support both [system and code values] CONF-0058 SHALL When searching using the reference type searchparameter (how to search by reference) The Server SHALL support both [id and Type values] CONF-0061 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 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 SHOULD Servers are strongly encouraged to support a query for resources without requiring a status parameter. CONF-0064 SHALL (conditional) If business requirements prohibit [querying a resource without a status parameter], they SHALL follow the guidelines here. CONF-0065 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 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 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 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 SHALL-NOT [For systems that require a status parameter to be provided, they] SHALL NOT restrict search results ( i.e., apply ‘hidden’ filters) when a Client includes status parameters in the query. CONF-0070 SHOULD (conditional) [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 SHOULD (conditional) [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 SHOULD (conditional) [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 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-0074 SHALL When an element is Mandatory, the data is expected always to be present. CONF-0075 SHALL (conditional) 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 SHALL-NOT (conditional) For querying and reading US Core Profiles, Must Support on any profile data element SHALL be interpreted as follows…: When information on a particular data element is not present, and the reason for absence is unknown, US Core Responders SHALL NOT include the data elements in the resource instance returned as part of the query results. CONF-0080 SHOULD (conditional) 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 SHOULD (conditional) [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 SHALL (conditional) 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 SHALL (conditional) Implementors [US Core Responders] [not] seeking ONC certification [in the ONC IT Health Certification program] SHALL interpret Additional USCDI Requirements as … optional. CONF-0087 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 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 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 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 SHALL If any sub-element is marked as Must Support [for a complex element], it must also meet the Must Support requirements and satisfy the Must Support requirements for the parent element. CONF-0095 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 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 represented in the structure, Servers SHALL support the sub-element(s) marked as Must Support. CONF-0097 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 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 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-0103 MAY The U.S. Core Data for Interoperability (USCDI) may require additional elements, [which is a requirement for certification in the ONC IT Health Certification program, but not a requirement of US Core conformance for US Core Responders] CONF-0105 SHALL In certain profiles, only specific resource references 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 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 SHALL In specific profiles, only a single resource reference is present on an element labeled Must Support. ... US Core Responders SHALL be capable of providing [such an element] with a valid reference to [the Must Support Profile.] CONF-0111 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 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 SHALL (conditional) There are several instances in this Guide where there is a choice of supporting one or another profile element to meet the Must Support or Additional USCDI requirement. In such cases, the Server or Certifying System SHALL support at least one element. CONF-0117 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 SHOULD (conditional) 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 SHALL (conditional) 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 SHALL Implementations [US Core Responders] supporting Backend Services ... SHALL include support for the Client-confidential-asymmetric capability. CONF-0121 SHALL Implementations [US Core Responders] supporting Backend Services ... SHALL include support for the ... system/scopes. CONF-0123 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-0124 SHALL (conditional) Implementations meeting US EHR certification [of the ONC IT Health Certification program] requirements must support all US Core’s required scopes. CONF-0125 MAY Other systems only need to support scopes for the US Core APIs they support [instead of all US Core's required scopes] CONF-0126 MAY Servers MAY support other scopes in addition to those listed below and in the Quick Start sections. CONF-0128 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 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 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 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 SHALL (conditional) 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 SHALL (conditional) 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 SHALL (conditional) 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 SHALL (conditional) 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 SHALL (conditional) 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 SHALL (conditional) 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 SHALL (conditional) 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 SHALL (conditional) 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 SHALL (conditional) 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 SHALL (conditional) 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 SHALL (conditional) 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 SHALL (conditional) 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 SHALL (conditional) 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 SHALL (conditional) 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 SHALL (conditional) 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 SHALL (conditional) 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 SHALL (conditional) 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 SHALL (conditional) 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 SHALL (conditional) 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 SHALL (conditional) 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 SHALL (conditional) 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 SHALL (conditional) 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 SHALL (conditional) 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 SHALL (conditional) 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 should not consider … [the required scopes] an exhaustive list). CONF-0170 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 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 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 SHOULD Therefore, a reference to a US Core resource SHOULD include a logical id (Reference.reference), not an identifier (Reference.identifier). CONF-0175 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 SHOULD-NOT When responding to a query, Servers SHOULD not use inline contained resources to represent the returned data. CONF-0177 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 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 SHOULD (conditional) [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 SHOULD (conditional) [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 MAY (conditional) [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 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 SHOULD (conditional) [If a] US Core Profiles binds the Quantity.code element in the Quantity datatype to the UCUM code system, [then] systems should also use UCUM for the optional valueRange and valueRatio datatypes (which are complex datatypes with Quantity elements) CONF-0184 SHOULD (conditional) [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 SHOULD (conditional) [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 SHOULD-NOT (conditional) [If a] US Core Profiles binds the Quantity.code element in the Quantity datatype to the UCUM code system, [when] no units [are available systems SHOULD NOT supply the unit field] CONF-0187 SHOULD-NOT A FHIR Server SHOULD not delete records. CONF-0188 SHOULD A FHIR Server SHOULD update the appropriate resource status to entered-in-error or inactive [when requested to delete records] CONF-0189 SHOULD (conditional) If a system supports the deletion of records, they SHOULD refer to the Deletion Safety Checks in the FHIR specification. CONF-0190 SHOULD (conditional) A FHIR Server SHOULD allow these resources [those entered in error] to be searchable by Client applications. CONF-0191 SHOULD (conditional) 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 MAY (conditional) 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 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 SHOULD (conditional) [When Clients request a resource in a specific language] Servers SHOULD make reasonable efforts to translate what can be safely translated. CONF-0196 SHOULD (conditional) [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 SHOULD (conditional) [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 SHOULD (conditional) [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 SHOULD (conditional) [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 SHOULD Servers SHOULD support the _lastUpdated search parameter for US Core Profiles CONF-0201 SHOULD Servers ... SHOULD populate Resource.meta.lastUpdated for US Core Profiles as accurately as possible. CONF-0202 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 MAY US Core Servers [MAY support compartment based searchs, but] are not required to support patient compartment based searches. CONF-0204 MAY US Core Servers [MAY resolve absolute URLs, but] are not required to resolve absolute URLs external to their environment. CONF-0205 MAY Servers can [MAY] choose to return the results in a series of pages to manage the number of search results returned. CONF-0206 SHALL Servers SHALL support, at minimum, these … "Common Clinical Notes": Consultation Note (11488-4) CONF-0207 SHALL Servers SHALL support, at minimum, these … "Common Clinical Notes": Discharge Summary (18842-5) CONF-0208 SHALL Servers SHALL support, at minimum, these … "Common Clinical Notes": History & Physical Note (34117-2) CONF-0209 SHALL Servers SHALL support, at minimum, these … "Common Clinical Notes": Procedures Note (28570-0) CONF-0210 SHALL Servers SHALL support, at minimum, these … "Common Clinical Notes": Progress Note (11506-3) CONF-0211 SHALL Servers SHALL support, at minimum, these … "Common Clinical Notes": Imaging Narrative (18748-4) CONF-0212 SHALL Servers SHALL support, at minimum, these … "Common Clinical Notes": Laboratory Report Narrative (11502-2) CONF-0213 SHALL Servers SHALL support, at minimum, these … "Common Clinical Notes": Pathology Report Narrative (11526-1) CONF-0214 SHALL Servers SHALL support, at minimum, these … DiagnosticReport categories: Cardiology (LP29708-2) CONF-0215 SHALL Servers SHALL support, at minimum, these … DiagnosticReport categories: Pathology (LP7839-6) CONF-0216 SHALL Servers SHALL support, at minimum, these … DiagnosticReport categories: Radiology (LP29684-5) CONF-0217 SHOULD systems are encouraged to support other common notes types, such as: Referral Note (57133-1) CONF-0219 SHOULD systems are encouraged to support other common notes types, such as: Nurse Note (34746-8) CONF-0220 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 SHALL when DiagnosticReport.presentedForm.url references a Scan (PDF), that Attachment SHALL also be accessible through DocumentReference.content.attachment.url CONF-0222 MAY Systems [Servers] may extend their capabilities [around types of clinical notes] to the complete US Core DocumentReference Type Value Set. CONF-0223 SHALL This guide requires [Server] systems to implement the US Core DocumentReference Profile CONF-0224 SHALL This guide requires [Server] systems to implement the US Core DiagnosticReport Profile for Report and Note exchange CONF-0225 MAY Systems [Servers] may support other [DiagnosticReport] categories as well. CONF-0227 SHOULD The following SHOULD be exposed via DiagnosticReport: Imaging Narrative CONF-0228 SHOULD The following SHOULD be exposed via DiagnosticReport: Laboratory Report Narrative CONF-0229 SHOULD The following SHOULD be exposed via DiagnosticReport: Pathology Report Narrative CONF-0230 SHOULD The following SHOULD be exposed via DiagnosticReport: Procedure Note CONF-0231 SHALL Servers that support DiagnosticReport will include the clinical note narrative content in DiagnosticReport.presentedForm CONF-0233 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 SHOULD (conditional) [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] CONF-0235 SHOULD (conditional) [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] CONF-0236 SHOULD (conditional) [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] CONF-0237 SHOULD (conditional) [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] CONF-0238 SHOULD (conditional) [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] CONF-0239 SHOULD (conditional) [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] CONF-0240 SHOULD (conditional) [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] CONF-0241 SHOULD (conditional) [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] CONF-0242 SHOULD (conditional) [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] CONF-0243 SHOULD (conditional) [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] CONF-0244 SHOULD (conditional) [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] CONF-0245 SHOULD (conditional) [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] CONF-0246 MAY [The MedicationAdministration and MedicationStatement] medication resources are not profiled by US Core, and systems that support US Core are permitted to use them CONF-0247 SHALL (conditional) 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 MAY USCDI recommends the National Drug Codes (NDC) as an optional medication terminology. They can be supplied as an additional coding element [when representing a medication] CONF-0249 MAY (conditional) 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 SHALL (conditional) if an external reference to Medication is used, the Server SHALL support the _include parameter for searching this element CONF-0252 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 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 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 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-0257 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] use the MedicationRequest.reported[x] element to indicate ... the source of the report. CONF-0258 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 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 SHOULD (conditional) 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 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 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-0266 SHALL The HIE must maintain the original data source. CONF-0267 MAY An agent.type=”assembler”, agent.type=”transmitter”, or other agents from Provenance Agent Type value set MAY also be included. CONF-0268 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 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 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 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 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 must be surfaced as an Observation. CONF-0273 SHALL 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 must be surfaced as an Observation. CONF-0274 SHALL For FHIR implementers, it is important to note that QuestionnaireResponse [which represent the source-of-truth of a completed form, shall] references a specific version of a form, whether it was represented as a FHIR Questionnaire or not. This reference provides the context of exactly what options were available, what logic was used to calculate answers, and what questions were asked. CONF-0280 SHOULD Implementers SHOULD treat these [USCDI Health Status Assessments Data Element] value sets as having an extensible binding. CONF-0281 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-0282 MAY A Server may support Version DSTU2 and Argonaut Data Query CONF-0283 MAY A Server may support … FHIR R4 and US Core ver 3.1.1+ CONF-0284 MAY A Server may support [both] [(]Version DSTU2 and Argonaut Data Query[) and (] FHIR R4 and US Core ver 3.1.1+[)] CONF-0285 MAY A Server may make explicit which version of Argo/US Core is on their FHIR endpoint (e.g., “DSTU2” or “R4” path component or separate files based on version). CONF-0287 SHOULD Servers SHOULD maintain a stable common identifier for a resource across [FHIR] versions. CONF-0288 SHOULD In an upgraded R4 endpoint, any data in FHIR DSTU2 SHOULD be in FHIR R4. CONF-0289 SHOULD (conditional) The FHIR RESTful resource types supported in a DSTU2 implementation SHOULD be supported in a R4 implementation CONF-0290 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 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 SHOULD (conditional) Servers SHOULD make available the same information in DSTU2 and R4 where the more recent standard allows. CONF-0296 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 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 SHOULD Data SHOULD be maintained between [FHIR] versions (i.e., not be degraded). CONF-0300 SHALL Separate authorization is required [between different versions of FHIR] CONF-0302 SHALL [The clinical status of the allergy] SHALL be present if verification status is not “entered-in-error” CONF-0303 SHALL-NOT [The clinical status of the allergy] SHALL NOT be present if verification Status is “entered-in-error” CONF-0305 MAY (conditional) Profile Specific Implementation Guidance: No Known Allergies may be represented using the US Core-AllergyIntolerance profile CONF-0306 SHALL (conditional) [When used No Known Allergies is documented the system Shall use an] appropriate negation code in AllergyIntolerence.code CONF-0307 SHALL (conditional) [When used No Known Allergies is documented the system Shall use an] verification status in AllergyIntolerance.verificationStatus CONF-0308 SHOULD (conditional) 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, then element omitted) CONF-0309 SHOULD (conditional) 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 SHOULD Considerations for systems aligning with HL7 Consolidated (C-CDA) Care Plan requirements: US Core Goal SHOULD be present in CarePlan.goal CONF-0311 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 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 SHALL (conditional) 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 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 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 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-0320 SHOULD (conditional) For Problems and Health Concerns [records, systems SHOULD] use the US Core Condition Problems and Health Concerns Profile. CONF-0321 SHALL (conditional) [Newly created Encounter Diagnosis records SHALL have a] Condition.code … [from the] “current” … [value set] binding. CONF-0322 MAY (conditional) [Historical Encounter Diagnosis records MAY have a] Condition.code … [from the] base “preferred” … [value set] binding. CONF-0323 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 SHOULD [A US Core Condition Encounter Diagnosis] encounter SHOULD always be referenced in Condition.encounter. CONF-0330 SHOULD (conditional) For Encounter Diagnosis [records, systems SHOULD] use the US Core Condition Encounter Diagnosis Profile. CONF-0331 SHOULD (conditional) If the category is "problem-list-item", Condition.clinicalStatus SHOULD be present. CONF-0332 SHOULD Updates to .meta.lastUpdated SHOULD reflect: New problems and health concerns CONF-0333 SHOULD Updates to .meta.lastUpdated SHOULD reflect: Changes in the clinical status or verifications status of problems or health concerns [This will change to a SHALL requirement in US Core v8.0.0] CONF-0334 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-0335 SHOULD Implementers should refer to the PHDSC Payer Type Committee User’s Guide for the Source of Payment Typology when selecting codes. CONF-0336 SHOULD To differentiate Medicare Parts A, B, C, and D systems can use the following codes [when sending Coverage.type]: [For] Part A and B [use] 121 (Medicare Fee For Service) CONF-0337 SHOULD To differentiate Medicare Parts A, B, C, and D systems can use the following codes: [For] Part C (Medicare Advantage Plan) [use] 111 (Medicare HMO), 112 (Medicare PPO), 113 (Medicare POS) CONF-0338 SHOULD To differentiate Medicare Parts A, B, C, and D systems can use the following codes: [For] Part D [use] 122 (Medicare Drug Benefit) CONF-0339 SHOULD (conditional) 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. CONF-0340 SHOULD For non-implantable devices (for example, software or crutches), use the base FHIR Device resource or other use case-specific Device profiles. CONF-0341 SHOULD Implementers are encouraged to use the FDA Global UDI Database (GUDID) and associated APIs to parse and validate the [unique device ID] UDI CONF-0342 SHALL Implantable medical devices with UDI information SHALL represent the UDI code in Device.udiCarrier.carrierHRF CONF-0343 SHALL UDI-PI elements present [in Device.udiCarrier.carrierHRF] SHALL be represented in the corresponding US Core Implantable Device Profile elements CONF-0344 SHOULD (conditional) 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 SHOULD (conditional) 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-0346 SHOULD Servers SHOULD support query by Device.type to allow Clients to request the patient’s devices by a specific type. CONF-0347 MAY Records of implanted devices MAY be queried against UDI data, including: UDI HRF string (udi-carrier) CONF-0348 MAY Records of implanted devices MAY be queried against UDI data, including:UDI Device Identifier (udi-di) CONF-0349 MAY Records of implanted devices MAY be queried against UDI data, including: Manufacturer (manufacturer) CONF-0350 MAY Records of implanted devices MAY be queried against UDI data, including: Model number (model) CONF-0351 MAY Implementers MAY also adopt custom SearchParameters for searching by lot numbers CONF-0352 MAY Implementers MAY also adopt custom SearchParameters for searching by serial number CONF-0353 MAY Implementers MAY also adopt custom SearchParameters for searching by expiration date CONF-0354 MAY Implementers MAY also adopt custom SearchParameters for searching by manufacture date CONF-0355 MAY Implementers MAY also adopt custom SearchParameters for searching by distinct identifier CONF-0356 SHALL (conditional) 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 SHALL (conditional) When the report was released … SHALL be present if status [of the diagnostic report] is ‘partial’, ‘preliminary’, ‘final’, ‘amended’, ‘corrected’, or ‘appended’. CONF-0358 SHOULD Updates to .meta.lastUpdated SHOULD reflect New laboratory reports. CONF-0359 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-0360 SHALL The DiagnosticReport.category binding Must Support, at a minimum, the US Core DiagnosticReport Category Codes of Cardiology, Radiology, and Pathology CONF-0361 MAY Other [diagnostic report] categories may be supported [when using US Core DiagnosticReport Profile for Report and Note Exchange] CONF-0362 MAY [L]inkages between specific LOINC codes and the LP-type codes may be used as guidance [for a Server's categorization of diagnostic reports] CONF-0364 SHOULD (conditional) For Diagnostic Imaging Reports systems SHOULD support using the subset of LOINC codes defined in CONF-DIR-19 in HL7 Implementation Guide for CDA Release 2: Imaging Integration, Levels 1, 2, and 3, Basic Imaging Reports in CDA and DICOM Diagnostic Imaging Reports (DIR) - Universal Realm, Release 1.0. CONF-0365 SHALL The DocumentReference.type binding Must Support, at a minimum, the 10 Common Clinical Notes CONF-0366 MAY The DocumentReference.type binding may extend to the whole US Core DocumentReference Type Value Set CONF-0367 MAY [DocumentReference.type may also use] other category schemes such as the LOINC-based Document Class Value Set and IHE XDSclassCode CONF-0368 SHALL (conditional) 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 SHALL If there are multiple DocumentReference.content element repetitions, these SHALL all represent the same document in different formats or attachment metadata CONF-0373 SHALL-NOT The [documentReference.content] element SHALL NOT contain different versions of the same content. CONF-0374 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 SHALL (conditional) 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 SHOULD (conditional) If Encounter.reasonReference references an Observation, it SHOULD conform to a US Core Observation [profile applicable to the observation being made] CONF-0379 SHALL (conditional) 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 SHALL (conditional) If the event facility/location differs from the Encounter.location, systems SHOULD reference it directly CONF-0383 SHALL (conditional) 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 MAY (conditional) 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 SHOULD Updates to .meta.lastUpdated SHOULD reflect New encounters/visits CONF-0386 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 SHALL (conditional) 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 SHALL [Servers shall] use the status code: not-done to represent that an immunization was not given. CONF-0391 SHALL (conditional) [For organization participating in the ONC Health IT Certification program] CVX vaccine codes are required CONF-0392 SHOULD NDC vaccine codes SHOULD be supported as an additional code [of CVX Vaccine Codes] CONF-0393 SHOULD The preferred code system identifier … is http://hl7.org/fhir/sid/cvx for CVX [vaccine codes] CONF-0394 SHOULD The preferred code system identifier … is http://hl7.org/fhir/sid/ndc for NDC vaccine codes] CONF-0395 SHOULD Systems SHOULD follow the Project US@ Technical Specification for Patient Addresses Final Version 1.0 as the standard style guide for Location.address.line CONF-0396 SHOULD Systems SHOULD follow the Project US@ Technical Specification for Patient Addresses Final Version 1.0 as the standard style guide for Location.address.city CONF-0397 SHALL (conditional) When using a code [to represent a medication for a medication dispense], RXNorm concepts are used. CONF-0398 MAY (conditional) When using a code [to represent a medication for a medication dispense], National Drug Codes (NDC) can be supplied as an additional coding element. CONF-0399 MAY When referencing a Medication resource in .medicationReference, the resource may be contained CONF-0400 MAY When referencing a Medication resource in .medicationReference, the resource may be an external resource CONF-0401 SHALL (conditional) 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 SHALL (conditional) If an external reference to a Medication resource is used, the Server SHALL support the _include parameter for searching this element. CONF-0405 SHALL (conditional) [For organization participating in the ONC Health IT Certification program Servers SHALL support the additional USCDI requirement:], The reason or indication for the prescription CONF-0406 SHALL (conditional) [For organization participating in the ONC Health IT Certification program Servers SHALL support the additional USCDI requirement:] reported adherence to prescribed medication instructions CONF-0407 SHOULD When recording “self-prescribed” medication, requester SHOULD be used to indicate the Patient or RelatedPerson as the prescriber CONF-0408 SHALL (conditional) 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-0411 SHALL (conditional) Although both MedicationRequest.reasonCode and MedicationRequest.reasonReference are marked as Additional USCDI Requirements [which are required for organizations participating in the ONC Health IT Certification program]. The certifying Server system is not required to support both, but SHALL support at least one of these elements CONF-0414 SHALL (conditional) [For organizations participating in the ONC Health IT Certification program and supporting MedicationRequest.reasonReference,] Servers SHALL support at least one target resource in MedicationRequest.reasonReference CONF-0416 SHOULD (conditional) [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 SHOULD Source EHR identifiers SHOULD be included to support deduplication across MedicationRequest resources. CONF-0419 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 SHOULD [For an Observation a] code system value SHOULD be supplied for each additional code CONF-0421 SHALL (conditional) 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 SHOULD (conditional) The context or precondition of a patient’s [care experience] preference SHOULD be supplied in the Observation.valueString or in an extension CONF-0423 SHOULD (conditional) Servers SHOULD use the base FHIR [Observation Category Codes] (http://hl7.org/fhir/R4/valueset-observation-category.html) [in Observation.category] CONF-0424 SHOULD (conditional) Systems SHOULD support Observation.effectivePeriod to accurately represent measurements over time CONF-0425 SHALL (conditional) An Observation.component without a value, SHALL include a reason why the data is absent CONF-0426 MAY (conditional) Systems that never provide a component observation without a component value … [MAY choose not] to support Observation.component.dataAbsentReason CONF-0427 SHALL (conditional) An Observation without a value, SHALL include a reason why the data is absent CONF-0428 MAY (conditional) [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 MAY (conditional) Systems that never provide an observation without a value ... [MAY choose not] to support Observation.dataAbsentReason CONF-0430 SHOULD (conditional) [When sending US Core Laboratory Results Observation Profile] updates to .meta.lastUpdated SHOULD reflect new laboratory observations CONF-0431 SHOULD (conditional) [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 SHALL (conditional) [When sending US Core Observation Occupation Profile] for … [a] current job, [Servers SHALL] omit observation.effectivePeriod.end to indicate it is ongoing. CONF-0433 SHALL When the industry is known, but the occupation is not, [Servers SHALL] use the value “unknown” from the DataAbsentReason Code System CONF-0434 SHALL when the occupation is known but the industry is not, [Servers SHALL] omit the industry Observation.component CONF-0435 SHALL To represent the patient’s pregnancy status, [Servers SHALL] use the US Core Observation Pregnancy Status Profile. CONF-0436 SHALL To represent the patient’s intent to become pregnant, [Servers SHALL] use the US Core Observation Pregnancy Intent Profile. CONF-0437 SHOULD (conditional) [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 SHOULD (conditional) 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 SHALL (conditional) the Server system ... SHALL support [either] Reference(US Core Observation Screening Assessment Profile) or Reference(US Core QuestionnaireResponse Profile) for Observation.derivedFrom CONF-0440 MAY (conditional) Additional codes that translate or map to the Observation code (e.g., local codes) are allowed [when using US Core Observation Sexual Orientation Profile] CONF-0441 SHOULD Observations formally part of an assessment tool or survey SHOULD use the US Core Observation Screening Assessment Profile. CONF-0442 SHOULD An assertion or determination derived from screening and assessment tools SHOULD reference them using Observation.derivedFrom CONF-0443 SHOULD When using `Observation.derivedFrom’ to reference an Observation, the referenced Observation SHOULD be a US Core Observation CONF-0444 SHALL (conditional) Although none of the Observation.derivedFrom references are flagged as Must Support, the Server SHALL support at least one of them CONF-0445 MAY (conditional) [US Core] treatment intervention preferences expressed by a patient may be documented in narrative (text) form or the result of selecting from a list of options provided by the content creator/implementer. CONF-0446 SHOULD (conditional) [When using US Core Treatment Intervention Preference Profile] the context or precondition of a patient’s preference SHOULD be supplied in the Observation.valueString ... or an extension CONF-0447 MAY [US Core Vital Signs] observations MAY have component observations … [see] FHIR core specification vital signs table for examples CONF-0448 SHOULD Information about the growth chart tables used to determine percentiles SHOULD be supplied in Observation.note.text CONF-0449 SHOULD (conditional) [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 SHALL (conditional) [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 SHALL (conditional) [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 MAY (conditional) 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 SHOULD (conditional) 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 SHOULD (conditional) 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 SHALL Systems SHALL support National Provider Identifier (NPI) for organizations CONF-0456 SHOULD Systems … SHOULD the National Association of Insurance Commissioners NAIC Company code (sometimes called “NAIC Number” or “cocode”) for payers. CONF-0457 SHOULD Systems … SHOULD support Clinical Laboratory Improvement Amendments (CLIA) for laboratories CONF-0458 SHOULD Systems SHOULD follow the Project US@ Technical Specification for Patient Addresses Final Version 1.0 as the standard style guide for Organization.address.line and Organization.address.city CONF-0459 SHALL (conditional) The Complex [Extension] for Race ... allow[s] for one or more codes of which Must Support at least one category code from the OMB Race ... Category Value Sets that draw from the Race & Ethnicity - CDC (CDCREC) code system [for the [US Core Race Extension] (https://hl7.org/fhir/us/core/STU8/StructureDefinition-us-core-race.html)]. CONF-0460 SHALL (conditional) The Complex [Extension] for ... Ethnicity allow[s] for one or more codes of which Must Support at least one category code from the OMB ... Ethnicity Category Value Sets that draw from the Race & Ethnicity - CDC (CDCREC) code system [for the [US Core Ethnicity Extension] (https://hl7.org/fhir/us/core/STU8/StructureDefinition-us-core-ethnicity.html)]. CONF-0461 MAY (conditional) 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 MAY (conditional) 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 SHALL (conditional) 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 SHALL (conditional) 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-0465 SHALL Although Patient.deceased[x] is marked as additional USCDI, certifying systems are not required to support both [boolean and dateTime data types], but SHALL support [at] least Patient.deceasedDateTime CONF-0466 SHOULD (conditional) Previous name is represented by setting Patient.name.use to “old” or providing an end date in Patient.name.period or doing both CONF-0467 SHOULD (conditional) Previous address is represented by setting Patient.address.use to “old” or providing an end date in Patient.address.period or doing both. CONF-0469 SHALL Certifying systems [, those that are participating in the ONC Health IT certification program,] SHALL ... 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-0470 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 MAY (conditional) [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] does not apply to historical records or documents that are exposed through FHIR-based APIs. [Organizations MAY choose not to use use Project US@ Technical Specification for Patient Addresses Final Version 1.0 when sending historical records] CONF-0472 SHOULD-NOT The Patient’s Social Security Numbers SHOULD NOT be used as a patient identifier in Patient.identifier.value CONF-0473 SHALL (conditional) 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 MAY (conditional) 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 SHALL (conditional) [When using the US Core Practioner Profile] Practitioner.address … SHALL [be supported] if … [the Server does] not support the US Core PractitionerRole Profile CONF-0477 SHOULD Only professional/work contact information about the practitioner SHOULD be available to the patient CONF-0478 SHOULD Systems SHOULD follow the Project US@ Technical Specification for Patient Addresses Final Version 1.0 as the standard style guide for Practitioner.address.line and Practitioner.address.city. CONF-0479 MAY Procedure codes … [MAY] be taken from SNOMED-CT, CPT, HCPCS II, ICD-10-PCS, CDT, or LOINC [for procedure.code] CONF-0480 SHOULD (conditional) [If using LOINC codes in procedure.code] only LOINC concepts that reflect actual procedures SHOULD be used CONF-0481 SHOULD communication.preferred MAY designate a preferred language when multiple languages are represented CONF-0482 SHALL (conditional) [For organizations participating in the ONC Health IT Certification program] Servers … SHALL support ... US Core Procedure Profile for communicating the reason or justification for a referral as Additional USCDI Requirements CONF-0484 SHALL (conditional) [For organizations participating in the ONC Health IT Certification program,] although both Procedure.reasonCode and Procedure.reasonReference are marked as Additional USCDI Requirements, the certifying Server system is not required to support both, but SHALL support at least one of these elements. CONF-0486 SHALL (conditional) [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 SHOULD (conditional) [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 SHALL The US Core Provenance resource SHALL be supported for … [this] US Core resource type AllergyIntolerance CONF-0490 SHALL The US Core Provenance resource SHALL be supported for … [this] US Core resource type CarePlan CONF-0491 SHALL The US Core Provenance resource SHALL be supported for … [this] US Core resource type CareTeam CONF-0492 SHALL The US Core Provenance resource SHALL be supported for … [this] US Core resource type Condition CONF-0493 SHALL The US Core Provenance resource SHALL be supported for … [this] US Core resource type Coverage CONF-0494 SHALL The US Core Provenance resource SHALL be supported for … [this] US Core resource type Device CONF-0495 SHALL The US Core Provenance resource SHALL be supported for … [this] US Core resource type DiagnosticReport CONF-0496 SHALL The US Core Provenance resource SHALL be supported for … [this] US Core resource type Document Reference CONF-0497 SHALL The US Core Provenance resource SHALL be supported for … [this] US Core resource type Encounter CONF-0498 SHALL The US Core Provenance resource SHALL be supported for … [this] US Core resource type Goal CONF-0499 SHALL The US Core Provenance resource SHALL be supported for … [this] US Core resource type Immunization CONF-0500 SHALL The US Core Provenance resource SHALL be supported for … [this] US Core resource type MedicationDispense CONF-0501 SHALL The US Core Provenance resource SHALL be supported for … [this] US Core resource type MedicationRequest CONF-0502 SHALL The US Core Provenance resource SHALL be supported for … [this] US Core resource type Observation CONF-0503 SHALL The US Core Provenance resource SHALL be supported for … [this] US Core resource type Patient CONF-0504 SHALL The US Core Provenance resource SHALL be supported for … [this] US Core resource type Procedure CONF-0505 SHALL The US Core Provenance resource SHALL be supported for … [this] US Core resource type QuestionnaireResponse CONF-0506 SHALL The US Core Provenance resource SHALL be supported for … [this] US Core resource type RelatedPerson CONF-0507 SHALL The US Core Provenance resource SHALL be supported for … [this] US Core resource type ServiceRequest CONF-0508 SHALL (conditional) 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 MAY (conditional) If a system receives a provider in Provenance.agent.who as free text, … [upon request they] MAY include the free text provider. CONF-0510 SHOULD Systems that need to know the activity has occurred SHOULD populate the activity [Provenance.activity] CONF-0511 SHALL (conditional) If the QuestionnaireResponse is based on a non-FHIR form [then a] ... FHIR Questionnaire [needs to] represent at least the relevant metadata CONF-0512 MAY (conditional) If the QuestionnaireResponse is based on a non-FHIR form [then a] … FHIR Questionnaire's questions may be omitted CONF-0513 SHOULD Systems SHOULD follow the Project US@ Technical Specification for Patient Addresses Final Version 1.0 as the standard style guide for RelatedPerson.address.line and RelatedPerson.address.city CONF-0514 MAY The Must Support ServiceRequest.category is bound, at a minimum, to the US Core ServiceRequest Category Codes, and other category codes can be used. CONF-0515 SHOULD The ServiceRequest.code value ... SHOULD be constrained to a subset for a particular use case or domain CONF-0516 SHALL (conditional) [For organizations participating in the ONC Health IT Certification program] Servers … SHALL support ... US Core Service Request Profile for communicating the reason or justification for a referral as Additional USCDI Requirements CONF-0518 SHALL (conditional) [For organizations participating in the ONC Health IT Certification program,] although both ServiceRequest.reasonCode and ServiceRequest.reasonReference are marked as Additional USCDI Requirements, the certifying Server system is not required to support both, but SHALL support at least one of these elements. CONF-0520 SHALL (conditional) [For organizations participating in the ONC Health IT Certification program,] when using ServiceRequest.reasonReference Servers SHALL support at least one target resource in ServiceRequest.reasonReference CONF-0522 SHOULD (conditional) [For organizations participating in the ONC Health IT Certification program,] when using ServiceRequest.reasonReference …The referenced resources SHOULD be a US Core Profile as documented in Referencing US Core Profiles CONF-0523 MAY Since the binding [for Specimen.type and additional USCDI elements] is extensible when a code is unavailable, just text is allowed [and conformant]. CONF-0524 SHALL (conditional) 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-0532 SHOULD [Servers] SHOULD Support the ... SMART App Launch version 2.0.0 and later CONF-0533 SHALL US Core Server SHALL support the US Core Patient resource profile CONF-0534 SHALL US Core Server SHALL support … at least one additional resource profile [in addition to the US Core Patient resource profile] from the list of US Core Profiles CONF-0535 SHALL US Core Server SHALL … Implement the RESTful behavior according to the FHIR specification. CONF-0536 SHALL US Core Server SHALL … return the following response class (Status 400) [for] invalid parameters CONF-0537 SHALL US Core Server SHALL … return the following response class (Status 401/4xx) [for] unauthorized request CONF-0538 SHALL US Core Server SHALL … return the following response class (Status 403) [for] insufficient scopes CONF-0539 SHALL US Core Server SHALL … return the following response class (Status 404) [for] unknown resource CONF-0540 SHALL US Core Server SHALL … support JSON source formats for all US Core interactions. CONF-0541 SHOULD US Core Server SHOULD … support XML source formats for all US Core interactions. CONF-0542 SHOULD US Core Server SHOULD … identify the US Core profiles supported as part of the FHIR meta.profile attribute for each instance. CONF-0543 SHALL (conditional) A Server SHALL reject any unauthorized requests by returning an HTTP 401 "Unauthorized", HTTP 403 "Forbidden", or HTTP 404 "Not Found" CONF-0548 SHOULD [US Core Servers] SHOULD support $expand operation CONF-0549 SHOULD (conditional) If a Server supports DocumentReference for creating, using, and sharing clinical notes, it SHOULD also support the context and contextdirection parameters of the $expand operation CONF-0550 SHALL Systems SHALL establish a risk analysis and management regime that conforms with HIPAA security regulatory requirements CONF-0552 SHOULD US Federal systems SHOULD conform with the risk management and mitigation requirements defined in NIST 800 series documents. CONF-0554 SHOULD US Federal systems … SHOULD include security category assignment following NIST 800-60 vol. 2 Appendix D.14. CONF-0556 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 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 SHOULD The selected time service SHOULD be documented in the Business Associate Agreement when available. CONF-0562 SHALL Systems SHALL keep audit logs of the various transactions. CONF-0564 SHALL Systems SHALL use TLS version 1.2 or higher for all transmissions not taking place over a secure network connection. CONF-0566 SHOULD US Federal systems SHOULD conform with FIPS PUB 140-2. CONF-0568 SHALL Systems SHALL conform to FHIR Communications Security requirements. CONF-0570 SHALL For Authentication and Authorization, Systems SHALL support any SMART App Launch Version 2.0.0 for Client <-> Server interactions. CONF-0572 SHALL Systems SHALL implement consent requirements per their state, local, and institutional policies. CONF-0574 SHOULD The Business Associate Agreements SHOULD document systems’ mutual consent requirements. CONF-0576 SHOULD Systems SHOULD provide Provenance statements using the US Core Provenance Profile resource and associated requirements. CONF-0578 MAY Systems MAY implement the FHIR Digital Signatures CONF-0580 MAY Systems MAY protect the confidentiality of data at rest via encryption and associated access controls. CONF-0583 SHALL (conditional) The [additional] current binding [FHIR R5 link] requires newly recorded, non-legacy data to be drawn from the [bound] value set. CONF-0584 SHALL (conditional) If the QuestionnaireResponse is based on a non-FHIR form [then a] ... FHIR Questionnaire [will communicate] the identifier of the non-FHIR form instead of the canonical URI using the US Core Extension Questionnaire URI extension. CONF-0587 SHALL Each AllergyIntolerance Must Support: a verification status CONF-0588 SHALL Each AllergyIntolerance Must Support: a reaction manifestation CONF-0801 SHALL (conditional) If an element is marked as Additional USCDI and defined by a pattern [as described by ElementDefinition.pattern], then the pattern defines the elements and element values that the Certifying System SHALL be capable of providing. CONF-0802 SHALL (conditional) Primitive elements are single elements with a primitive value…. If they are marked as Additional USCDI, then the Certifying System SHALL be capable of providing the element value to meet the Additional USCDI requirement. CONF-0803 SHALL For any complex element marked as Additional USCDI, the Certifying System SHALL be capable of providing at least one of the sub-element values. CONF-0804 SHALL (conditional) 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-0805 SHALL [I]f any sub-element is marked as Additional USCDI [for a complex element] and the parent element is not… [and] the parent element is represented in the structure, Certifying System SHALL support the sub-elements labeled as Additional USCDI. CONF-0808 SHALL (conditional) When a Reference type element is labeled as Must Support and has a single target profile referenced, the target profile SHALL be supported. CONF-0809 SHALL (conditional) When a Reference type element is labeled as Additional USCDI and has a single target profile referenced, the target profile SHALL be supported for Certifying Systems. CONF-0810 SHALL (conditional) 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-0811 SHALL (conditional) When a Reference type element labeled as Additional USCDI, has multiple target profiles referenced, and specific targets are labeled as Must Support, the Must Support target profile(s) SHALL be supported by Certifying Systems. CONF-0812 SHALL (conditional) [I]f a slice is labeled as ... Additional USCDI and the slicer element is not labeled as ... Additional USCDI, then if the ... certifying system supports the element, it must support the slice's definition. There are no examples of this structure in US Core. CONF-0813 MAY (conditional) [If a] slicer's Must Support property only defines the element level … Additional USCDI property[, i.e.,] no … Additional USCDI property is defined for the slice, then support for that slice's definition is optional. CONF-0814 SHALL (conditional) [I]f a slice is labeled as … Additional USCDI and the slicer element is ... labeled as … Additional USCDI, then … certifying system [SHALL support] the element[ and] the slice's definition. CONF-0818 SHALL Servers SHALL support, at minimum, these … "Common Clinical Notes": Surgical Operation Note (11504-8) CONF-0819 SHALL Servers SHALL support, at minimum, these … "Common Clinical Notes": Emergency Department Note (34111-5) CONF-0820 SHALL (conditional) Servers that support the USCDI Health Status/Assessments Data Class SHALL support the US Core Observation Screening Assessment Profile CONF-0821 SHOULD (conditional) Servers that support the USCDI Health Status/Assessments Data Class ... SHOULD support the SDC Base Questionnaire and the US Core QuestionnaireResponse Profile." CONF-0822 SHALL For the US Core Simple Observation Profile, Servers SHALL support all the category codes listed. CONF-0823 SHALL For the … US Core Observation Screening Assessment Profiles, Servers SHALL support all the category codes listed. CONF-0824 SHALL For the US Core Condition Problems and Health Concerns Profile, Servers SHALL support the code ,"sdoh" CONF-0825 SHOULD For the US Core Condition Problems and Health Concerns Profile, Servers SHOULD support the other category codes listed. CONF-0826 SHOULD For the US Core ServiceRequest Profile, Servers SHOULD support all the [listed] category codes. CONF-0827 SHALL-NOT US Core SearchParameters referenced in [the US Core Client] CapabilityStatement that are derived from standard FHIR SearchParameters are only defined to document Server ... expectations. They specify additional expectations for the following SearchParameter elements:B7 multipleAnd multipleOr comparator modifier chain They SHALL NOT be interpreted as search parameters for search. CONF-0828 SHOULD Servers ... SHOULD use the standard FHIR SearchParameters. CONF-0831 SHALL [The Server SHALL support the] category of "problem-list-item" CONF-0832 SHALL [The Server SHALL support the] category of "health-concern" CONF-0833 SHALL (conditional) Certifying Systems SHALL support, a category of "sdoh" CONF-0834 SHOULD Certifying Systems ... SHOULD support the ... US Core Simple Observation Category codes CONF-0835 MAY Certifying Systems ... MAY support other categories CONF-0836 SHOULD (conditional) The DiagnosticRequest.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 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 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 SHOULD (conditional) If the referenced a 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. CONF-0840 SHALL (conditional) 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 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 SHALL Servers SHALL return all active medications following the Get All Active Medications guidance. CONF-0843 SHOULD (conditional) [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 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 SHALL [For the US Core Observation Screening Assessment Profile, the] category type "survey" is required. CONF-0846 SHALL (conditional) [For the US Core Observation Screening Assessment Profile,] Certifying Systems SHALL support, the US Core Screening Assessment Observation Category codes CONF-0847 SHOULD [For the US Core Observation Screening Assessment Profile,] Certifying Systems SHOULD support, the US Core Screening Assessment Observation Maximum Category codes CONF-0848 MAY [For the US Core Observation Screening Assessment Profile,] Certifying Systems MAY support other codes. CONF-0850 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 MAY Servers can 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-0852 SHALL (conditional) Although the [US Core Interpreter Needed Extension] is marked as an Additional USCDI Requirement 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-0855 SHOULD Systems SHOULD designate the patient's preferred language in the Patient.communication.preferred element. CONF-0856 SHALL (conditional) The Procedure.performed is mandatory if Procedure.status is "completed" or "in-progress". CONF-0857 SHOULD [In the US Core ServiceRequest Profile, for] the USCDI Laboratory Order, ... implementers SHOULD use the corresponding category codes listed ... below: 108252007 Laboratory procedure (procedure) CONF-0858 SHOULD [In the US Core ServiceRequest Profile, for] the USCDI ... Clinical Test Order, ... implementers SHOULD use the corresponding category codes listed ... below: 386053000 Evaluation procedure (procedure) 410606002 Social service procedure (procedure) 387713003 Surgical procedure (procedure) CONF-0859 SHOULD [In the US Core ServiceRequest Profile, for] the USCDI ... Imaging Order, ... implementers SHOULD use the corresponding category codes listed ... below: 363679005 Imaging (procedure) CONF-0860 SHOULD [In the US Core ServiceRequest Profile, for] the USCDI ... Procedure Order Data Elements, implementers SHOULD use the corresponding category codes listed ... below: 386053000 Evaluation procedure (procedure) 410606002 Social service procedure (procedure) 387713003 Surgical procedure (procedure) CONF-0861 SHOULD (conditional) [For US Core Simple Observation Profile, ]Certifying Systems ... SHOULD support the other US Core Simple Observation Category codes [in addition to the US Core Screening Assessment Observation Category codes] CONF-0862 SHALL (conditional) [For US Core Simple Observation Profile, ]Certifying Systems SHALL support, the US Core Screening Assessment Observation Category codes CONF-0863 MAY (conditional) [For US Core Simple Observation Profile, ]Certifying Systems ... MAY support other categories [in addition to US Core Screening Assessment Observation Category codes and US Core Simple Observation Category codes]. CONF-0864 SHALL An Observation without a value, SHALL include a reason why the data is absent unless there are 1) component observations, or 2) reporting panel observations using Observation.hasMember. CONF-0865 MAY (conditional) Systems that never provide an observation without a value are not required to support Observation.dataAbsentReason. CONF-0866 SHALL An Observation.component without a value, SHALL include a reason why the data is absent. CONF-0867 MAY (conditional) Systems that never provide a component observation without a component value are not required to support Observation.component.dataAbsentReason. CONF-0868 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-0870 SHALL (conditional) [I]f a slice is labeled as Must Support... and the slicer element is not labeled as Must Support..., then if the Server... supports the element, it must support the slice's definition. There are no examples of this structure in US Core. CONF-0871 MAY (conditional) [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-0872 SHALL (conditional) [I]f a slice is labeled as Must Support... and the slicer element is ... labeled as Must Support..., then ... the Server... [SHALL support] the element[ and] the slice's definition. CONF-0881 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.
HL7 International / Cross-Group Projects
This Requirements resources 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 ASTP Health IT Certification (g(10) certification.
Used by permission of HL7 International, all rights reserved Creative Commons License
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 ValueSet **SHALL** be used if an applicable concept is present.
[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 provided.
For `CodeableConcept` [with an [extensible binding] (http://hl7.org/fhir/R4/terminologies.html#extensible) … If only text is available and it has no conceptual overlap with the bound coded values, then just text may be used.
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 are strongly encouraged to 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
[For systems that require a status parameter to be provided, they] **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.`
When an element is Mandatory, the data is expected always to be present.
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).
For querying and reading US Core Profiles, Must Support on any profile data element **SHALL** be interpreted as follows…: When information on a particular data element is not present, and the reason for absence is unknown, US Core Responders **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 must 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 represented in the structure, 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
The U.S. Core Data for Interoperability (USCDI) may require additional elements, [which is a requirement for certification in the ONC IT Health Certification program, but not a requirement of US Core conformance for US Core Responders]
In certain profiles, only specific resource references 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
In specific profiles, only a single resource reference is present on an element labeled Must Support. ... - 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](http://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](http://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](http://hl7.org/fhir/smart-app-launch/STU2/conformance.html#patient-access-for-standalone-apps) [Clinician Access for EHR Launch](http://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](http://hl7.org/fhir/smart-app-launch/STU2/conformance.html#patient-access-for-standalone-apps) [Clinician Access for EHR Launch](http://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](http://hl7.org/fhir/smart-app-launch/STU2/token-introspection.html#token-introspection).
Implementations meeting US EHR certification [of the ONC IT Health Certification program] requirements must support all US Core’s required scopes.
Other systems only need to 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
[If a] US Core Profiles binds the Quantity.code element in the Quantity datatype to the [UCUM](http://unitsofmeasure.org/) code system, [when] no units [are available systems SHOULD NOT supply the unit field]
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.
This guide requires [Server] systems to implement the [US Core DocumentReference Profile](https://hl7.org/fhir/us/core/STU8/StructureDefinition-us-core-documentreference.html)
This guide requires [Server] systems to 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 will 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]
[The [MedicationAdministration](http://hl7.org/fhir/R4/medicationadministration.html) and [MedicationStatement](http://hl7.org/fhir/R4/medicationstatement.html)] medication resources are not profiled by US Core, and systems that support US Core are permitted to use them
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 can 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: Servers [MAY] use the `MedicationRequest.reported[x]` element to indicate ... the source of the report.
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
The HIE must maintain the original data source.
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 must be surfaced as an Observation.
For FHIR implementers, it is important to note that QuestionnaireResponse [which represent the source-of-truth of a completed form, shall] references a specific version of a form, whether it was represented as a FHIR Questionnaire or not. This reference provides the context of exactly what options were available, what logic was used to calculate answers, and what questions were asked.
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)
A Server may support Version DSTU2 and Argonaut Data Query
A Server may support … FHIR R4 and US Core ver 3.1.1+
A Server may support [both] [(]Version DSTU2 and Argonaut Data Query[) and (] FHIR R4 and US Core ver 3.1.1+[)]
A Server may make explicit which version of Argo/US Core is on their FHIR endpoint (e.g., “DSTU2” or “R4” path component or separate files based on version).
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).
Separate authorization is required [between different versions of FHIR]
[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”
Profile Specific Implementation Guidance: No Known Allergies may be represented using the US Core-AllergyIntolerance profile
[When used No Known Allergies is documented the system Shall use an] appropriate negation code in AllergyIntolerence.code
[When used 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, then 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.
For Problems and Health Concerns [records, systems SHOULD] use the [US Core Condition Problems and Health Concerns Profile](https://hl7.org/fhir/us/core/STU8/StructureDefinition-us-core-condition-problems-health-concerns.html).
[Newly created Encounter Diagnosis records SHALL have a] Condition.code … [from the] [“current”](https://hl7.org/fhir/R5/terminologies.html#binding) … [value set] binding.
[Historical Encounter Diagnosis records MAY have a] Condition.code … [from the] base “preferred” … [value set] binding.
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.
For Encounter Diagnosis [records, systems SHOULD] use the [US Core Condition Encounter Diagnosis Profile](https://hl7.org/fhir/us/core/STU8/StructureDefinition-us-core-condition-encounter-diagnosis.html).
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 verifications status of problems or health concerns [This will change to a SHALL requirement in US Core v8.0.0]
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.
Implementers should refer to the [PHDSC Payer Type Committee User’s Guide](https://www.nahdo.org/sites/default/files/2020-12/SourceofPaymentTypologyUsersGuideVersion9.2December2020.pdf) for the Source of Payment Typology when selecting codes.
To differentiate Medicare Parts A, B, C, and D systems can 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 can 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 can 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.
For non-implantable devices (for example, software or crutches), use the base FHIR Device resource or other use case-specific Device profiles.
Implementers are encouraged to use the FDA Global UDI Database (GUDID) and associated APIs to parse and validate the [unique device ID] UDI
Implantable 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 Implantable 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
Servers SHOULD support query by Device.type to allow Clients to request the patient’s devices by a specific type.
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).
The DiagnosticReport.category binding Must Support, at a minimum, the US Core DiagnosticReport Category Codes of Cardiology, Radiology, and Pathology
Other [diagnostic report] categories may be supported [when using US Core DiagnosticReport Profile for Report and Note Exchange]
[L]inkages between specific LOINC codes and the LP-type codes may be used as guidance [for a Server's categorization of diagnostic reports]
For Diagnostic Imaging Reports systems SHOULD support using the subset of LOINC codes defined in CONF-DIR-19 in HL7 Implementation Guide for CDA Release 2: Imaging Integration, Levels 1, 2, and 3, Basic Imaging Reports in CDA and DICOM Diagnostic Imaging Reports (DIR) - Universal Realm, Release 1.0.
The DocumentReference.type binding Must Support, at a minimum, the 10 [Common Clinical Notes](https://hl7.org/fhir/us/core/STU8/StructureDefinition-us-core-documentreference.html#mandatory-and-must-support-data-elements)
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.
[For organization participating in the ONC Health IT Certification program] [CVX vaccine codes](https://www2a.cdc.gov/vaccines/iis/iisstandards/ndc_crosswalk.asp) are required
[NDC vaccine codes](http://www2a.cdc.gov/vaccines/iis/iisstandards/ndc_crosswalk.asp) SHOULD be supported as an additional code [of [CVX Vaccine Codes](https://www2a.cdc.gov/vaccines/iis/iisstandards/ndc_crosswalk.asp)]
The preferred code system identifier … is [http://hl7.org/fhir/sid/cvx](http://hl7.org/fhir/sid/cvx) for CVX [vaccine codes]
The preferred code system identifier … is [http://hl7.org/fhir/sid/ndc](http://hl7.org/fhir/sid/ndc) for NDC vaccine codes]
Systems 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 Location.address.line
Systems 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 Location.address.city
When using a code [to represent a medication for a medication dispense], RXNorm concepts are used.
When using a code [to represent a medication for a medication dispense], [National Drug Codes (NDC)](https://www.fda.gov/drugs/drug-approvals-and-databases/national-drug-code-directory) can be supplied as an additional coding element.
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.
[For organization participating in the ONC Health IT Certification program Servers SHALL support the [additional USCDI requirement](https://hl7.org/fhir/us/core/STU8/must-support.html#additional-uscdi-requirements):], The reason or indication for the prescription
[For organization participating in the ONC Health IT Certification program Servers SHALL support the [additional USCDI requirement](https://hl7.org/fhir/us/core/STU8/must-support.html#additional-uscdi-requirements):] reported adherence to prescribed medication instructions
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
Although both MedicationRequest.reasonCode and MedicationRequest.reasonReference are marked as Additional USCDI Requirements [which are required for organizations participating in the ONC Health IT Certification program]. The certifying 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 and supporting MedicationRequest.reasonReference,] Servers SHALL support at least one target resource in MedicationRequest.reasonReference
[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, [Servers SHALL] omit observation.effectivePeriod.end to indicate it is ongoing.
When the industry is known, but the occupation is not, [Servers 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, [Servers SHALL] omit the industry Observation.component
To represent the patient’s pregnancy status, [Servers SHALL] use the [US Core Observation Pregnancy Status Profile](https://hl7.org/fhir/us/core/StructureDefinition-us-core-observation-pregnancystatus.html).
To represent the patient’s intent to become pregnant, [Servers SHALL] use the [US Core Observation Pregnancy Intent Profile](https://hl7.org/fhir/us/core/StructureDefinition-us-core-observation-pregnancyintent.html).
[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
Additional codes that translate or map to the Observation code (e.g., local codes) are allowed [when using US Core Observation Sexual Orientation Profile]
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
Although none of the Observation.derivedFrom [references are flagged as Must Support](https://hl7.org/fhir/us/core/STU8/must-support.html#must-support---resource-references), the Server SHALL support at least one of them
[US Core] treatment intervention preferences expressed by a patient may be documented in narrative (text) form or the result of selecting from a list of options provided by the content creator/implementer.
[When using US Core Treatment Intervention Preference Profile] the context or precondition of a patient’s preference SHOULD be supplied in the Observation.valueString ... or an extension
[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
Systems 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 Organization.address.line and Organization.address.city
The Complex [Extension] for Race ... allow[s] for one or more codes of which [Must Support](https://hl7.org/fhir/us/core/STU8/must-support.html) at least one category code from the OMB Race ... Category Value Sets that draw from the [Race & Ethnicity - CDC (CDCREC)](https://phinvads.cdc.gov/vads/ViewCodeSystem.action?id=2.16.840.1.113883.6.238) code system [for 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 [Must Support](https://hl7.org/fhir/us/core/STU8/must-support.html) at least one category code from the OMB ... Ethnicity Category Value Sets that draw from the [Race & Ethnicity - CDC (CDCREC)](https://phinvads.cdc.gov/vads/ViewCodeSystem.action?id=2.16.840.1.113883.6.238) code system [for the [US Core Ethnicity Extension] (https://hl7.org/fhir/us/core/STU8/StructureDefinition-us-core-ethnicity.html)].
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)]
Although Patient.deceased[x] is marked as additional USCDI, certifying systems are not required to support both [boolean and dateTime data types], but SHALL support [at] least Patient.deceasedDateTime
Previous name is represented by setting Patient.name.use to “old” or providing an end date in Patient.name.period or doing both
Previous address is represented by setting Patient.address.use to “old” or providing an end date in Patient.address.period or doing both.
[Certifying systems](https://www.healthit.gov/topic/certification-ehrs/about-onc-health-it-certification-program) [, those that are participating in the ONC Health IT certification program,] SHALL ... 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.
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] does not apply to historical records or documents that are exposed through FHIR-based APIs. [Organizations MAY choose not to use use Project US@ Technical Specification for Patient Addresses Final Version 1.0 when sending historical records]
The Patient’s Social Security Numbers 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 Practioner 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
Systems 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 Practitioner.address.line and Practitioner.address.city.
Procedure codes … [MAY] be taken from SNOMED-CT, CPT, HCPCS II, ICD-10-PCS, CDT, or LOINC [for procedure.code]
[If using LOINC codes in procedure.code] only LOINC concepts that reflect actual procedures SHOULD be used
communication.preferred MAY designate a preferred language when multiple languages are represented
[For organizations participating in the ONC Health IT Certification program] Servers … SHALL support ... US Core Procedure Profile for communicating the reason or justification for a referral as Additional USCDI Requirements
[For organizations participating in the ONC Health IT Certification program,] although both Procedure.reasonCode and Procedure.reasonReference are marked as Additional USCDI Requirements, the certifying 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,] 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 … [this] US Core resource type AllergyIntolerance
The US Core Provenance resource SHALL be supported for … [this] US Core resource type CarePlan
The US Core Provenance resource SHALL be supported for … [this] US Core resource type CareTeam
The US Core Provenance resource SHALL be supported for … [this] US Core resource type Condition
The US Core Provenance resource SHALL be supported for … [this] US Core resource type Coverage
The US Core Provenance resource SHALL be supported for … [this] US Core resource type Device
The US Core Provenance resource SHALL be supported for … [this] US Core resource type DiagnosticReport
The US Core Provenance resource SHALL be supported for … [this] US Core resource type Document Reference
The US Core Provenance resource SHALL be supported for … [this] US Core resource type Encounter
The US Core Provenance resource SHALL be supported for … [this] US Core resource type Goal
The US Core Provenance resource SHALL be supported for … [this] US Core resource type Immunization
The US Core Provenance resource SHALL be supported for … [this] US Core resource type MedicationDispense
The US Core Provenance resource SHALL be supported for … [this] US Core resource type MedicationRequest
The US Core Provenance resource SHALL be supported for … [this] US Core resource type Observation
The US Core Provenance resource SHALL be supported for … [this] US Core resource type Patient
The US Core Provenance resource SHALL be supported for … [this] US Core resource type Procedure
The US Core Provenance resource SHALL be supported for … [this] US Core resource type QuestionnaireResponse
The US Core Provenance resource SHALL be supported for … [this] US Core resource type RelatedPerson
The US Core Provenance resource SHALL be supported for … [this] US Core resource type 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.
Systems that need to know the activity has occurred SHOULD populate the activity [Provenance.activity]
If the QuestionnaireResponse is based on a non-FHIR form [then a] ... FHIR Questionnaire [needs to] represent at least the relevant metadata
If the QuestionnaireResponse is based on a non-FHIR form [then a] … FHIR Questionnaire's questions may be omitted
Systems 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 RelatedPerson.address.line and RelatedPerson.address.city
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 can be used.
The ServiceRequest.code value ... SHOULD be constrained to a subset for a particular use case or domain
[For organizations participating in the ONC Health IT Certification program] Servers … SHALL support ... US Core Service Request Profile for communicating the reason or justification for a referral as Additional USCDI Requirements
[For organizations participating in the ONC Health IT Certification program,] although both ServiceRequest.reasonCode and ServiceRequest.reasonReference are marked as Additional USCDI Requirements, the certifying 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,] when using ServiceRequest.reasonReference Servers SHALL support at least one target resource in ServiceRequest.reasonReference
[For organizations participating in the ONC Health IT Certification program,] when using ServiceRequest.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)
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, just text is allowed [and conformant].
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.
[Servers] SHOULD Support the ... [SMART App Launch version 2.0.0 and later](http://hl7.org/fhir/smart-app-launch/history.html)
US Core Server SHALL support the US Core Patient resource profile
US Core Server SHALL support … at least one additional resource profile [in addition to the US Core Patient resource profile] from the list of US Core Profiles
US Core Server SHALL … Implement the RESTful behavior according to the FHIR specification.
US Core Server SHALL … return the following response class (Status 400) [for] invalid parameters
US Core Server SHALL … return the following response class (Status 401/4xx) [for] unauthorized request
US Core Server SHALL … return the following response class (Status 403) [for] insufficient scopes
US Core Server SHALL … return the following response class (Status 404) [for] unknown resource
US Core Server SHALL … support JSON source formats for all US Core interactions.
US Core Server SHOULD … support XML source formats for all US Core interactions.
US Core Server SHOULD … identify the US Core profiles supported as part of the FHIR meta.profile attribute for each instance.
A Server SHALL reject any unauthorized requests by returning an HTTP 401 "Unauthorized", HTTP 403 "Forbidden", or HTTP 404 "Not Found"
[US Core Servers] SHOULD support [$expand](http://hl7.org/fhir/OperationDefinition/ValueSet-expand) operation
If a Server supports DocumentReference for creating, using, and sharing clinical notes, it SHOULD also support the context and contextdirection parameters of the $expand operation
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) for Client <-> Server interactions.
Systems SHALL implement consent requirements per their state, local, and institutional policies.
The Business Associate Agreements SHOULD document systems’ mutual consent requirements.
Systems SHOULD provide Provenance statements using the [US Core Provenance Profile](https://hl7.org/fhir/us/core/STU8/StructureDefinition-us-core-provenance.html) resource and associated requirements.
Systems MAY implement the [FHIR Digital Signatures](http://hl7.org/fhir/R4/security.html#digital%20signatures)
Systems MAY protect the confidentiality of data at rest via encryption and associated access controls.
The [additional] current binding [[FHIR R5 link](https://hl7.org/fhir/R5/terminologies.html#binding)] requires newly recorded, non-legacy data to be drawn from the [bound] value set.
If the QuestionnaireResponse is based on a non-FHIR form [then a] ... FHIR Questionnaire [will communicate] the identifier of the non-FHIR form instead of the canonical URI using the US Core Extension Questionnaire URI extension.
Each AllergyIntolerance Must Support: a verification status
Each AllergyIntolerance Must Support: a reaction manifestation
If an element is marked as *Additional USCDI* 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 Certifying System **SHALL** be capable of providing.
Primitive elements are single elements with a primitive value…. If they are marked as *Additional USCDI*, then the Certifying System **SHALL** be capable of providing the element value to meet the *Additional USCDI* requirement.
For any complex element marked as *Additional USCDI*, the Certifying System **SHALL** be capable of providing at least one of the sub-element values.
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.
[I]f any sub-element is marked as *Additional USCDI* [for a complex element] and the parent element is not… [and] the parent element is represented in the structure, Certifying System **SHALL** support the sub-elements labeled as *Additional USCDI*.
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 Additional USCDI and has a single target profile referenced, the target profile **SHALL** be supported for Certifying Systems.
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.
When a Reference type element labeled as Additional USCDI, has multiple target profiles referenced, and specific targets are labeled as Must Support, the Must Support target profile(s) **SHALL** be supported by Certifying Systems.
[I]f a slice is labeled as ... Additional USCDI and the slicer element is not labeled as ... Additional USCDI, then if the ... certifying system supports the element, it must support the slice's definition. There are no examples of this structure in US Core.
[If a] slicer's Must Support property only defines the element level … Additional USCDI property[, i.e.,] no … Additional USCDI property is defined for the slice, then support for that slice's definition is optional.
[I]f a slice is labeled as … Additional USCDI and the slicer element is ... labeled as … Additional USCDI, then … certifying system [**SHALL** support] the element[ and] the slice's definition.
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 **SHALL** support the US Core Observation Screening Assessment Profile
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.
US Core SearchParameters referenced in [the US Core Client] CapabilityStatement that are derived from standard FHIR SearchParameters are only defined to document Server ... expectations. They specify additional expectations for the following SearchParameter elements:B7 - multipleAnd - multipleOr - comparator - modifier - chain They **SHALL NOT** be interpreted as search parameters for search.
Servers ... **SHOULD** use the standard FHIR SearchParameters.
[The Server **SHALL** support the] category of "problem-list-item"
[The Server **SHALL** support the] category of "health-concern"
Certifying Systems **SHALL** support, a category of "sdoh"
Certifying Systems ... **SHOULD** support the ... [US Core Simple Observation Category](https://hl7.org/fhir/us/core/STU8/ValueSet-us-core-simple-observation-category.html) codes
Certifying Systems ... **MAY** support other categories
The `DiagnosticRequest.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 a 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,] Certifying Systems **SHALL** support, the [US Core Screening Assessment Observation Category](https://hl7.org/fhir/us/core/STU8/ValueSet-us-core-screening-assessment-observation-category.html) codes
[For the US Core Observation Screening Assessment Profile,] Certifying Systems **SHOULD** support, the [US Core Screening Assessment Observation Maximum Category](https://hl7.org/fhir/us/core/STU8/ValueSet-us-core-screening-assessment-observation-maximum-category.html) codes
[For the US Core Observation Screening Assessment Profile,] Certifying Systems **MAY** support other codes.
[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 can 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.
Although the [[US Core Interpreter Needed Extension](https://hl7.org/fhir/us/core/STU8/StructureDefinition-us-core-interpreter-needed.html)] is marked as an Additional USCDI Requirement 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.
Systems **SHOULD** designate the patient's preferred language in the Patient.communication.preferred element.
The `Procedure.performed` is mandatory if `Procedure.status` is "completed" or "in-progress".
[In the [US Core ServiceRequest Profile](https://hl7.org/fhir/us/core/STU8/StructureDefinition-us-core-servicerequest.html), for] the USCDI Laboratory Order, ... implementers SHOULD use the corresponding category codes listed ... below: - [108252007 Laboratory procedure (procedure)](https://browser.ihtsdotools.org/?perspective=full&conceptId1=108252007&edition=MAIN/2024-10-01&release=&languages=en&latestRedirect=false)
[In the [US Core ServiceRequest Profile](https://hl7.org/fhir/us/core/STU8/StructureDefinition-us-core-servicerequest.html), for] the USCDI ... Clinical Test Order, ... implementers SHOULD use the corresponding category codes listed ... below: - [386053000 Evaluation procedure (procedure)](https://browser.ihtsdotools.org/?perspective=full&conceptId1=386053000&edition=MAIN/2024-10-01&release=&languages=en&latestRedirect=false) - [410606002 Social service procedure (procedure)](https://browser.ihtsdotools.org/?perspective=full&conceptId1=410606002&edition=MAIN/2024-10-01&release=&languages=en&latestRedirect=false) - [387713003 Surgical procedure (procedure)](https://browser.ihtsdotools.org/?perspective=full&conceptId1=387713003&edition=MAIN/2024-10-01&release=&languages=en&latestRedirect=false)
[In the [US Core ServiceRequest Profile](https://hl7.org/fhir/us/core/STU8/StructureDefinition-us-core-servicerequest.html), for] the USCDI ... Imaging Order, ... implementers SHOULD use the corresponding category codes listed ... below: - [363679005 Imaging (procedure)](https://browser.ihtsdotools.org/?perspective=full&conceptId1=363679005&edition=MAIN/2024-10-01&release=&languages=en&latestRedirect=false)
[In the [US Core ServiceRequest Profile](https://hl7.org/fhir/us/core/STU8/StructureDefinition-us-core-servicerequest.html), for] the USCDI ... Procedure Order Data Elements, implementers SHOULD use the corresponding category codes listed ... below: - [386053000 Evaluation procedure (procedure)](https://browser.ihtsdotools.org/?perspective=full&conceptId1=386053000&edition=MAIN/2024-10-01&release=&languages=en&latestRedirect=false) - [410606002 Social service procedure (procedure)](https://browser.ihtsdotools.org/?perspective=full&conceptId1=410606002&edition=MAIN/2024-10-01&release=&languages=en&latestRedirect=false) - [387713003 Surgical procedure (procedure)](https://browser.ihtsdotools.org/?perspective=full&conceptId1=387713003&edition=MAIN/2024-10-01&release=&languages=en&latestRedirect=false)
[For [US Core Simple Observation Profile](https://hl7.org/fhir/us/core/STU8/StructureDefinition-us-core-simple-observation.html), ]Certifying Systems ... **SHOULD** support the other [US Core Simple Observation Category codes](https://hl7.org/fhir/us/core/STU8/ValueSet-us-core-simple-observation-category.html) [in addition to the [US Core Screening Assessment Observation Category codes](https://hl7.org/fhir/us/core/STU8/ValueSet-us-core-screening-assessment-observation-category.html)]
[For [US Core Simple Observation Profile](https://hl7.org/fhir/us/core/STU8/StructureDefinition-us-core-simple-observation.html), ]Certifying Systems **SHALL** support, the [US Core Screening Assessment Observation Category codes](https://hl7.org/fhir/us/core/STU8/ValueSet-us-core-screening-assessment-observation-category.html)
[For [US Core Simple Observation Profile](https://hl7.org/fhir/us/core/STU8/StructureDefinition-us-core-simple-observation.html), ]Certifying Systems ... **MAY** support other categories [in addition to [US Core Screening Assessment Observation Category codes](https://hl7.org/fhir/us/core/STU8/ValueSet-us-core-screening-assessment-observation-category.html) and [US Core Simple Observation Category codes](https://hl7.org/fhir/us/core/STU8/ValueSet-us-core-simple-observation-category.html)].
An Observation without a value, **SHALL** include a reason why the data is absent unless there are 1) component observations, or 2) reporting panel observations using Observation.hasMember.
Systems that never provide an observation without a value are not required to support `Observation.dataAbsentReason`.
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 are not required to support `Observation.component.dataAbsentReason`.
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.
[I]f a slice is labeled as Must Support... and the slicer element is not labeled as Must Support..., then if the Server... supports the element, it must support the slice's definition. There are no examples of this structure in US Core.
[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.
[I]f a slice is labeled as Must Support... and the slicer element is ... labeled as Must Support..., then ... the Server... [**SHALL** support] the element[ and] the slice's definition.
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.