Before you apply to ACCESS: the reporting burden you are signing up for

If your organization is weighing an ACCESS application, you have probably already sized the clinical side. You know which patients would enroll, which track fits, who would do the work.

The part that tends to get sized last — and costs the most when it is underestimated — is the reporting. ACCESS is an outcomes-aligned model, which means the data is not paperwork attached to the care. The data is how the care gets counted. A beneficiary you treated well but reported late can be scored as though the care did not happen.

This post is the operational picture, taken from CMS's own published documents, so you can decide with it in front of you rather than discovering it in month three. We are a reporting-infrastructure company, so treat the last section as our interest showing — but the rules below are CMS's, not ours, and each one is sourced.

First, about the dates: use CMS's page, not ours

We are not going to tell you when applications are due, and we would gently suggest you distrust anyone who does without linking you to a live CMS page.

Here is why. CMS's ACCESS Model page currently describes rolling start dates. The Request for Applications describes application deadlines — and the RFA itself says the deadline for each cohort will be announced on the CMS Innovation Center website and through the model's listserv, rather than by reissuing the RFA. The page has since moved ahead of the PDF: as of our last check of both documents on July 26, 2026, the start dates on the model page do not appear in the RFA's cohort table, and the deadlines that go with those starts are not published on either one. There is precedent for movement, too — the first-cohort application deadline was extended from April 1 to May 15 this spring.

So: check the CMS model page, on the day you are deciding — and if you are seriously considering a cohort, get on the ACCESS listserv, since the RFA names it alongside the website as where deadlines get announced. Everything below is independent of which cohort you land in.

The three clocks that attach to every enrolled beneficiary

Enrollment is not the commitment. Enrollment starts three clocks per beneficiary, and they run on their own schedule for the entire care period.

Clock 1 — the baseline, within 60 days of alignment. A valid baseline measure must be submitted within 60 days of alignment via the Data Reporting API. Miss it and the beneficiary is unaligned: the participant may not provide services under the model until re-alignment. Of the three clocks, this is the one that voids an entire care period. (CMS Payment Amounts & Performance Targets paper, p.7.)

Clock 2 — "quarterly" is not quarterly. A valid quarterly measure must land 70 to 110 days after your previous submission — not on a calendar quarter, and not measured from alignment. Submit early and the next window moves with you. Miss the 110th day and the submission is invalid. (Same paper, p.7.) This is the rule most teams model wrong, because "quarterly" reads like something your existing calendar already handles, and it isn't: every beneficiary is on a personal, drifting window that depends on when you last submitted for them.

Clock 3 — the end of the period, no later than 425 days from alignment. The end-of-period measure is due within 425 days of alignment (365 + 60). Early submission is allowed, but it is measured backward from Day 365 — up to 90 days before for the eCKM/CKM tracks, up to 180 days before for the BH and MSK tracks. Day 365 is the early-window anchor; Day 425 is the outer wall. (Same paper, p.7.)

Three clocks, per beneficiary, each with a different origin. Multiply by your expected panel and you have the tracking problem, and it is not one a spreadsheet holds gracefully once the second clock starts drifting.

A reading can be on time and still not count

The clocks decide when you submit. A second set of rules decides whether what you submit is usable at all. A reading is valid only if it was collected within its own window before submission:

(CMS Payment Amounts & Performance Targets paper, p.6.)

Read the 15-day rows against Clock 2 and the operational consequence appears: for the vitals and the PROMs, a 40-day submission window does not mean 40 days of latitude. The reading has to be fresh on the day it goes out, so the real question is whether you can reliably get a patient measured inside a two-week band that lands inside a drifting 40-day band. That is a scheduling problem before it is a data problem.

And the method counts, not just the date

"Valid" is more than timing. Blood pressure must come from a validated upper-arm cuff averaging at least three readings — manual entry is not permitted. Labs must be accredited/CLIA. Self-reported values are disallowed except for weight and PROMs. (ACCESS RFA, Appendix C.)

This is the rule that most often invalidates data an organization already has. A blood pressure sitting in your chart as a single typed number is a real clinical observation and it is not an ACCESS-valid one. Before you apply, it is worth checking what your devices actually emit and whether the averaging happens in the device or in someone's head.

The five questions worth answering before you commit

Not a sales checklist — these are the questions whose answers determine whether the reporting side is a project or a crisis.

• Can you produce each required measure as structured data, with its collection date and method attached? The date and the method are as load-bearing as the value.
• Can you track a per-beneficiary window that moves every time you submit? Clock 2 is stateful. Whatever tracks it has to remember your own last submission for each person.
• Who owns Day 60 and Day 425? Both are absolute, and the first one silently voids a care period rather than delaying a payment.
• Do your blood-pressure devices average three readings, and do your labs come back CLIA-attributed? If not, that is a procurement or workflow change with a lead time, and it is cheaper to discover now.
• Who submits, and through what? Submission runs through CMS's Data Reporting API. The FHIR Implementation Guide for it is published as a draft (v0.9.12 as of this writing), so plan for the transport layer to keep changing while the policy rules above stay put — they come from the payment and application documents, not from the IG.

One honest note on effort accounting: quarterly submissions are collected for monitoring and auditing rather than being used directly to set payment amounts. That does not make them optional — timely submission is still a hard, billing-affecting deadline. (Payment paper, p.7.) Do not let anyone plan around skipping them.

What a reporting vendor can and cannot do for this

Our interest, stated plainly: we build reporting infrastructure for ACCESS participants, and everything above is the problem we work on.

So here is the boundary. No software raises clinical attainment. Not ours, not anyone's — attainment is what happens between a clinician and a patient, and a vendor claiming their product improves your outcomes is making a promise they have no mechanism to keep. What infrastructure legitimately changes is narrower: whether data that exists and qualifies actually arrives inside its window, in a form that survives reconciliation. That is a real failure mode with a real cost, and it is a different sentence from "we improve your results."

If you are pre-application, you do not need a vendor yet. You need an honest sizing. That is what this post is for, and the rules above are yours whether or not we ever speak.

The short version

Three clocks per beneficiary — 60 days to baseline, a rolling 70–110 days that moves with every submission, and 425 days to close — plus six freshness windows and a set of collection-method rules that can invalidate data you already have. None of it is unmanageable; all of it is easier to build for before you enroll your first beneficiary than after. And for the dates that decide when you would start, use CMS's model page, because those have moved and we will not be the source for them.

If you want to walk your own setup against this list, we are happy to do it with you: [email protected].

---

Outcome Rail builds reporting infrastructure for participants in the CMS ACCESS Model. This post summarizes publicly published CMS rules and is not legal, financial, or clinical advice. It states no measure target values and makes no claim about clinical outcomes. CMS decides payment.

Sources: CMS ACCESS Model page · ACCESS Model Payment Amounts & Performance Targets (PDF) (deadline and validity-window rules, p.6–7) · ACCESS Request for Applications (PDF) (collection-method rules, Appendix C) · ACCESS Technical FAQ · CMS ACCESS FHIR Implementation Guide (DRAFT v0.9.12) · AHA — CMS extends first-cohort application deadline, 2026-04-14.