Data Exchange For Quality Measures Implementation Guide, published by HL7 International / Clinical Quality Information. This guide is not an authorized publication; it is the continuous build for version 1.0.0-cibuild built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/HL7/davinci-deqm/ and changes regularly. See the Directory of published versions

General Guidance

Introduction

Clinical Quality Measures are a common tool used throughout healthcare to help evaluate and understand the impact and quality of the care being provided to an individual or population.

The Data Exchange for Quality Measures (DEQM) Implementation Guide defines the interactions for several purposes in the Quality Measure Ecosystem.

• The first interaction is when a Producer — the system holding the data, such as a practitioner's EHR — needs to exchange that data with a Consumer of that data, such as a payer, a registry or public health agency. We call this the Data Exchange Scenario. Examples of this interaction might be when a provider has patient information from a recent visit that they need to share with a payer under a value based contract. There may also be use cases where the Producer in this scenario is a Payer and needs to exchange data with a Provider.

• The second interaction is when a Reporter — the system that calculates the measure results — needs to exchange a measure report with a Receiver. This guide addresses the Individual Measure Reporting and the Summary Reporting. As an example, Individual Measure Reports may be used by hospitals acting as the Reporter to report a specific measure to a payer acting as a Receiver. Similarly, Summary Measure Reports may be used to report yearly eCQM results on a specific measure.

• The third interaction is Gaps in Care Reporting. Gaps in Care Reporting is used to report the open, closed, and/or prospective gaps for quality measures over a gaps through period specified by a Client. Optionally, it is also used to report details of the open and/or prospective gaps identified and mitigation steps for addressing them. It further provides capability of associating clinical data included in the report with the population criteria (i.e. denominator, numerator) of a measure that they apply to.

To illustrate how these interactions can be used to facilitate quality reporting, the following scenario describes payer/provider reporting at the highest level, from setup and configuration of the measures and population involved, to exchange of and reporting on the data. This scenario acts as an index for the detailed guidance in the rest of the framework topics.

Overall Payer/Provider Quality Reporting Process

NOTE: In the discussion of this quality reporting process, the terms Payer, Provider, and Measure Authority are used in the sense of stakeholders in the quality reporting process; Measure Authorities are the Specifier stakeholders described in the Quality Measurement Standards Landscape. Depending on the actual interaction, each of these stakeholders will play different roles - Producer, Consumer, Reporter, or Receiver - as called out at each step below and defined in the Glossary. Note also that this process spans interactions defined in the Quality Measure implementation guide (for representing and exchanging measure specifications), as well as this Data Exchange for Quality Measures implementation guide (for exchanging the data-of-interest and reporting on that data).

• To begin with, CMS, NCQA and other Measure Authorities create Quality Measure(s)
  • In FHIR, each Quality Measure is represented by
    • A Measure Resource which contains the name of the Measure, the steward, URL, and other metadata about the measure. This points to 1 or more Library Resources
      • The Library Resource contains the data requirements which is what resources based on date and value sets are used by the measure. It also contains the CQL logic which is what the CQL Engine uses to calculate the Individual MeasureReport and Summary MeasureReport.
• The Measure Authority will publish the computable specifications, i.e. the Measure(s) and associated Library(ies) for the Payer and Provider. See the Measure Repository Service for more detail on this process.
• The Payer creates an ATR Group(s) for the Provider. This could be based on contract, regulatory requirements or other defined requirements.
• The ATR Group is pulled from the Payer by the Provider using the ATR Member Attribution List Exchange Interactions
  • The Provider performs a patient match on each patient in the ATR group and records the Payer-provided Patient Identifier to return in the FHIR data
• The Provider then queries their system for the data needed for each measure for every patient within the ATR group for which they are reporting
  • The Provider understands the data required based on the dataRequirements published by the Measure Authority, which can be discovered using the $data-requirements operation.
• The Provider then makes the data available for exchange, ideally using FHIR Bulk protocol (ndjson) with the data organized by Patient option. In this interaction, the Provider is playing the role of Producer and the Payer is playing the role of Consumer.
  • The Provider can optionally include a Data Exchange MeasureReport for each measure to identify which resources are intended to be used for calculation for which measures. Note that data is not duplicated in the process. For example, if an Encounter Resource is used by multiple measures, the Resource is only sent once.
  • Note: The preferred method when possible is for the Provider's system to stage the FHIR data in bulk format and allow the Payer to retrieve the data from the Provider's system on an agreed schedule using a suitable bulk operation. This does not preclude other methods, when necessary, such as a Payer directly accessing a Provider’s API.
• The Payer has the Quality Data
  • The Payer will use the Payer-provided Patient Identifier from the ATR Group
  • The Payer then ingests this data into their environment
  • The Payer gets the CQL logic from the Measure Authority's Library content
  • This is loaded into their CQL Engine
    • Note: A Measure Authority might have a requirement to run a certified CQL engine.
      • The Digital Quality Implementers Community (DQIC) is working to vet CQL engines to ensure they run the logic in a consistent and appropriate manner by running a conformance demonstration.
      • This is different from Measure certification for HEDIS submission
  • The Payer runs the CQL engine ($evaluate in FHIR) against the FHIR data using the ATR group to produce:
    • Individual MeasureReport(s), a report for each patient for each measure that references evaluatedResources. The engine will create a Bundle per patient including all the MeasureReports and evaluated Resources. Each evaluated Resource will only be sent a single time even though they may be referenced by multiple MeasureReports.
    • Summary MeasureReport(s), which has the overall calculations across all patients for a specific measure and does not include individual data – only the score and counts for initial population, numerator, denominator, and exclusions.
• The Payer then shares a bundle that includes the Individual MeasureReport(s) and associated evaluated Resources with the Provider (this may be based on the ATR Group). In this interaction, the Payer is playing the role of Reporter and the Provider is playing the role of Receiver. Note that the Payer system that acted as the Consumer above is the Reporter here. See Individual Reporting for the detail of this transaction.
• Where the quality initiative requires it, the Payer also reports the Summary MeasureReport(s) to the Measure Authority or other quality program, again playing the role of Reporter, with the receiving program playing the role of Receiver. See Summary Reporting.
• Based on these reports, the Provider would repeat the process of sharing data as described above. The Provider may also request a Gaps in Care Report from the Payer to identify open gaps that could be closed before the end of the measurement period; in that interaction the Provider is playing the role of Client and the Payer’s system the role of Server.

Note that depending on the sizes of the populations involved, scale is necessarily a consideration throughout all these interactions. This is why the DEQM exchange and reporting interactions are structured around the subject, so that implementers can choose streaming, bulk, and/or patient-at-a-time architectures as appropriate for their environments. For example, in cases of extremely large payers, implementations may choose to only receive summary data for the entire population, with selective sampling for individuals across the population. These choices do not fundamentally alter the nature of the interactions, and facilitating them is one of the primary drivers of the flexibility provided by the DEQM framework.

Preconditions and Assumptions

• Although the exact mechanisms for securing these exchanges are not specified as part of this implementation guide:

  • Exchanges are limited to mutually agreed upon (i.e., between the Producer and Consumer) patients list or population.

  • Systems should use standard authentication and authorization approaches. The SMART App Launch and SMART backend services authentication/authorization approach are recommended models.

• The Measure resource is used to provide both human- and machine-readable definitions of a quality measure

• The MeasureReport provides an association to a specific quality measure and links the submitted data together to simplify processing for the receiving system.

• It is the responsibility of the Producer to ensure that measure data is present in a structured, retrievable form.

• The required data is represented in the referenced resources defined by the MeasureReport.

  • Multiple MeasureReport may reference the same instance of a resource.

• Both Consumers and Producers should use a common expression language, such as Clinical Quality Language (CQL), that allows the same measures to be applied in healthcare and at the aggregator. This also enables the application of the same measures across populations that span multiple Consumers (such as payers). Using common measures across payers reduces development burden for FHIR implementers.

  • The MeasureReport profiles in this IG are used to report CQM Measures. In the context of the FHIR Clinical Quality Framework, CQL is used to facilitate the definition and execution of measures, however the CQM Measure profile does not require the use of CQL. DEQM MeasureReports can reference any CQM Measure, including those not utilizing CQL.

Timezone Support

When evaluating measure logic with $evaluate and $care-gaps, it is often the case that the operation should not be performed with respect to the server's timezone, but rather a timezone specified by the client is typically a more correct option. The timezone header is available for use in $evaluate and $care-gaps to provide guidance to the measure evaluator about the correct timezone to use. Any number of other methods to specify a timezone could be implemented by measure evaluators, but these would be beyond the scope of this implementation guide. Note that even specifying a single timezone isn't always correct because the evaluation may be running over data from multiple sources in different timezones.

DEQM MeasureReport Profiles

The MeasureReport resource is used as an organizer for both the Data Exchange Scenario and for measure reporting scenario. To meet the different needs in these scenarios, DEQM has created 5 MeasureReport profiles. Technically the type of profiles can be determined by inspecting the meta.profile element if present or the type element.

The MeasureReport resource is also used for the Gaps in Care Reporting Scenario. A DEQM MeasureReport profile defined in this guide is used to support the needs of Gaps in Care Reporting.

Data Exchange

The DEQM Data Exchange MeasureReport Profile is used to get the data from the Producer to a Consumer of the data. The Consumer might be a system that calculates the measure report but they could also be an aggregator who sends that data on to another system to do measure calculation and reporting. Along with Data Exchange MeasureReport Profile, the Producer sends the Organization, Patient and any relevant resources for the measure they have produced data on. When a Producer, such as a practitioner's EHR, sends a MeasureReport bundle, it may not have all the data that is required to calculate the measure report. One example might be because the measure requires outcome data from at a later point in time during the measurement period. Another example where the Producer may not have all the data would be continuous coverage period as the Producer may not know the patient was covered on the day the patient was seen. The Consumer (in this case the payer as aggregator) is the owner of all coverage information. Therefore, only the Consumer could determine if the continuous coverage period requirement is met.

Measure Reporting

Measure Reporting is done by a Reporter that has all of the data that is required to generate a report(s). Three profiles for measure reporting have been defined in this guide.

The DEQM Individual MeasureReport Profile is used when a measure is reported for a specific patient. It contains all of the data that is relevant to generate the report including the measure outcome. The MeasureReport(s) are packaged in a FHIR Bundle with Organization, Patient and any other resources that were used to calculate this measure.

The DEQM Subject List MeasureReport Profile is used when a measure is reported for a list of subjects, and it also allows Individual MeasureReports be provided for each of the subjects in the population.

The DEQM Summary MeasureReport Profile is used when a measure is reported for a group of patients at the conclusion of a measure measurement period. It includes the measure outcome data. Unlike the DEQM Individual MeasureReport Profile, the report is typically transacted as a single MeasureReport report.

Measure population determination SHALL be done as specified in the Quality Measure (QM) IG's section Population Criteria. This section describes how the appropriate population is determined for each subject when evaluating a measure. These populations are reported in the measure reports.

As an example, consider reporting a proportion measure, so named because it calculates the proportion of the denominator population that is also in the numerator population (accounting for exclusions and exceptions as well). The measure populations can be made up of either the subject of the measure itself, or it can be data related to the subject.

• Subject-based measures count the number of subjects in each population. That is, the measure's population basis is boolean to indicate if the subject belongs to the population. A subject-based proportion measure, for example, that has a subject of Patient may define the denominator as "Patients with condition A that had one or more encounters during the measurement period" and the numerator as "Patients that underwent procedure B during the measurement period." A "true" or "false" indicates whether or not the subject belongs to each population. When evaluating subject-based measures, a null result is interpreted as false. A patient with "condition A" but no procedure would be evaluated as "true" for the denominator and "false" for the numerator, and so would contribute to the denominator count but not to the numerator count in the MeasureReport. For more information, see the measure conformance (QMs) section of the QM IG.
• Non-subject-based measures report populations of data related to the subject. That is, the measure's population basis is items of a single type related the subject, typeically a type of FHIR resource. A non-subject-based proportion measure, for example, that has a subject of Patient may define the denominator as "All encounters where the patient has condition A during the measurement period" and the numerator as "All encounters from the denominator where procedure B was performed during the encounter." The reported Encounter resources that make up the measure populations are evaluated within the context of subject, but are not an evaluation of the subject itself. For non-subject-based measures, a null result is interpreted as an empty list, and null elements within the resulting list do not contribute to the result. A patient with "condition A" during an encounter but no procedure would contribute an encounter to the denominator but would not contribute one to the numerator in the MeasureReport. For more information, see the measure conformance (QMs) section of the QM IG.

Populations and data outside of the regular measurement populations (e.g. Initial Population, Numerator, Measure Population, etc.) can also be defined in the Measure resource.

• Criteria-based stratifiers report each measure population broken down into the categories defined by the stratifier criteria. This type of stratifier must evaluate to the same type as the measure basis. For example, consider a subject-based measure with stratifier criteria that categorize the subjects as under age 18. The MeasureReport would report the overall population results and also the population results for subjects under age 18. For more information, see the stratification section of the QM IG.
• Value-based stratifiers report each measure population broken down into the categories defined by the stratifier criteria. This type of stratifier evaluates to a value, which is then used to categorize the population results. For example, consider a subject-based measure with a value-based stratifier that simply returns Patient.gender. The MeasureReport would report the overall population results and also the population results for each value returned from the stratifier. For more information, see the stratification section of the QM IG.
• Supplemental data elements define an expression that returns desired data related to the measure subject. This data does not affect the population reporting but rather is reported as a reference to a contained resource in the MeasureReport. For more information, see the supplemental data elements section of the QM IG.
• Continuous variable measure observations are the individual measure observations that are combined to produce a continuous variable result. The method used to combine results is defined by the measure-observation criteria. For more information, see the continuous variable measures section of the QM IG.

For a detailed description of how calculation algorithms are evaluated for each scoring type, refer to the Measure Population Semantics section of the QM IG.

Group, Stratifier, and Population Codes and Ids

A measure defines calculation rates using the group elements, and it can identify these groups with several data elements. A DEQM measure report's groups SHALL be organized and identified in the same manner as in the evaluated measure without alteration. The table below shows which measure elements must be present in measure report.

All linkId and code elements in the measure identified in the table above SHALL be in the measure report in the corresponding location. All id elements SHOULD be in the measure report. There are two exceptions to the linkId and id requirements above: (1) supplementalData.id SHALL be in the measure report if and only if the supplementalData.linkId is not present, and (2) supplementalData.code SHALL be in contained Observation resources on the code element that report supplemental data.

For backwards compatibility with measure specifications that do not use linkId elements, MeasureReports MAY be produced that do not include the linkId, but in these cases, the report SHALL provide the corresponding id elements to ensure measure components in the report can be correlated to the measure specification.

If the measure does not contain all of these elements, then they would not be reflected in the measure report. If the measure does not have group.stratifier elements, then the measure report would not reflect any elements any group.stratifier.stratum elements.

For example, the below measure population criteria and stratifier would result in the following measure report snippet.

Click Here To See Example Measure Population Criteria

"group": [{
    "id": "group-1",
    "code": {
      "coding": [{
          "system": "http://example.org/group",
          "code": "group",
          "display": "group-1"
        }
      ]
    },
    "population": [{
        "id": "initial-population-1",
        "code": {
          "coding": [{
              "system": "http://terminology.hl7.org/CodeSystem/measure-population",
              "code": "initial-population",
              "display": "Initial Population"
            }
          ]
        },
        "criteria": {
          "language": "text/cql-identifier",
          "expression": "Initial Population"
        }
      }, {
        "id": "numerator",
        "code": {
          "coding": [{
              "system": "http://terminology.hl7.org/CodeSystem/measure-population",
              "code": "numerator",
              "display": "Numerator"
            }
          ]
        },
        "criteria": {
          "language": "text/cql-identifier",
          "expression": "Numerator"
        }
      }, {
        "id": "denominator",
        "code": {
          "coding": [{
              "system": "http://terminology.hl7.org/CodeSystem/measure-population",
              "code": "denominator",
              "display": "Denominator"
            }
          ]
        },
        "criteria": {
          "language": "text/cql-identifier",
          "expression": "Denominator"
        }
      }
    ],
    "stratifier": [{
        "id": "stratifier-1",
        "code": {
          "text": "Stratifier 1"
        },
        "criteria": {
          "language": "text/cql-identifier",
          "expression": "Stratifier 1"
        }
      }
    ]
  }
]

Click Here To See Example Resulting Measure Report Group and Stratification

"group": [{
    "id": "group-1",
    "code": {
      "coding": [{
          "system": "http://example.org/group",
          "code": "group"
        }
      ]
    },
    "population": [{
        "id": "initial-population-1",
        "code": {
          "coding": [{
              "system": "http://terminology.hl7.org/CodeSystem/measure-population",
              "code": "initial-population"
            }
          ]
        },
		"count" : 100
      }, {
        "id": "numerator",
        "code": {
          "coding": [{
              "system": "http://terminology.hl7.org/CodeSystem/measure-population",
              "code": "numerator"
            }
          ]
        },
		"count" : 85
      }, {
        "id": "denominator",
        "code": {
          "coding": [{
              "system": "http://terminology.hl7.org/CodeSystem/measure-population",
              "code": "denominator"
            }
          ]
        },
		"count" : 100
	  }],
    "stratifier": [{
        "id": "stratifier-1",
        "code": {
          "text": "Stratifier 1"
        },
		"stratum":[<...>]
      }
    ]
  }
]

Gaps in Care Reporting

Gaps in Care Reporting can be requested by a Client to a Server system that has all of the data that is known about the patient(s) at a point in time during a gaps through period. The care-gaps operation is used to request and receive Gaps in Care Report for measures.

When the care-gaps operation is run on the Server, it returns a FHIR Bundle for each patient. The bundle conforms to the DEQM Gaps In Care Bundle Profile, which must contain a Composition that uses the DEQM Gaps In Care Composition Profile. The DEQM Gaps In Care Composition references one to many MeasureReport resource; each MeasureReport is for a single measure and conforms to the DEQM Individual MeasureReport Profile. Optionally, the actual individual MeasureReport resources referenced are also packaged in the same DEQM Gaps In Care Bundle, along with Patient, Organization, and other resources that were used to calculate this measure. A DetectedIssue resource defined using the DEQM Gaps In Care DetectedIssue Profile must be included to indicate gap status of that measure via the DEQM Gap Status Extension, a modifier extension.

The DEQM Individual MeasureReport contains all of the data that is relevant to calculate the report including the measure outcome and indication of open gaps or prospective gaps. The care-gaps operation determines the gaps status for the patient for a specific measure based on the measureScore data contained in the MeasureReport. Depending on what input parameters are provided to the care-gaps operation for generating a Gaps in Care Report, a DEQM Gaps In Care Composition may contain reports for measures with any combination of open, closed, and prospective gaps. The CQF Criteria Reference Extension to the evaluatedResource is added to the DEQM Individual MeasureReport Profile to support associating an evaluated resource with a specific measure population or populations that it applies to. For example, a colonoscopy procedure done for an individual 5 years ago is used to meet the numerator population criteria when evaluating the colorectal cancer screening measure for the individual. Through the use of this CQF Criteria Reference Extension the Server can indicate this colonoscopy procedure data was used for evaluating the numerator population, identified by the population group id for numerator specified in the Colorectal Cancer Screening Measure resource.

Data Requirements

Measure specifications define logic and data requirements necessary to perform evaluation of a given measure, often through the use of CQL definitions. The use of CQL definitions/queries supports the retrieval of applicable data elements and associated metadata. Measure specifications will typically make use of a set of defined profiles suitable for use in the target environment, such as US Core or QI-Core, to ensure that data exchanged is standardized, consumable, and suitable for evaluation.

Duplicate Data

Implementations SHOULD avoid sending duplicate data (identical FHIR resources) in data exchanges (collect-data or submit-data) or as resolvable references in MeasureReport.evaluatedResources.

Duplicate data is a concern in DEQM because the operations support multiple measures per subject. The same resource instance could be referenced by multiple MeasureReports, or multiple measures may use different elements within the same resource. Another situation to consider when evaluating a measure is when multiple value sets have overlapping codes, then two different CQL retrieve operations can return the same resource instance because it matches a code twice from the overlap.

​Note that the $data-requirements operation is currently defined for a single Measure or Library, so it is a responsibility of the Producer to check for, and address, duplicate data.

As described below in the section "DEQM Operation Bundles Organized by Subject," Bundles utilized in DEQM operations are organized by subject. This reduces the potential for proliferation of duplicate data because resources common to the subject, such as Encounters, would not be repeated across Bundles. As described in (Resource URL & Uniqueness rules in a bundle), a given version of a resource SHALL occur only once in a Bundle, and for DEQM that requires consideration of the data of interest and evaluated resources within the Bundle.

Receiving systems need to consider the possibility that some duplicate data may be present across Bundles, such as an Organization resource that is relevant to more than one subject.

DEQM Operation Bundles Organized by Subject

The Bundles used in the DEQM operations enable the evaluation and exchange of data for multiple measures, while also constraining duplicate data. Bundles SHOULD be organized by subject, meaning that a Bundle SHOULD contain the resources, the including MeasureReport(s) and data of interest (in MeasureReport.evaluatedResources), for all of the measures that apply to a single subject. Resources that are not unique to the subject, such as Practitioner or Organization, may still be duplicated across Bundles.

Referential Integrity in Bundles

The guidance in this section applies to every DEQM scenario. The system sending a Bundle is the Producer in the exchange scenarios, the Reporter in the reporting scenarios, and the Server in the Gaps in Care scenarios; the system receiving it is the Consumer, the Receiver, and the Client, respectively.

The sending system SHOULD include all and only the data required to calculate the measure and send it in a way that reduces data duplication as much as reasonably possible. This may result in bundles that have references to data that is not included in the bundle, which could be both patient-specific information, such as immunizations, and non-patient-specific information, such as locations and practitioners, that are not relevant to the evaluated measure.

The receiving system SHALL be permissive in accepting references to data that are not included in the bundle.

Considerations such as privacy, consent, authorization, minimum necessary, etc., are outside the scope of this IG.

Bundle Transaction Support

The reporting scenarios in this guide post Bundles of measure reports and their supporting resources. Implementations differ in whether they can offer true bundle-level atomicity: FHIR servers often act as facade layers over existing APIs that perform individual POST/PUT operations atomically, and where the FHIR layer interacts directly with the database, atomicity over large bundles can require pessimistic locking that risks contention and deadlocks. For that reason this guide requires support for one of the two Bundle types rather than both.

All systems SHALL support one of "batch" or "transaction", and the server SHALL declare its support in the capability statement for these Bundle transaction types.

This requirement applies to the Individual, Summary, and Subject List reporting scenarios.

Ad-hoc Organizations for DEQM Operations

Producers and Consumers may want to gather data from different locations and providers within a large organization that is comprised of multiple sub-organizations. In such cases, it can be desirable to model portions of the organization from which data should be gathered as a way to target data requests. The $care-gaps and $collect-data operations allow an Organization resource to be either referenced or passed in as part of the request body. If it is passed in, it can be an ad-hoc Organization created only as part of that request. PractitionerRole resources can be used to link Practitioner resources to the Organization to model the set of participating practitioners.

The ad-hoc organization example illustrates an Organization resource with two contained PractitionerRole resources. It assumes a simple attribution model for the patient-provider interactions. In practice, attribution of patient encounters to providers will be more sophisticated and include factors such as coverage, ACOs, etc.

The organization provided in $care-gaps or $collect-data, whether in the "organization" parameter or the "organizationResource" parameter, SHALL be the reporter in the resulting measure report(s) and SHALL be included as a contained resource if necessary. When included as a contained resource in the measure report, the structure must be flattened so that the Organization does not have any contained resources because contained resources cannot themselves have contained resources. References among the contained resources SHALL be maintained. See the organizationResource example and the resulting MeasureReport example.

Negation Patterns for Quality Measures

When DEQM is used to report CQM Measures that use CQL and the QI-Core data model, negation patterns allow identifying when events are not present or when events are documented as not occurring for a reason. They may appear throughout a measure in any of the population criteria. For example, the absence of a particular medication may be grounds for membership in the initial population, denominator, numerator, or an exclusion or exception criteria, depending on how the measure is constructed. The negation pattern for the MedicationRequest (MedicationNotRequested) resource is demonstrated in the Single Indv Vte Report Option 7 example. For more information refer to the Using CQL IG section on negation and the QI-Core Negation page.

Using Contained Resources in the Response Transaction

Contained resources SHOULD NOT be used when responding to the submit-data or collect-data operation or to the Individual reporting transactions. The data exchange transaction payloads are Parameters resources containing resource parameters. The response to the individual reporting transactions are Bundles. The only time contained resource can be used is when the source data exists only within the context of the transaction. For example, if the only information about the patient's coverage is the payor name, the Coverage resource could be contained by the Patient resource:

{
  "resourceType": "Patient",
  "id": "patient01",
  "contained": [
    {
      "resourceType": "Coverage",
      "status": "active",
      "beneficiary": {
        "reference": "#"
      },
      "payor": [
        {
          "reference": "Organization/organization04"
        }
      ]
    }
  ]
  ...<rest of patient resource>
}

Contained resources SHOULD NOT be used when responding to the care-gaps operation.

Must Support

Certain elements in the profiles defined in this implementation guide are marked as Must Support. The Must Support flag is used to indicate that the element plays a critical role in defining and sharing quality measures, and implementations SHALL understand and process the element.

When exchanging data and reporting with DEQM, any Must Support flags in the supporting data model should be respected when exchanging data with DEQM profiles. The use of DEQM profiles alone does not imply that evaluated resources are valid to base FHIR or any other FHIR profiles.

For more information, see the definition of Must Support in the base FHIR specification.

Must Support guidance here requires additional clarifications, we are seeking implementer feedback on what type of guidance would be most useful.

Location Awareness In Measure Reports

Healthcare is very often geographical in nature and, in particular, it's local. Reporting in the public health domain often benefits from geographical analysis as causal relations are often geographic in nature. Epidemiologic spread of disease is proximity based; climate refugees follow the paths of storms or wildfires; hospitals report increased numbers of some conditions (i.e. heatstroke) based on seasonality and location. To this extent, MeasureReports benefit from being location aware. Important approaches include ZIP (postal routes), FIP (county taxation), HSA (ambulance dispatch zones, approximately), and GPS (point location). In some instances, geography parameters for outlining the boundary of a location in GEOJSON format are also useful. The Examples include a Location-Aware Bundle as an illustration.