For a Director of Analytics, the most consequential change in quality measurement over the next five years is not a new measure or a tougher cut point. It is the quiet retirement of the translation layer your team has lived inside for years.
NCQA is moving HEDIS, the quality measure set that feeds Medicare Advantage Star Ratings and most commercial and Medicaid quality programs, to a fully digital model. That shift rewrites where the hard work lives, where errors hide, and where vendors and internal teams actually compete. Here is the timeline, and then the part that should shape your next three budget cycles.
What is actually changing
NCQA has committed to making HEDIS reporting fully digital by measurement year 2030. The hybrid methodology, the one that blends administrative claims data with manual medical record review, is scheduled to phase out by measurement year 2029. Some hybrid measures will revert to an administrative-only method. Others will move to Electronic Clinical Data Systems reporting, known as ECDS, and the long-term destination for the whole set is digital quality measures expressed in two computable standards: the HL7 FHIR data model and Clinical Quality Language, or CQL.
You can already feel the transition in the measurement-year 2026 specifications. NCQA rewrote the technical specification format so it aligns with FHIR, and it changed some of the vocabulary in the process. “Eligible population” is now initial population. “Required exclusions” are now denominator exclusions. There are other term changes in the same direction, all of them nudging the language of HEDIS toward the language of FHIR and CQL. The intent of each measure does not change. The way you are expected to compute it does.
That is the whole story in one sentence: the computation is moving from prose your team interprets to logic NCQA publishes. Everything else follows from that.
ECDS, dQM, and eCQM: the vocabulary that trips teams up
Three acronyms get used loosely in this transition, and conflating them leads to bad planning. It is worth being precise.
A digital quality measure, or dQM, is a self-contained package. It includes the human-readable technical specification alongside the computable, interoperable version expressed in the FHIR standard and CQL. The dQM is the artifact you execute rather than interpret.
ECDS is a reporting standard, NCQA’s method for using structured electronic clinical data to calculate a measure. It is the on-ramp to digital reporting, and it is where a growing share of the HEDIS set already lives.
An eCQM, or electronic clinical quality measure, is a related but distinct lineage. eCQMs were originally developed for the federal EHR incentive programs and are designed for eligible clinicians and hospitals, drawing primarily on EHR data. They share the FHIR and CQL DNA, which is why the worlds are converging, but they are not the same program as HEDIS ECDS reporting.
If your roadmap treats these as interchangeable, you will mis-scope the work. The practical point for a health plan is simple: the HEDIS set is moving toward ECDS and FHIR and CQL, and that is the path you have to be ready to run.
Why this is an infrastructure story, not a measures story
For years, the hard and valuable part of quality engineering was translation. NCQA published a written specification, dense and precise, and your team turned that prose into SQL against your warehouse. That translation was a genuine skill. It was also a genuine source of error and a place where vendors quietly competed, because two careful teams could read the same specification and produce slightly different numerators.
That advantage is evaporating. When NCQA publishes the measure logic itself in FHIR and CQL, nobody competes on who can read the specification correctly, because the logic is the artifact. You do not interpret it. You execute it. The skill that used to separate a strong quality shop from a mediocre one is being standardized by the body that writes the measures.
So the competition moves. It moves upstream of the logic, into your data, and downstream of the logic, into what you do with the answer. Both of those are harder than spec translation ever was, and neither is solved by buying a measure engine.
The real bottleneck is upstream, and nobody wants to talk about it
Here is the part that does not fit on a vendor slide. Your data does not arrive in FHIR. It arrives as claims feeds in one shape, eligibility files in another, lab results through an interface that predates half your team, pharmacy data from a benefit manager, and a dozen EHR extracts that disagree about how to spell a diagnosis, how to represent a date, and where a result value lives. The published HEDIS logic in CQL expects clean, conformant FHIR resources as input. It cannot run against your raw feeds.
That gap is the new bottleneck. Mapping your messy, multi-source reality into standardized FHIR resources, Patient, Condition, Observation, MedicationDispense, Encounter, and the rest, with codes bound correctly to LOINC, SNOMED, RxNorm, and ICD-10, is the hard, unglamorous, decisive work of the next five years. NCQA itself has been direct that success in the digital era depends on accurate data that can be trusted, mapped and transformed into FHIR before it ever reaches calculation.
Whoever owns that normalization owns the outcome. If the FHIR resources going into the engine are wrong, the engine will compute a precise, defensible, completely incorrect rate, and it will do it quickly. This is why the digital transition does not make quality measurement easier. It moves the difficulty from a place many teams had mastered, spec reading, to a place most teams have underinvested in, data normalization and conformance.
The reasoning layer is downstream, and it is where the value is
Even a perfectly computed rate is not an answer. It is a number. Knowing that your breast cancer screening rate is 71.4 percent tells you where you stand. It does not tell you which members fell out of the initial population and why, which ones sit just outside the denominator on a technicality you could fix, or which apparent gaps are real versus artifacts of a mapping error three steps upstream.
That is the work the measure engine will never do for you. The engine gives you the number. The reasoning layer, the part that can trace a single member back through the FHIR resources, through the normalization step, to the raw source row that put them in or out, is what turns the number into a decision. In a world where everyone runs the same published CQL against their own data, the rate is a commodity. The explanation is the differentiator.
The readiness checklist before measurement year 2029
If you are the analytics leader who has to make this real, here is the honest self-assessment to run now, while you still have runway.
First, can you produce conformant FHIR resources from your source data today, or are you still living in custom extracts and one-off SQL? The ECDS domain keeps expanding. Roughly 19 HEDIS measures were reportable through ECDS for measurement year 2025, and for measurement year 2026 NCQA added seven measures, retired two, and transitioned four more into ECDS reporting. Each cycle moves more of the set into the digital path, and the path runs one direction only.
Second, can you execute CQL, or are you still re-implementing measure logic by hand? Re-implementing logic that NCQA already publishes in a computable form is technical debt you are choosing to take on, and it reintroduces exactly the translation error the digital standard was designed to remove.
Third, is your lineage intact from source to score? When a rate looks wrong, and one will, can you trace it back through the FHIR resources, through the normalization layer, to the specific source row that caused it? If you cannot, you will spend measurement year 2029 debugging numbers you cannot explain to an auditor, a regulator, or your own Chief Medical Officer.
Fourth, is your terminology current? It sounds small, but code, documentation, and dashboards that still say “eligible population” will drift out of step with specifications that now say initial population, and that drift compounds quietly until a handoff breaks.
How to sequence the work
The good news is that NCQA built a transition window on purpose, and you can use it. Many measures pass through optional or dual reporting status during the changeover, which means you can run the digital version in parallel with your established method and compare results before anything is official. That parallel period is the cheapest insurance you will ever buy. It lets your team build trust in CQL execution, find the mapping errors while they are still harmless, and document the differences before they count toward a rating.
A reasonable sequence looks like this. In the near term, stand up the ability to produce and validate FHIR resources for the measures already in ECDS, and run them in parallel with your current process. In the middle term, push more of your source domains, claims, labs, pharmacy, and clinical, into your FHIR normalization pipeline, and begin using digital results for measures where your confidence is high. By the time the hybrid method retires in measurement year 2029, the goal is that digital is your primary path and the legacy method is the fallback, not the reverse.
The teams that win the next five years will not be the ones who read specifications fastest. That race is ending. They will be the ones who normalized their data into FHIR cleanly and kept their lineage honest from source to score.
A worked example: the gap that is not a gap
Picture a single measure, colorectal cancer screening, and a single member who shows up as an open gap. The published logic says she has no qualifying screening on record. The care team gets a gap alert, someone makes an outreach call, and the member says, correctly, that she had a colonoscopy eighteen months ago.
What happened? The colonoscopy lived in a gastroenterology feed that your pipeline maps into FHIR, but the procedure was recorded in a local code that never got bound to the standard value set the measure expects. The data was there. The normalization was not. The measure engine did exactly what it was told, and it was told something incomplete.
Now multiply that by every measure, every source feed, and every member. In the hybrid era, a chart chase might have caught it. In the digital era, there is no chart chase. The FHIR resource is the truth the engine sees, and if the resource is wrong, the gap is wrong, the outreach is wasted, and the rate that lands on your Star Ratings is wrong in a way nobody can explain after the fact, unless the lineage was captured at every step. That is the whole argument for treating normalization and lineage as first-class infrastructure rather than plumbing you bolt on at the end.
The honest version
The digital transition of HEDIS is not a software purchase. It is an infrastructure decision, and it is the kind that stays invisible right up until the year it is not. The plans and provider groups that treat measurement year 2026 through 2029 as build time will move into the digital era with data they trust and answers they can defend. The ones that wait will be reverse-engineering their pipelines in the year the numbers count, which is the worst possible time to learn that a mapping was wrong. Build time is cheap now and ruinously expensive then.
That normalization layer, transparent and traceable from the raw row to the reported rate, is exactly the foundation we think every serious quality operation needs. It is also the part we refuse to treat as a black box, because a rate you cannot trace is not an answer, no matter how precisely the engine computed it.
HEDIS is a registered trademark of the National Committee for Quality Assurance. FHIR is a registered trademark of Health Level Seven International.