US Quality Core Implementation Guide
0.1.0 - cibuild
US Quality Core Implementation Guide
0.1.0 - cibuild
US Quality Core Implementation Guide, published by ASTP. This guide is not an authorized publication; it is the continuous build for version 0.1.0 built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/FHIR/us-quality-core/ and changes regularly. See the Directory of published versions
This page documents requirements common to all US Quality Core actors in this guide. The conformance verbs - SHALL, SHOULD, MAY - used in this guide are defined in FHIR Conformance Rules.
In addition to adherence to core FHIR requirements, conformance to this US Quality Core Implementation Guide also requires the following:
Within FHIR resources, some elements are considered Modifier Elements, indicating that the value of that element may change the interpretation of the resource. Typical examples of modifier elements are elements such as status that exists in many resources and doNotPerform element in MedicationRequest. For example, Procedure.status with a value of not-done indicating that the procedure was not performed.
Decision support and quality implementations MUST always check the values of modifier elements. For example, in processing a Procedure resource, the application must inspect the status element to determine whether the procedure was performed or not performed to the patient. For this reason, modifier elements SHALL be treated as MustSupport, even if not declared.
US Quality Core adopts QI-Core’s concept of negation and its approach to constraining negated concepts, which follows the informative publication established by HL7.1
US Quality Core constrains these negated concepts as follows:
Absence of data
The measure or Clinical Decision Support (CDS) artifact uses CQL to determine that an expected record artifact does not exist.
Documented absence of data with a valid reason
The measure or CDS artifact uses a specifically designed US Quality Core profile to indicate that an activity intentionally did not occur for a valid reason.
When there is a need to document evidence that an expected activity was not done due to patient preference and/or specific criteria, systems should use one of the ten US Quality Core specific negation rationale profiles that align with existing profiles representing the expected actions. The US Quality Core Negation page of this guide provides detailed descriptions and guidance on these profiles.
Quality improvement artifact authors should pay close attention to binding parameters specified in the
profiles to determine whether the value set defined in the binding is exemplar or should be constrained to a specific value set when used. For example, the code element of the US Quality Core Medication profile is bound to the complete value set for the RxNorm code system, indicating that all Medication instances SHALL use codes from the RxNorm code system, but within any given artifact, instances will typically use a restricted value set.
FHIR resources frequently contain references (pointers) to other FHIR resources. For example, Encounter.subject is a reference to a Patient resource. In US Quality Core, most references are constrained to US Quality Core profiled resources. For example, the US Quality Core Encounter profile's Encounter.patient must point to a Patient resource that conforms to the US Quality Core Patient profile. Consequently, any extensions or bindings expected to exist in US Quality Core Patient are also present in the resource pointed to by Encounter.patient. References to US Quality Core extensions accessed through references are guaranteed to be valid. References to resources that do not currently have US Quality Core profiles are not constrained, and as such, only the core FHIR properties and bindings are guaranteed to exist.
A particular problem occurs when a resource reference permits any type of resource, such as Encounter.indication. When dealing with "Any" references, the current method of specifying profiles does not allow the profile author to specify something to the effect of "a US Quality Core resource when there is one, and a FHIR core resource if there isn't." As stated in the Summary of Conformance Requirements section above, in US Quality Core, the resources in "Any" references SHALL conform to US Quality Core profiles if the base resource has been profiled.
Footnotes:
For further information about representing negatives in HL7 standards, see: HL7 Cross Paradigm Specification: Representing Negatives, Release I. April 2022. Available at: http://www.hl7.org/implement/standards/product_brief.cfm?product_id=592. Retrieved 31 December 2023. ↩