From eCQM to dQM: Three shifts leaders need to understand
Subscribe to our newsletter
SubscribeAfter two decades implementing quality measures across CMS programs, HEDIS, and The Joint Commission, I can tell you exactly how the annual cycle goes:
A new specification is published. Vendors and implementation teams translate it into system-specific logic. Quality teams spend weeks or months validating results, reconciling discrepancies, and trying to explain why two systems running the “same measure” don’t produce the same output.
Just when you get everything stabilized, the next update cycle begins.
I’ve seen this cycle play out many times: complex implementation environments, manual spec interpretation, inconsistent results across implementations. Over time, quality teams have reluctantly accepted it as “just how measurement works.”
Digital Quality Measures (dQMs) don’t improve this workflow. They eliminate entire steps from it.
This isn’t just a technology upgrade. It’s an operating model shift, and most organizations haven’t fully grasped what that means yet.
To be clear, this isn’t a critique of vendors. Many have done enormous work to operationalize highly complex specifications. The variation we’ve seen was a predictable outcome of narrative specifications that required human interpretation rather than executable logic.
So, in this blog, I want to focus on what often gets missed in the dQM conversation: what actually changes in practice when measures become digital.
What is a dQM?
Let’s start with what isn’t changing.
dQMs are still quality measures:
- Same CQL-based logic foundation
- Same CMS regulations and NCQA oversight
- Same measurement intent
What’s different is how they’re specified and executed:
- FHIR-native: Measures work directly with FHIR data models, not proprietary formats
- Machine-executable: The specification is executable code — not prose requiring interpretation
- Unambiguous: One measure definition produces one result, regardless of who executes it
- Standardized: The same CQL runs on any compliant engine — no vendor-specific translations
Think of it this way: instead of a 47-page PDF describing how to identify bilateral mastectomy exclusions, the dQM specification is the code that identifies them. The spec and the logic are the same artifact.
For CMS and NCQA, this shift also enables more consistent, auditable reporting and reduces the operational burden of implementing and maintaining measures across the ecosystem.
If you’d like deeper background on how CQL enables digital quality measurement, we previously hosted a webinar with NCQA on this topic: CQL and the Future of Quality Measures. It provides helpful context for the ideas explored here.
The three operational shifts
Shift 1: The interpretation layer disappears
Most quality teams don’t just run measures. They manage interpretation.
I’ve debugged enough discrepancies to recognize the pattern: Two systems. Same spec. Same data. One reports 72%, the other 68%. Both are confident, and both can justify their logic.
This is one reason quality reporting has historically been so expensive. The industry has relied on human interpretation and implementation-specific translation as the default delivery model.
With eCQMs:
- Specification: 40+ pages of written specifications, tables, decision trees
- Vendor / implementation teams: Translate into implementation-specific logic
- Your team: Validates the interpretation
- Discrepancy: Call vendor, debate, wait for fix
- Result: Different implementations can produce different results
Many measures have been expressed in CQL for years — but typically against the Quality Data Model (QDM). Implementers still had to interpret QDM semantics and translate them into system logic. The interpretation layer remained.
With dQMs:
- Specification is executable CQL against FHIR
- No interpretation and translation step needed
- All engines execute identical logic
- Discrepancies are inspected via execution trace to see exactly what happened
- Result: Transparent, reproducible validation
For example (oversimplified):
An eCQM might express a bilateral mastectomy exclusion using QDM-based CQL. Implementers must interpret how to normalize intervals, derive relevant dates, and evaluate temporal conditions.
In a dQM, the logic is computable directly against FHIR data. The question shifts from “How do we implement this?” to “Does our data support this?” Same measure, same code, same result.
For vendors and implementers, this reduces annual reimplementation cycles and allows teams to focus on performance, scalability, and workflow integration instead of rebuilding logic year after year. Organizations can now focus on using the results to improve patient outcomes.
Shift 2: Validation changes from reconciliation to debugging
Validation is one of the most expensive parts of quality measurement; not because it isn’t necessary, but because it’s often opaque.
When results don’t match expectations, teams:
- Compare outputs across systems
- Pull patient-level details
- Open vendor tickets
- Rerun measures repeatedly until the numbers finally align
An annual update cycle can quickly turn into weeks of reconciliation.
With dQMs, validation becomes different.
Because the measure logic is standardized and executable, discrepancies are less about “Did the logic get implemented correctly?” and more about “do we have the right data, in the right structure, and can we explain the outcome?”
Instead of reconciling implementations, teams debug data and trace execution. Data quality improvements propagate across every measure — making validation transparent and repeatable. That’s a fundamental operational change.
Shift 3: From reporting cycles to continuous measurement
The third shift often underestimated: the cost of change.
Measure specifications evolve constantly. New measures are introduced. Existing measures are revised. Corrections are issued.
In the traditional eCQM model, every update triggers:
- Interpretation
- Implementation
- Testing
- Release cycles
- Revalidation
That’s why measure updates often take weeks or months to operationalize.
With dQMs, updates are delivered as executable CQL packages. Instead of waiting on vendor timelines, you load updated content, run the new logic, validate it against your data, and deploy it to production in days.
But the bigger impact isn’t just speed — it’s frequency.
When execution becomes standardized and easier to deploy, organizations aren’t limited to quarterly or annual compliance runs. Measures can be executed continuously and used operationally.
That’s the difference between:
- “Last quarter, 72% of diabetic patients had HbA1c under control.”
and - “Today, 247 diabetic patients are overdue for HbA1c testing.”
Instead of retrospective reporting, measurement becomes proactive intervention. That’s where quality improvement actually happens.
Why this matters (and what’s next)
These three shifts aren’t incremental improvements. They fundamentally change the cost structure, scalability, and transparency of quality measurement.
But this doesn’t happen overnight. Even organizations with mature reporting infrastructure need time to build the FHIR foundation:
- Data mapping
- Terminology alignment
- Validation of workflows and governance
The earlier you start, the more control you retain over the transition, and the sooner you’ll reap the benefits.
CMS and NCQA have both also signaled clearly that digital quality measurement is the long-term direction, with adoption accelerating over the next several years.
But the real impact goes beyond compliance. Once measure execution becomes standardized and repeatable, organizations spend less time on reconciliation and rework — and more time using quality measurement as an operational tool.
I hear the same concern from quality leaders, implementers, and vendors alike: “This sounds expensive and disruptive. We’re already stretched thin.”
In my next blog, I’ll show why the opposite is true, and why organizations starting now are building advantages that late adopters will struggle to match.
If you’re considering dQM adoption, get in touch and we’d be happy to share what this looks like in practice. Or check out our Implementing CQL-based Quality Measures training.
A couple of our other resources:
