This is the last post in the deadline-mechanics series, and it closes the loop the first post opened. B1 covered the two clocks that start at alignment; B2 covered the rolling window in between; B3 covered how long a single reading stays fresh; B4 covered whether a reading was eligible the moment it was captured. What's left is the far end of the care period — the final measure, and the deadline math that governs when you can submit it.
The end-of-period deadline is the one number from this model most people can recite: 425 days from alignment. It is also the number most likely to lull a team into submitting later than they should, because the 425 is an outer wall, not a target — and the window you actually want to aim at is anchored to a different day.
The final, end-of-period measure is due no later than 425 days after alignment. The figure isn't arbitrary: it's the 365-day care period plus the same 60-day reporting tail that gives the baseline measure its window at the start of the period. So the shape is symmetric — 60 days to report at the front, 60 days to report at the back, one year of care in between. (Source: ACCESS Payment Amounts and Performance Targets, p.7, End-of-Period Reporting.)
That's the deadline everyone remembers. The trouble is that "you have until Day 425" quietly implies "so aim for Day 425," and that is the wrong reading of the rule.
Here is the part that catches teams out. End-of-period measures may be submitted early — but the early window is measured backward from Day 365, not from Day 425. Per the Payment paper, the early-submission allowance is:
So Day 365 is the anchor the early window is built around, and Day 425 is the outer wall past which nothing counts. The two numbers do different jobs, and the mistake is to treat 425 as if it were the anchor. It isn't. If your reporting logic counts forward toward 425 to decide when the end-of-period measure "opens," it is anchored to the wrong day — the early window opens relative to 365, and the gap between 365 and 425 is reporting slack, not measurement time.
Put plainly: the early window is a lead-in ahead of Day 365, and the 60 days after Day 365 (up to 425) is the tail you use to actually get the submission in and accepted. Aiming for the wall means throwing away the entire early window and leaving zero margin for a rejected submission.
Every earlier post in this series made the same underlying point: in this model, being late by any amount is the same as not submitting. A reading past its freshness window doesn't count; a rolling window that closes on Day 111 doesn't reopen. The end-of-period measure is the highest-stakes instance of that rule, because there is no next window after it — it is the final measurement of the care period.
That's why the anchor is the number to build around, not the wall. A team that targets Day 425 has designed for the last possible moment: if that submission is rejected — a validity-window problem from B3, a collection-method problem from B4, a formatting error — there may be no room left to correct and resubmit before the wall. A team that opens its work relative to Day 365 and treats the following 60 days as correction margin has given itself the thing the earlier posts kept insisting on: slack before a hard clock, not after it.
The track difference reinforces this. The BH and MSK tracks get a longer early runway (up to 180 days before Day 365) than the eCKM/CKM tracks (up to 90). A reporting layer that hard-codes a single end-of-period "open" date for all tracks will be wrong for at least one of them. The open date is track-dependent and measured backward from 365; the deadline is common and measured out to 425.
As with the earlier posts, being precise about the rule means being precise about its edges. The Payment paper gives the two anchors — the 90/180-day early windows relative to Day 365, and the Day 425 outer deadline — but a builder will eventually need things this summary does not resolve: exactly how a beneficiary's track is assigned (which decides whether the 90- or 180-day runway applies), how boundary days are counted (is Day 425 itself inclusive?), and how a rejected-then-resubmitted end-of-period measure is adjudicated against the wall. We are not going to invent those. Build to the conservative reading — anchor the early window to Day 365, treat Day 425 as a firm wall with no boundary-day benefit of the doubt, and keep the correction tail as margin — and put the mechanical questions to CMS through the ACCESS Technical FAQ and the RFA, which are the governing texts.
The rule set dictates the design here the same way it did in every prior post. An end-of-period tracker needs two dates per beneficiary, not one: an open date (Day 365 minus the track's early-window length — 90 or 180) and a hard deadline (Day 425). The state you want to surface isn't "days until 425"; it's "are we inside the early window yet, and how much correction margin remains before the wall." Counting down to 425 alone tells a team it has plenty of time right up until it doesn't.
That closes the series. Under ACCESS, a measure has to be submitted at the right time (B1, B2), be recent enough (B3), be captured the right way (B4) — and, at the end of the care period, land inside a window anchored to Day 365, not against the Day 425 wall. The whole model rewards the same habit: find the earliest date each clock allows, and build toward that, because none of these deadlines give anything back once they pass.
---
Outcome Rail builds reporting infrastructure for ACCESS participants. If you're working through these rules, we're happy to compare notes: [email protected].
Sources: CMS ACCESS Model Payment Amounts and Performance Targets (PDF), p.7 (End-of-Period Reporting) · ACCESS RFA (PDF) · ACCESS Technical FAQ.
Device, lab, and PROM data in; compliant FHIR submissions out — validity windows, cadence clocks, and provenance rules enforced before CMS ever sees the bundle. We're onboarding a small founding cohort of design partners this quarter.