29 Jul
Key takeaways
- NCQA requires every organization reporting HEDIS results to complete a HEDIS Compliance Audit conducted by an independent Certified HEDIS Compliance Auditor, covering information systems and specification compliance, not just the final rates.
- Supplemental data sources have to be documented in the Roadmap and approved by the auditor before they can count toward HEDIS reporting, and gaps here are one of the most common findings.
- The Data Aggregator Validation program specifically checks whether data passed through an aggregator still reflects what the original source system reported, which matters for any organization relying on third-party data pipelines.
- Most organizations submit well before the deadline. NCQA has reported that only 2 percent of HEDIS MY 2024 results came in on the final submission day, which suggests early preparation is standard practice, not an exception.
- Primary Source Verification is where compliance issues surface most often, because it is the first point where an auditor checks documentation against the actual data, not just the reported numbers.
- A working checklist covers four phases: Roadmap documentation, supplemental data approval, Primary Source Verification, and preliminary rate review, each with its own common failure points.
- Waiting until preliminary rate review to address a finding leaves little room to fix it. Issues caught earlier in the process are far easier to resolve than issues caught close to the deadline.
A health plan’s data team spends months pulling HEDIS measures together, feels good about the numbers, and hands everything off to their auditor. Then Primary Source Verification starts, and the auditor flags a supplemental data source that was never properly documented in the Roadmap. The deadline is weeks away, and now there is a scramble nobody planned for.
This pattern repeats every reporting season, and it rarely comes from bad data. It comes from compliance issues that were sitting in the process the whole time, unnoticed because nobody checked for them until an outside auditor did. NCQA’s validation requirements are detailed enough that catching problems early takes a deliberate checklist, not a general sense that things look fine.
This piece walks through what NCQA’s HEDIS Compliance Audit and Data Aggregator Validation program check, where compliance issues tend to hide, and what a working checklist looks like before submission day arrives.
Table of contents
Why does NCQA validation matter beyond meeting a deadline?
Submitting HEDIS results on time answers one question: did the organization meet the deadline. It does not answer whether the underlying data collection, documentation, and reporting process would hold up under independent review, which is a separate and more important question.
NCQA built its audit process around this distinction on purpose. A Certified HEDIS Compliance Auditor is required to maintain strict independence, with no allowance for providing technical assistance or advisory services during the audit itself, according to NCQA’s own guidance on HEDIS reporting. That independence is what makes an audited result trustworthy for public reporting, and it also means the auditor has no incentive to overlook a gap.
What does the HEDIS Compliance Audit check?
The audit covers more ground than most people expect before they go through it for the first time. NCQA describes it as an information systems capabilities assessment combined with an evaluation of compliance with HEDIS specifications and standards, applied by Certified HEDIS Compliance Auditors using a standardized methodology.
That means the audit is not just checking whether a final rate looks reasonable. It examines how the data was collected, whether systems were capable of producing it accurately, and whether documented processes match what happened during the reporting period.
What is the Data Aggregator Validation program?
Many organizations no longer pull HEDIS data directly from a single system. Data often passes through an aggregator that combines information from multiple sources before it reaches the health plan’s reporting process, and that extra step introduces its own risk of error or drift.
NCQA’s Data Aggregator Validation (DAV) program exists specifically to check this. It validates incoming and outgoing data from aggregators to confirm the data still reflects what the original source reported, and to confirm it meets NCQA’s standards and protocols before it can be used as standard supplemental data. Organizations relying on a third-party aggregator should confirm that aggregator has gone through this validation, rather than assuming the data arriving from it is automatically clean.
What are the most common compliance issues auditors find?
Common compliance issues by category
| Category | What Typically Goes Wrong |
|---|---|
| Roadmap documentation | Supplemental data sources used in reporting but never fully documented or updated in the Roadmap. |
| Supplemental data timing | Data collection continuing after the cutoff date, or amendments made after the documentation deadline. |
| Aggregator data integrity | Data from a third-party aggregator that does not match what the original source system actually reported. |
| System capability gaps | Information systems that cannot reliably reproduce the same result on request, undermining confidence in the reported rate. |
| Preliminary rate discrepancies | Rates that shift unexpectedly between preliminary submission and final review, without a clear documented reason. |
What should an NCQA validation checklist include?
A validation checklist by phase
| Phase | What to Confirm |
|---|---|
| Roadmap documentation | Every supplemental data source used is documented, current, and submitted to the auditor ahead of the deadline. |
| Supplemental data approval | All nonstandard supplemental data collection stopped by the required cutoff, with no late amendments. |
| Primary Source Verification | Sample records match documented processes exactly, with no unexplained gaps between what was recorded and what the system produced. |
| Preliminary rate review | Any unexpected shift in a preliminary rate has a documented, defensible explanation before the auditor asks about it. |
Building this into a running checklist, reviewed well before each phase’s deadline, catches most of what an auditor would otherwise flag independently.
Why do so many issues surface at Primary Source Verification specifically?
Primary Source Verification is the first point in the audit where documentation gets checked against the underlying data itself, rather than against a summary or a reported rate. Up to that point, an organization can look compliant on paper while a real gap sits quietly underneath the numbers.
That is exactly why PSV cannot happen before an organization has finished all supplemental data collection and entry. NCQA’s audit timeline makes this explicit: PSV for nonstandard supplemental data must not occur before all data processes are complete, without exception. Rushing this phase, or treating it as a formality once the numbers look right, is where most late-stage findings originate.
What happens if compliance issues surface after submission?
Preliminary rates go through the IDSS for auditor review, and organizations then have a defined window to respond to any findings before final rates are locked. Not responding to an issue at this stage can result in a rate being marked not reportable, which affects public reporting and can carry real downstream consequences for the organization.
This is why a compliance issue caught during internal review, weeks before preliminary submission, is a manageable fix. The same issue surfacing during preliminary rate review is a much harder problem, with less time and less room to correct it properly.
Where does this leave organizations preparing for their next submission?
Passing NCQA validation is less about the final numbers and more about whether the documentation, timing, and data integrity behind those numbers would hold up to independent review. Most findings trace back to a handful of recurring gaps: an undocumented supplemental source, a late amendment, an aggregator’s data drifting from its original source, or a rate shift nobody can explain yet.
A checklist built around the same phases NCQA’s own audit follows, Roadmap documentation, supplemental data approval, Primary Source Verification, and rate review, catches most of these before an auditor has to raise them, which is a far better position to be in with weeks left before a deadline than during preliminary rate review.
FAQs
Yes. All health plans reporting HEDIS results must participate in a HEDIS Compliance Audit conducted by a Certified HEDIS Compliance Auditor, following a standardized methodology.
It confirms that data passed through an aggregator still matches what the original source system reported, and that it meets NCQA's standards before being used as supplemental data for HEDIS reporting.
By the cutoff date set in NCQA's audit timeline, with no exceptions for late amendments. Documentation completed after that point cannot be used for HEDIS reporting.
Preliminary rates are submitted through the IDSS for auditor review first. Organizations then respond to any findings before rates are finalized and locked for reporting.
Because it is the first step where documentation gets checked against actual underlying data, rather than a summarized rate, which is where quiet gaps tend to surface.
Early submission is the norm. NCQA reported that only 2 percent of HEDIS MY 2024 results were submitted on the final day, suggesting most organizations build in time to catch and fix issues before the deadline.
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.
