This
page
is
part
of
the
FHIR
Specification
(v4.0.1:
R4
-
Mixed
Normative
and
STU
)
in
it's
permanent
home
(it
will
always
be
available
at
this
URL).
(v5.0.0-snapshot1:
R5
Snapshot
#1).
The
current
version
which
supercedes
this
version
is
5.0.0
.
For
a
full
list
of
available
versions,
see
the
Directory
of
published
versions
.
Page
versions:
R5
R4B
R4
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 |
|
|
| Endorser | 0..1 |
|
|
| 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 | guidance | 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
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
Release
1
Normative
specification,
and
Table
2.1
from
the
QDM-based
HQMF
IG
.
| MeasureType | 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
id
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 are also specified using FHIR resource paths, however, supplemental data only results in groups in the summary measure report. For individual-level reports, supplemental data elements are reported as Observation resources and included by reference in the evaluateResource for the individual-level report.
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
parameters
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 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
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.
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.
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.
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.