Quality Measure Implementation Guide (STU5)
5.0.0-ballot - ballot United States of America flag

This page is part of the Quality Measure STU2 for FHIR R4 Implementation Guide (v5.0.0-ballot: STU5 (v5.0.0) Ballot 1) based on FHIR (HL7® FHIR® Standard) R4. The current version which supersedes this version is 4.0.0. For a full list of available versions, see the Directory of published versions

Quality Measure Implementation Guide Homepage

Official URL: http://hl7.org/fhir/us/cqfmeasures/ImplementationGuide/hl7.fhir.us.cqfmeasures Version: 5.0.0-ballot
Active as of 2023-12-15 Computable Name: CQFMeasures

This STU 5.0.0-ballot is currently dependent on the QI-Core STU 6.0.0-ballot, but will update to QI-Core STU6 once published

Where possible, new and updated content are highlighted with green text and background

Note To Balloters

  1. We are seeking examples of non-patient subject composite measures for inclusion as examples in this implementation guide.

  2. We are requesting additional guidance on MeasureImprovementNotation:

    Reviewers: CQI will be adding the code:

    Reference range with definition of score within a defined interval (or a “passing score” over or under a certain threshold) indicates better quality to the improvement notation value set. Please provide comments on this additional code and if there are other codes needed in this value set.

    If an additional code is added to the improvement notation (like normative reference range as suggested), where is guidance about the reference range best included in the specification for implementer use? Some suggestions include: the guidance field, the rate aggregation field or adding an extension to improvementNotation to add text.

    valueset: MeasureImprovementNotation

The following resolutions have been voted on by the members of the sponsoring work group HL7 International Clinical Quality Information.

Comments and their resolutions

Listed below are the resolved trackers for this version:

Status: Summary:(Jira Issue)

  1. Applied: Reference to composites should address content as entity and not limit to patient (FHIR-35922)(Applied here), (here), (here), and (here)
  2. Applied: Make R4 CQFM Publishable CodeSystem profile compatible with R5 (FHIR-37371)(Applied here), (here), and (here)
  3. Applied: Notes to balloters improvement request (FHIR-39893)(Applied here)
  4. Applied: Update Dependency to US Core 6.0.0 (FHIR-39894)(Applied here)
  5. Applied: Hard to tell what is new content (FHIR-39895)(Applied here)
  6. Applied: ImprovementNotation Allowed Values (FHIR-42116)(Applied here), and (here)
  7. Applied: PLease add ‘Operations’ as a an options on the FHIR artifacts menu (FHIR-42715)(Applied here), and (here)
  8. Applied: Clarify ratio measure Numerator definition (FHIR-42826)(Applied here), and (here)
  9. Applied: Clarify or Correct Conformance Requirement 3.4 (FHIR-42894)(Applied here)
  10. Applied: Enable QMIG to Handle Population-based Measures (FHIR-42898)(Applied here), and (here)
  11. Applied: Allow for use of multiple expressions in a population (FHIR-42907) (Applied here)
  12. Applied: Level of Precision/Rounding and Unit of Measure (FHIR-42908)(Applied here), and (here)
  13. Applied: Add support for measure manifests in the quality program profile (FHIR-42920)(Applied here)
  14. Applied: Consider requiring the use of a SignatureLevel higher than none (FHIR-42922)(Applied here), (here), and (here)
  15. Applied: Does improvementNotation field need to allow for additional guidance? (FHIR-42976)(Applied here), and (here)
  16. Applied: Draft 2018 should be Active 2023 (FHIR-43039) Applied to numerous json files throughout IG in profiles and vocabulary
  17. Applied: Correct invalid json in StructureDefinition-cqfm-fhirQueryPattern.json (FHIR-43086)(Applied here)
  18. Applied: Allow multiple quality programs and bind value set as example (FHIR-43320)(Applied here) and (here)
  19. Applied: Correct short description about appliesTo extension (FHIR-43358)(Applied here)

Quality Measure Implementation Guide

Summary

The Fast Healthcare Interoperability Resource (FHIR) Quality Measure Implementation Guide (this IG) describes an approach to representing Quality Measures (QMs) using the FHIR Clinical Reasoning Module and Clinical Quality Language (CQL) in the US Realm. However, this Implementation Guide can be usable for multiple use cases across domains, and much of the content is likely to be usable outside the US Realm.

The implementation guide is based upon the previous generation of QM representation standards, the HL7 V3-based Health Quality Measure Format (HQMF) and accompanying implementation guides. As an HL7 FHIR Implementation Guide, changes to this specification are managed by the sponsoring Clinical Quality Information Work Group and are incorporated as part of the standard balloting process.

Examples

Refer to the QI-Core implementation guide for examples of how to represent data involved in calculation of quality measures.

How to read this Guide

This Guide is divided into several pages which are listed at the top of each page in the menu bar:

  • Home: The home page provides the summary and background information for the FHIR Quality Measure Implementation Guide
  • Introduction: The introduction provides a more detailed overview of quality measurement and the background for this guide
  • QMs: This page describes measure representation and conformance requirements for QMs
  • Using CQL: This page covers using Clinical Quality Language to author QMs
  • Composites: This page covers composite measure representation and conformance requirements
  • Packaging: This page describes measure packaging and distribution requirements for QMs Measures IG
  • Profiles: This page lists the set of profiles defined for use by QMs
  • Extensions: This page lists the set of extensions defined for use by QMs
  • Terminology: This page lists value sets and code systems defined in this IG
  • Capabilities: This page defines services and operations in support of authoring, publishing, and distributing QMs
  • Operations: This page defines services and operations in support of authoring, publishing, and distributing QMs
  • Examples: This page provides examples used in the other pages, as well as by the Data Exchange for Quality
  • Glossary This page defines terms related to quality measurement.
  • Downloads: This page provides links to downloadable artifacts for implementations.
  • Acknowledgements

Background

Quality Improvement Ecosystem

As shown in step 1 in the diagram below, the Quality Improvement Ecosystem begins with information, preferably evidence-based from research, public health surveillance, and data mining and other analyses performed by third parties such as academic institutions or payers. Such information indicates existing status and knowledge about a given clinical topic. In step 2, stakeholders, such as professional societies, public health agencies, and governmental bodies, publish such information to assure awareness among consumers, healthcare practitioners, and healthcare organizations about what is known and suggested methods for managing the clinical topic. Ideally, suggested management efforts are captured and documented in guidelines based on collaboration among clinical subject matter experts, terminologists, informaticists, clinicians and consumers. In step 3, these clinical guidelines are translated into clinical decision support (CDS) artifacts to incorporate relevant, evidence based, and patient-specific clinical recommendations and actions directly within clinical workflow. To adequately impact clinical care for clinicians and patients requires local implementation activities as shown in Step 4. CDS is not intended to replace clinician judgment, but rather to provide information to assist care team members in managing the complex and expanding volume of biomedical and person-specific data needed to make timely, informed, and higher quality decisions based on current clinical science. Ideally, the clinical guidelines and CDS include methods for evaluating what successful implementation means, (i.e., whether the clinical care ultimately provided included processes that addressed the intent of the guideline and if it achieved the desired outcomes). Further information on CDS and its optimization of care delivery can be found here. In step 5, to close the loop and enable continuous improvement, the results of such measurement analytics must be reported for aggregate review. Step 6, “Reporting” serves the purpose of evaluating clinical performance and outcomes, whether it be internally for health care organizations, or for third parties such as public health or for payers. Ultimately, this information may then serve as part of the evidence base shown in step 1.

Figure 1-1: The Quality Improvement Ecosystem Diagram
Export_new.png

Practictioner organizations along with stakeholders such as public health have ongoing needs for quality improvement at the point of care. Every effort should be made to establish a capable distributed rule processing environment in FHIR. For additional information about idealized processes for moving evidence and information from guidelines to CDS and measurement, refer to an effort by the Centers for Disease Control and Prevention (CDC) called Adapting Clinical Guidelines for the Digital Age.

Quality Measurement Standards Landscape

This implementation guide is part of a larger FHIR-based quality improvement and quality measurement standards landscape, depicted in the following diagram:

Figure 1-2: The Quality Measurement Standards Landscape Diagram
quality-measurement-standards-landscape.png

The left side of the quality measurement standards landscape diagram depicts the activities and standards associated with measure specification, while the right side depicts measure reporting. Stakeholders and the roles they play are represented by the three rounded rectangles in the foreground. Note that the lists are representative of typical stakeholders, but that a single stakeholder may play any or all of the roles in this diagram. For example, an institution specifying its own measures for internal use would be the Producer, Consumer, and Specifier.

Quality measure (or performance measure) is a numeric quantification of healthcare quality for a designated accountable healthcare entity, such as hospital, health plan, nursing home, clinician, etc. A healthcare performance measure is a way to calculate whether and how often the healthcare system does what it should. Measures are based on scientific evidence about processes, outcomes, perceptions, or systems that relate to high-quality care. Source

Measure specification involves the end product of the measure development process, a precisely specified, valid, reliable, and clinically significant measure specification to support accurate data representation and capture of quality measures. Clinical Quality Measures (CQMs) are tools that help measure and track the quality of health care services provided in care delivery environments, including eligible clinicians (ECs), eligible hospitals (EHs), and critical access hospitals (CAHs). Measuring and reporting CQMs helps to ensure that our health care system is delivering effective, safe, efficient, patient-centered, equitable, and timely care. CQMs measure many aspects of patient care, including patient and family engagement, patient safety, care coordination, public health, population health management, efficient use of healthcare resources, and clinical process and effectiveness. For more information on the basics of Clinical Quality Measures, see Clinical Quality Measures Basics. Before Electronic Health Record (EHR) systems, chart-abstracted CQMs were predominant. Modern EHR systems enable electronic CQMs, or eCQMs.

Measure reporting involves the data collection and aggregation, calculation and analytics, and ultimately reporting of quality measures. Measure reporting may be accomplished in different ways at various levels of the healthcare delivery system, from individual providers attesting to specific quality measures as part of federally-regulated healthcare quality initiatives, to provider organizations reporting to healthcare plans as part of payer quality improvement activities, to institutions reporting on the quality of their own healthcare delivery.

Stakeholders in the quality space, represented by the three rounded rectangles in the foreground of the above diagram, fall into three broad categories:

  1. Data Producers in the diagram represent the various stakeholders involved in the de novo creation of healthcare data. Data Producers can include providers and provider systems; patients, care teams, caregivers, and patient engagement systems; and other related clinical systems such as laboratory, clinic, and hospital information systems that are primary producers of patient healthcare information.

  2. Data Consumers in the diagram represent the various stakeholders involved in the consumption and use of healthcare data. Data Consumers can include data routers and aggregators, payers, health information exchanges and health integrated networks, as well as public health, registries, and other healthcare-related agencies.

  3. Specifiers in the diagram represents the various stakeholders involved in the specification of quality measures for use in healthcare quality measurement and reporting. Specifiers can include quality agencies, public health, and other healthcare-related agencies, industry consortiums concerned with improving care quality, and clinical professional societies. Specifiers may also be institutions and clinics using the quality measurement standards to specify quality measures for use in their own environments and quality improvement initiatives.

The shaded areas underlying the stakeholders depict the various standards involved (see Clinical Quality Framework for more information).

Fast Healthcare Interoperability Resources (FHIR)

Fast Healthcare Interoperability Resources, or FHIR, is a Health Level 7 (HL7) platform specification for healthcare that supports exchange of healthcare information between systems. FHIR is universally applicable, meaning that it can be used in a broad variety of implementation environments. The platform provides layers of implementation that support foundational protocols; base implementation functionality such as conformance and terminology; administrative functionality to represent patients, care teams, locations, and organizations; healthcare processes including clinical and diagnostic information, as well as medication, workflow, and financial; and finally, a clinical reasoning layer that provides support for the representation of knowledge and reasoning about healthcare.

The quality measurement standards landscape makes use of all these layers of FHIR: the foundational and implementation layers to define interactions and profiles; the administrative and process layers to represent the data of interest for quality measurement; and the clinical reasoning layer to specify and support evaluation and reporting of quality measures.

Clinical Quality Language (CQL)

Clinical Quality Language, or CQL, is an HL7 cross-paradigm specification that defines a high-level, domain-specific language focused on clinical quality and targeted for use by measure and decision support artifact authors. In addition, the specification describes a machine-readable canonical representation called Expression Logical Model (ELM) targeted at implementations and designed to facilitate sharing and evaluation of clinical knowledge.

This ability to render clinical knowledge in a high-level human-readable form as well as an intermediate-level, platform-independent machine-readable form makes CQL an ideal mechanism for specifying the criteria involved in quality measures.

FHIR Quality Measure Implementation Guide

The FHIR Quality Measure Implementation Guide (this IG) defines conformance profiles and guidance focused on the specification of quality measures using the FHIR Measure and Library resources. The IG does not standardize the content of any particular measure, rather it defines the standard approach to the representation of that content so that quality measure specifiers can define and share standardized FHIR-based electronic Clinical Quality Measures (eCQMs).

Quality Improvement Core Implementation Guide (QI-Core)

The Quality Improvement Core Implementation Guide, or QI-Core, defines a set of FHIR profiles with extensions and bindings needed to create interoperable, quality-focused applications. Importantly, the scope of QI-Core includes both quality measurement and decision support to ensure that knowledge expressed can be shared across both domains. QI-Core is derived from US Core, meaning that where possible, QI-Core profiles are based on US Core to ensure alignment with and support for quality improvement data within healthcare systems in the US Realm.

Data Exchange for Quality Measures (DEQM)

The Data Exchange for Quality Measures Implementation Guide, or DEQM, provides a framework that defines conformance profiles and guidance to enable the exchange of quality information and quality measure reporting (e.g. for transferring quality information from a health care provider to a payer). The DEQM expects to use quality measures specified in accordance with the Quality Measure IG and QI-Core.

Data Model Standards Landscape

The quality improvement ecosystem covers every aspect of the healthcare delivery system, and needs to be able to represent information across that entire spectrum. FHIR provides a foundation for representation of this information in a universally applicable way. In particular cases, more specificity is required to capture the intended meaning of healthcare information. As FHIR is more and more broadly adopted, consensus among participating stakeholders on the use of particular profiles and patterns enables semantic interoperability for more use cases.

Within the US Realm, US Core profiles comprise this base consensus, and although it enables a variety of interoperability use cases, the profiles do not represent all of the requirements for quality improvement. The QI-Core profiles are derived from US Core and provide this additional functionality.

There are occasional instances where additional specificity or functionality is required explicitly for quality measurement, or a particular component within a quality measure. In these cases, additional profiles are defined within the changes DEQM, or by stakeholders such as measure developers or implementers. A general example of this could be the development of profiles for specific measures, such as the ones that reference the Healthcare Effectiveness Data and Information Set (HEDIS) Implementation Guide (currently no link available).

The following diagram depicts this data model standards landscape:

Figure 3: The Data Model Standards Landscape Diagram
data-model-standards-landscape.png

As illustrated, FHIR provides the foundation, and sets of profiles are built on top of FHIR that provide more and more focused use cases by constraining profiles and extending functionality to cover gaps. While the additional layers are necessary to represent specific operations and provide space for agreement among relevant stakeholders, the consensus-based standards development process is used to suggest changes to the layers below, resulting in an ever-broadening umbrella of interoperability.

This layering of profiles balances the relative adoption and implementation maturity of FHIR and the data representation requirements of the use cases involved, guided by the following principles:

  1. Avoid proliferation of profiles. To the extent possible, make use of existing profiles at the lowest level of the stack, only defining a new profile if absolutely necessary to express a requirement for a particular use case that cannot be represented by an existing one.
  2. Share profiles across measures. There should not be profiles specific to any particular measure. Instead, QI Core provides a layer for the expression of quality improvement requirements across measures and decision support artifacts.
  3. No terminology-narrowing-only profiles. Profiles should not be used to specify only terminology narrowing constraints. The FHIR Clinical Reasoning module and CQL enable the representation of data requirements for quality measures and decision support artifacts.
  4. Promote data-related profiles. When it becomes necessary to define a data-related profile at the measurement-specific level (in DEQM or HEDIS for example), steps should be taken to promote that profile to the broadest consensus group possible.
1.3.3.1 FHIR Version Support

There are three broadly used and fully published versions of the FHIR specification:

  • FHIR DSTU2 - This version has broad support among US-based vendors as it is the basis for the Argonaut profiles. Most major vendors today support some subset of this version of FHIR
  • FHIR STU3 - This is the version that US Core, QI Core, and many other implementation guides are based on. There is broad vendor support for this version.
  • FHIR R4 - This is the first normative release of FHIR, including several of the foundational, conformance, and administrative resources going normative.

In addition to what data is reported, use cases frequently require the communication of when, where and how to report. See the Electronic Case Reporting (eCR) implementation guide for a more complete discussion of these design considerations. We are actively seeking feedback from implementers how this type of information is currently communicated in quality reporting scenarios and when it would be useful to do so electronically.

References

Centers for medicare & medicaid. Clinical Quality Measures Basics. [Online]. Available from: https://www.cms.gov/Regulations-and-Guidance/Legislation/EHRIncentivePrograms/ClinicalQualityMeasures.html [Accessed 11 October 2019].

Centers for disease control and prevention. Adapting Clinical Guidelines for the Digital Age. [Online]. Available from: https://www.cdc.gov/ddphss/clinical-guidelines/index.html [Accessed 11 October 2019].

Health level seven. Clinical Quality Framework - HL7 Clinical Quality Information Work Group Confluence Page. [Online]. Available from: https://confluence.hl7.org/display/CQIWC/Clinical Quality Framework [Accessed 11 October 2019].

Dependencies

The dependency on QI-Core is included for the purposes of example validation only. In addition the dependency on VSAC packages is indirect via the QI Core and US Core. The conformance profiles in this IG do not make use of the value sets in VSAC.

IGPackageFHIRComment
.. Quality Measure Implementation Guide (STU5)hl7.fhir.us.cqfmeasures#5.0.0-ballotR4
... FHIR Extensions Packhl7.fhir.uv.extensions.r4#1.0.0R4Automatically added as a dependency - all IGs depend on the HL7 Extension Pack
... Clinical Quality Framework Common FHIR Assetsfhir.cqf.common#4.0.1R4
.... Clinical Practice Guidelineshl7.fhir.uv.cpg#1.0.0R4
... QI-Core Implementation Guidehl7.fhir.us.qicore#6.0.0-ballotR4
.... HL7 Terminology (THO)hl7.terminology.r4#5.0.0R4
.... US Core Implementation Guidehl7.fhir.us.core#6.1.0R4
..... Bulk Data Access IGhl7.fhir.uv.bulkdata#2.0.0R4
..... SMART App Launchhl7.fhir.uv.smart-app-launch#2.1.0R4
..... us.nlm.vsac#0.10.0R4
..... Structured Data Capturehl7.fhir.uv.sdc#3.0.0R4
...... FHIR R4 package : Exampleshl7.fhir.r4.examples#4.0.1R4
..... us.cdc.phinvads#0.12.0R4
..... IHE FormatCode Vocabularyihe.formatcode.fhir#1.1.0R4
.... fhir.dicom#2023.3.20230704R4
... HL7 Terminology (THO)hl7.terminology#5.4.0R4

Package hl7.fhir.uv.extensions.r4#1.0.0

This IG defines the global extensions - the ones defined for everyone. These extensions are always in scope wherever FHIR is being used (built Sun, Mar 26, 2023 08:46+1100+11:00)

Package hl7.fhir.uv.cpg#1.0.0

Implementation guidance for creating Clinical Practice Guidelines with formal artifacts to facilitate sharing and implementation of the guideline (built Thu, Feb 11, 2021 20:29+0000+00:00)

Package fhir.cqf.common#4.0.1

This implementation guide contains common FHIR assets for use in CQFramework content IGs, including FHIRHelpers and the FHIR-ModelInfo libraries. (built Fri, Nov 12, 2021 16:25+1100+11:00)

Package hl7.fhir.uv.bulkdata#2.0.0

FHIR based approach for exporting large data sets from a FHIR server to a client application (built Fri, Nov 26, 2021 05:56+1100+11:00)

Package hl7.fhir.r4.examples#4.0.1

Example resources in the R4 version of the FHIR standard

Package hl7.fhir.uv.sdc#3.0.0

The SDC specification provides an infrastructure to standardize the capture and expanded use of patient-level data collected within an EHR.
This includes two components:
* Support more sophisticated questionnaire/form use-cases such as those needed for research, oncology, pathology and other clinical domains.
*Support pre-population and auto-population of EHR data into forms/questionnaires for uses outside direct clinical care (patient safety, adverse event reporting, public health reporting, etc.). (built Tue, Mar 8, 2022 18:32+0000+00:00)

Package ihe.formatcode.fhir#1.1.0

Implementation Guide for IHE defined FormatCode vocabulary. (built Thu, Feb 24, 2022 16:55-0600-06:00)

Package hl7.fhir.us.core#6.1.0

The US Core Implementation Guide is based on FHIR Version R4 and defines the minimum conformance requirements for accessing patient data. The Argonaut pilot implementations, ONC 2015 Edition Common Clinical Data Set (CCDS), and ONC U.S. Core Data for Interoperability (USCDI) v1 provided the requirements for this guide. The prior Argonaut search and vocabulary requirements, based on FHIR DSTU2, are updated in this guide to support FHIR Version R4. This guide was used as the basis for further testing and guidance by the Argonaut Project Team to provide additional content and guidance specific to Data Query Access for purpose of ONC Certification testing. These profiles are the foundation for future US Realm FHIR implementation guides. In addition to Argonaut, they are used by DAF-Research, QI-Core, and CIMI. Under the guidance of HL7 and the HL7 US Realm Steering Committee, the content will expand in future versions to meet the needs specific to the US Realm. These requirements were originally developed, balloted, and published in FHIR DSTU2 as part of the Office of the National Coordinator for Health Information Technology (ONC) sponsored Data Access Framework (DAF) project. For more information on how DAF became US Core see the US Core change notes. (built Thu, Jun 29, 2023 19:17+0000+00:00)

Package hl7.fhir.us.qicore#6.0.0-ballot

The QICore 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. (built Thu, Aug 3, 2023 13:01+0000+00:00)

Cross Version Analysis

This is an R4 IG. None of the features it uses are changed in R4B, so it can be used as is with R4B systems. Packages for both R4 (hl7.fhir.us.cqfmeasures.r4) and R4B (hl7.fhir.us.cqfmeasures.r4b) are available.

Global Profiles

Global Profiles:

TypeSourceProfile
Encounterhl7.fhir.us.qicore#6.0.0-ballotQICore Encounter
Encounterhl7.fhir.us.qicore#6.0.0-ballotQICore Encounter
Immunizationhl7.fhir.us.qicore#6.0.0-ballotQICore Immunization
Immunizationhl7.fhir.us.qicore#6.0.0-ballotQICore Immunization
Observationhl7.fhir.us.qicore#6.0.0-ballotQICore Simple Observation
Observationhl7.fhir.us.qicore#6.0.0-ballotQICore Simple Observation
Organizationhl7.fhir.us.qicore#6.0.0-ballotQICore Organization
Organizationhl7.fhir.us.qicore#6.0.0-ballotQICore Organization
Patienthl7.fhir.us.qicore#6.0.0-ballotQICore Patient
Patienthl7.fhir.us.qicore#6.0.0-ballotQICore Patient
Practitionerhl7.fhir.us.qicore#6.0.0-ballotQICore Practitioner
Practitionerhl7.fhir.us.qicore#6.0.0-ballotQICore Practitioner
PractitionerRolehl7.fhir.us.qicore#6.0.0-ballotQICore PractitionerRole
PractitionerRolehl7.fhir.us.qicore#6.0.0-ballotQICore PractitionerRole

All resources of these types must conform to these profiles.

IP Statements

This publication includes IP covered under the following statements.