Guide · Quality Measurement · Updated July 2026
CQM Requirements Through 2030: The Move to Digital Quality Measures
CQM requirements change every year, and CMS has been clear about where they are going: FHIR-based digital quality measures. Here is what applies today, what is changing, and how to prepare.
2026 · NOW
QRDA-based eCQM reporting, updated annually. Draft FHIR dQMs out for public comment.
2027–2028
CMS’s stated goal: QDM-based eCQMs and FHIR dQMs both accepted
2029–2030 · TARGET
FHIR dQMs only; fully digital quality measurement
eCQM requirements today
Electronic clinical quality measures (eCQMs) are calculated from certified EHR data using CMS specifications and reported across several programs. As of the 2026 performance year, the core eCQM requirements look like this:
- MIPS. Clinicians and groups report quality measures, including eCQMs, with annual updates to the measure list and scoring rules.
- Medicare ACOs. Under the APP Plus measure set, Shared Savings Program ACOs report eCQMs across their entire patient population or Medicare CQMs for ACO patients, aggregated across every EHR in the ACO. Our ACO eCQM Reporting Guide covers this in depth.
- Hospital IQR and Promoting Interoperability. Hospitals report a eCQMs each year from the available set, with progressive expansion of mandatory measures.
- HRSA UDS. Health center clinical tables are aligning with eCQM specifications, and UDS+ adds patient-level FHIR submission. See the UDS Reporting Guide.
Submissions today are largely QRDA based, and each year’s specifications are published in advance through the eCQI Resource Center with final details set in annual rulemaking.
Between January 21 and February 25, 2026, CMS posted draft FHIR digital quality measure packages for public comment covering eligible clinician, hospital inpatient, and hospital outpatient programs. CMS has FHIR specifications for more than 70 measures and has described FHIR as the standard for new measures going forward.
The direction of travel, year by year
While exact future-year specifications are set annually, the trajectory has been consistent across recent rulemaking, CMS’s digital quality measurement roadmap, and what CMS staff have said publicly through 2026.
Now · 2026
Annual eCQM updates continue, dQMs go out for comment
Specifications refresh each year and QRDA remains the primary submission path. APP Plus eCQM reporting phases in for ACOs, and hospital eCQM measures change annually. In parallel, CMS ran its first broad public comment period on draft FHIR dQMs. Response was largely positive; the recurring concerns were data latency, vendor readiness, realistic test cases, and clearer provenance guidance.
Near term · 2027–2028
Consolidation, then a dual-acceptance window
Measure sets consolidate around the Universal Foundation, and FHIR-based reporting options expand. CMS staff have described the goal as a window in which both QDM-based eCQMs and FHIR dQMs are accepted by 2028.
Target · 2029–2030
FHIR dQMs only
The goal CMS has articulated is that only FHIR-based dQMs are accepted past 2029, completing the move to fully digital quality measurement computed from interoperable data.
Important: the 2028 and 2029 dates above are goals, as CMS staff have stated publicly, most recently at the July 2026 HL7 FHIR Connectathon. They are not in a final rule. CMS finalizes each performance year’s requirements through annual rulemaking, so always confirm a specific year against that year’s final rule and the eCQI Resource Center. Plan infrastructure to prepare for CMS changes; commit to specifics only once they are finalized.
What is a digital quality measure?
CMS defines digital quality measures (dQMs) as quality measures that use standardized digital data from one or more sources of health information and are exchanged via interoperable standards. In practice that means FHIR: measure logic that reads FHIR resources directly instead of depending on program-specific extract formats.
The practical difference from today’s eCQMs is where the data comes from and how automatically it flows. An eCQM is calculated from certified EHR data and submitted in a reporting format on a reporting schedule. A dQM is designed to be computed from interoperable FHIR data whenever it is needed. Measure logic that can run whenever it is needed can run during the visit, not just at submission time.
What actually changes: the standards behind the measures
“Moving to FHIR” is easy to say and hard to picture. Concretely, the transition swaps out the standards a quality measure is written in and the standards it is reported in. CMS and HL7 describe the shift like this:
eCQM Standards → dQM Standards
Current eCQM approach
QDM Data Model
Quality Data Model
CQL Logic
Carries over unchanged
HQMF eCQM
Health Quality Measure Format
→
dQM FHIR approach
QI-Core Profiles
FHIR data model, built on US Core
CQL Logic
Carries over unchanged
QM IG
FHIR Quality Measure IG (Measure resource)
eCQM Reporting → dQM Reporting
Current eCQM approach
QDM Data Model
Quality Data Model
QRDA I
Patient-level results
QRDA III
Aggregate results
→
dQM FHIR approach
QI-Core Profiles
FHIR data model, built on US Core
DEQM Individual
Patient-level MeasureReport
DEQM Summary
Aggregate MeasureReport
Structure follows the eCQM-to-dQM comparison published by CMS and ONC on the eCQI Resource Center.
Read left to right, three things are happening at once.
- The data model changes: QDM, a quality-specific abstraction, gives way to QI-Core, a set of FHIR profiles built directly on top of US Core and base FHIR resources — the same resources your certified API already exposes.
- The measure structure changes: CQL-based HQMF is replaced by the FHIR Quality Measure IG, which specifies how to use the FHIR Measure resource to package a measure’s metadata, logic, and population criteria.
- And the submission format changes: QRDA I and QRDA III are replaced by DEQM MeasureReports — Individual for patient-level results, Summary for aggregate — defined in HL7’s Data Exchange for Quality Measures implementation guide.
Every box on the right is a base FHIR resource plus an implementation guide that constrains it for quality measurement. The data model is US Core resources constrained by QI-Core. The measure itself is the Measure resource constrained by the Quality Measure IG. The report is the MeasureReport resource constrained by DEQM.
CQL logic carries over. The clinical intent of a measure (who is in the denominator, what satisfies the numerator, which exclusions apply) is expressed in Clinical Quality Language today and stays in Clinical Quality Language under dQMs.
See this architecture in practice
Our white paper shows FHIR-based quality logic running in real time inside the EHR workflow, closing gaps in care before the patient leaves.
How far along the standards actually are
A roadmap is only worth planning against if the specifications underneath it are real. Our team sat in the FHIR Quality Reporting with DEQM track at the July 2026 HL7 FHIR Connectathon, and the honest answer is that the dQM content set is much further along than most quality teams assume.
74
measures in the 2025 annual update dQM content set
3,964
test cases with published expected results
98.16%
passing as of July 2026, with issues filed on every remaining discrepancy
Those measures were authored in MADiE from the QDM 2025 annual update and exported as QI-Core 6 FHIR content, with test cases and expected results published alongside them. Three measures still had discrepancies: two missing results across 71 test cases, and one with mismatched results on two.
End-to-end payer/provider exchange was tested under DEQM against measures quality teams already recognize:
- CMS122 (Diabetes HbA1c Poor Control)
- CMS124 (Cervical Cancer Screening)
- CMS125 (Breast Cancer Screening)
- CMS165 (Controlling High Blood Pressure) on the eligible clinician side,
- plus CMS71 (Anticoagulation Therapy for Atrial Fibrillation/Flutter) and CMS1028 (Severe Obstetric Complications) for hospitals.
The full flow was exercised: load terminology, load the measure bundle, define an attributed patient Group, load patient test data, then evaluate individually and in summary.
Two things are worth noting beyond CMS’s own programs:
- NHSN is piloting FHIR-based hospital safety reporting — acute care daily and monthly cohort measures that collect data elements feeding downstream analytics for hypoglycemia and hospital-onset bacteremia.
- In July 2026, HL7’s board approved a new Quality Improvement FHIR Accelerator, with letters of intent from CMS, CDC, VHA, NCQA, IPRO, ICF, Bellese, Firely, Smile Digital Health, and TMIT. Organizations signing the statement of understanding by September 30, 2026 count as founding members.
The newest piece: USCDI+ Quality and US Quality Core
The biggest obstacle to dQMs: the gap between what a certified EHR API exposes and what a quality measure actually needs.
USCDI+ Quality is the quality-specific extension of USCDI. Version 1 was released at the end of January 2026 with 179 data elements across 29 data classes; a draft version 2, whose comment period closed on July 17, 2026, expands that to 188 elements across 30 classes. USCDI+ Quality names the data quality programs need. It is not, on its own, a technical specification.
The US Quality Core implementation guide is what turns that list into FHIR. It is built on US Core 6.1.0 and QI-Core 6.0.0, maps each USCDI+ Quality element to a FHIR profile, and handles element-level support through a USCDI+ Quality tag rather than a separate must-support flag. It is targeting the September 2026 HL7 ballot cycle. A draft Inferno test kit has already been generated from the IG, with server and client suites that check CapabilityStatement conformance, read and search behavior, and data access.
Why this matters more than it sounds: EHR vendors have optimized for (g)(10) certification and USCDI, and that does not cover everything quality measurement needs. An analysis presented at the July 2026 connectathon found that roughly ten additional data elements in US Core would allow most CMS measures to be calculated straight from a certified (g)(10) endpoint. Closing that gap is exactly what USCDI+ Quality and US Quality Core exist to do.
How to prepare without rebuilding twice
The organizations that will absorb the dQM transition with the least disruption are the ones treating it as an infrastructure decision now rather than a compliance scramble later. Three moves matter most:
- Consolidate measure calculation. If MIPS, ACO, and UDS numbers come from different calculation paths, they will drift. One engine, like CQMsolution, calculating every program from one data foundation removes that entire class of problem.
- Stand up a FHIR data pipeline you actually use. A certified FHIR API that only exists for certification checkboxes will not carry you into dQMs. Ours, the Dynamic FHIR API, already carries production reporting workloads like UDS+ patient-level submission.
- Put quality logic to work before submission day. Running measure logic in real time against FHIR data is the dQM operating model.
The tools we have for the transition
Those three moves are not theoretical. Each one maps to something we already build and run in production today, so you can start the transition with the data and the measures you have right now.
Data conversion
QRDA I to FHIR
The fastest way into FHIR is to stop waiting for your EHR to hand it to you. The Dynamic FHIR API and its Datastore ingest the data you already produce and transform it into FHIR resources.
Real-time measure evaluation
Care Insights API
Care Insights runs dQM logic against a patient’s FHIR data in real time and delivers the result into the clinician’s workflow through HL7 CDS Hooks, the same standard ONC now certifies to under 45 CFR §170.315(j)(20). It is available as a standalone API: CQMsolution is built on the same engine, but it is not a prerequisite.
Coverage
Digital measures we have successfully tested
Our engine currently passes testing on the 69 digital quality measures listed below. The set spans eligible clinician, hospital inpatient, hospital outpatient, and rural emergency hospital reporting, including the hybrid measures that pair EHR data with claims.
| CMS eCQM ID | Measure |
|---|---|
| CMS2 | Preventive Care and Screening: Screening for Depression and Follow-Up Plan |
| CMS22 | Preventive Care and Screening: Screening for High Blood Pressure and Follow-Up Documented |
| CMS50 | Closing the Referral Loop: Receipt of Specialist Report |
| CMS56 | Functional Status Assessment for Total Hip Replacement |
| CMS68 | Documentation of Current Medications in the Medical Record |
| CMS69 | Preventive Care and Screening: Body Mass Index (BMI) Screening and Follow-Up Plan |
| CMS71 | Anticoagulation Therapy for Atrial Fibrillation/Flutter |
| CMS72 | Antithrombotic Therapy by End of Hospital Day 2 |
| CMS74 | Primary Caries Prevention Intervention as Offered by Dentists |
| CMS75 | Children Who Have Dental Decay or Cavities |
| CMS90 | Functional Status Assessments for Heart Failure |
| CMS104 | Discharged on Antithrombotic Therapy |
| CMS108 | Venous Thromboembolism Prophylaxis |
| CMS117 | Childhood Immunization Status |
| CMS122 | Diabetes: Glycemic Status Assessment Greater Than 9% |
| CMS124 | Cervical Cancer Screening |
| CMS125 | Breast Cancer Screening |
| CMS128 | Antidepressant Medication Management |
| CMS129 | Prostate Cancer: Avoidance of Overuse of Bone Scan for Staging Low Risk Prostate Cancer Patients |
| CMS130 | Colorectal Cancer Screening |
| CMS131 | Diabetes: Eye Exam |
| CMS133 | Cataracts: 20/40 or Better Visual Acuity within 90 Days Following Cataract Surgery |
| CMS135 | Heart Failure (HF): ACE Inhibitor or ARB or ARNI Therapy for Left Ventricular Systolic Dysfunction (LVSD) |
| CMS136 | Follow-Up Care for Children Prescribed ADHD Medication |
| CMS137 | Initiation and Engagement of Substance Use Disorder Treatment |
| CMS138 | Preventive Care and Screening: Tobacco Use: Screening and Cessation Intervention |
| CMS139 | Falls: Screening for Future Fall Risk |
| CMS142 | Diabetic Retinopathy: Communication with the Physician Managing Ongoing Diabetes Care |
| CMS143 | Primary Open-Angle Glaucoma (POAG): Optic Nerve Evaluation |
| CMS144 | Heart Failure (HF): Beta-Blocker Therapy for Left Ventricular Systolic Dysfunction (LVSD) |
| CMS146 | Appropriate Testing for Pharyngitis |
| CMS149 | Dementia: Cognitive Assessment |
| CMS153 | Chlamydia Screening in Women |
| CMS154 | Appropriate Treatment for Upper Respiratory Infection (URI) |
| CMS155 | Weight Assessment and Counseling for Nutrition and Physical Activity for Children and Adolescents |
| CMS156 | Use of High-Risk Medications in Older Adults |
| CMS157 | Oncology: Medical and Radiation – Pain Intensity Quantified |
| CMS159 | Depression Remission at Twelve Months |
| CMS165 | Controlling High Blood Pressure |
| CMS190 | Intensive Care Unit Venous Thromboembolism Prophylaxis |
| CMS314 | HIV Viral Suppression |
| CMS334 | Cesarean Birth |
| CMS347 | Statin Therapy for the Prevention and Treatment of Cardiovascular Disease |
| CMS349 | HIV Screening |
| CMS506 | Safe Use of Opioids – Concurrent Prescribing |
| CMS529 | Core Clinical Data Elements for the Hybrid Hospital-Wide Readmission (HWR) Measure with Claims and Electronic Health Record Data |
| CMS645 | Bone Density Evaluation for Patients with Prostate Cancer and Receiving Androgen Deprivation Therapy |
| CMS646 | Intravesical Bacillus-Calmette-Guerin for Non-Muscle Invasive Bladder Cancer |
| CMS771 | Urinary Symptom Score Change 6-12 Months After Diagnosis of Benign Prostatic Hyperplasia |
| CMS816 | Hospital Harm – Severe Hypoglycemia |
| CMS819 | Hospital Harm – Opioid-Related Adverse Events |
| CMS826 | Hospital Harm – Pressure Injury |
| CMS832 | Hospital Harm – Acute Kidney Injury |
| CMS844 | Core Clinical Data Elements for the Hybrid Hospital-Wide All-Condition All-Procedure Risk-Standardized Mortality Measure (HWM) |
| CMS871 | Hospital Harm – Severe Hyperglycemia |
| CMS951 | Kidney Health Evaluation |
| CMS986 | Malnutrition Care Score |
| CMS996 | Appropriate Treatment for ST-Segment Elevation Myocardial Infarction (STEMI) Patients in the Emergency Department (ED) |
| CMS1028 | Severe Obstetric Complications |
| CMS1056 | Excessive Radiation Dose or Inadequate Image Quality for Diagnostic Computed Tomography (CT) in Adults (Clinician Level) |
| CMS1074 | Excessive Radiation Dose or Inadequate Image Quality for Diagnostic Computed Tomography (CT) in Adults (Facility Inpatient) |
| CMS1154 | Screening for Abnormal Glucose Metabolism in Patients at Risk of Developing Diabetes |
| CMS1157 | HIV Annual Retention in Care |
| CMS1173 | Diagnostic Delay of Venous Thromboembolism in Primary Care |
| CMS1188 | Sexually Transmitted Infection (STI) Testing for People with HIV |
| CMS1206 | Excessive Radiation Dose or Inadequate Image Quality for Diagnostic Computed Tomography (CT) in Adults (Facility OOR) |
| CMS1218 | Hospital Harm – Postoperative Respiratory Failure |
| CMS1244 | Emergency Care Access & Timeliness (HOQR) |
| CMS1264 | Emergency Care Access & Timeliness (REHQR) |
eCQM and dQM requirements: frequently asked questions
What is the difference between an eCQM and a dQM?
An eCQM is an electronic clinical quality measure calculated from certified EHR data and reported through formats like QRDA on a program schedule. A digital quality measure (dQM) is CMS’s broader, next-generation concept: measure logic that computes from standardized, interoperable digital data, in practice FHIR resources, potentially from multiple sources. Every eCQM is expected to have a dQM successor as CMS completes the transition; the logic is similar, but the data plumbing and timing flexibility are fundamentally different.
What replaces QRDA, QDM, and HQMF under digital quality measures?
Each current standard has a FHIR successor. The QDM data model is replaced by QI-Core, a set of FHIR profiles built on US Core and base FHIR resources. CQL-based HQMF, which packages a measure’s structure, is replaced by the FHIR Quality Measure Implementation Guide (the QM IG), which specifies how the FHIR Measure resource carries a measure’s metadata, logic, and population criteria. For reporting, QRDA I (patient-level) becomes the DEQM Individual MeasureReport and QRDA III (aggregate) becomes the DEQM Summary MeasureReport, both defined in HL7’s Data Exchange for Quality Measures (DEQM) implementation guide. The one component that does not change is CQL: the measure logic itself is written in Clinical Quality Language today and remains in CQL under dQMs, which is why the transition affects how measure data is represented and submitted rather than what the measures actually calculate.
Are the eCQM requirements for 2028 or 2030 final yet?
No. CMS finalizes each performance year’s measure specifications and program requirements through annual rulemaking, typically the year before they take effect. What exists for later years is direction rather than regulation: CMS staff have publicly described a goal of accepting both QDM-based eCQMs and FHIR dQMs by 2028 and only FHIR dQMs past 2029, and recent rules have steadily expanded mandatory eCQM counts and FHIR-based options. Those dates are goals, not finalized requirements. Plan infrastructure against the direction; confirm specifics against each year’s final rule.
Will QRDA go away?
Eventually, but not abruptly. QRDA I and III remain the workhorse submission formats for eCQM programs today, and CMS has kept them in place while FHIR-based alternatives mature. The transition CMS has described is a dual-acceptance window rather than a cutover: both QDM-based eCQMs and FHIR dQMs accepted around 2028, with FHIR dQMs the only accepted path past 2029.
What are USCDI+ Quality and the US Quality Core IG?
USCDI+ Quality is the quality-specific extension of USCDI — the list of data elements quality programs need beyond the core certified set. Version 1 arrived at the end of January 2026 with 179 elements across 29 data classes, and draft version 2 expands it to 188 elements across 30 classes. Because a data element list is not a technical specification, the US Quality Core implementation guide translates it into FHIR: built on US Core 6.1.0 and QI-Core 6.0.0, mapping each element to a profile and flagging element-level support through a USCDI+ Quality tag. It is targeting the September 2026 HL7 ballot cycle and already has a draft Inferno test kit. Practically, this is the work of closing the gap between what a certified (g)(10) API exposes and what a measure needs to calculate.
Can FHIR handle patient-level quality reporting at population scale?
This is the most common practical objection, and it was raised directly at the July 2026 HL7 connectathon: registries routinely need data on 100,000-plus patients to calculate measures like CMS2, Bulk FHIR can be slow, and some EHRs cap how many patients can be exported in a single request. The answer given was that several approaches are viable and that current implementations are seeing reasonable performance with patient-at-a-time access, where the measure retrieves only the data of interest across the relevant measure set rather than bulk-exporting entire records. It remains an open engineering question, which is a good argument for running a FHIR pipeline against real production volumes now rather than discovering your ceiling in a submission window.
What should we be doing about dQMs right now?
Three things: consolidate measure calculation onto one engine so program numbers cannot drift apart, make your FHIR data pipeline a production system rather than a certification artifact, and start using quality logic in real time where it benefits you today, such as point-of-care gap closure. All three pay for themselves under current programs and are exactly the capabilities dQM reporting will require.
Get ahead of the dQM transition
The same team that tracks these rules builds the certified engine and FHIR pipeline behind them. Tell us where your quality program stands.