Device, lab, and PROM data in. Compliant FHIR submissions out. Validity windows, cadence clocks, and provenance rules enforced before CMS ever sees the bundle — so the withheld half of your payment has a fighting chance at reconciliation.
ACCESS ties half your Medicare payment to data that has to be captured the right way, from the right source, inside a moving window — for 10 years. A missed Day-60 baseline auto-unaligns the beneficiary. Blood-pressure readings must be validated-cuff, three-reading averages, no manual entry. Quarterly windows are a rolling 70–110 days from your last accepted submission, not the calendar. Get any of it wrong and the beneficiary can't count toward your outcome targets — and the withhold rides on it.
We get ACCESS participants to a compliant submission: a plug-in rail that turns device, lab, and PROM data into CMS-ready FHIR bundles — data built to survive reconciliation.
One rail sits between your data and Medicare's ACCESS reporting API. You send what you already collect; we enforce the rules and keep the deadline clock.
Device, EHR, lab, and PROM data in — from the sources you already run.
Checked against CMS measure rules: validity windows, cadence clocks, collection-method and provenance rules — before submission.
Assembled into FHIR bundles built to CMS's draft ACCESS reporting spec.
Sent through the model's reporting API, with every attempt logged to an append-only audit trail.
A per-beneficiary dashboard: what's due, what's accepted, who's trending off-track vs. CMS's published attainment rules, and what that puts at risk in withheld dollars — all year, not just at reconciliation.
Built against CMS's ACCESS reporting Implementation Guide, which is currently DRAFT and version-drifting. Absorbing that drift is the product: when the spec moves, we patch once — your team doesn't chase it.
A build runs an estimated $65–140K up front, plus a decade of chasing a DRAFT spec that drifts. That's headcount doing CMS compliance instead of your roadmap. We absorb the drift for every participant at once.
The heavyweights are six-figure contracts and quarter-long implementations built for health systems. This is purpose-built for ACCESS — designed to be live in days, not quarters.
Pipes move FHIR resources; they don't know an LDL-C's validity window, which provenance fields survive reconciliation, or the rolling 70–110-day cadence. We sit on top of your pipes and handle the measure logic.
Half of every outcome payment is withheld until CMS confirms your end-of-period results — but your quarterly submissions already carry the signal. The rail reads them: every beneficiary gets a trajectory against the CMS attainment rule for their measure and track, an arithmetic projection to day 365, and a place on a care-manager worklist — who needs a collection, whose window closes next, who's trending off-track, and what each group puts at risk in withheld dollars ($72–168 per beneficiary per year at the conservative base). Submission deadlines always outrank forecast findings: a closing CMS window can never be buried by a forecast view.
Forecasting and monitoring only: projections are arithmetic (last value + trend), not clinical predictions, and never a guarantee of reconciliation outcomes. The worklist surfaces data-collection status — no clinical recommendations. Demo runs on synthetic data.
ACCESS withholds half of every Outcomes-Based Adjustment Payment pending reconciliation — a conservative reading of published CMS allowed amounts puts that at $72–168 per aligned beneficiary per year (50% of the Medicare 80% share), depending on track. That's revenue you've already booked, released only if your data holds up. The rail exists to protect it.
One missed Day-60 baseline stops the full payment for that beneficiary. It isn't a late fee — CMS unaligns them. A failed reconciliation cycle costs more than any tooling decision you'll make this year: the data either survives, or the withheld half doesn't come back. Every rule the rail enforces exists because getting it wrong is the expensive path.
Want this run for your track mix and beneficiary counts? Email us your rough numbers and we'll send the worked estimate.
Based on CMS-published ACCESS Model payment amounts (Effective Period Jul 2026–Dec 2027). Actual payments depend on enrollment, outcome attainment, and CMS payment adjustments. Not a guarantee of revenue.
A small founding cohort on founding terms, in exchange for spec feedback and a logo. You get the rail live before your first baseline deadlines bite.
You can — the question is opportunity cost. The IG is public but DRAFT and version-drifting, the cadence is a rolling window rather than calendar quarters, and a missed Day-60 baseline auto-unaligns the beneficiary. A build is an estimated $65–140K plus a decade of maintenance. When the spec moves, an in-house team patches alone; we patch once for everyone.
That's the argument for buying. The payment-policy numbers — windows, deadlines, rates — come from the CMS Payment paper and RFA and are stable; we've verified them to primary source. What drifts is the transport layer, and absorbing that drift is exactly the product.
Every beneficiary you align now has a hard Day-60 baseline. Missing it isn't a late fee — CMS unaligns the beneficiary and you may not provide services under the model for them. Waiting means aligning beneficiaries you can't keep.
The budget is the withhold itself — $72–168 per aligned beneficiary per year that you've already booked as at-risk revenue. Weigh any tooling decision against what a single failed reconciliation cycle puts at risk. (And to be clear: CMS provides no infrastructure funding for this — we checked the RFA and FAQ in full.)
ACCESS is explicitly not MIPS — it won't qualify as an Advanced APM and its services don't feed MIPS reporting. Registries are built for annual QPP submissions on calendar cycles; ACCESS is per-beneficiary rolling windows with device-provenance rules and a bespoke reporting API.
Your data stays yours. Submissions are standard ACCESS FHIR bundles, exportable any day — leaving us costs a re-point, not a rebuild. The 10-year horizon is the argument: it's dozens of rolling windows per cohort. The real risk isn't us disappearing; it's whether an internal build survives a decade of spec drift.
Tell us your track and rough beneficiary volume. We'll send the annotated deadline summary and set up a 20-minute working session — no slides, just your reporting problem.