dQMs don’t cost more, waiting does

The most common reaction to Digital Quality Measures (dQMs) is a mix of curiosity and skepticism. Quality leaders see the potential, but the follow-up is usually the same: “This sounds like a massive technical migration just to meet a 2030 deadline. Why should I prioritize this now?”

But if compliance is the only reason you’re looking at this, you’re missing the actual value.

It isn’t a rip-and-replace. The hidden cost of that assumption grows every year you stay on legacy infrastructure. For a fuller breakdown of what actually changes with dQMs, see my last post.

In this post, I’ll run through what staying on legacy systems is actually costing you, and what dQMs actually make possible.

The hidden costs of the status quo

Staying on legacy eCQM or hybrid systems isn’t the ‘safe, free’ option. It carries costs that most organizations have absorbed so gradually they’ve stopped questioning them. Below we’ve outline some of the areas where those costs actually show up.

Re-implementation on every update cycle

Every specification update triggers weeks of development and QA per measure, per system. That’s not a vendor problem; it’s what the narrative specification model requires of everyone building on it.

Structural measure discrepancies

Reconciliation meetings happen because two systems running the same measure produce different results. When the specification is a PDF rather than executable code, some degree of variation is a structural outcome, not an implementation failure. With dQMs, the logic is identical everywhere it runs. Same measure, same data, same result, every time.

Opaque, expensive validation

Without visibility into how the result was calculated, analysts spend hours pulling patient records and re-running measures to understand a discrepancy. That work disappears when you can inspect exactly which logic branch produced the result.

Retroactive data discovery

In a legacy cycle, you often don’t discover a data mapping issue until after the measurement period closes. At that point, there’s nothing left to do but report the gap. Continuous execution against live FHIR data surfaces those issues while you can still act on them.

Slow, costly custom development

Building measures for populations outside standard CMS or NCQA coverage usually means custom development work, long timelines, and logic tied to a specific platform. That makes iteration slow and expensive regardless of who’s doing the work.

Ongoing manual abstraction

Where FHIR data mapping isn’t complete, teams are still doing this work by hand. For most organizations, that covers a large portion of their measure portfolio.

Add it up across your measure portfolio, and the status quo has a price tag. Here’s a conservative estimate of how much your organization could save by switching to a dQM model.

What you actually gain

The efficiency gains are real, but it’s the capability story that tends to shift the conversation for CFOs, Quality Directors, and product leaders.

Real-time care gap closure

Because a dQM engine runs continuously against a live FHIR data layer, you’re no longer looking at last quarter’s report. You’re looking at today’s overdue patients. In a value-based care or Star Rating context, closing a gap in February versus finding out in April that you missed it is the difference between earning the bonus and reporting the miss.

Custom measures for your specific populations

Every organization has cohorts that standard CMS or NCQA measures don’t fully capture: SDOH risk populations, rural health programs, specific chronic condition protocols. In a dQM environment, you can author that logic in CQL and run it on the same engine as your required measures. You build what your programs need, on your timeline.

Write once, run everywhere

If you’re an ACO or health system reporting the same measures to multiple payers, dQMs let you consolidate. One logic set, one engine, multiple reporting outputs.

What’s actually required

The honest answer: less than most people assume, but more than a weekend project. The three pillars are:

• A FHIR-first data layer. Your clinical data needs to be accessible in FHIR format. If you’ve been building toward CMS-0057-F compliance, you’re already on this path.
• A production-grade CQL engine. This is the execution environment that runs the measure logic. It doesn’t require anything proprietary; the whole stack runs on open standards.
• Data validation and mapping. You still need to confirm your FHIR data is complete and correctly structured. That’s not a new concept; it’s just a more manageable problem than reconciling vendor implementations.

The good news: there’s still time to do this properly. CMS is targeting pilot programs as early as 2027 for select measures, with broader adoption toward 2030.

The organizations moving now are building an advantage that will be hard to close later. The ones treating this as a future problem are paying for that assumption today.

The case for moving first

Quality leaders, architects, and vendor teams tell me the same thing: they’re stretched, and a new infrastructure initiative feels like one more thing. The organizations moving now aren’t clearing their roadmaps to do it. They’re starting with one or two measures, proving the execution model, and building from there.

We’ve been doing this work alongside NCQA, who used our CQL engine to validate their own digital HEDIS measures. What we’ve seen consistently is that getting started is the hard part. Once teams are in it, the complexity is always smaller than they expected. I’ve never seen an organization wish they’d started this later.

If you’re evaluating dQM adoption and want to understand what this looks like in practice, get in touch. Or explore our Implementing CQL-based Quality Measures training.