This is the Continuous Integration Build of FHIR (will be incorrect/inconsistent at times).
See the Directory of published versions
Work Group Clinical Quality Information | Maturity Level: 2 | Standards Status: Trial Use |
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 area of measurement. A given measure may include any number of population groups, each with different criteria for the various measure components.
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 eMeasure to the elements defined in the Measure resource:
eMeasure | 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. Although the base resource allows for the measure to reference any number of libraries, for simplicity of managing sharing, 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.
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 specify various types of populations, 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 from the HQMF Release 1 Normative specification, and Table 2.1 from the QDM-based HQMF IG .
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 |
The Measure resource then 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 id="CMS146-group-1">
<population>
<code>
<coding>
<code value="initial-population"/>
</coding>
</code>
<criteria value="CMS146.InInitialPopulation"/>
</population>
<population>
<code>
<coding>
<code value="numerator"/>
</coding>
</code>
<criteria value="CMS146.InNumerator"/>
</population>
<population>
<code>
<coding>
<code value="denominator"/>
</coding>
</code>
<criteria value="CMS146.InDenominator"/>
</population>
<population>
<code>
<coding>
<code value="denominator-exclusion"/>
</coding>
</code>
<criteria value="CMS146.InDenominatorExclusions"/>
</population>
</group>
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.
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 can also be specified using FHIR resource paths, in which case the supplementalData element is the result of evaluating that path against the subject.
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:
The data criteria for the primary library defines the data of interest in the measure as a set of DataRequirement elements. 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:
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:
module-definition
library.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 Measure representation of an eMeasure, this section describes the $evaluate-measure
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. 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 eMeasure with id "CMS146" for all patients over a measurement period that consists of all of 2014. Some items of note:
[base]/Measure
which is the type of resource and specifies the eMeasure to evaluate using a parameter [base]/Measure/CMS146
which is the Measure instance that represents that measure so there's no need to also include a reference to the eMeasure in the operation parametersHTTP GET
method is used since the $evaluate-measure
operation is idempotent[base]
is used as a shortcut for the base URI of the FHIR serverThe next example demonstrates how to obtain the results of evaluating the eMeasure 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
When electronic Clinical Quality Measures (eCQMs) are represented with the Health Quality Measure Format (HQMF), a single HQMF document represents both the measure itself and the request. Meanwhile, the responses are represented as Quality Reporting Document Architecture (QRDA) documents. QRDA documents come in two flavors: Category I for individual patient 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 (subject-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. 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.
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 include a reference to a Bundle containing the subject-specific resources that were used to calculate the result.
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
, stratifier
, and supplementalData
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 include for each population 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. 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.