Data Exchange For Quality Measures Implementation Guide
1.0.0-ballot - STU 1 Ballot

Data Exchange For Quality Measures Implementation Guide - Downloaded Version 1.0.0-ballot See the Directory of published versions

## Home

Official URL: http://hl7.org/fhir/uv/deqm/ImplementationGuide/hl7.fhir.uv.deqm | Version: 1.0.0-ballot | Highlight text changes?
IG Standards status: Trial-use Active as of 2026-04-07 | Maturity Level: 4 | Computable Name: DEQM
Copyright/Legal: Used by permission of HL7 International - Clinical Quality Information Work Group, all rights reserved Creative Commons License

> This implementation guide is the Universal Realm successor of the US-based Data Exchange for Quality Measures IG STU 5, and incorporates stakeholder feedback and implementation experience from that specification.

### Introduction

This implementation guide defines a framework to support quality measurement, reporting, and related use cases by enabling the following capabilities:

1. The exchange of the data of interest for a measure or set of measures
2. The reporting of quality measurement results, with or without the data involved in calculating those results

Interoperability challenges have limited many stakeholders in the healthcare community from achieving better care at lower cost. The dual challenges of data standardization and easy information access are compromising the ability of both payers and providers to create efficient care delivery solutions and effective care management models. To promote interoperability across value-based care stakeholders and to guide the development and deployment of interoperable solutions on a national scale, the industry needs common information models and data exchange standards. The intent of the framework defined in this guide is to enable automatic data collection and submission limiting the need for manual processing and intervention. Ultimately, a national standard based on FHIR for data structure and exchange will reduce the burden on clinicians of transforming data between systems.

The guide is based upon prior work from the US Core and QI Core Implementation Guides and the QRDA Category I and III reporting specifications. Initially supported by the Da Vinci initiative, development and ongoing maintenance of this specification is managed by the sponsoring HL7 Clinical Quality Information (CQI) and Clinical Decision Support (CDS) workgroups. Implementation feedback is incorporated through the standard HL7 balloting process.

### How to read this Guide

This Guide is divided into several pages which are listed at the top of each page in the menu bar.

- Home: The home page provides the introduction for The Data Exchange For Quality Measures (DEQM) implementation guide.
- Scenarios: This topic provides an overview of the scenarios supported by the DEQM framework.
- Background: This page provides background for the Clinical Quality Measures Ecosystem and Quality Reporting use cases.
- Framework: These pages provide guidance on the set of FHIR transactions that provide a general framework to enable the exchange of measure data.
  - General Guidance gives overall guidance including preconditions, assumptions and an overview of the FHIR artifacts used in the different reporting scenarios.
  - Data Exchange gives guidance on the interactions between Consumers and Producers to exchange the data of interest for a measure.
  - Individual Reporting gives guidance on the interactions between Reporters and Receivers to exchange the individual reports for a measure.
  - Summary Reporting gives guidance on the interactions between Reporters and Receivers to exchange the summary reports for a measure.
  - Subject List Reporting gives guidance on the interactions between Reporters and Receivers to exchange the subject-list reports for a measure.
  - Gaps in Care Reporting gives guidance on the interactions between Clients and Servers to exchange the Gaps in Care Reports for a measure. Note that Clients and Servers are defined in section 1.7.3. Gaps in Care Reporting Scenarios.
- Use cases: Example use cases are presented to demonstrate how to implement the DEQM framework for a particular measure.
  - Medication Reconciliation (MRP): This example shows how to implement a data exchange, and individual and summary measure reporting for the medication reconciliation post-discharge measure.
  - Colorectal Cancer Screening (COL): The colonoscopy measure is an example of a process measure evaluating screenings for preventive health services. Screening measures assess the number of eligible persons receiving clinical guideline recommended screening for all patients in the population receiving care during the measurement period.
  - Venous Thromboembolism Prophylaxis (VTE-1): This example is based on an existing CMS Eligible Hospital program measure (CMS108v7). It is an example of a process measure, using proportion scoring and is within the Preventative Care Meaningful Measure Area.
  - Gaps in Care: This page lists example use cases for Gaps in Care Reporting.
- FHIR Artifacts: List of all DEQM FHIR artifacts.
  - Profiles and Extensions: A list of all DEQM FHIR profiles and extensions.
  - Operations: A list of all DEQM operations.
  - Terminology: A list of all DEQM terminology code systems and value sets.
  - Capability statements: A list of all DEQM capability statements for the various DEQM roles.
- Examples: List of all the examples used in this guide.
- Downloads: This page provides links to downloadable artifacts.

### Scenarios

The following scenarios illustrate the various ways that the DEQM framework can be used, providing an overview of and index into the more detailed use cases and specification documentation in the implementation guide.

Broadly, these scenarios fall into three categories: 1) Exchange Scenarios, focused on exchanging the data of interest for a measure or set of measures, 2) Reporting Scenarios, focused on communicating the results of a quality measure calculation, typically at the end of a measurement period as part of a quality improvement initiative, and 3) Gaps in care scenarios.

As a precondition, systems in these scenarios make use of relevant measure specifications being reported from a measure repository as described in the Quality Measure IG Measure Repository.

#### Exchange Scenarios

Figure 1-4 illustrates Exchange Scenarios.

Figure 1-4 Quality Reporting Exchange Scenarios

Exchange scenarios are used to exchange the data of interest for a measure or set of measures, either throughout the measurement period, or at the end of the measurement period as the first step in the reporting process. These scenarios enable providers and quality stakeholders such as payers, accountable care organizations, and other secondary use partners to keep better track of how patients are performing with respect to a particular quality measure during the measurement period.

The exchange scenarios are:

1. Submit Data - Used by a producing system to submit a subset of the data of interest for a measure to a consuming system
2. Collect Data - Used by a consuming system to collect a subset of the data of interest for a measure from a producing system

For these scenarios, the actors are Producers and Consumers, used in the same sense as the Producers and Consumers stakeholders in the Quality Measurement Standards Landscape diagram. Note that within any particular use case, different stakeholders will play the same roles. For example, a Provider may be playing the role of Producer in a particular exchange, while the Payer may be playing the role of Consumer.

##### Exchange Payload

DEQM is a framework specification that supports a broad set of use cases. As such, DEQM profiles do not require the use of any specific set of profiles to characterize the data being exchanged; rather, the framework relies on the content (i.e. the measure specifications) to drive the data requirements and profiles. For example, measures may make use of the QI Core profiles in the US Realm, and many of the examples in this implementation guide do so. It is the measures that specify the profiles to be used, not DEQM directly.

##### Bulk Data

In each of the scenarios described in DEQM, the FHIR API can be used directly to access the data of interest for the measure being reported. However, to support large volumes of data, Bulk Data may be used to transfer the data of interest between the clinical data repository and the reporting system. As of the time of this publication, the Bulk Data specification is being updated to include important capabilities that will improve the performance of bulk data for the quality reporting use case, in particular the ability to organize bulk data feeds by subject. A future version of this publication will provide more detail on how this capability can be used directly once the updated Bulk Data specification is published (expected to ballot in September 2026, currently in draft here.

##### Aggregated Reporting

In aggregated reporting, the reporting system gathers (or receives) data of interest from multiple clinical data repositories, allowing for reporting in a variety of ways, including multiple facilities for a single provider, as well as multi-provider organizations:

Because data from multiple facilities and organizations can be aggregated in many ways; this specification is not prescriptive about how that aggregation is performed.

##### Multiple Measures and Data Requirements

For simplicity, each of the above reporting scenarios is specified in terms of a single measure. However, all the framework operations and scenarios support specifying any number of measures to be reported, or the exchange scope:

Figure 1-5 Exchange Scope

Exchanging data for multiple measures impacts:

1. data requirements: For reporting on multiple measures, data requirements can be combined across measures to determine overall reporting requirements
2. data of interest: Exchanging data of interest for multiple measures prevents data elements that are used by multiple measures from being communicated more than once
3. submitted data: In submitted measure report bundles, multiple MeasureReports may be included, allowing each measure report to reference only data used by that measure

In the simplest case, this approach identifies all the data required for calculation of any measure used in the quality initiative.

However, the approach also allows for submitting systems to choose which measures they are reporting, and determine only the data required for those measures.

For more details on data requirements, see the Data Requirements framework topic.

#### Reporting Scenarios

Figure 1-6 illustrates the Reporting Scenarios:

Figure 1-6 Reporting Scenarios

Reporting scenarios are used to report the results of quality measures on patient populations, typically, though not always, at the end of a measurement period. Measure reports are provided to attest the standard of care given to patients in a population as measured by specific quality measures. The measures are typically identified as part of a quality improvement initiative by a payer or other quality improvement stakeholder such as public health agencies.

For the reporting scenarios, the actors are Reporters and Receivers:

Reporters are the actors submitting the results of a quality measure. Depending on the reporting requirements for a particular scenario as well as the technical capabilities of the systems involved, the reporter may be different stakeholders such as providers, provider organizations, aggregators, or payers. For the purposes of these scenarios, a reporter is conceptually a Reporting System, which has access to the information generated by or derived from the delivery of healthcare (potentially gathered through an exchange scenario), and is responsible for calculation of measure results.

Receivers are the actors receiving the results of quality measures. Again, depending on the reporting requirements and technical capabilities, receivers may be different stakeholders, but are typically aggregate-level stakeholders such as healthcare agencies, payers, and quality improvement organizations.

In each of these scenarios, the patients to be considered are determined by attribution. Since different quality initiatives may use the same measures with different attribution models, attribution is typically not specified as part of the measure specifications. The DaVinci Member Attribution List implementation guide supports the definition and exchange of member attribution lists as one approach to identifying patients to be considered for reporting, but any mechanism that identifies a group of subjects may be used.

##### Population Reporting Without Supporting Data

In this scenario, a reporter such as a clinic submits a summary level quality measure report for a specific measure, attributed patients, and measurement period:

1. The reporting system gathers the data of interest from available sources (potentially from a prior exchange scenario)
2. The reporting system calculates the measure, producing the MeasureReport
3. The reporting system then POSTs the MeasureReport to the receiver

In this scenario, the resulting MeasureReport is a summary level measure report which includes only the population counts and calculated measure score. This scenario does not result in any patient-level data being communicated to the receiving system.

For more details on this scenario, see the Summary Reporting framework topic.

##### Population Reporting With Supporting Data

In this scenario, a reporter such as a hospital submits individual level quality measure reports for a specific measure and measurement period, for each attributed patient.

1. The reporting system gathers the data of interest from available sources (potentially from a prior exchange scenario)
2. The reporting system calculates the measure, producing a MeasureReport for each attributed patient
3. The reporting system assembles a Bundle for each patient, consisting of the calculated MeasureReport and any data referenced during the calculation (i.e. evaluatedResource)
4. The reporting system POSTs the measure report Bundles to the receiver

In this scenario, there is a Bundle of individual-level patient data for each attributed Patient. Determining the overall measure score then requires the additional step of aggregating the individual MeasureReport resources. Alternatively, a subject-list report can be included that references all the individual-level MeasureReports and provides the summary level measure score.

For more details on this scenario, see the Individual Reporting and Subject-list Reporting framework topics.

#### Gaps in Care Reporting Scenarios

Gaps in Care Reporting is a reporting scenario supported in this implementation guide. Similar to the quality reporting scenarios, a Gaps in Care Report is used to report the results of quality measures on patients or population, but for a gaps through period that is of interest for a Client.

1. Gaps in Care - Used to report the results of open, closed, and/or prospective gaps of a quality measure or quality measures for a patient or a group of patients to a Client. Optionally, it is also used to provide details to the open, closed, and/or prospective gaps.

The process below can be run as many times as useful during the reporting period to assure that all open gaps are closed.

Figure 1-5 Gaps in Care Reporting Scenarios

For the Gaps in Care Reporting Scenarios, the actors are Clients and Servers.

Clients are the actors requesting gaps in care results of quality measure(s). Depending on the reporting requirements for a particular scenario as well as the technical capabilities of the systems involved, the clients may be different stakeholders such as providers, provider organizations, aggregators, or payers. For example, if a provider requests a report from the payer's system, then the provider serves as the client. If a payer requests a report from their own system, they are the client.

Servers are the actors receiving the request for the Gaps in Care Report and producing it based on the information they have in their system. Again, depending on the reporting requirements and technical capabilities, receivers may be different stakeholders, but are typically aggregate-level stakeholders such as healthcare agencies, payers, and quality improvement organizations. For example, if a provider requests a report from the payer's system, then the payer's system serves as the server. If a payer requests a report from their own system, the payer's system serves as the server.

### Acknowledgements

This Implementation Guide was made possible by the thoughtful contributions of the following people and organizations:

- The twenty-two founding Da Vinci Project member organizations.
- Bryn Rhodes, Dynamic Content Group
- Eric Haas, Health eData Inc
- Floyd Eisenberg, iParsimony LLC
- Gay Dolin, Namaste Informatics, LLC
- Jocelyn Keegan, Point of Care Partners
- Linda Michaelsen, Optum
- Lloyd Mckenzie, Gevity
- Rob Reynolds, Dynamic Content Group
- Robert Dieterle, EnableCare
- Robert Samples, ESAC
- Sam Sayer, The MITRE Corporation
- Viet Nguyen, Stratametrics
- Yan Heras, Optimum eHealth LLC

#### Dependency Table

Implementation Guide | Version(s) | Reason
--- | --- | ---
Canonical Resource Management Infrastructure | 1.0.0 | Imported by Quality Measure (and potentially others)
FHIR Extensions Pack | 5.3.0-ballot-tc1 |
5.2.0 | Imported by HL7 Terminology (THO) (and potentially others)
5.1.0 | Imported by Canonical Resource Management Infrastructure (and potentially others)
1.0.0 | Imported by HL7 Terminology (THO) (and potentially others)
FHIR R4 package : Core | 4.0.1 | Imported by HL7 Terminology (THO) (and potentially others)
HL7 Terminology (THO) | 7.1.0 | Automatically added as a dependency - all IGs depend on HL7 Terminology
6.5.0 | Imported by FHIR Extensions Pack (and potentially others)
5.5.0 | Imported by Canonical Resource Management Infrastructure (and potentially others)
Quality Measure | 2.0.0-ballot |
Using CQL With FHIR | 2.0.0 | Imported by Quality Measure (and potentially others)

#### IP Statements

This publication includes IP covered under the following statements.

- © Copyright 2022 American Medical Association
  Show Usage
  - NUCC Provider Taxonomy: Ad hoc org
- Most of the information on the CDC and ATSDR websites is not subject to copyright, is in the public domain, and may be freely used or reproduced without obtaining copyright permission.For information and exceptions regarding use of CDC material please see https://www.cdc.gov/other/agencymaterials.html.
  Show Usage
  - CDC Race and Ethnicity: Bundle/multiple-indv-mrp-obs-report, Bundle/multiple-indv-mrp-task-report... Show 27 more, Bundle/non-document-gaps-in-care, Bundle/sde-example-patient-data-bundle, Bundle/single-gaps-closed-indv-report01, Bundle/single-gaps-closed-indv-report02, Bundle/single-gaps-open-indv-report01, Bundle/single-indv-col-obs-report, Bundle/single-indv-mrp-obs-report, Bundle/single-indv-mrp-task-report, Bundle/single-indv-vte-report-option1, Bundle/single-indv-vte-report-option7, MeasureReport/indv-measurreport-stratification-example, MeasureReport/sde-example, Parameters/col-collect-obs, Parameters/col-submit-obs, Parameters/mrp-submit-obs, Parameters/mrp-submit-task, Parameters/multiple-gaps-indv-report01, Parameters/multiple-gaps-indv-report02, Parameters/single-gaps-closed-indv-report01, Parameters/single-gaps-closed-indv-report02, Parameters/single-gaps-open-indv-report01, Patient/gaps-patient01, Patient/gaps-patient02, Patient/nhsn-iip-ip101, Patient/patient01, Patient/patient02 and Patient/patient03
- The UCUM codes, UCUM table (regardless of format), and UCUM Specification are copyright 1999-2009, Regenstrief Institute, Inc. and the Unified Codes for Units of Measures (UCUM) Organization. All rights reserved. https://ucum.org/trac/wiki/TermsOfUse
  Show Usage
  - Unified Code for Units of Measure (UCUM): Bundle/sde-example-patient-data-bundle, EXMPromotingInteroperabilityMeasure, MeasureReport/SupportingEvidenceExample, MeasureReport/sde-example and MedicationRequest/nhsn-iip-add101-10
- This material contains content from LOINC. LOINC is copyright © 1995-2020, Regenstrief Institute, Inc. and the Logical Observation Identifiers Names and Codes (LOINC) Committee and is available at no cost under the license. LOINC® is a registered United States trademark of Regenstrief Institute, Inc.
  Show Usage
  - LOINC: Bundle/sde-example-patient-data-bundle, Bundle/single-gaps-closed-indv-report01... Show 19 more, Bundle/single-gaps-closed-indv-report02, Bundle/single-gaps-open-indv-report01, Bundle/single-indv-col-obs-report, Composition/gaps-composition01, Composition/gaps-composition02, Composition/gaps-composition03, DEQMGapsInCareComposition, DEQMLibraryVenousThromboembolismProphylaxis, EXMPromotingInteroperabilityMeasure, GuidanceResponse/detailedguidanceresponse01, GuidanceResponse/detailedguidanceresponse02, Observation/DNA-occultblood, Parameters/col-collect-obs, Parameters/col-submit-obs, Parameters/multiple-gaps-indv-report01, Parameters/multiple-gaps-indv-report02, Parameters/single-gaps-closed-indv-report01, Parameters/single-gaps-closed-indv-report02 and Parameters/single-gaps-open-indv-report01
- This material contains content that is copyright of SNOMED International. Implementers of these specifications must have the appropriate SNOMED CT Affiliate license - for more information contact https://www.snomed.org/get-snomed or info@snomed.org.
  Show Usage
  - SNOMED Clinical Terms&reg; (SNOMED CT&reg;): Ad hoc org, Bundle/multiple-indv-mrp-obs-report... Show 12 more, Bundle/multiple-indv-mrp-task-report, Bundle/sde-example-patient-data-bundle, Bundle/single-indv-vte-report-option1, Bundle/single-indv-vte-report-option7, Condition/nhsn-iip-con101, Encounter/encounter01, Encounter/encounter02, Encounter/encounter03, FHIRPathExample, MeasureReport/sde-example, Parameters/mrp-submit-obs and Parameters/mrp-submit-task
- This material derives from the HL7 Terminology (THO). THO is copyright ©1989+ Health Level Seven International and is made available under the CC0 designation. For more licensing information see: https://terminology.hl7.org/license.html
  Show Usage
  - Condition Category Codes: Bundle/sde-example-artifact-bundle, Bundle/sde-example-patient-data-bundle and Condition/nhsn-iip-con101
  - Condition Clinical Status Codes: Bundle/sde-example-patient-data-bundle and Condition/nhsn-iip-con101
  - ConditionVerificationStatus: Bundle/sde-example-patient-data-bundle and Condition/nhsn-iip-con101
  - Diagnosis Role: Bundle/sde-example-artifact-bundle, Bundle/sde-example-patient-data-bundle and Encounter/nhsn-iip-en101
  - Discharge disposition: Bundle/multiple-indv-mrp-obs-report, Bundle/multiple-indv-mrp-task-report... Show 7 more, Bundle/sde-example-patient-data-bundle, Encounter/encounter01, Encounter/encounter02, Encounter/encounter03, Encounter/nhsn-iip-en101, Parameters/mrp-submit-obs and Parameters/mrp-submit-task
  - DoseAndRateType: Bundle/sde-example-patient-data-bundle and MedicationRequest/nhsn-iip-add101-10
  - LibraryType: Bundle/sde-example-artifact-bundle, DEQMLibraryEXM124Example, DEQMLibraryEXM130Example, DEQMLibraryMRPExample and DEQMLibraryVenousThromboembolismProphylaxis
  - Location type: Bundle/single-indv-vte-report-option1 and Bundle/single-indv-vte-report-option7
  - MeasureDataUsage: MeasureReport/sde-example
  - MeasureImprovementNotation: Bundle/multiple-indv-mrp-obs-report, Bundle/multiple-indv-mrp-task-report... Show 41 more, Bundle/multiple-summ-report, Bundle/non-document-gaps-in-care, Bundle/single-gaps-closed-indv-report01, Bundle/single-gaps-closed-indv-report02, Bundle/single-gaps-open-indv-report01, Bundle/single-indv-col-obs-report, Bundle/single-indv-mrp-obs-report, Bundle/single-indv-mrp-task-report, Bundle/single-indv-vte-report-option1, Bundle/single-indv-vte-report-option7, DEQMGroupImprovementNotationExtension, DEQMMeasureMRPExample, DateOfLastPowerOutage, EXMPromotingInteroperabilityMeasure, FHIRPathExample, MeasureReport/FHIRPath-example, MeasureReport/MeasureReport-PI-example, MeasureReport/SupportingEvidenceExample, MeasureReport/date-of-last-power-outage, MeasureReport/gaps-indv-measurereport01, MeasureReport/gaps-indv-measurereport02, MeasureReport/gaps-indv-measurereport03, MeasureReport/gaps-indv-measurereport04, MeasureReport/indv-measurereport-patient-level-linear, MeasureReport/indv-measurereport-weighted-composite, MeasureReport/indv-measurereport01, MeasureReport/indv-measurereport02, MeasureReport/indv-measurereport03, MeasureReport/indv-measurreport-stratification-example, MeasureReport/subjectlist-measurereport01, MeasureReport/summ-contained-supplemental, MeasureReport/summ-measurereport01, MeasureReport/summ-measurereport02, MeasureReport/summ-medicare-stratification-example, MeasureReport/summary-measurereport-patient-level-linear, MeasureReport/summary-measurereport-weighted-composite, Parameters/multiple-gaps-indv-report01, Parameters/multiple-gaps-indv-report02, Parameters/single-gaps-closed-indv-report01, Parameters/single-gaps-closed-indv-report02 and Parameters/single-gaps-open-indv-report01
  - Measure Population Type: Bundle/multiple-indv-mrp-obs-report, Bundle/multiple-indv-mrp-task-report... Show 45 more, Bundle/multiple-summ-report, Bundle/non-document-gaps-in-care, Bundle/sde-example-artifact-bundle, Bundle/single-gaps-closed-indv-report01, Bundle/single-gaps-closed-indv-report02, Bundle/single-gaps-open-indv-report01, Bundle/single-indv-col-obs-report, Bundle/single-indv-mrp-obs-report, Bundle/single-indv-mrp-task-report, Bundle/single-indv-vte-report-option1, Bundle/single-indv-vte-report-option7, DEQMMeasureMRPExample, DateOfLastPowerOutage, EXMImmunizationRegistryReporting, EXMPromotingInteroperabilityMeasure, FHIRPathExample, MeasureReport/FHIRPath-example, MeasureReport/MeasureReport-PI-example, MeasureReport/SupportingEvidenceExample, MeasureReport/attestation-boolean-example, MeasureReport/date-of-last-power-outage, MeasureReport/gaps-indv-measurereport01, MeasureReport/gaps-indv-measurereport02, MeasureReport/gaps-indv-measurereport03, MeasureReport/gaps-indv-measurereport04, MeasureReport/indv-measurereport-patient-level-linear, MeasureReport/indv-measurereport-weighted-composite, MeasureReport/indv-measurereport01, MeasureReport/indv-measurereport02, MeasureReport/indv-measurereport03, MeasureReport/indv-measurreport-stratification-example, MeasureReport/ratio-measurereport01, MeasureReport/sde-example, MeasureReport/subjectlist-measurereport01, MeasureReport/summ-contained-supplemental, MeasureReport/summ-measurereport01, MeasureReport/summ-measurereport02, MeasureReport/summ-medicare-stratification-example, MeasureReport/summary-measurereport-patient-level-linear, MeasureReport/summary-measurereport-weighted-composite, Parameters/multiple-gaps-indv-report01, Parameters/multiple-gaps-indv-report02, Parameters/single-gaps-closed-indv-report01, Parameters/single-gaps-closed-indv-report02 and Parameters/single-gaps-open-indv-report01
  - Measure Scoring: Bundle/multiple-indv-mrp-obs-report, Bundle/multiple-indv-mrp-task-report... Show 42 more, Bundle/multiple-summ-report, Bundle/non-document-gaps-in-care, Bundle/sde-example-artifact-bundle, Bundle/single-gaps-closed-indv-report01, Bundle/single-gaps-closed-indv-report02, Bundle/single-gaps-open-indv-report01, Bundle/single-indv-col-obs-report, Bundle/single-indv-mrp-obs-report, Bundle/single-indv-mrp-task-report, Bundle/single-indv-vte-report-option1, Bundle/single-indv-vte-report-option7, DEQMMeasureMRPExample, DEQMMeasureScoringExtension, DateOfLastPowerOutage, EXMImmunizationRegistryReporting, EXMPromotingInteroperabilityMeasure, MeasureReport/MeasureReport-PI-example, MeasureReport/SupportingEvidenceExample, MeasureReport/attestation-boolean-example, MeasureReport/date-of-last-power-outage, MeasureReport/gaps-indv-measurereport01, MeasureReport/gaps-indv-measurereport02, MeasureReport/gaps-indv-measurereport03, MeasureReport/gaps-indv-measurereport04, MeasureReport/indv-measurereport-patient-level-linear, MeasureReport/indv-measurereport-weighted-composite, MeasureReport/indv-measurereport01, MeasureReport/indv-measurereport02, MeasureReport/indv-measurereport03, MeasureReport/indv-measurreport-stratification-example, MeasureReport/subjectlist-measurereport01, MeasureReport/summ-contained-supplemental, MeasureReport/summ-measurereport01, MeasureReport/summ-measurereport02, MeasureReport/summ-medicare-stratification-example, MeasureReport/summary-measurereport-patient-level-linear, MeasureReport/summary-measurereport-weighted-composite, Parameters/multiple-gaps-indv-report01, Parameters/multiple-gaps-indv-report02, Parameters/single-gaps-closed-indv-report01, Parameters/single-gaps-closed-indv-report02 and Parameters/single-gaps-open-indv-report01
  - MeasureType: Bundle/sde-example-artifact-bundle, DEQMMeasureMRPExample, DateOfLastPowerOutage and FHIRPathExample
  - MedicationRequest Category Codes: Bundle/sde-example-patient-data-bundle
  - MedicationRequest Course of Therapy Codes: Bundle/sde-example-patient-data-bundle
  - Observation Category Codes: Bundle/multiple-indv-mrp-obs-report, Bundle/sde-example-artifact-bundle... Show 9 more, Bundle/single-indv-col-obs-report, Bundle/single-indv-mrp-obs-report, Observation/DNA-occultblood, Observation/observation01, Observation/observation02, Observation/observation03, Parameters/col-collect-obs, Parameters/col-submit-obs and Parameters/mrp-submit-obs
  - Organization type: Bundle/multiple-indv-mrp-obs-report, Bundle/multiple-indv-mrp-task-report... Show 23 more, Bundle/multiple-summ-report, Bundle/single-gaps-closed-indv-report01, Bundle/single-gaps-closed-indv-report02, Bundle/single-gaps-open-indv-report01, Bundle/single-indv-col-obs-report, Bundle/single-indv-mrp-obs-report, Bundle/single-indv-mrp-task-report, Bundle/single-indv-vte-report-option1, Bundle/single-indv-vte-report-option7, DVPayer04, DaVinciHospital01, DaVinciHospital02, DaVinciHospital03, GapsReportingVendor01, Parameters/col-collect-obs, Parameters/col-submit-obs, Parameters/mrp-submit-obs, Parameters/mrp-submit-task, Parameters/multiple-gaps-indv-report01, Parameters/multiple-gaps-indv-report02, Parameters/single-gaps-closed-indv-report01, Parameters/single-gaps-closed-indv-report02 and Parameters/single-gaps-open-indv-report01
  - Software System Type Codes: Device/deqm-software-system-example
  - SubscriberPolicyholder Relationship Codes: Bundle/single-indv-mrp-obs-report, Bundle/single-indv-mrp-task-report, Coverage/coverage01, Parameters/mrp-submit-obs and Parameters/mrp-submit-task
  - UsageContextType: EXMPromotingInteroperabilityMeasure and FHIRPathExample
  - identifierType: Bundle/multiple-indv-mrp-obs-report, Bundle/multiple-indv-mrp-task-report... Show 33 more, Bundle/multiple-summ-report, Bundle/non-document-gaps-in-care, Bundle/sde-example-patient-data-bundle, Bundle/single-gaps-closed-indv-report01, Bundle/single-gaps-closed-indv-report02, Bundle/single-gaps-open-indv-report01, Bundle/single-indv-col-obs-report, Bundle/single-indv-mrp-obs-report, Bundle/single-indv-mrp-task-report, Bundle/single-indv-vte-report-option1, Bundle/single-indv-vte-report-option7, DVPayer04, DaVinciHospital01, DaVinciHospital02, DaVinciHospital03, GapsReportingVendor01, Parameters/col-collect-obs, Parameters/col-submit-obs, Parameters/mrp-submit-obs, Parameters/mrp-submit-task, Parameters/multiple-gaps-indv-report01, Parameters/multiple-gaps-indv-report02, Parameters/single-gaps-closed-indv-report01, Parameters/single-gaps-closed-indv-report02, Parameters/single-gaps-open-indv-report01, Patient/gaps-patient01, Patient/gaps-patient02, Patient/patient01, Patient/patient02, Patient/patient03, Practitioner/practitioner01, Practitioner/practitioner02 and Practitioner/practitioner03
  - ActCode: Bundle/multiple-indv-mrp-obs-report, Bundle/multiple-indv-mrp-task-report... Show 30 more, Bundle/non-document-gaps-in-care, Bundle/sde-example-artifact-bundle, Bundle/sde-example-patient-data-bundle, Bundle/single-gaps-closed-indv-report01, Bundle/single-gaps-closed-indv-report02, Bundle/single-gaps-open-indv-report01, Bundle/single-indv-mrp-obs-report, Bundle/single-indv-mrp-task-report, Bundle/single-indv-vte-report-option1, Bundle/single-indv-vte-report-option7, DEQMGapsInCareDetectedIssue, DetectedIssue/gaps-detectedissue01, DetectedIssue/gaps-detectedissue02, DetectedIssue/gaps-detectedissue03, DetectedIssue/gaps-detectedissue04, DetectedIssue/gaps-detectedissue05, Encounter/encounter01, Encounter/encounter02, Encounter/encounter03, Encounter/gaps-encounter01, Encounter/gaps-encounter02, Encounter/gaps-encounter03, Encounter/nhsn-iip-en101, Parameters/mrp-submit-obs, Parameters/mrp-submit-task, Parameters/multiple-gaps-indv-report01, Parameters/multiple-gaps-indv-report02, Parameters/single-gaps-closed-indv-report01, Parameters/single-gaps-closed-indv-report02 and Parameters/single-gaps-open-indv-report01
  - AdministrativeGender: MeasureReport/summ-contained-supplemental
  - MaritalStatus: Bundle/multiple-indv-mrp-obs-report, Bundle/multiple-indv-mrp-task-report... Show 12 more, Bundle/single-indv-col-obs-report, Bundle/single-indv-mrp-obs-report, Bundle/single-indv-mrp-task-report, Bundle/single-indv-vte-report-option1, Bundle/single-indv-vte-report-option7, Parameters/col-collect-obs, Parameters/col-submit-obs, Parameters/mrp-submit-obs, Parameters/mrp-submit-task, Patient/patient01, Patient/patient02 and Patient/patient03
  - RoleCode: Bundle/sde-example-patient-data-bundle and Location/nhsn-iip-loc101
- Using RxNorm codes of type SAB=RXNORM as this specification describes does not require a UMLS license. Access to the full set of RxNorm definitions, and/or additional use of other RxNorm structures and information requires a UMLS license. The use of RxNorm in this specification is pursuant to HL7's status as a licensee of the NLM UMLS. HL7's license does not convey the right to use RxNorm to any users of this specification; implementers must acquire a license to use RxNorm in their own right.
  Show Usage
  - RxNorm: Bundle/sde-example-patient-data-bundle, MeasureReport/sde-example, MedicationRequest/nhsn-iip-add101 and MedicationRequest/nhsn-iip-add101-10

Hospital icons created by Freepik - Flaticon