NCQA is defining how clinical data quality can be continuously measured

What the Data Quality Solutions can mean for health plans and the clinical data sources they depend on

Health plans have more access to clinical data, from more sources, for increasingly consequential programs. That data may support HEDIS measurement today and a growing range of quality, risk, population health, and member-engagement use cases tomorrow. But, before a plan can use the data with confidence, it has to answer a deceptively difficult question: Is this source consistently producing data that is fit for the intended purpose?

Historically, answering that question meant relying on point-in-time source verification or finding data defects late in the reporting cycle.

One of NCQA’s central goals for DQS is to modernize Primary Source Verification (PSV) itself.

PSV has long been one of the most burdensome parts of HEDIS audit season—a manual, evidence-intensive process where health plans and auditors verify, source by source, that clinical data is trustworthy enough to support measurement. Done by hand, it is slow, expensive, and difficult to scale as plans add more data sources. By encoding PSV-relevant checks into an automated, continuous specification, NCQA is aiming to replace much of that manual burden with a repeatable, evidence-based process—one that produces the same rigor auditors expect, without re-litigating source trust from scratch every audit cycle.

NCQA’s Data Quality Solutions (DQS) beta program is designed to make data trust objective, scalable, and continuous. CareEvolution^® is one of a small group of organizations selected to participate in the implementation beta—giving us an early opportunity to apply these specifications within real-world data pipelines and help transform data quality from a periodic certification event into a continuous operational signal.

Truly measuring data quality

Traditional data validation often focuses on whether required fields are populated and whether a file conforms to the expected format. Those checks still matter, but they do not confidently inform a health plan whether the data is believable, whether it remains dependable over time, or what happened to it before it arrived.

NCQA’s approach evaluates four connected dimensions:

Usability

Is the data complete and properly structured for HEDIS calculations?

Plausibility

Is the population-level data statistically reasonable and likely to reflect reality?

Stability

Are the content and delivery of the data remaining consistent over time?

Integrity

Can the organization understand where the data originated and how it was exchanged and transformed?

Together, these dimensions create a much stronger definition of ‘fit for HEDIS’ than a simple file-level pass or fail.

Plausibility and stability are the important leap forward

Two of the dimensions are especially significant: plausibility and stability.

Plausibility asks whether a source’s data makes sense at the population level. A source may deliver syntactically valid records with all expected fields, yet still produce patterns that defy clinical reality. Automated plausibility testing intercepts improbable physiological values—such as systolic blood pressure recorded as 300/200 mmHg—or catches unmapped local lab codes before they flow into measure calculation, audit preparation, or downstream analytics.

Stability adds the element of time—looking for pattern changes over time. A source that performed well during onboarding may change its coding practices, interfaces, mappings, provider coverage, or delivery patterns months later. Under a point-in-time validation model, that degradation remains invisible until it affects results. Continuous stability monitoring surfaces anomalies as they occur—such as an upstream EHR update that silently drops incoming feed volume by 40%—alerting the team before reporting windows are compromised.

Is a data source plausible for HEDIS—and will it remain stable after you acquire it?
For health plans, the value of plausibility and stability is not limited to evaluating data after it has been implemented. The same concepts inform decisions across the data source lifecycle:

Before acquisition: Evaluate whether a prospective source has the coverage and measure-relevant clinical data needed to support HEDIS before purchasing or onboarding it.
After implementation: Continuously monitor the source to detect subtle changes before they affect downstream quality workflows.

A scalable way to assess and monitor source data

The beta includes more than 100 pass/fail checks across multiple components, including completeness, conformance, and plausibility. NCQA also provides the applicable HEDIS Volume 2 value sets so implementations use consistent definitions, alongside FHIR-formatted test patient data and expected results to support testing.

In practice, these specifications help organizations:

Determine the quality of clinical data within and across individual sources.
Identify specific coding issues that need to be corrected upstream.
Monitor ongoing data exchange instead of relying solely on onboarding tests.
Establish and maintain trust in the sources used for HEDIS and digital Quality Measures (dQMS).

The emphasis on upstream assessment matters. Problems are easier and significantly less expensive to address near their origin than later—after data has been aggregated, transformed, and distributed across multiple downstream systems.

What this could mean for health plans

For health plans, the practical value is not another quality report sitting alongside the data. It is the ability to understand which sources are ready-for-use, where the risks are, and whether quality is changing while data actively supports the program.

Are we missing care, or missing data?

Separating true clinical gaps from evidence that is incomplete, delayed, improperly coded, or unmatched.

Which data sources are hurting us?

Scoring each source and estimating its potential impact on HEDIS performance.

Are we getting what we are paying for?

Measuring the usable HEDIS evidence actually contributed by each vendor, HIE, provider feed, or acquisition partner.

What could create an audit problem?

Surfacing questionable provenance, unstable sources, inconsistent coding, and weak evidence chains before an auditor does.

What changed since last week?

Detecting new gaps, resolved gaps, source anomalies, and material shifts in projected performance as they happen, not at year-end.

This model reduces reliance on labor-intensive, point-in-time source-verification processes. Rather than demonstrating only that a source met requirements at a particular moment, plans can maintain an ongoing, evidence-based view of source quality, plausibility, and stability. That is particularly important as the industry accelerates toward digital quality measurement.

It also creates a more productive relationship between plans and data partners. Instead of finding a downstream discrepancy and working backward to determine its cause, both parties can use common specifications and results to identify, prioritize, and correct issues closer to the source.

Building data quality into the pipeline

At CareEvolution, we see DQS as a natural extension of a managed clinical-data pipeline. Data quality should not be an isolated step after ingestion. It should operate natively within your data fabric alongside source connectivity, identity resolution, normalization, terminology management, deduplication, provenance, and FHIR delivery.

Through our Orchestrate platform, CareEvolution applies NCQA’s specifications within the flow of live clinical data—flagging plausibility anomalies and volume drops at ingestion.

The larger opportunity is straightforward: health plans should not have to choose between obtaining more clinical data and knowing whether they can trust it. Automated, scalable, and continuous assessment makes trust a measurable property of the data pipeline.