Building an ACO Data Platform: Architecture & Requirements

An ACO data platform is the unified analytics layer that sits between your clinical systems, payer claims feeds, and the operational dashboards your care teams and leadership rely on. For value-based care performance (MSSP, ACCESS Model, Medicare Advantage risk contracts, commercial VBC), the platform is the difference between performing on your contracts and leaving money on the table.

This guide walks through the reference architecture, the data products that matter, and the build-vs-buy trade-offs.

What the platform has to do

At minimum, an ACO data platform needs to:

1. Ingest clinical data from every EHR the ACO touches (via FHIR) plus payer claims feeds and quality measure outputs.
2. Normalize across source formats so downstream analytics doesn't have to care which EHR a patient's data came from.
3. Attribute members correctly for each contract (MSSP attribution differs from Medicare Advantage or commercial).
4. Calculate care gaps, HCC worklists, quality measures, and cost/utilization metrics, reliably and on a known cadence.
5. Expose results to clinicians (pre-visit worklists), care managers (outreach lists), and leadership (performance dashboards).
6. Govern PHI access with audit-grade logging and role-based controls.

Reference architecture

A lakehouse pattern is the pragmatic standard in 2026. Whether you build on Azure + Microsoft Fabric, Databricks, Snowflake, or a similar stack, the layered structure looks the same:

The layer that most under-invest in: silver. Teams rush from bronze to consumer-ready gold, skipping the normalization step, and end up with gold tables that quietly break whenever an EHR refresh changes a FHIR response shape.

The key gold data products

Attribution

Member attribution is the foundation. Every downstream metric is "for whom?" If attribution is wrong, every dashboard is wrong.

• MSSP attribution is prospective and claims-based (plurality of primary care visits).
• Medicare Advantage is plan-based and comes from the payer.
• Commercial VBC varies by contract; some are plurality-of-claims, some are explicit PCP assignment.
• ACCESS Model extends prospective attribution with additional scoping rules for chronic conditions.

Attribution also churns. You need a time-sliced attribution table (who was attributed to which contract in which performance period) so a care gap opened in March 2025 is counted for the person who was attributed at that point in time, not whoever's attributed today.

Care gaps

Care gaps are the missing recommended services or screenings for an attributed patient, driven by quality measures (HEDIS, eCQM) or care bundle specifications. Care gap data products feed clinician worklists, care manager outreach, and payer reporting.

Key requirements:

• Specification-driven (the measure logic is versioned)
• Denominator and numerator calculated consistently across EHRs
• Exclusions and exceptions applied correctly
• Surfaced pre-visit when possible

HCC worklist

Pre-visit suggestions of unaddressed HCCs, as covered in the HCC risk adjustment article. The data product depends on NLP extraction from clinical notes plus structured problem list data, mapped to V28.

Quality measures

HEDIS, eCQM, MIPS, MSSP quality set, ACCESS-specific measures. Calculated on known data freshness, auditable to individual patient records.

Cost and utilization

Claims-driven view of total cost of care, site-of-service mix, high-cost / high-utilization patients, admissions/ED visits. This is the financial lens on the population.

Outcome attainment (ACCESS Model)

New in ACCESS. Requires structured patient-goal data, PROMs, and a scoring layer, see the ACCESS Model article.

Build vs. buy

For most ACOs the answer isn't all-or-nothing. A pragmatic split:

Greenfield ACOs sometimes buy an end-to-end "ACO platform" product. These work but lock you in and rarely flex to custom contract structures. Health systems with significant data engineering capacity typically build the core with purchased components at the edges.

Common failure modes

• Treating FHIR as structured gold. Raw FHIR output varies significantly between Epic instances. Always normalize.
• Over-indexing on dashboards. Dashboards that aren't tied to clinical workflows don't move metrics.
• Under-investing in attribution. Wrong attribution = wrong everything else.
• Ignoring refresh freshness. Month-old data is not operational; teams stop using it.
• No audit trail. PHI access must be logged; CMS and payer audits will want this.

Frequently asked questions

How long does a real ACO data platform take to build?

For a mid-sized ACO starting from scratch, expect 9–18 months from commit to fully operational, with earlier milestones for specific data products (attribution first, then care gaps, then HCC worklists, etc.).

Can we reuse our health system's existing data warehouse?

Sometimes. Existing warehouses are often built for fee-for-service reporting, not VBC contract management. Adapt or rebuild depending on the gap.

What's the minimum team size?

A lean team is 1–2 data engineers, 1 analytics engineer, and 1 clinical informaticist, supported by clinical leadership. Larger ACOs need more, especially for multi-EHR footprints.

Cloud preference?

No wrong answer. Azure + Microsoft Fabric is a natural fit for health systems already on Microsoft. Databricks is strong for multi-cloud. Snowflake is popular for data-first teams. What matters is getting the data layer right; the cloud is a secondary choice.

---

How DATA4AI helps: We design and build ACO data platforms on Azure and Microsoft Fabric for health systems, ACOs, and physician enablement platforms. Book a discovery call to talk through your platform roadmap.