STU 3 Candidate
This page is part of the FHIR Specification (v1.4.0: STU 3 Ballot 3). The current version which supercedes this version is 5.0.0. For a full list of available versions, see the Directory of published versions 
The Clinical Quality Language (CQL) standard aims to unify the expression of logic for electronic Clinical Quality Measures (eCQM) and Clinical Decision Support (CDS). This document defines an approach to using CQL with Fast Health Interoperability Resources (FHIR) DSTU2 for defining eCQMs.
This Implementation Guide (IG) specifies how the Clinical Quality Language (CQL) is used in conjunction with the Quality Improvement Core (QICore) FHIR profiles to define and invoke clinical quality measures.
This approach supercedes previous approaches to representing eCQMs using the Health Quality Measure Format (HQMF).
The Measure resource builds on the general approach to representing knowledge artifacts and adds the metadata and structure information that is specific to quality measures:
Quality measures follow a generally hierarchical structure that defines:
Population Groups: Groups of population criteria that define a particular focus of measurement. A given measure may include any number of population groups, each with different criteria for the various measure components.
The following table provides a requirements mapping from the content of an eMeasure to the elements defined in the Measure resource:
| eMeasure | Cardinality | Element | Notes |
|---|---|---|---|
| Title | 0..1 | moduleMetadata.title | |
| Identifier | 0..1 | moduleMetadata.identifier | identifier type code as http://hl7.org/fhir/cqi/ecqm/MeasureArtifact/Identifier/cms |
| Version Number | 0..1 | moduleMetadata.version | |
| NQF Number | 0..1 | moduleMetadata.identifier | identifier type code as http://hl7.org/fhir/cqi/ecqm/MeasureArtifact/Identifier/nqf |
| GUID | 0..1 | moduleMetadata.identifier | identifier type code as http://hl7.org/fhir/cqi/ecqm/MeasureArtifact/Identifier/guid |
| Measure Steward | 0..1 | moduleMetadata.publisher | |
| Measure Developer | 0..1 | moduleMetadata.contributor | type.code of author |
| Endorser | 0..1 | moduleMetadata.contributor | type.code of endorser |
| Description | 0..1 | moduleMetadata.description | |
| Copyright | 0..1 | moduleMetadata.copyright | |
| Reference | 0..* | moduleMetadata.relatedResource | type.code of citation |
| Disclaimer | 0..1 | disclaimer | String (containing Markdown) |
| Measure Scoring | 0..1 | scoring | Code, e.g. proportion, CV |
| Measure Type | 0..1 | type | Code, e.g. process, outcome |
| Risk Adjustment | 0..1 | riskAdjustment | String |
| Rate Aggregation | 0..1 | rateAggregation | String |
| Rationale | 0..1 | rationale | String (containing Markdown) |
| Clinical Recommendation Statement | 0..1 | clinicalRecommendationStatement | String (containing Markdown) |
| Improvement Notation | 0..1 | improvementNotation | String, e.g. Higher score indicates better quality |
| Definition | 0..1 | definition | String (containing Markdown) |
| Guidance | 0..1guidance | String (containing Markdown) | |
| Measure Set | 0..1 | set | String, e.g. Preventive Care and Screening |
As with other knowledge artifacts, logic is included by referencing a Library resource. Although the base resource allows for the measure to reference any number of libraries, for simplicity of managing sharing, this implementation guide requires that a measure reference only one Library, the primary measure library, and that this library contain all the named expressions required to define the measure structure.
Note that this restriction does not preclude sharing of logic between measures, it only requires that that sharing be explicitly done as dependencies within the referenced libraries, rather than allowing a measure.
A measure can specify various types of populations, depending on the type of measure scoring being used. The following table shows which population criteria types are required (R), optional (O), or not permitted (NP) for proportion, ratio, and continuous variable measures. This table is adapted from Table 1 from the HQMF DSTU Release 2 specification, and Table 2.1 from the QDM-based HQMF IG.
| MeasureType | Initial Population | Denominator | Denominator Exclusion | Denominator Exception | Numerator | Numerator Excxlusion | Measure Population | Measure Population Exclusion | Measure Score |
|---|---|---|---|---|---|---|---|---|---|
| Proportion | R | R | O | O | R | O | NP | NP | O |
| Ratio | R | R | O | NP | R | O | NP | NP | O |
| Continuous Variable | R | NP | NP | NP | NP | NP | R | O | O |
| Cohort | R | NP | NP | NP | NP | NP | NP | NP | NP |
For quality measures that contain multiple populations, the criteria are specified once for each group. The group element contains an identifier that is used to uniquely identify the group within the measure, as well as within the quality reporting results.
Continuous variable measures may include a measure observation section. This section defines variables (for example, time from check-in to time of antibiotic administration) used to score particular aspects of performance. Measure observations are not population criteria in that they do not determine whether or not a patient is to be counted in a measure. Rather, measure observations are data elements to be collected on patients meeting the population criteria within a continuous variable measure.
Stratifiers and supplemental data are specified using the stratifier and supplementalData elements of the Measure resource. Stratification criteria are specified either as a reference to a CQL named expression within a Library (e.g. CMS146.AgesUpToNine), or as FHIR resource paths (e.g. Patient.gender). When the stratification criteria is an expression, the stratification will yield as many result groups as the expression returns. For example, if the expression returns a boolean, then there would be two stratification groups: true and false. When the stratification criteria is a FHIR resource path, there will be as many stratification groups as possible values for the resource path. For example, specifying Patient.gender will yield four stratification groups since FHIR has four gender codes: male, female, other, and unknown.
Supplemental data elements are also specified using FHIR resource paths, and the number of resulting groups for supplemental data is determined in the same way.
The data criteria for the primary library defines the patient data of interest in the measure as a set of DataRequirements. Each data requirement identifies specific types of data along with constraints that the data must meet. For example, one data requirement for CMS 146 identifies FHIR Condition resources that represent confirmed diagnoses of acute pharyngitis. Other data requirements for this measure include Encounters, DiagnosticReports and other FHIR resources representing specific data that is used to calculate the measure.
Specifying the data criteria in this way enables the following use cases:
The Health Quality Measure Format (HQMF) defines the electronic representation of an eMeasure but does not define a mechanism for invoking an eMeasure. FHIR defines both the representation of resources and a general mechanism for interacting with them via the OperationDefinition resource. Prior sections of this specification described the MeasureArtifact representation of an eMeasure, this section describes the evaluateMeasure operation that is used to invoke an eMeasure and obtain the results.
FHIR defines a standard set of common interactions that include read, update, delete and search. In addition, FHIR defines a standard set of extended operations that can be performed on resources, resource types and system wide. The standard operations include profile validation, concept translation and value set expansion. FHIR also supports custom operations via the FHIR OperationDefinition resource. This resource offers a means to create a formal definition of a custom operation that can be performed on a FHIR server. For the purposes of measure evaluation we define a new custom operation with a code of $evaluate-measure.
The $evaluate-measure operation has the following properties:
The effect of invoking the $evaluate-measure operation is to calculate the quality measure according to the supplied parameters and to return a MeasureReport resource through which the results will be made available. As described below in Section 5, measure calculation may not be instantaneous and the MeasureReport resource provides a mechanism to handle long running calculations.
GET [base]/Basic/$evaluate-measure?measure=CMS146&periodStart=2014&periodEnd=2014 GET [base]/Basic/CMS146/$evaluate-measure?periodStart=2014&periodEnd=2014
The above examples show how to obtain the results of evaluating the eMeasure with identifier "CMS146" for all patients over a measurement period that consists of all of 2014. Some items of note:
The next example demonstrates how to obtain the results of evaluating the eMeasure with identifier "CMS146" for the patient with identifier "124" over a measurement period that consists of the first three months of 2014.
GET [base]/Basic/CMS146/$evaluate-measure?patient=124&periodStart=2014-01&periodEnd=2014-03
When eCQMs are represented with the Health Quality Measure Format (HQMF), a single HQMF document represnts both the measure itself and the request. Meanwhile, the responses are represented as Quality Reporting Document Architecture (QRDA) documents. QRDA documents come in three flavors: Category I for individual patient reports, Category II for patient list reports, and Category III for population reports.
When eCQMs are represented with FHIR resources, the measure is represented as a Measure resource, and the request is an HTTP GET conforming to the OperationDefinition described above. Meanwhile, the responses are represented as MeasureReport resources. Like QRDA, the MeasureReport allows for Category I (individual), Category II (patient-list), and Category III (population) reports.
A MeasureReport will contain one group of data for each group specified in the corresponding Measure, consisting of a set of population elements, one for each criteria defined in each group.
In addition, each group will contain stratifiers with a value stratum for each value defined by the stratifier criteria, for each criteria defined in the measure, as well as supplemental data value groups for each supplemental data element.
When using a MeasureReport resource to represent the results of an individual calculation, the MeasureReport SHALL have a type-code of "individual" and SHALL have a reference to a patient that is the subject of the report. In addition, the result SHOULD include a reference to a Bundle containing the patient-specific resources that were used to calculate the result.
When using a MeasureReport resource to represent a patient-list, the MeasureReport SHALL have a type-code of "patient-list" and SHALL NOT have a reference to a patient. Instead, the resource SHALL include for each population a reference to a List resource that references individual level MeasureReport resources for the same measure, one for each patient in the overall population.
For example, the initial population report, in addition to providing the count, provides a reference to a List resource that identifies each of the patients that make up that population. For each of those patients, the List will contain a reference to an individual-level report for that patient.
© HL7.org 2011+. FHIR STU3 Candidate (v1.4.0-8139) generated on Thu, Mar 31, 2016 08:10+1100. QA Page
Links: Search |
Version History |
Table of Contents |
Compare to DSTU2 |
|
Propose a change