If you read one sentence of the CMS "ACCESS Model Payment Amounts and Performance Targets" paper closely, make it the quarterly reporting rule on p.7: a valid quarterly measure must be submitted 70 to 110 days after the previous submission.
Not "once per calendar quarter." Not "every 90 days from alignment." After the previous submission. That one phrase changes what kind of problem this is — and it's why we called this the easiest rule in the model to misread in our overview of the two clocks. This post is the deeper cut: what a rolling anchor actually does to a reporting schedule.
1. The anchor is your own behavior, not a date CMS publishes. A calendar-quarter regime gives everyone the same fixed walls. The ACCESS window is computed from the date you last submitted for that beneficiary. Two beneficiaries aligned the same week can end up on completely different submission schedules within a couple of cycles, because their windows depend on when each prior submission actually landed.
2. Both bounds bind. Day 69 after your previous submission is outside the window, the same as day 111. Per the Payment paper, a valid quarterly measure lands in the 70–110 band — there is a too early, not just a too late. Any workflow tuned only to "don't be late" is checking half the rule.
3. Every submission rewrites the rest of the schedule. Submit on day 70 of your window and your next window opens 70 days from that date. Submit on day 110 and it opens 40 days later than it would have. Each submission is also a scheduling decision for every window after it.
This part is pure arithmetic on the rule as stated — no interpretation.
On paper, a fixed cadence can sit inside the window: 90 days is between 70 and 110, so a plan that says "submit every 90 days" is compliant as long as every submission actually happens on the planned day. The trouble is that the plan and the rule use different anchors. Your reminder system counts from the schedule; the window counts from what actually happened.
Walk one slip through: the plan says submit on day 90, but the reading isn't collected until day 106 — still inside that window, no violation. Your next planned date, day 180 of the original schedule, is now only 74 days after the actual submission — still legal, but you've quietly moved from the middle of the window to 4 days above its floor. Let that drift keep accumulating in the same direction and a planned date eventually lands before day 70 of the real window: an early, invalid submission, triggered by a calendar that never looked wrong.
Batching runs the same math in the other direction. Submitting "ahead of schedule" to clear a backlog pulls every subsequent window earlier — compression compounds, because each early submission re-anchors the next one.
The failure mode isn't the arithmetic being hard. It's that the arithmetic is done against a date that lives in your submission history, and most reminder tooling doesn't read submission history.
Being precise about the source also means being precise about its edges. The Payment paper states the 70–110 rule; in our reading it does not spell out, for example, how the anchor behaves after a submission that fails validity (a reading collected outside its freshness window, or via a non-permitted method — the ACCESS RFA, Appendix C, governs collection methods). Does an invalid submission reset the clock, or does the window keep counting from the last valid one? We're not going to guess in either direction: build conservatively, and put the question to CMS directly — the ACCESS Technical FAQ and the model's support channels exist for exactly this class of question.
And one distinction worth repeating from the paper itself: quarterly submissions are collected for monitoring and auditing rather than used directly to set the payment amount — but timely quarterly submission is still a hard requirement that satisfies active care delivery and counts toward attainment. "Not a payment input" does not mean "optional."
The rule dictates the design: next-window bounds have to be computed from actual submission dates, per beneficiary, not scheduled from a calendar. Concretely, that means a ledger where every beneficiary row carries the date of the last valid submission and two derived dates — earliest legal next submission (last + 70) and the wall (last + 110) — recomputed the moment a submission lands. Reminders fire from the derived dates, not from a repeating calendar event. Anything less, and the schedule you're following and the window CMS is applying will eventually be two different things.
If you're doing this in a spreadsheet today, that's workable at small volume — the point is where the dates come from, not the tool. The two derived columns are the whole defense.
Next in the series: the six validity windows that decide when a reading stops counting at all.
---
Outcome Rail builds reporting infrastructure for ACCESS participants. If you're working through these windows, we're happy to compare notes: [email protected].
Sources: CMS ACCESS Model Payment Amounts and Performance Targets (PDF), p.7 · ACCESS RFA (PDF), Appendix C · 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.