CMS ACCESS Model: What the API Spec Actually Says (And What It Doesn’t)

Version note, because it matters: I read these conformance artifacts at v0.9.1 of the implementation guide package cms.fhir.us.accessChecking the IG site again while finishing this piece, the version had already moved to v0.9.12, still marked “no official version has been published yet.” If you’re building against this spec, pin your version and re-run validation on every release. It moved twice while I was writing this sentence.

As of this week, more than 150 organizations have been accepted into the CMS ACCESS Model, and the model has been live since July 5, 2026. The APIs those organizations are required to report through are still a draft, and the operation that outcome payment actually depends on has no specification at all.

I read the implementation guide to work out how much of this is buildable right now. Short answer: most of it, with one real hole and about a dozen smaller inconsistencies that will cost someone a week each if they hit them in production instead of in a spec review.

I. What ACCESS Actually Is

Most coverage of ACCESS calls it an interoperability requirement. That framing is wrong, and it leads teams to build the wrong thing first.

ACCESS is a payment model. It runs for ten years, through June 30, 2036. Original Medicare pays per visit today: you see a patient, you bill the encounter. ACCESS replaces that, for four qualifying chronic-condition tracks, with a fixed payment tied to whether the patient’s numbers actually move.

The four tracks are specific, not generic “chronic disease” language. Early cardio-kidney-metabolic (eCKM) covers hypertension, dyslipidemia, obesity with a marker of central obesity, and prediabetes. Cardio-kidney-metabolic (CKM) covers diabetes, chronic kidney disease stage 3a or 3b, and atherosclerotic cardiovascular disease. Musculoskeletal (MSK) covers chronic musculoskeletal pain. Behavioral health (BH) covers depression and anxiety.

Once you see it as a payment model, the API design stops looking arbitrary. If CMS is paying you to manage a person over time instead of to perform a procedure, CMS has to know exactly who you’re responsible for, starting when, and whether they improved. That’s what the API does. It isn’t a compliance filing. It’s the mechanism that decides whether the payment reaches you at all.

I’d push that point hard with anyone scoping the build cost. The integration isn’t overhead sitting on top of the model. It is how revenue from the model reaches you.

II. The Four Operations

The published guide defines four operations, and all four are type-level operations on Patient, meaning they post to Patient/$operation-name rather than to a specific resource instance.

$check-eligibility asks whether a specific Medicare beneficiary qualifies. CMS answers with one of eight result codes covering whether they’re on Medicare, whether their diagnoses qualify, whether another organization has already claimed them, and whether they landed in the control group.

$align is the one that matters. It’s a claim of responsibility. Actually, it’s more than a claim, it’s a lock: from the moment it succeeds, CMS records that your organization manages this beneficiary’s care for this condition from this date, and no other organization can claim the same person for the same condition. No alignment, no payment, no matter how well you treat the patient. Seven result codes.

$unalign ends that relationship, with a required reason pulled from a fixed list of four codes.

$submission-status exists because none of the above are synchronous. Every write returns HTTP 202 with a Content-Location header, and you poll that location until you get a 200 back with the actual answer.

That async pattern is the first thing that trips teams up. You don’t send a patient and get a decision. You send a patient, get a receipt, and come back later for the decision. Everything downstream has to be built around that, including your retry logic and your UI’s sense of “pending.”

III. The Hole in the Middle

Here’s the finding that changes project plans: there is no $report-data operation. Not underspecified. Not tucked into a later section. I searched all 56 conformance artifacts in the package. The string doesn’t appear once. The guide marks outcome reporting as a future release.

Reporting is the part the payment is actually tied to.

What CMS has published are the deadlines that reporting will eventually have to meet, encoded in a code system for event types, and the deadlines are specific. Baseline data is due within 60 days of aligning a patient, or CMS auto-unaligns them. Quarterly submissions run 70 to 110 days apart. End-of-year data is due no later than 425 days from alignment.

So the deadline that can silently cost you a patient already exists, and the API to satisfy it doesn’t. If you’re scoping this, build the eligibility and alignment flow now, track those deadlines from day one so the exposure is visible on a dashboard somewhere rather than discovered in month 14, and treat reporting as a phase that starts the day CMS actually publishes it. Anyone quoting a fixed price for a complete ACCESS integration today is quoting for something that can’t be finished. I’d want to know that before I signed anything.

That gap connects directly to how ACCESS interacts with existing chronic-care billing. If your organization also runs APCM alongside CCM billing, you already know CMS won’t let you bill both programs for the same patient in the same month. ACCESS adds a third rail to that same concurrency problem, and the reporting gap means you can’t yet fully automate the check.

IV. Your EHR Does Not Cover This

I’ve heard several versions of “our EHR is certified, so we’re fine.” It’s a reasonable assumption, and it’s wrong.

ONC (the Office of the National Coordinator for Health IT) certification, the (g)(10) standardized API requirement, US Core support: all of that gives you standard FHIR (Fast Healthcare Interoperability Resources, the data-exchange standard behind most modern EHR integrations) read and write against standard resources. ACCESS doesn’t use standard resources for its lifecycle. It uses custom operations CMS defined specifically for this model. No EHR ships $alignbecause $align didn’t exist before CMS wrote it.

I checked the public positioning of a certified EHR that markets itself as ACCESS-ready. What’s actually described is registries, documentation habits, and quality-reporting workflow. Useful preparation. Not an API integration, and to be fair, not claimed as one.

So there’s a layer that has to exist between the EHR and CMS. It reads clinical data out of the record system, converts it into the exact shapes the guide requires, calls the CMS operations, and tracks what happened. Whether you build that yourself or bring in a partner who’s already done deep FHIR interoperability testing work, somebody is writing that layer. It isn’t going to show up in your next EHR update.

V. Two Things That Cannot Be Automated

This one catches teams late, and it’s a design constraint, not a technical bug.

$align requires a parameter called isProviderReferral Mandatory, single occurrence, boolean. It answers “was this patient referred to the ACCESS Model by a provider?” That’s a fact about how a person arrived in your practice. No EHR has a field for it.

$unalign requires a reason pulled from four codes. One of them, loss-of-contact, is defined by CMS as three or more outreach attempts over thirty or more days. Another is patient-initiated, meaning the patient asked to leave. Neither is structured data anywhere in a typical chart.

Which means enrollment and withdrawal need a person, and that person needs somewhere to work. If you’re scoping this, there’s a small internal screen in your future: a list of eligible patients, a referral toggle, an enroll action, and a record of who approved what. That kind of enrollment audit trail sits right next to the work most CCM teams already do for compliance automation documentation. It isn’t much software. It also isn’t optional, because without it, the model can’t be operated day to day.

If you want loss-of-contact to ever be usable as a reason, you also need somewhere to log outreach attempts with dates. Most teams today don’t record that anywhere a system can read.

VI. You Will Need Your Own Ledger

CMS offers no way to ask “which of my patients are currently aligned.”

I want to be precise here, because it reads like an oversight and it isn’t. The capability statements declare no search parameters and no read/search interactions on Patient. These are operation-only APIs. You post a question, you get an answer, and CMS keeps no view for you to query later.

So if you don’t record what you submitted, that information doesn’t exist anywhere you can reach. Combine that with asynchronous submission, where a request gets accepted now and resolved later, and you need real persistence: a row per patient with their current state, a row per submission with its identifier and outcome, and timers running against the reporting windows.

Teams that treat this as a thin API client and skip the state layer will be able to submit patients and unable to answer the first operational question anyone asks them Monday morning.

VII. The Control Group Is Real

Some qualifying patients will come back as not-eligible-control-group and some alignment attempts will return not-aligned-control-group

That’s not a bug or a data problem. ACCESS is a ten-year test of whether technology-supported chronic care actually works, and testing that requires a comparison group. CMS randomizes some eligible beneficiaries out of the model on purpose.

Two practical consequences follow. Don’t retry those patients on every data change, because the answer won’t improve. And set expectations with your clinical team before the first screening run, because a care manager watching a qualified patient get refused will assume the integration is broken when it isn’t.

VIII. The Rough Edges I Would Want to Know About First

These read like small details in a spec review. In implementation, each one becomes a sprint.

The participant identifier has a hard validation rule: it must match ACCESS followed by exactly four digits, enforced by an invariant, not left to convention. Every call carries it.

The musculoskeletal diagnosis value set isn’t a list you can paste into a constant. It combines five hierarchical filters covering osteoarthritis families with roughly 350 individually enumerated codes, plus a block of 32 exclusions for non-billable parent codes. There’s no precomputed expansion anywhere in the guide. You need a terminology server that actually understands ICD-10-CM hierarchy to know whether a given code qualifies.

None of these are fatal on their own. All of them are cheaper to find in a spec read than in a failed submission during a live reporting window.

IX. Why CMS Built It This Way

Once you follow the money, the design makes sense.

Fee-for-service pays for activity. Easy to bill, hard to tie to whether anyone actually got better. CMS has spent a decade trying to pay for outcomes instead, and the recurring obstacle has always been attribution. If you’re going to pay an organization for a patient’s improvement, you need an unambiguous record of who was responsible, from when, and what the starting numbers were.

The API is that record. $align is the attribution event. The 60-day baseline requirement exists because an outcome payment without a starting measurement is unauditable. The control group exists because CMS is trying to learn something real, not just spend money differently. The whole structure sits on the same outcome-aligned payment logic that drives value-based care broadly, ACCESS just makes the attribution mechanics explicit in a way most VBC contracts never bother to.

Read that way, the parts that feel bureaucratic are the parts doing the actual work.