The last post in this series, on the six validity windows, ended on a loose thread: passing the freshness window tells you a reading is recent enough, but it does not tell you the reading is eligible. A blood pressure collected yesterday — comfortably inside its 15-day window — can still be disqualified. Not because of when it was taken, but because of how.
That's the subject of this post. The ACCESS model constrains the collection method for its outcome measures, and those constraints apply at the moment of capture, upstream of every clock the earlier posts covered. A reading that was captured the wrong way is not a stale reading you can refresh — it never counted in the first place.
The collection-method requirements live in the ACCESS "Request for Applications" (RFA), Appendix C. In our reading, three of them do most of the work:
Read those three lines together and a single principle falls out: for most measures, the model does not accept a number on its own. It accepts a number plus a provenance — a specific instrument, a specific kind of lab, a specific chain of custody. A value with the right magnitude but the wrong origin is not a lesser reading; it is an ineligible one.
The freshness windows from the last post are a submission-time check: at the moment you assemble a submission, is each reading still inside its window? You can run that check against data you already hold.
The collection-method rules are a capture-time check, and that is a harder place to enforce them — because by the time a value reaches your reporting layer, the facts that decide eligibility (which cuff, how many readings, which lab) may already be lost. If your intake accepts a blood pressure as a bare number, you have no field that tells you whether it came from a validated upper-arm cuff or a nurse typing a hallway reading into a box. The reading looks fine. It is not fine. And you find that out — if you find it out at all — far downstream of where the problem was created.
So the practical order of operations inverts the way people usually think about data quality. Freshness you can fix after the fact by collecting again inside the window. Provenance you cannot fix after the fact at all: if the capturing system didn't record how a value was obtained, no later step can reconstruct it. The cheapest place to enforce the collection-method rules is the intake form, not the submission builder.
Blood pressure — instrument and method, not just value. The requirement is a validated upper-arm cuff, averaging at least three readings, with manual entry excluded. That is two constraints, not one: a device constraint (validated, upper-arm) and a method constraint (an average of multiple readings). A single office reading typed into a field satisfies neither, even if the number is clinically reasonable. What this means for a reporting layer is that a blood-pressure record needs to carry more than a systolic/diastolic pair — it needs enough about its own origin to stand behind the "not manual entry" rule.
Labs — the source has to be accredited/CLIA. For the lab measures, eligibility depends on where the value was produced. A value copied from a patient's own notes, or from a non-accredited point-of-care device, is a different thing from a CLIA-lab result even when the two numbers match. The reporting-layer consequence is the same shape as the blood-pressure one: the record needs to identify its source well enough to show the source qualifies.
Self-report — disallowed, except where it's explicitly allowed. The default is that self-reported values don't count. The two carve-outs are weight and PROMs — which makes sense, because a patient-reported outcome measure is, by definition, self-reported, and weight is routinely patient-reported. The trap here is symmetry bias: it is tempting to treat "the patient told us" as uniformly acceptable or uniformly unacceptable, and the rule is neither. It is a short allow-list against a disallow default. Build the allow-list explicitly; don't infer it.
Being precise about the source means being precise about its edges. The Companion rule as we've summarized it establishes that a validated upper-arm cuff and a multi-reading average are required — it does not, in our summary, pin down every mechanical detail a builder would eventually need: exactly which validation protocol or device listing qualifies a cuff, precisely how the "at least three readings" are to be spaced or averaged, or how edge cases (a device that is validated but not upper-arm, a lab that is accredited under a non-CLIA framework) are adjudicated. We are not going to invent those specifics. Build to the conservative reading of the rule — require the provenance fields, reject bare numbers — and put the mechanical questions to CMS directly through the ACCESS Technical FAQ and the RFA itself, which is the governing text.
The rule set dictates the design, the same way the freshness windows did. Where the validity layer from the last post carried a date per reading, the eligibility layer has to carry an origin per reading: for a blood pressure, enough to assert it wasn't manual entry; for a lab, enough to assert an accredited/CLIA source; for any self-reported value, a flag that routes it against the weight/PROMs allow-list rather than the disallow default.
Put the two layers side by side and the shape of a minimal eligibility check emerges. A reading is submittable only when it is both inside its freshness window (the last post) and captured by an accepted method (this post) — two independent gates, both of which have to be green, and the second of which has to be captured at intake or it can't be answered later. If you're tracking this in a spreadsheet today, the collection-method rule is the column you cannot backfill: the date you can always recompute, but "how was this obtained" is only true if someone recorded it when the reading was taken.
That's the whole series' throughline in one sentence: under ACCESS, a reading has to be submitted at the right time (B1, B2), be recent enough (B3), and have been captured the right way (this post) — and the earliest of those to fail is the last one you can fix.
---
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: ACCESS RFA (PDF), Appendix C (collection-method requirements) · CMS ACCESS Model Payment Amounts and Performance Targets (PDF), p.6 (OAP Measure Validity, referenced) · 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.