FHIR CI-Build

This is the Continuous Integration Build of FHIR (will be incorrect/inconsistent at times).
See the Directory of published versions icon

Work Group Clinical Quality Information iconMaturity Level: 5Standards Status: Trial Use

Note that throughout this section, the following terms are used:

  • Measure (capitalized) refers to a FHIR Measure resource
  • Quality measure, or QM, refers to a measure at the conceptual level
  • Quality measure specification, or QMS, refers to a published measure specification with a defined owner/steward of the intellectual property

Quality measures help improve the quality of health care through a consistent and accountable approach to evaluating care delivery. The Measure resource represents a structured, potentially computable definition of a health-related measure such as a clinical quality measure, public health indicator, or population analytics measure. The resource builds on the general approach to representing knowledge artifacts and adds the metadata and structure information that is specific to measures:

Measure Structure

Quality measures follow a general hierarchical structure that defines:

  • Population Groups: Groups of population criteria that define a particular area of measurement. A given Measure may include any number of population groups, each with different criteria for the various measure components.

    • Populations: Within each population group, a measure defines criteria appropriate to the type of measure being calculated. Each population type identifies a specific component of the calculation such as the numerator, denominator, and initial population.
    • Stratifiers: Additional criteria used to subdivide a measure population along different dimensions such as race, age, social risk factors, income, or region. A measure may define any number of stratifiers for each population group.
  • Supplemental Data: Additional descriptive information providing additional context to the population group being measured. Supplemental data is specified alongside the calculated measure scores, allowing a more nuanced analysis of performance.

Population Quality Measures are often focused on evaluating from a patient perspective, but this is not always the case. The subject element of the Measure indicates the intended subjects of a measure. If no subject is specified, the measure subject is Patient, but Practitioners, Organizations, Locations, or even Devices can also be the subject of a measure.

The following table provides a requirements mapping from the content of an electronic Clinical Quality Measure (eCQM) icon to the elements defined in the Measure resource:

Metadata Element Cardinality Element Notes
Title 0..1 Measure.title
Identifier 0..1 Measure.identifier identifier type code as http://hl7.org/fhir/cqi/ecqm/Measure/Identifier/cms
Version Number 0..1 Measure.version
NQF Number 0..1 Measure.identifier identifier type code as http://hl7.org/fhir/cqi/ecqm/Measure/Identifier/nqf
GUID 0..1 Measure.identifier identifier type code as http://hl7.org/fhir/cqi/ecqm/Measure/Identifier/guid
Measure Steward 0..1 Measure.publisher
Measure Developer 0..1 Measure.author
Endorser 0..1 Measure.endorser
Description 0..1 Measure.description
Copyright 0..1 Measure.copyright
Reference 0..* Measure.relatedArtifact 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..1 Measure.usage String (containing Markdown)

As with other knowledge artifacts, logic is included by referencing a Library resource.The Library resource is a general purpose container for clinical knowledge artifacts. It can be used to describe and expose existing knowledge such as logic and information model descriptions, as well as to describe a collection of knowledge artifacts. Measures should reference only one Library, the primary measure library, and that library should contain all the named expressions required to define the measure structure. For more information on using libraries with CQL and FHIR, refer to the Libraries icon topic in the Using CQL with FHIR Implementation Guide.

Note that this approach 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 to reference multiple libraries directly.

A measure can include various population criteria, depending on the 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 in the Quality Measure Implementation Guide icon.

Measure Scoring Initial Population Denominator Denominator Exclusion Denominator Exception Numerator Numerator Exclusion Measure Population Measure Population Exclusion
Proportion R R O O R O NP NP
Ratio R R O NP R O NP NP
Continuous Variable R NP NP NP NP NP R O
Cohort R NP NP NP NP NP NP NP
Attestation O O O O O O O O

The Measure resource identifies specific named expressions within the referenced primary measure library that define the criteria for each population. For example, the following fragment illustrates the population criteria definitions for the CMS146 measure example:

<group>
  <linkId value="CMS146-group-1"/>
  <population>
    <linkId value="CMS146-group-1-ip"/>
    <code>
      <coding>
        <system value="http://terminology.hl7.org/CodeSystem/measure-population-type"/>
        <code value="initial-population"/>
      </coding>
    </code>
    <criteria value="CMS146.InInitialPopulation"/>
  </population>
  <population>
    <linkId value="CMS146-group-1-num"/>
    <code>
      <coding>
	    <system value="http://terminology.hl7.org/CodeSystem/measure-population-type"/>
        <code value="numerator"/>
      </coding>
    </code>
    <criteria value="CMS146.InNumerator"/>
  </population>
  <population>
    <linkId value="CMS146-group-1-den"/>
    <code>
      <coding>
        <system value="http://terminology.hl7.org/CodeSystem/measure-population-type"/>
	    <code value="denominator"/>
      </coding>
    </code>
    <criteria value="CMS146.InDenominator"/>
  </population>
  <population>
    <linkId value="CMS146-group-1-denex"/>
    <code>
      <coding>
        <system value="http://terminology.hl7.org/CodeSystem/measure-population-type"/>
        <code value="denominator-exclusion"/>
      </coding>
    </code>
    <criteria value="CMS146.InDenominatorExclusions"/>
  </population>
</group>

Supplemental data are descriptive in nature and do not represent an evidence-based quality opportunity, rather thay may provide useful additional contextual information about a measure population, or support quality program requirements such as Helth IT certifiaction. Strata are an integral component of the core measure specification. Each evidence-based stratum represents significant clinical or policy rationale for subdividing the measure population.

  • Strata are an integral component of the quality measure specification. Each evidence-based stratum represents significant clinical or policy rationale for subdividing the measure population.
  • Each variable used for stratifying measure populations is rigorously tested as part of quality measure specification development, meeting strict criteria for scientific soundness, reliability, useability, feasibility and validity (https://mmshub.cms.gov/about-quality/quality-at-CMS/principles icon).
  • A direct link from each stratum is associated with one or more quality improvement opportunities- stratification represents these improvement opportunities for specific measure subpopulations (i.e., each stratified population represents a different clinical pathway, or a different quality opportunity based on those specific variables on which the cohort was stratified upon).

Measure stratification is specified using the stratifier element 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.deceased). 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.

Supplemental data represent additional information about a person or population beyond what is included in a core measure specification. Supplemental data often contain information specific to the entity primarily accountable for taking action on the measure results, such as provider-specific variables or those associated with a specific payment system. Supplemental data are descriptive in nature and do not represent an evidence-based quality opportunity, rather they may provide useful additional contextual information about a measure population, or support quality program requirements such as Health IT certification.

Some measure reporting programs, such as the CMS Eligible Clinician Electronic Clinical Quality Measurement program, require specific supplemental data elements (SDEs) to be included in the measure report.

Supplemental data are specified using the supplementalData element of the Measure resource. Like stratifier criteria, supplemental data elements are specified either as a reference to a CQL named expression within a Library or as FHIR resource paths.

For individual-level reports, if the result of evaluating the supplemental data expression for the subject of the report is not a resource, it is reported as a contained Observation resource and included by reference in the supplementalData element of the MeasureReport.

For summary-level reports, supplementalData is reported using contained Observation resources that indicate the number of times each value was encountered as the supplementalData for members of the population. In this case, the code element of the Observation corresponds to the code of the supplementalData, and the component.code element of the observation specifies the supplementalData values encountered, and the component.value[x] element is specified as an integer that represents the number of times that value was encountered in the members of the population.

The CMS146 example measure illustrates the stratification and supplemental data described above:

Quality measures often specify multiple rates, with different population crtiteria for each rate. This is different than stratifying the scores for the same population. For quality measures that contain multiple rates, the Measure will contain multiple group elements, where the criteria are specified once for each group. The linkId attribute of the group element 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 measure particular aspects of a process or outcome. Note that measure observations are not population criteria in that they do not filter the population in any way. Rather, measure observations are data elements, to be collected from each subject that satisfies the population criteria, which are used to calculate the results for each member of the population.

The data requirements for a measure represent the data of interest as a set of DataRequirement elements. Each data requirement identifies a specific type 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 needed to calculate a valid measure score.

Specifying the data criteria in this way enables the following use cases:

  • Determining the set of data used by a particular Measure.
  • Limited "scoop-and-filter" for creation of population reports.
  • Limited backwards compatibility with existing implementations of previous Measure IGs.

Data criteria can be specified statically, or they can be inferred from the expressions referenced by the measure. The $data-requirements operation can be invoked to retrieve the aggregate data requirements for the measure. This approach has two advantages:

  • When the data requirements for the expression contain dynamic criteria (such as date ranges relative to today), the results returned are based on the evaluation request time.
  • When the expressions involve multiple libraries, rather than having to retrieve and deal with the requirements for each library, the $data-requirements operation can aggregate the requirements and return them as a single module-definition library.

In addition to multiple rate measures, the Measure resource allows for composite measures to be built by referencing existing measures. For example, public health indicators may be defined and combined in multiple ways by different public health agencies:

Measure Structure

In the above example, two different agencies are able to make use of the same definitions in different ways by using composite measures.

For a more complete treatment of composite measures, refer to the Quality Measure icon implementation guide.

FHIR defines both the representation of resources and a general mechanism for interacting with them via the OperationDefinition resource. Prior sections of this topic described the Measure representation of an quality measure, this section describes the $evaluate-measure operation that is used to request the results of calculating a Quality Measure.

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:

  • Idempotent The operation may be invoked multiple times without side effects. Note that the result of invoking the operation may vary over time if clinical data or parameters used by the measure change between invocations.
  • InvocationTarget The operation can be invoked on instances of the Measure resource that represent a particular quality measure or on the type of the resource with a parameter that specifies the Measure to calculate.

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. Note that because measure calculation might not be instantaneous, the MeasureReport resource provides a mechanism to handle long running calculations.

GET [base]/Measure/$evaluate-measure?measure=CMS146&periodStart=2014&periodEnd=2014
GET [base]/Measure/CMS146/$evaluate-measure?periodStart=2014&periodEnd=2014

The above examples show how to obtain the results of evaluating the measure with id "CMS146" for all patients over a measurement period that consists of all of 2014. Some items of note:

  • the first variant evaluates the operation on [base]/Measure which is the type of resource and specifies the quality measure to evaluate using a parameter
  • the second variant evaluates the operation on [base]/Measure/CMS146 which is the Measure instance that represents that measure so there's no need to also include a reference to the measure in the operation parameters
  • the HTTP GET method is used since the $evaluate-measure operation is idempotent
  • [base] is used as a shortcut for the base URI of the FHIR server
  • the period start and end values are both specified to a granularity of a year, the description of the parameters above explains why this results in a measure period that spans the entire year

The next example demonstrates how to obtain the results of evaluating the measure with id "CMS146" for the patient with id "124" over a measurement period that consists of the first three months of 2014.

GET [base]/Basic/CMS146/$evaluate-measure?subject=124&periodStart=2014-01&periodEnd=2014-03

The MeasureReport resource represents the results of calculating a measure for a specific subject or group of subjects. The $evaluate operation of the Measure resource is defined to return a MeasureReport. The resource is capable of representing three different levels of report: individual, subject-list, and summary.

A MeasureReport will contain a group for each group specified in the corresponding Measure consisting of a set of population elements, one for each criteria defined in each group. The Measure.group.linkId and Measure.group.population.linkId elements define a linking id that is used to correlate the group and population elements in the MeasureReport back to the corresponding elements in the Measure.

Population Measure Report

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. The Measure.group.stratifier.linkId element defines a linking id that is used to correlate the stratifier elements in the MeasureReport back to the corresponding elements in the Measure.

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 the subject of the report. In addition, the result SHOULD use the evaluatedResource element to include references to any subject-specific resources that were used to calculate the result.

Individual Measure Report

See the MeasureReport examples for a detailed illustration of how the data elements involved in the calculation of the measure are communicated through the evaluatedResources element.

As with population-level reports, the group, population, and stratifier elements have a linkId element that defines a linking id that is used to correlate these elements in the MeasureReport back to the corresponding elements in the Measure.

When using a MeasureReport resource to represent a subject-list, the MeasureReport SHALL have a type-code of "subject-list" and if a subject reference is present, it SHALL be a reference to a Group. In addition, the resource SHALL

  • either include for each population, using the MeasureReport.group.population.subjectResults element, a reference to a List resource that references individual-level MeasureReport resources for the same measure, one for each subject 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 subjects that make up that population. For each of those subjects, the List will contain a reference to an individual-level report for that subject.
  • or include for each population, using the MeasureReport.group.population.subjectReport element, references to individual-level MeasureReport resources for the same measure directly.
Subject-List Measure Report

For both options (measure reports provided directly using the subjectReport element or indirectly through a List resource using the subjectResults element), note that for very large populations, implementations MAY decide to limit the size of the result, either by returning an error indicating the request is too costly, or by returning a partial result, so long as there is an indication that the report is only a partial response. In addition, we are actively seeking feedback on how best to approach evaluation of quality measures on large populations, including the use of bulk data formats.

In addition, implementations may return a MeasureReport with a status of pending, indicating that the evaluation is in progress. In this case, clients can request the MeasureReport resource until the status changes to complete.

As part of the evaluation of a Measure to produce a MeasureReport, systems may report information messages, warnings, and errors using the messages element. The messages can be used to reference an OperationOutcome resource describing issues that have occurred during the evaluation. Note that the OperationOutcome resource referenced is typically contained within the returned MeasureReport.

  1. HL7 Standard: Clinical Quality Language Specification, Release 1 (Standard for Trial Use, Release 2). icon
  2. Quality Improvement Core (QICore) FHIR Implementation Guide. icon
  3. Representation of the Health Quality Measures Format (eMeasure) Release 1 Normative. icon
  4. HL7 Version 3 Implementation Guide: Quality Data Model (QDM)-based Health Quality Measure Format (HQMF), R1 - US Realm, Volume 1 (Draft Standard for Trial Use) icon
  5. HL7 Version 3 Implementation Guide: Quality Data Model (QDM)-based Health Quality Measure Format (HQMF), R1 - US Realm, Volume 2 (Draft Standard for Trial Use) icon
  6. HL7 Version 3 Implementation Guide: Clinical Quality Language (CQL)-based Health Quality Measure Format (HQMF), Release 1 - US Realm (Standard for Trial Use) icon
  7. Quality Data Model, Version 4.2 icon
  8. HL7 CDA R2 Implementation Guide: Quality Reporting Document Architecture - Category I (QRDA I) DSTU Release 3 (US Realm) icon