What "data that survives reconciliation" means

The last five posts were all about clocks. B1 covered the two that start at alignment; B2 covered the rolling window between submissions; B3 covered how long a single reading stays fresh; B4 covered whether a reading was even eligible when it was captured; B5 covered the deadline at the far end of the care period. Each one described a different way a reading that looks fine can quietly fail to count.

This post is about the thing all five have in common — and what you actually have to build to survive it.

The gap this whole series has been circling

Here is the uncomfortable fact underneath every earlier post. When you submit ACCESS data, the endpoint that receives it checks whether the submission is structurally correct: is this well-formed data in the shape the rulebook describes? What that check does not do is re-derive, on submission day, whether each reading inside the bundle was fresh enough, on the right cadence, and traceable to a defensible source. A submission can pass the structural check — be accepted, get a ticket back, look done — and still contain a reading that will not hold up when the rules are applied in full at year-end.

That year-end true-up is reconciliation: the point where a participant's submitted data is compared against the model's rules and payment is adjusted accordingly. It is also the worst possible moment to discover a problem, because it arrives long after the window that would have let you fix it has closed. A stale reading isn't rejected the day you send it. It's counted as a miss almost a year later, when there is nothing left to do about it.

So there are really two different questions you can ask about a submission:

• "Will this be accepted today?" — a question about structure, answered on submission day.
• "Will this survive reconciliation?" — a question about freshness, cadence, and provenance, answered eleven months later unless you answer it yourself first.

Everything in the ACCESS ruleset lives in the space between those two questions. "Data that survives reconciliation" is just our name for data that answers the second one before you send it, not after.

Answering the second question early is an engineering problem, not a policy one

The reason this gap is a product and not just a warning is that the second question is mechanically answerable in advance. You do not need CMS to tell you a reading is stale — the freshness window is published. You do not need to wait for reconciliation to know a submission is outside its cadence window — the cadence rule is published. You do not need a ruling to know a reading has no defensible source — either the provenance is attached or it isn't. Every rule that decides the year-end outcome is knowable at submission time. The only thing missing, for most teams, is a layer that actually checks all of them before the bundle goes out and refuses to send anything that would fail.

That is the shape of what we build. Concretely, it means four properties have to be true of the data, and stay true all the way to the audit:

It has to be fresh and on-cadence at submission. Every reading is checked against its own validity window and every submission against its cadence window before packaging — the exact rules the earlier posts walked through. Anything outside the window is held back rather than sent, because sending it doesn't make it count; it just moves the failure from today to reconciliation.

Every held-back reading has to come with a reason. When something is refused, the refusal is written in plain English: what was missed, which rule it broke, and what would have made it qualify. That is deliberately not a log line for engineers — it's an account a compliance lead can act on the same day, and the same account they can hand to an auditor later. A refusal you can't explain is a refusal you can't defend.

Every reading has to carry its own biography. Where it came from, when it was collected, by what method — attached to the reading itself, so the proof travels with the data rather than living in a separate spreadsheet someone has to reconstruct under pressure a year later. Losing that trail is treated, in our system, as data corruption, not as a missing label.

And the whole thing has to be checkable, not just asserted. The rules are encoded as versioned data, not buried in code, so when CMS revises the rulebook the change is one edit to a data table, and the checks that depend on it move with it. The pipeline is exercised end-to-end against our own test server — built line-by-line to CMS's draft specification, and never presented as a live CMS system — so "the submission flow works" is something we can demonstrate rather than promise.

Why "we send FHIR" and "our data survives reconciliation" are not the same sentence

Plenty of teams can produce a structurally valid bundle. That clears the first question — accepted today. It says nothing about the second one. The compounding difficulty, and the reason this is worth building carefully, is in the parts that don't show up on submission day:

• The rules-as-data encoding of the fine print — the rolling cadence keyed to the previous submission, the inclusive boundary days, the baseline-miss consequence, the track-dependent windows — all the details the earlier posts spelled out, encoded once and verified against the primary sources rather than reimplemented from memory each time.
• The provenance-first data model, where every number is defensible after the fact. This is nearly impossible to bolt on later; either the biography rode with the reading from the start or it didn't.
• The plain-English explanation of every refusal, which is not an internal debugging convenience but a surface a customer shows their own auditors.
• A verification habit — deterministic runs, independent re-checks, a reproduction path an outsider can follow — so the claims are the kind a stranger can test, not the kind you have to take on faith.

None of those is glamorous. Together they are the entire difference between clearing the structural check and holding up at the audit. That difference is the product.

What this doesn't claim

Being precise about the property means being precise about its limits. "Survives reconciliation" is a statement about data quality — freshness, cadence, and provenance holding up against the published rules — and nothing more. It is not a claim about clinical outcomes, not a prediction about payment, and not a guarantee that any given submission will be paid. Our checks run today on synthetic data against our own test server built to CMS's draft specification; where the rules depend on information the system wasn't given, it says so rather than guessing. And because the specification is still a draft, the honest posture is that the rulebook can move — which is exactly why the rules live as data that can move with it.

The earlier posts each described one way to lose a care period to a clock. This is the other half of the same idea: the losses are all preventable at submission time, and preventing them — not sending FHIR — is what the work actually is.

---

Outcome Rail builds reporting infrastructure for ACCESS participants. If you're working through these rules, we're happy to compare notes: hello@outcomerail.com.

Sources: CMS ACCESS Model page · ACCESS Technical FAQ · ACCESS RFA (PDF) · ACCESS Payment Amounts and Performance Targets (PDF). Deadline-mechanics detail is carried in the companion posts B1–B5 (linked above); this post states no rule figures of its own.