This page is part of the Quality Measure STU2 for FHIR R4 Implementation Guide (v0.1.0: STU 1 Ballot 1) based on FHIR R3. The current version which supercedes this version is 3.0.0. For a full list of available versions, see the Directory of published versions

1 Introduction

1.1 Purpose

The National Academy of Medicine (NAM) defines quality as: “The degree to which health services for individuals and populations increase the likelihood of desired health outcomes and are consistent with current professional knowledge.” ¹ For care quality to be evaluated, it must be standardized and communicated to the appropriate organizations. To that end, this Implementation Guide has been written to provide guidance for authoring electronic clinical quality measures (eCQMs), clinical quality measures specified in a standard electronic format and designed to use structured, encoded data present in the electronic health record.² This implementation guide references the following standards for creating eCQMs:

• Fast Healthcare Interoperability Resources (FHIR) STU3 ³
• Clinical Quality Language (CQL) R1.4 ⁴
• QI-Core Implementation Guide (QI-Core) R3.2 ⁵

To avoid variation in the use of FHIR Resources and metadata consistently across eCQMs and clinical decision support (CDS), a quality-related implementation guide based on a logical data model is essential. In the US Realm, eCQM developers should use FHIR Quality Improvement Core (QICore) and Quality Improvement Clinical Knowledge (QUICK) as the data model to maintain consistency.

Although the specification is based on the 1.4 version of CQL, backwards-compatible future versions of CQL can be used as well. In addition, if necessary, the 1.2 and 1.3 versions of CQL can be used without loss of functionality for this Implementation Guide.

Note that this implementation guide is based on FHIR STU3, as that is the first version with the Clinical Reasoning module, which provides the necessary support for representing and reporting quality measures. Future versions of this implementation guide will address the use of R4 and later versions of FHIR.

Except where noted, material from the base FHIR specification, and in particular the Clinical Reasoning module, is not repeated here.

As features and functionality are identified by this implementation guide that apply more broadly, those features may be promoted to the base FHIR specification.

1.2 Structure of this Guide

This implementation guide is structured as follows:

1. Introduction - This section, providing narrative introduction and background material
2. Measure Conformance - Provides detailed guidance and conformance requirements for measures
3. Composite Measures - Discusses composite measure calculation and representation approaches
4. Using CQL - Provides guidance and conformance requirements for the use of CQL within measures

In addition, there are appendices for examples, references, acknowledgements, and a glossary.

1.3 Audience

The audience for this IG includes software developers of measure authoring tools such as the US Centers for Medicare and Medicaid Services (CMS) Measure Authoring Tool (MAT); measure developers who will specify clinical quality measures using FHIR and CQL; software developers and implementers who will implement the quality measures specified in FHIR and CQL in their institutions or in their vendor products; institutions and organizations who wish to use FHIR and CQL to express and implement quality measures within their health systems; and local, regional, and national quality reporting agencies who wish to receive and process quality reporting documents that are based on measures specified in FHIR and CQL.

1.4 Approach

The approach taken here is consistent with balloted IGs for FHIR. These publications view the ultimate implementation specification as a set of formal artifacts, including profiles, extensions, and terminologies. The base FHIR specification provides for the representation of quality measures using the Measure resource, as well as guidance on quality reporting within the Clinical Reasoning module. IGs such as this add constraints to the base resources and guidance through profiles and conformance requirements that further define and restrict the sequence and cardinality of elements in the FHIR resources and the vocabulary sets for coded elements.

This IG is STU1 of the FHIR Quality Measure IG. Section 1.8 describes the development of this STU.

1.5 Scope

This IG is a conformance profile, as described in the “Conformance” ⁶ section of the HL7 FHIR specification. The base resource for this IG is the HL7 FHIR Measure and Library resources and associated guidance within the Clinical Reasoning module. This IG does not describe every aspect of quality reporting in FHIR. Rather, it defines profiles and constraints on the base Measure and Library resources used in a FHIR Quality Measure. Additional optional Measure and Library elements, not included here, can be included and the result will be compliant with the specifications in this guide. The FHIR Clinical Reasoning module provides resources and universally applicable guidance for reporting quality measurement results, and the Data Exchange for Quality Measures Implementation Guide ⁷ provides additional guidance and use cases related to quality reporting.

1.6 Conventions

The keywords SHALL, SHALL NOT, SHOULD, SHOULD NOT, MAY, and NEED NOT in this document are to be interpreted as defined in RFC 2119. Unlike RFC 2119, however, this specification allows that different applications may not be able to interoperate because of how they use optional features. In particular

• SHALL: an absolute requirement for all implementations
• SHALL NOT: an absolute prohibition against inclusion for all implementations
• SHOULD/SHOULD NOT: a best practice or recommendation to be considered by implementers within the context of their particular implementation; there may be valid reasons to ignore an item, but the full implications must be understood and carefully weighed before choosing a different course
• MAY/NEED NOT: truly optional; can be included or omitted as the implementer decides with no implications

1.7 Background

This Implementation Guide (IG) defines an approach to using CQL with the FHIR Measure and Library resources for specifying quality measures. The guidance here is drawn from the FHIR Clinical Reasoning Module ⁸, as well as the CQL-Based HQMF IG.

This Implementation Guide is the successor of the CQL-based HQMF IG STU4 (Figure 2a).

Figure 2: Relationship between QDM based and CQL based HQMF IG’s.

Note that the QI Core implementation guide includes an author-focused view of QI Core called QUICK. This view provides a conceptual model for the development of quality improvement artifacts such as decision support rules and quality measures. However, although the authoring view is available, implementation tooling and guidance is still being developed to fully support the use of QUICK. Until this tooling is available, this implementation guide uses the QI Core profiles directly.

1.7.1 Clinical Quality Language R1.4

Clinical Quality Language R1.4 (CQL) is an HL7 standard for trial use (STU) ⁴. It is part of the effort to harmonize standards between electronic clinical quality measures (eCQMs) and clinical decision support (CDS). CQL provides the ability to express logic that is human readable yet structured enough for processing a query electronically.

1.7.2 CQL based HQMF IG R1 STU3

The first version of the CQL-based HQMF IG was released in September 2015 and was intended to be used in conjunction with the pre-existing QDM based HQMF R1 IG. Since 2015, the community and the standards evolved and the current version of QDM (v5.4) no longer contains expression logic, ceding this functionality to CQL. The CQL-based HQMF IG is the sole guide describing how to use QDM, CQL, and HQMF in combination (Figure 2a).

A result of replacing QDM-based logic with CQL is that all QDM logic elements previously encoded in HQMF were replaced with CQL. This means that QDM data criteria specify only the data of interest (e.g. value sets, effective time, properties) for the eCQM, and the previous use of QDM expressions that captured interrelationships between data criteria (such as “starts after end of”) or identified subsets of data (such as min, max, last, and first) are now represented with CQL expressions. This IG documents the full approach in detail starting in Chapter 2.

This implementation guide, the FHIR Quality Measure IG, covers the use of FHIR, CQL, FHIR QI-Core and QUICK, and other emerging approaches to define eCQMs.

1.7.3 HQMF

HQMF is a structured document markup standard* “…for representing a health quality measure as an electronic document. A quality measure is a quantitative tool to assess the performance of an individual or organization’s performance in relation to a specified process or outcome via the measurement of an action, process, or outcome of clinical care. Quality measures are often derived from clinical guidelines and are designed to determine whether the appropriate care has been provided given a set of clinical criteria and an evidence base.” ^{8 9}

HQMF is now a normative HL7 V3 based standard that defines a header for classification and management of the quality measure as well as important metadata. HQMF also defines a document body that carries the content of the quality measure. It standardizes a measure’s structure, metadata, definitions, and logic, the HQMF ensures measure consistency and unambiguous interpretation.

The FHIR Clinical Reasoning module replaces HQMF by defining the Measure resource.

1.7.4 Quality Reporting Document Architecture (QRDA)

Quality Reporting Document Architecture (QRDA)¹⁰ is an HL7 Standard that supports quality reporting at the patient level (referred to as a Category I QRDA document), and the summary level (referred to as a Category III QRDA) document. The aspects of QRDA related to reporting results are captured in the MeasureReport resource, while the aspects of QRDA representing patient information are captured by QI Core. The FHIR Clinical Reasoning module replaces QRDA by defining the MeasureReport structure, and the Data Exchange for Quality Measures implementation guide⁷ provides implementation guidance for measure reporting.

References