MHDC Quality Measures Specifications and Implementation Guides
**NEW** Quality Measures FHIR Implementation Guide (IG), Version 1.0.0
Document Files (Released June 9, 2026):
Release Notes:
The MHDC Quality Measures FHIR IG (v1.0.0) builds on the established MHDC Quality Measures flat-file specification while leveraging HL7® FHIR® standards to support standardized quality measures reporting and clinical data exchange between payers and providers.
The guide uses the HL7 US Core Implementation Guide and selectively leverages Quality Improvement Core (QI-Core) profiles to support quality measurement and reporting requirements not fully addressed by US Core alone. By prioritizing nationally adopted standards and avoiding custom profiles or extensions, the IG aligns with federal operability initiatives while supporting the quality reporting needs of the MHDC community.
Please note that the FHIR IG is an MHDC Member benefit. Email dgc@mahealthdata.org to request access.
Quality Measures Specification, Version 2.0.0
Document Files (Released: Dec 12, 2025):
Release Notes:
v2.0.0 is a backward-compatible update that introduces significant enhancements to v1.1.0 of the specification. This release adds four new data groups to support the ability to capture screening data, social determinants of health (SDOH) interventions, and disability information. Demographic properties have also been expanded to support the collection of sexual orientation and gender identity (SOGI), religion, written and spoken language, English proficiency, and housing status. The update also includes new capabilities to support the collection of validation data—such as updated and verified dates—for race, ethnicity, language, disability (RELD), SOGI, and additional demographic data elements.
For a complete list of all changes, please consult the v2.0.0 Changelog (pdf).
Quality Measures Specification, Version 1.1.0
Document Files (Released: Jan 22, 2021):
Release Notes:
v1.1.0 is a backwards compatible update that primarily fixes issues found during implementation and clarifies usage descriptions in v1.0.3 that some users found confusing or insufficient. It also adds a few additional supported values for race and ethnicity matching those used in the US Core Implementation Guide that stands in for the USCDI requirements in the CMS-mandated clinical data exchanges. In addition, it adds support for an optional summary file indicating how many rows are in each included data group file and an option to upload content in a zip file provided its internal directory structure and file naming matches the rules outlined in the specification. It includes other minor additions and expanded documentation, most notably documentation on how to handle null data within constituent components of the patientID and a change to the definition of diagnoses and their reported date (technically not entirely backwards compatible but no one was actively using the mechanisms outlined in previous versions of the spec and the change was deemed necessary).
For a complete list of all changes, please consult the v1.1.0 change log (pdf).
Quality Measures Specification, Version 1.0.3
Document Files (Released: Jan 31, 2020):
Release Notes:
v1.0.3 changes the name of the specification to Quality Measures Project Specification and provides a new feedback email address, quality_spec@mahealthdata.org, removes the logo from the specification until such time as it can be properly rendered, and fixes the numbering of ID components as well as a couple of other typos.
It also introduces a new Quality Measures Reference Card to use in conjunction with the specification meant to be a portable, printable list of available data groups and their fields. It does not replace the specifications discussion of these elements which remains the gold standard definition both payers and providers should meet.
Quality Measures Specification, Version 1.0.0
Document Files (Released: Dec 31, 2019):
Release Notes:
This is a version 1 specification meant to allow people to start using the process defined within; this version should reflect all of the changes and updates discussed during the review meetings.
