28 Sep
For the last several measurement years, a payer client moving to digital HEDIS reporting had a built-in check most of them never had to think about. Parallel testing required them to run traditional and digital results side by side, and any discrepancy between the two surfaced automatically, before it ever reached a public report. That check is no longer mandatory. The discrepancies it used to catch don’t disappear along with the requirement. They just stop getting caught unless someone builds a replacement for the step NCQA removed.
What did parallel testing actually protect a payer client from?
Under the requirement as it stood, NCQA’s own guidance on parallel testing describes it as a mandatory step for at least one measurement year, comparing traditional and digital HEDIS results side by side to catch discrepancies before an organization relied on digital output for reporting. NCQA’s guidance is direct about why the discrepancies happen in the first place: differences in how data is captured, processed, or mapped into standard data models like FHIR compared to the traditional method. Parallel testing didn’t guarantee perfect data. It guaranteed that a client would find out about the gap before it shipped.
What changed for digital HEDIS reporting in March 2026?
NCQA’s own update is unambiguous: as of March 2026, NCQA no longer requires organizations to complete a formal parallel testing period through IDSS before reporting digital HEDIS results. Organizations can now move to submitting digital measure results without first proving, through a mandated side-by-side comparison, that their pipeline produces the same answer the traditional method did.
This is a genuine reduction in burden for payer clients who have already built confidence in their digital pipeline. It’s also the removal of the one step that used to force a systematic comparison to happen at all. Nothing about the underlying data mapping risk went away. What went away is the requirement that anyone check for it before results go public.
The removal doesn’t happen in isolation either. NCQA’s technical specifications for Measurement Year 2026 already shifted format to align with the FHIR data standard, matching the structure used in Electronic Clinical Data Systems reporting, and the broader roadmap points toward digital-first HEDIS measurement over the next several measurement years. A client moving faster into that structure, with fewer mandatory checkpoints along the way, is exactly the client whose mapping quality is worth verifying independently rather than assuming.
Why does removing a requirement create work for you, not less?
A client who hears that parallel testing is no longer required tends to hear it as one less thing to worry about. That’s true from a compliance-checkbox standpoint and misleading from a data-quality standpoint. NCQA’s own resources are careful to note that organizations remain responsible for submission accuracy regardless of the requirement change, and that internal comparative testing and data mapping validation continue to matter as practices even though they are no longer mandatory steps.
That’s precisely the gap a consulting engagement can fill. A client moving straight to digital reporting without any comparative check is making a bet that their FHIR-based data pipeline maps cleanly to what HEDIS expects, with nothing forcing that bet to be tested before the results are public and tied to accreditation, benchmarking, or performance-based payment. The bet might pay off. Plenty of pipelines will map cleanly. The problem is that a client no longer finds out which case they’re in until after the results are already submitted.
What should a digital HEDIS data-quality review actually check?
The review that used to happen automatically through mandated parallel testing now has to be reconstructed deliberately, and it doesn’t need to replicate a full side-by-side IDSS submission to be useful. It needs to catch the same category of problem: data that maps incorrectly, incompletely, or inconsistently once it moves from a source system into the structured format digital HEDIS measures expect.
| What mandatory parallel testing used to catch | What a standing data-quality review should check instead |
|---|---|
| Rate discrepancies between traditional and digital results | Field-level completeness in the FHIR resources feeding digital measures |
| Differences in initial populations, exclusions, and numerators | Whether source-system mappings are producing the coded values a measure expects |
| Data mapping and production process issues, reviewed by a Certified HEDIS Compliance Auditor | Whether the client’s own team has a repeatable way to spot-check mappings before every submission cycle |
- Pull a sample of the FHIR-based data a client’s digital HEDIS pipeline actually produces, using synthetic or de-identified data, not a live production submission.
- Check that sample against NCQA-oriented validation criteria before the client relies on it for a real measurement year.
- Document which specific measures or data elements show mapping gaps, rather than issuing a general pass or fail.
- Repeat the check every measurement year the client updates their pipeline, source systems, or vendor, since a clean result once doesn’t guarantee a clean result after any change.
How do you scope this as a standing engagement rather than a one-time favor?
This fits naturally as a recurring line item tied to each measurement year’s reporting cycle, not a single audit. A client who no longer has to run parallel testing still benefits from a lighter, faster version of the same idea: a documented check, run before submission, that catches mapping problems while there’s still time to fix them. Framed that way, it’s a smaller and more frequent engagement than a full comparative testing exercise used to require, which makes it easier to price as an annual or per-cycle retainer rather than a large one-time project.
Hgear’s free NCQA/Care Compliance Validator gives a fast way to run that check. Load a client’s synthetic or de-identified FHIR data and see whether it holds up against NCQA-oriented validation criteria, then turn the result into a documented finding the client can act on before their next submission, not after.
How do you position this so it reads as a natural addition, not a new sales conversation?
The easiest way to introduce this is to connect it directly to the requirement change itself, since it’s a specific, dated, independently verifiable fact rather than a general pitch about data quality. A client who reads NCQA’s own guidance and sees that parallel testing is no longer mandatory is primed to hear the follow-up question: what replaces it internally. That’s a more natural opening than trying to sell a data-quality service in the abstract.
Pricing it as a lighter, recurring check rather than a full audit also matches what actually changed. Mandatory parallel testing used to force a heavyweight, once-a-cycle comparison process. A validator-driven pre-submission check is smaller in scope and can run every cycle without becoming a burden of its own, which makes it easier to fold into an existing retainer or offer as a standalone add-on priced per measurement year rather than per project.
Want a fast way to check a client's digital HEDIS data before they submit it?
Hgear’s free NCQA/Care Compliance Validator is built for exactly this kind of pre-submission check. Run a client’s synthetic or de-identified FHIR data through it and turn the parallel-testing gap into a documented part of your engagement instead of an unmonitored risk.
FAQs
Parallel testing required organizations to run traditional and digital HEDIS results side by side for at least one measurement year through NCQA's Interactive Data Submission System, comparing rates, populations, exclusions, and numerators before relying on digital results for reporting.
No. As of March 2026, NCQA no longer requires organizations to complete a formal parallel testing period through IDSS before reporting digital HEDIS results, according to NCQA's own published guidance.
NCQA's guidance notes that organizations remain responsible for submission accuracy regardless of the requirement change. Without a mandated comparative step, data mapping errors between a source system and digital HEDIS measures can reach public reporting without being caught first, unless an organization builds a replacement check.
NCQA attributes discrepancies to differences in how data is captured, processed, or mapped into standard data models such as FHIR compared to the traditional reporting method, since each organization's underlying data systems vary in quality and completeness.
Yes. Hgear's free NCQA/Care Compliance Validator is built to be run against synthetic or de-identified FHIR data, so a consultant can check a client's data mapping and completeness without any real patient data entering the review.
It should be repeated for every measurement year in which a client updates their pipeline, source systems, or vendor, since a clean result in one cycle doesn't guarantee the same result after a change to how data is captured or mapped.
ISO 27001:2022 Certified
Aigilx health specializes in developing Interoperability solutions to create a healthcare ecosystem and aids in the delivery of efficient, patient-centric and population-focused healthcare.
