What ECDS actually is

ECDS stands for Electronic Clinical Data Systems. NCQA defines four ECDS data sources:

  1. Member management systems (eligibility, enrollment, demographic data)
  2. Administrative claims (medical and pharmacy)
  3. Electronic health records (clinical data captured during encounters)
  4. Health information exchanges and clinical registries (supplemental clinical data flowing between organizations)

An ECDS-reported measure pulls from any combination of these sources to compute the measure for the entire eligible population, not a sample.

The hybrid model that ECDS replaces

Hybrid HEDIS measures combine administrative claims data with manual chart abstraction. Plans pull a sample (typically 411 members per measure), send chart-chasing teams to physician offices, and abstract the additional clinical evidence by hand. The sample is then statistically projected to the full population.

Hybrid worked when EHR adoption was uneven and supplemental data infrastructure did not exist. It is also enormously expensive: chart-chasing season runs January through May, costs roughly $25 to $80 per chart, and concentrates the entire year of effort into five months.

The retirement timeline

NCQA's published roadmap moves measures from hybrid to ECDS-only across reporting years 2024 through 2029. Some highlights:

By 2029, no measure will accept the chart-abstraction-and-project methodology. Every HEDIS measure must be computed from continuous electronic data covering the full eligible population.

Why this is a 35x to 75x data problem

Under the hybrid model, a plan reporting on a 50,000-member panel needed clinical evidence for roughly 411 sampled members per measure. Under ECDS, the same plan needs clinical evidence for all 50,000 members per measure. Supplemental data volume per measure increases by a factor of roughly 35 to 75, depending on how much of the population is already covered by claims-only data.

35x-75x
Increase in supplemental data volume per measure under ECDS vs. hybrid
2029
Final reporting year for the last remaining hybrid HEDIS measures
12K → 3M
Typical annual supplemental data events for a 50K-member MA contract, hybrid to ECDS

For a typical MA contract reporting 30 to 40 ECDS-eligible measures, total supplemental data volume increases from roughly 12,000 chart abstractions per year to roughly 1.5 to 3 million electronic clinical events per year. The infrastructure that handled hybrid (a shared drive of PDFs, a chart-chasing vendor portal, an Excel reconciliation file) does not scale to that volume.

What changes operationally

From seasonal to continuous

Hybrid concentrates effort in January-May; ECDS spreads it across all 12 months. Plans must move from a "chart season" workflow to a "continuous evidence capture" workflow. The team structure, tooling, and incentives all change.

From sampling to full-population

Hybrid lets you focus on the 411 sampled members. ECDS forces you to think about all 50,000. Members who would never have been sampled now require the same evidence quality.

From abstraction to ingestion

Chart abstraction is a human activity producing structured fields from unstructured documents. ECDS ingestion is a data-engineering activity, normalizing FHIR resources, HL7 v2 messages, CCDA documents, payer SFTP drops, lab feeds, and registry exports into a single structured record.

From point-in-time to longitudinal

Hybrid evidence is point-in-time: was this measure satisfied at any point in the measurement year? ECDS preserves the full longitudinal record, which means measures will increasingly use sequence and timing logic that hybrid simply could not capture.

What to build now

Plans that wait until 2027 to build ECDS infrastructure will be 18 months behind, in a market where every other plan is hiring the same data engineers. The 2026-2027 window is when the work has to start.

The minimum viable ECDS infrastructure has five components:

  1. Multi-source ingestion. FHIR (R4 or higher) for EHR data, HL7 v2 for ADT and lab results, CCDA for cross-organization clinical summaries, payer SFTP drops, and pharmacy PDE and E1 feeds.
  2. Identity resolution. Match members across plans, providers across NPI/TIN combinations, and encounters to claims. Without resolution, ingested data does not map to eligible members.
  3. A canonical schema. One representation of member, encounter, diagnosis, procedure, medication, lab, vital sign, and gap. Each ECDS measure becomes a query against this schema, not a custom integration.
  4. Continuous gap recomputation. As new data lands, gaps must close (or open) in near-real-time. Monthly batch recomputation will miss the operational moments that drive measure performance.
  5. Audit retrievability. NCQA spot-checks ECDS data sources. Every reported measure must be traceable back to its source clinical evidence within hours.

Build versus buy

Most plans face a real build/buy decision. Building the five components in-house typically requires:

Buying means selecting an integration partner whose roadmap is aligned with NCQA's. The wrong partner is a partner whose ECDS readiness lags the retirement schedule.

The middle path some plans take is hybrid: buy the ingestion layer, build the measurement and reporting logic on top. This works only when the ingestion partner exposes a clean canonical record, not a vendor-locked database.

"ECDS is not a HEDIS project. It is a data infrastructure project that happens to surface in HEDIS first. Plans that treat it as a quality-team initiative will under-resource it by an order of magnitude."

Sources and further reading