QI-Core Implementation Guide: STU 3.2 (v3.2.0 for FHIR 3.0.1)
This page is part of the Quality Improvement Core Framework (v3.2.0: STU 3) based on FHIR R3. The current version which supercedes this version is 4.1.1. For a full list of available versions, see the Directory of published versions 
This STU update to the QI-Core profiles incorporates updates to the US-Core profiles, version 2.0.0. Specifically, it changes the QICore-Encounter and QICore-PractitionerRole profiles to be derived from the new USCore-Encounter and USCore-PractitionerRole profiles, rather than directly from the base resources, as well as changes the QICore-Coverage profile type element to bind to the SOP Payer value set.
The QI-Core Implementation Guide defines a set of FHIR profiles with extensions and bindings needed to create interoperable, quality-focused applications. The profiles in this implementation guide derive from and extend the US Core profiles to provide a common foundation for building, sharing, and evaluating knowledge artifacts across quality improvement efforts in the US Realm.
As an HL7 FHIR Implementation Guide, changes to this specification are managed by the sponsoring workgroup, Clinical Quality Information, and incorporated as part of the standard balloting process. The current roadmap follows closely behind the base FHIR roadmap, and the US Core Implementation Guide.
This Implementation Guide originated as a U.S. Realm Specification with support from the Clinical Quality Framework (CQF) initiative, which was a public-private partnership sponsored by the Centers for Medicare & Medicaid Services (CMS) and the U.S. Office of the National Coordinator (ONC) to harmonize standards for clinical decision support and electronic clinical quality measurement. The Clinical Quality Framework effort transitioned to HL7's Clinical Quality Information (CQI) and Clinical Decision Support (CDS) Work Groups in 2016. The HL7 CQI Work Group maintains this Implementation Guide, co-sponsored by the Clinical Decision Support (CDS) HL7 Work Group to inform electronic clinical quality improvement (i.e., measurement and decision support). This Quality Improvement Core (QI-Core) Implementation Guide is intended to be usable for multiple use cases across domains, and much of the content is likely to be usable outside the U.S. Realm.
Understanding QI-Core and how it is used in quality applications requires an understanding of the role of common reference models. Electronic Health Records (EHRs) are stored in many different local formats. Exchanging data between EHRs requires mapping between local data formats. It is well understood that standards can reduce the number of data maps each data provider must create. In a similar manner, to share quality measures and clinical decision support artifacts, the measures and artifacts must refer to data in a standardized way.
In the U.S. Realm, the common reference model for electronic clinical quality measures (eCQMs) is the Quality Data Model (QDM). For clinical decision support, a common reference model is the HL7 Virtual Medical Record for Clinical Decision Support(vMR). Decision support and quality measures are closely related, and can be viewed as "two sides of the same coin". Specifically, decision support provides guidance for clinical best practices, and quality measures assess whether clinical best practices have been followed. It therefore makes intuitive sense to use the same common reference model for both types of applications.
The resulting unified model is known as QUICK. QUICK is a logical model consisting of objects, attributes, and relationships. QUICK provides a uniform way for clinical decision support and quality measures to refer to clinical data. Authors of quality measures and clinical decision support artifacts may use QUICK, together with HL7's Clinical Quality Language (CQL), to create interoperable and executable knowledge artifacts.
This initiative began in 2013 with the creation of the Quality Improvement Domain Analysis Model (QIDAM), which drew on the vMR and QDM as sources of requirements. QIDAM gave rise to the QUICK logical model in 2014. Originally, QUICK was entirely independent of FHIR. However, recognizing the broader community focus on FHIR, QUICK was aligned, structurally and semantically, as closely as possible to FHIR. This alignment not only creates a common model for quality and interoperability, but will also make it easier in the future to leverage other FHIR-related efforts, such as Clinical Document Architecture (CDA) on FHIR. The conceptual, logical, and physical models in this initiative are, respectively, QIDAM, QUICK, and the QI-Core FHIR Profiles.
This project is part of an effort to align the HL7 Product Family in the area of health quality improvement. The goal is to have a single logical data model (QUICK), as well as a single logical processing language (CQL), for CDS and clinical quality measurement (CQM). This alignment will lessen the cost and complexity for product developers and vendors, reduce the learning curve, and consolidate efforts to maintain multiple standards.
The QUICK logical model was originally developed without reference to FHIR. However, when it became clear that FHIR would be the focus of interoperability efforts in HL7, it no longer made sense for the quality improvement community to maintain its own model of clinical information, for example, having a procedure model with different attributes than the FHIR procedure resource. The decision was made by the CDS and CQI working groups to align QUICK with FHIR, and use the FHIR resources to define the QUICK model. This decision means that QUICK benefits from all the thought and effort being put into FHIR, and stay in synchronization with the development and evolution of FHIR.
Using FHIR to define the QUICK logical model seems to reverse the usual flow from conceptual model to logical model to physical model. This is true, and has been the source of some controversy. Without revisiting that debate, the bottom line is whether the QUICK model has the right set of objects and attributes that are needed for quality improvement applications. To assure that QUICK does meet those requirements, the QI-Core profiles were created. QI-Core fills any gaps such as missing attributes and unspecified value sets, that might make QUICK insufficient for quality improvement applications. In turn, QUICK is derived from QI-Core profiles, rather than directly from FHIR.
QI-Core classes and attributes are the most relevant to the broader QI community, lying in the intersection of clinical quality measures (CQM) and CDS, thus providing a common foundation for reusability. To the extent possible, QI-Core derives content from USCore profiles and extensions. The expectation is that QI-Core will continue to grow over time as USCore grows, and by incorporating needed extensions with broad applicability. There may also be further extensions and coordinated profiles in specific domains beyond QI-Core, e.g., radiology-specific profiles. The CQI and CDS Work Groups coordinate with HL7 Work Groups that manage specific FHIR resources to align definitions and value sets that include concepts required for CDS and retrospective CQM use cases. When additional classes and attributes are needed for specific quality applications, they can be added through FHIR's extension mechanism. These extensions, however, would not automatically result in shareable artifacts without additional coordinating agreements between interested parties. It is expected that QI-Core will evolve over time to include some of the extensional content when the community identifies a common need and the additional content has been validated.
The QUICK model is the logical model used by quality artifact authors. To obtain data to evaluate the artifacts, the interactions with the local EHR can use FHIR or implement a custom data mapping to local EHR data. In addition to defining QUICK, the QI-Core profiles provide a bridge to using FHIR as QUICK's physical model. To correctly map between FHIR and QUICK, the data instances retrieved from a FHIR interface must conform to the QI-Core profiles. The QI-Core FHIR Profiles link the QUICK logical model to FHIR at the physical level.
QI-Core FHIR profiles provide a physical model for core elements of the Quality Information and Clinical Knowledge (QUICK) logical model. The QUICK model, derived from QI-Core, provides a uniform way for clinical decision support and quality measures to refer to clinical data. Simultaneously, the QI-Core profiles provide a physical implementation of QUICK, making data for quality improvement applications accessible via the FHIR interface. However, using FHIR in the physical layer is optional. If the QI-Core FHIR profiles are not used at the physical layer, implementers are responsible for mapping their data directly into the QUICK model via their own customized data access layer.
For system implementers, using FHIR as the physical data model behind QUICK may provide several benefits. It may be that the local EHR has already been mapped to FHIR. In this case, the same interface with minor modifications can be used for quality applications. Implementers can also leverage future reference implementations based on FHIR. Using FHIR as a common model for different applications (quality, interoperability, etc.) reduces the overall learning curve.
The QI-Core FHIR Implementation Guide provides requirements and guidance on the use of FHIR in quality measurement and decision support. The profiles in this implementation guide will be used to meet QI-Core project objectives of:
This IG is focused on representation of clinical data, and is limited in breadth to the profiles currently included in QI-Core. Not all FHIR resources are profiled, especially those that do not have clinical value in the context of quality improvement, or do not map to QIDAM. Additional extensions may be added to the current set of profiles, and additional profiles may be added at a later time. In particular, QI-Core represents a subset of the semantics covered in QIDAM, vMR, and QDM. The parts of the latter specifications that are not in the QI-Core profiles could be handled with additional profiles, if the DSTU period reveals the need for such additions. Keeping the QI-Core profiles (and QUICK) in line with FHIR and FHIR's "80%" rule is one way to make sure that the quality artifacts produced from QUICK and QI-Core are computable, based on commonly-collected clinical data. The current set of profiles will evolve to reflect changes to the underlying FHIR resources.
The following topics are explicitly out of scope for this implementation guide:
Some of the above topics are under active investigation and will be topics of future standards efforts. Specifically, the FHIR Clinical Reasoning module provides resources and guidance for how to represent and evaluate quality improvement artifacts within FHIR.
Quality applications may make use of patient-specific information. For this reason, all transactions must be appropriately secured, limiting access to authorized individuals and protecting data while in transit (as laid out in the FHIR Implementer's Safety Check List). These are the same considerations that would relate to any FHIR implementation, and include authentication, authorization, access control consistent with patient consent, transaction logging, and following best practices. For the purposes of QI-Core, security conformance rules are as follows:
It is the responsibility of the server (data provider) to ensure that any necessary consent records exist and are reviewed prior to each exchange of patient-identifiable healthcare information. This verification should be logged in the same manner as other transactions, as discussed above under General Security Considerations.
QI-Core has been harmonized with certain other FHIR-based initiatives, in particular, the Data Access Framework (DAF). US Core is a U.S. Realm Implementation Guide, developed under the DAF initiative, that maps ONC Common Clinical Data Set elements to FHIR resources. The data elements in US Core are also in QI-Core, and whenever possible, profiles defined in QI-Core are derived from the profiles in US Core. As a result, conforming to US Core automatically satisfies a significant subset of the conformance requirements of QI-Core. QI-Core conformance involves supporting certain additional data elements not required by US Core, because they are needed for quality measures or clinical decision support.
Because QI-Core profiles derive from US Core profiles where possible, wherever US Core defines a binding, the QI-Core profiles inherit that binding. QI-Core may specify additional constraints, such as requiring a binding that is only preferred in the USCore base profile, but in general, the QI-Core profiles use the same bindings as US Core. This means that QI-Core is currently a U.S. Realm specification. To support applications outside the U.S. Realm, additional binding analysis and effort would be required.
QI-Core's extensions have also been reviewed by HL7 Work Groups and other initiatives to validate that QI-Core extensions will not create future conflicts. Other initiatives that the QI-Core effort is aligning with include the Clinical Information Modeling Initiative (CIMI) and the Healthcare Services Platform Consortium (HSPC).
For the CIMI effort in particular, the QI-Core effort is engaged in the same work to identify and develop tooling to automatically generate FHIR profiles from a logical model, ideally resulting in a scenario where the CIMI modeling tools can be used to express the QUICK logical model, and then use the same tool chain to generate the QI-Core profiles, rather than infer the QUICK model from the definition of the QI-Core profiles as is currently done.
In addition, the QI-Core effort is actively working with the QDM to produce a mapping from QDM to QI-Core such that a CQL-based artifact written with QDM as the model would be executable against a QI-Core compliant FHIR endpoint.
The following table lists the QI-Core profiles that are part of the IG, which USCore profile they are derived from, if any, and the underlying FHIR resources:
The QUICK Logical View of these profiles is provided here.
QI-Core profiles are indicated by the prefix "QICore-". For example, the QI-Core profile of Patient is named QICore-Patient.
QI-Core adds a variety of extensions to core FHIR classes. These extensions derive from two primary sources: the Quality Improvement Domain Analysis Model (QIDAM), and the Quality Data Model (QDM). Profile pages contain definitions of extensions and mappings to QDM as an aid for current users of QDM.
Certain elements in the QI-Core profiles have a "MustSupport" flag. In the QI-Core quality profiles, the MustSupport flag is used to indicate whether the element must be supported in QI implementations. More specifically, labelling an element as MustSupport means that quality improvement implementations SHALL understand and process the element.
In addition, only elements where MustSupport is true can be used in quality measure criteria or decision support condition and triggering logic. This is because if the logic references an element, the conclusion is not valid unless the exchanging system supports the elements being referenced by the logic.
Although support is not guaranteed, references to elements where MustSupport is false (or does not appear) in the QI-Core profile would be useful and should be provided. All elements in the QI-Core profiles, including those that are not MustSupport, can be used in CDS actions (i.e. right-hand side or consequents of CDS rules). For example, vaccination protocol in ImmunizationRecommendation is not a MustSupport element, so it cannot be used in a quality measure or as a criteria for triggering a CDS action. However, it can be filled in as part of the recommendation of a CDS application.
Although the element may be returned in a resource when the resource is retrieved from an EHR, no logical processing involving that data element can be expected. Note that the MustSupport flag does not imply that the element will always have a value, if the lower cardinality is zero. The only assurance associated with MustSupport is that the quality improvement application will try to retrieve the data and process it if the data allows.
Specific applications can modify the profiles and set MustSupport flags to true if they will process additional elements, but setting a MustSupport flag from true to false is noncompliant.
In summary, MustSupport elements represent the minimal set of data elements that must be supported in quality applications, defined as follows:
Is-Modifier is a boolean property of an element, indicating that the value of that element may change the interpretation of the resource. Examples of modifying elements include status (in many resources), negations (e.g. Immunization.wasNotGiven), and certainty qualifications (e.g. Observation.reliability). Decision support and quality implementations MUST always check the values of modifying elements. For example, in processing an Immunization resource, the application must inspect the "wasNotGiven" element to determine whether the immunization was given or was not given to the patient. For this reason, modifying elements SHALL be treated as MustSupport, even if not declared.
As an aside, inclusion of modifying elements is a departure from the previous (January 2014) informative version of the QI-Core profiles, where profiles were developed for each meaning of each modifying attribute. For example, the Condition resource was represented using two profiles, one representing the occurrence of the condition, and the other the non-occurrence of the condition. However, it was felt the proliferation of profiles under this approach would lead to a non-sustainable situation, particularly in light of the future need to expand QI-Core by incorporation of third-party profiles, such as those being developed by CIMI. The current approach requires quality improvement artifact authors to make explicit checks for modifying elements when dealing with classes that have modifying elements.
Uniformity in vocabularies and value sets enhances the interoperability of knowledge artifacts, but also forces data owners to translate local data into the required vocabulary. As a US Realm product, QI-Core requires value sets and vocabularies referenced in the ONC Common Clinical Data Set (CCDS) and the US Core Data for Interoperability. Because QI-Core is expected to be applied outside the U.S. Realm, and also in clinical settings where local terminologies exist, U.S. Realm bindings could be accompanied by alternative codes as translation codes in the QI-Core profiles. In the case that the US Core Data for Interoperability adopts QI-Core, QUICK, and CQL, policy should be created to mandate the preferred bindings given in the standard.
Note that 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 constrainted to a specific value set when used. For example, the code element of the MedicationRequest profile is bound to the complete value set for the RxNorm code system, indicating that all MedicationRequest 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.patient is a reference to a Patient resource. In QI-Core, most references are constrained to QICore-profiled resources. For example, QICore-Encounter.patient must point to a Patient resource that conforms to the QICore-Patient profile. Consequently, any extensions or bindings expected to exist in QICore-Patient are also present in the resource pointed to by Encounter.patient. References to QI-Core extensions accessed through references, such as Encounter.patient.veteranMilitaryStatus, are guaranteed to be valid. References to resources that do not currently have QI-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 QI-Core resource when there is one, and a FHIR core resource if there isn't." In QI-Core, the resources in "Any" references SHALL conform to QI-Core profiles if the base resource has been profiled.
Conformance to this QI-Core Implementation Guide requires the following (in addition to adherence to core FHIR requirements):
| Author Name |
|---|
| Bryn Rhodes (Editor) |
| Floyd Eisenberg (Primary) |
| Yan Heras (Supporting) |
| Robert Samples (Supporting) |
| Mark Kramer (Originator) |
| Jason Mathews (Originator) |
| Claude Nanjo (Originator) |
| Marc Hadley (Supporting) |
| Lloyd McKenzie (Supporting) |
| Chris Moesel (Supporting) |
| Jason Walonoski (Supporting) |
© HL7.org 2011+. Package hl7.fhir.us.qicore#3.2.0 based on FHIR v3.0.1-11917. Generated on 14/04/2019
Links: Search |
QA Page |
|
Propose a change