Short, sourced explainers on the model's reporting deadlines, validity windows, and provenance rules — each one traced back to CMS's own documents, so you can read the source yourself. This is the reference we kept wanting while we built the rail.
Short reads that walk the rules in the order they bite: first the two clocks that govern when you submit, then the windows and methods that govern whether a reading is eligible in the first place. Best read in order.
ACCESS has one deadline that unaligns a beneficiary and one rolling window that isn't what "quarterly" sounds like. Both come from CMS's own payment paper.
Read it →The ACCESS quarterly reporting window is anchored to your previous submission, not the calendar. Here's the arithmetic of how the window actually moves — from CMS's own payment paper.
Read it →Under the ACCESS model, a reading is only eligible if it was collected inside its freshness window. Here are the six windows — and the collection-method rule behind them — straight from CMS's own documents.
Read it →Under the ACCESS model, a reading can be disqualified before it's ever submitted — by *how* it was captured. Here are the collection-method rules, straight from the RFA.
Read it →The ACCESS end-of-period measure has a hard outer deadline at Day 425 — but the *early* window that most teams should actually target is measured backward from a different day. Here's the math, straight from the Payment paper.
Read it →In the ACCESS model, a submission can be accepted the day you send it and still fail eleven months later at reconciliation. That gap — between "accepted today" and "survives the year-end audit" — is a specific, buildable engineering problem. Here's how we think about it.
Read it →The first question a security reviewer asks a reporting vendor is "where does our PHI sit in your cloud?" For an ACCESS-model pilot with us, the honest answer is: it doesn't. Here's the architecture, the one narrow data channel, and — read this part — the list of what we don't have yet.
Read it →Half of the Medicare portion of every Outcome-Aligned Payment (OAP) is withheld until CMS reconciles your outcomes — and a beneficiary you never reported still counts against your attainment threshold. Here's how a single slipped window turns into dollars, walked through honestly, with the numbers CMS actually published (and the one it hasn't).
Read it →8 measure types, 12 verdict codes, 4 rule families, 47 conformance scenarios. Here is the actual coverage map of our ACCESS validation engine — what it checks, how each check is tested, and the specific things this evidence does not tell you.
Read it →If you are deciding whether to apply to the CMS ACCESS Model, the clinical work is the part you can already picture. The reporting obligations are the part that surprises people. Here is what has to be true operationally, per CMS's own documents — every rule sourced, no deadline we can't stand behind.
Read it →The CMS ACCESS Model's FFS Exclusion applies at the beneficiary level, not per condition — and a separate, softer rule in the same document is scoped "for the same condition." Both quoted verbatim with page numbers, including who the exclusion does not bind.
Read it →CMS runs the ACCESS Model as a randomized evaluation with beneficiary-level randomization — a share of people who try to enroll are assigned to a comparison group and are ineligible for 12 months. The RFA publishes the year-1 rate. Here is what it does to a panel forecast, including ours.
Read it →CMS sets out what happens when a baseline reporting deadline is missed under the ACCESS Model, and the passage does not end where we used to end it. Here is the full paragraph, the remedy CMS names inside it, the part CMS has not specified, and the correction we owed our own readers.
Read it →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.