Back to Blog
ACCESS ModelValue-Based CareACOCMSCMMI

What is the CMS ACCESS Model? A Practical Guide for ACOs

DATA4AI ConsultingApril 22, 20265 min read

The CMS ACCESS Model, short for Accountable Care for Chronic Conditions Serving Seniors, is a value-based care program from the CMS Innovation Center (CMMI) that launches in January 2026 and runs for five performance years. It builds on the Medicare Shared Savings Program (MSSP) but adds new requirements around FHIR API interoperability, patient-reported outcome measures (PROMs), and outcome-attainment dashboards that go beyond what MSSP ACOs typically operate today.

For ACOs and health systems already participating in MSSP, the ACCESS Model is both an opportunity and a significant data infrastructure lift. This guide explains what the model requires, how it differs from MSSP, and what ACOs need to do between now and model start to be operationally ready.

What the ACCESS Model actually is

The ACCESS Model is a voluntary, downside-risk value-based care program focused specifically on Medicare beneficiaries with two or more chronic conditions. Participating ACOs are accountable for the total cost of care and a set of quality and outcome measures for their attributed population, with shared savings and losses determined by performance against benchmarks.

Unlike MSSP, the ACCESS Model puts digital interoperability, patient experience, and measurable outcome attainment at the center of scoring, not just claims-based quality measures and total cost of care.

Primary mechanics to know:

  • Attribution: prospective, based on plurality of primary care claims (similar to MSSP).
  • Risk track: single track with progressive downside risk across the five performance years.
  • Benchmark: regional + national blend, with risk adjustment.
  • Quality scoring: built around PROMs, care coordination measures, and outcome attainment, the degree to which documented patient goals are actually met.
  • Data submission: CMS requires participating ACOs to stand up FHIR APIs that expose structured clinical data and outcome-attainment data to CMS and, by patient consent, to third-party apps.

How ACCESS differs from MSSP

AreaMSSPACCESS Model
Focus populationAttributed Medicare FFS beneficiariesBeneficiaries with 2+ chronic conditions
Interop requirementMinimalProduction FHIR APIs required
PROMsOptionalRequired for scoring
Quality scoringCMS Web Interface / eCQMPROMs + outcome attainment + care coordination
Data submissionClaims + a subset of clinical measuresStructured clinical data via FHIR + outcomes

This is a meaningful shift. Many MSSP ACOs today operate on claims-driven analytics stacks that barely touch EHR data. ACCESS forces the clinical layer into the center of the platform.

What you need to build before Jan 2026

1. A production FHIR API surface

CMS will specify the exact FHIR profiles, but the baseline is clear: ACOs need a production FHIR R4 endpoint (or endpoints, if the ACO includes multiple provider organizations) that exposes Condition, Observation, Procedure, MedicationStatement, AllergyIntolerance, and Encounter resources for attributed patients. If you are using Epic, Cerner (Oracle Health), or Meditech, these resources are available via the vendor's FHIR layer, but wiring them up for scale, with proper authentication (SMART on FHIR / OAuth 2.0), requires work.

For a deeper dive, see the ONC-certified FHIR API requirements and the HL7 FHIR R4 spec.

2. PROMs collection at scale

Patient-reported outcome measures historically live in paper surveys, standalone portal experiences, or specialty clinics. For ACCESS, PROMs need to be:

  • Collected from a large share of the attributed population at specified cadence
  • Stored in a structured, queryable format
  • Tied back to individual patient records for longitudinal tracking
  • Exposed via FHIR (typically via the Observation or QuestionnaireResponse resources)

Most ACOs will need to deploy or integrate with a PROMs platform, tethered to patient portals, SMS workflows, or EHR-integrated surveys, and build the pipeline from that platform into their analytics layer.

3. Outcome-attainment dashboards

Outcome attainment is the most novel scoring element. It measures whether a patient's documented goals (e.g., A1C target, functional status improvement, pain score reduction) are actually being met, and to what degree. Building this requires:

  • A structured place to capture patient-specific goals (often custom fields in the EHR)
  • A mechanism to score attainment as new data arrives
  • A dashboard that gives care teams and ACO leadership visibility into attainment rates

4. An analytics platform that ties it all together

Underneath, ACCESS participants need a data platform that unifies EHR data (via FHIR), payer claims feeds (for risk and cost), PROMs, outcome-attainment data, and quality measure outputs. A modern lakehouse architecture (Azure Fabric, Databricks, Snowflake) is the standard fit.

Common readiness gaps

  • Auth and scoping on FHIR. Epic App Orchard vs. public FHIR endpoints have different scopes, rate limits, and consent models. Many ACOs under-estimate this.
  • PROMs participation rates. Collecting a PROM once isn't enough; sustained participation is hard and needs to be designed into clinical workflows.
  • Attribution churn. Outcomes are measured on attributed patients, but attribution can shift year over year. Your data model needs to handle this cleanly.
  • Care team workflow integration. Dashboards that aren't embedded into the clinical team's daily workflow don't get used.

Frequently asked questions

Is the ACCESS Model mandatory for MSSP ACOs?

No. ACCESS is voluntary. ACOs can continue in MSSP, move to ACCESS, or participate in both if eligible. Read CMS's program page for the latest rules.

What's the application timeline?

CMS has signalled a 2025 application window for January 2026 participation. The specific dates and Request for Applications are available on the CMS Innovation Center ACCESS Model page.

Can an ACO participate in ACCESS using just claims-driven analytics?

Practically, no. The clinical data and PROMs requirements make a pure claims stack insufficient. Most successful participants will operate a unified claims-plus-clinical platform.

What if our EHR doesn't support FHIR R4 in production?

Modern Epic, Cerner, and Meditech deployments all expose FHIR R4. Legacy systems or on-prem builds with disabled FHIR endpoints need to turn them on or work with the EHR vendor on production readiness. Getting the endpoints on, authenticated, and reliably querying at scale typically takes months, not weeks.


How DATA4AI helps: We work with ACOs and health systems preparing for the CMS ACCESS Model: FHIR readiness assessments, PROMs collection architecture, outcome-attainment dashboard design, and unified data platforms on Azure / Microsoft Fabric. Book a discovery call to talk through your readiness plan.

Let's talk about your value-based care project.

Working on a value-based care contract, ACCESS Model application, EHR integration, or AI-enabled clinical workflow project? Book a 20-minute discovery call or email [email protected].