ACCESS Is the Outcome-Aligned Payment Model — And the Bottleneck Is Your Data, Not the API

On July 5, 2026, the ACCESS Model (Advancing Chronic Care with Effective, Scalable Solutions) went live. It is a 10-year national test of a different way to pay for chronic care in Original Medicare. More than 150 organizations have been accepted for the first cohort, and CMS made a point worth pausing on: most of them have never served Medicare beneficiaries before. Private payers representing 165 million members across Medicare Advantage, Medicaid, and commercial coverage have pledged to align with the same payment approach.

The model is voluntary, the admissions are rolling through 2033, and the design principle is stated plainly in the technical FAQ: ACCESS rewards results, not activities.

That sentence is the whole story. The rest of this post is about why the organizations that win under ACCESS will be the ones whose clinical data is structured, coded, and validatable enough to prove the outcome, because that is what the payment depends on.

---

What ACCESS actually pays for

Original Medicare fee-for-service pays for defined activities: a visit, a test, a device. ACCESS introduces Outcome-Aligned Payments (OAPs), recurring payments for managing a qualifying chronic condition, with full payment tied to achieving measurable health outcomes.

The four clinical tracks and their outcome measures:

Payment depends on the Outcome Attainment Threshold: in Year 1, if 50% or more of your aligned beneficiaries meet their targets, you earn 100% of the payment. Below that, payment scales down, capped at a 50% reduction. The threshold can rise in later years.

This is not a tweak to fee-for-service. It is a structural inversion. The unit of payment moves from "we did a thing" to "the patient got better." The care team gets flexibility (in-person, virtual, asynchronous, device-supported) because CMS no longer cares how you got there. They care whether you got there.

That flexibility is the appeal. It is also the trap.

---

The flexibility is the trap

When payment was tied to activities, the data you had to produce was small and well-defined: a CPT code, a claim line, a proof of service. The clinical reality behind it could be messy. Nobody audited whether the blood pressure was actually controlled; they audited whether the visit happened.

When payment is tied to outcomes, the data you have to produce is the outcome. To prove a patient's blood pressure is controlled, you need a coded Observation with a LOINC-coded systolic/diastolic, a UCUM unit, a timestamp, and a provenance chain back to the device or encounter that measured it. To prove a depression outcome, you need a scored PHQ-9 as a FHIR QuestionnaireResponse, validated against the instrument definition, tied to the patient by their Medicare Beneficiary Identifier. To prove a CKM outcome, you need eGFR and UACR labs coded to the specific LOINC variants CMS expects, not the variants your lab vendor happens to send.

And you have to submit it through an API-only interface. There is no portal. There is no file upload. There are four FHIR R4 asynchronous operations ($check-eligibility, $align, $report-data, $unalign), and every submission is a FHIR document Bundle that must conform to ACCESS-specific profiles, US Core 6.1.0, track-specific ICD-10 value sets, and CMS's operations manual.

The organizations that have been doing Medicare FFS for twenty years mostly do not have this data in this shape. The organizations that are new to Medicare (the digital health companies, the chronic care platforms, the virtual clinics in the accepted-applicants list) have even less of it. They have flexible charting, free-text notes, lab results in vendor-specific codes, and patient-reported outcomes in form responses that were never designed to round-trip through a scored FHIR instrument.

This is the part that gets underweighted in the policy conversation. ACCESS is framed as a payment innovation. It is. But the payment innovation only works if the data infrastructure can carry the proof. The model that drafts a beautiful care plan is irrelevant if the system cannot produce a conformant bundle that says "this patient's HbA1c dropped from 8.1 to 6.9, here is the coded Observation, here is the LOINC code, here is the UCUM unit, here is the Provenance back to the lab, and here is the MBI that ties it to the Original Medicare beneficiary."

---

The real bottleneck is data sufficiency, not the API mechanics

We have been doing ACCESS integration work with a clinical platform that is, by most measures, ahead of the curve: they already have FHIR plumbing, C-CDA generation, CQM submission, terminology assets, and production change-capture infrastructure. The scoping question we were asked was the same one every ACCESS participant is about to face: how much of the pipe do we build, and how much do we leave to the customer?

The answer, after a feasibility pass, was that the API mechanics are the easy part. The four operations are knowable now: async request, poll for status, handle result codes. A competent FHIR engineer can stand up the client in weeks.

The hard part, the gating risk, the thing that sizes everything downstream, is data sufficiency. For every ACCESS data element, per track, you have to answer: do we hold this? Is it structured? Is it coded to the code system CMS expects? Is the code the right code, or a plausible-looking wrong one?

That audit looks like this:

Every ? in that table is a project. Every row where the answer is "we hold it, but not in the code CMS expects" is a terminology mapping exercise. Every row where the answer is "we don't hold it" is a product change or an alternative data source. And none of it is optional: a submission with a wrong LOINC, a missing MBI, or an unvalidated PROMIS score is a rejected submission, and the reporting window closes whether you submitted or not.

The API is the last 5% of the work. The other 95% is making your clinical data legible to a standards-conformant, auditable, coded representation of the outcome.

---

Why this is a terminology and conformance problem

This is where ACCESS stops being a payment story and becomes an infrastructure story.

The work between "we have the data somewhere" and "we can submit a conformant bundle" is three layers, and they are exactly the layers we have been building:

1. Terminology: the concept-to-code mapping

ACCESS does not accept "high blood pressure." It accepts an ICD-10-CM code from a specific value set. It does not accept "LDL." It accepts a LOINC code, in a UCUM unit, on an Observation resource profiled to ACCESS expectations. The mapping from how your system thinks about a concept to how CMS thinks about it is not a one-time lookup; it is a versioned, reviewable, auditable artifact. Each mapping carries a confidence level, a reviewer, a date, and a source. When the value set changes (and it will), the mapping updates and the downstream submissions update with it.

This is what ReasonHub is: a terminology platform for search, validation, and expansion of SNOMED CT, LOINC, ICD-10-CM, RxNorm, and UCUM, plus the artifact lifecycle to manage mappings from draft to validated to published. The reason ACCESS makes terminology non-optional is that the payment depends on the code being right, not approximately right.

2. FHIR conformance: the validation gate

ACCESS publishes a FHIR Implementation Guide with profiles, code systems, value sets, and example bundles. A submission that does not validate against the IG is a submission that gets rejected. The question is not "did we produce FHIR?" It is "does this resource conform to access-data-reporting-bundle, does the Patient carry US Core 6.1.0, does the Condition carry the right ICD-10 from the right value set, does the Observation carry the right LOINC and UCUM, and does the Composition resolve all its references inside the Bundle?"

This is what rh-validator is for. It is a native Rust FHIR validator built for the parts of delivery where validation needs to be immediate, repeatable, and inspectable: local development, pull requests, package builds, agent loops, and batch checks before a release. It runs profile-driven validation, FHIRPath invariants, ValueSet/terminology checks, and QuestionnaireResponse validation, and emits structured issues that can be printed for a developer, emitted as JSON for a pipeline, or rendered as a FHIR OperationOutcome for an agent.

The operational shape that matters under ACCESS: validation cheap enough to run constantly, clear enough for humans, and structured enough for automation. A validator that takes seconds to wake up becomes a release gate. A validator that returns prose-only output becomes awkward in CI. A validator with unclear conformance status creates false confidence. ACCESS submissions are too infrequent (quarterly windows of 70–110 days) and too high-stakes (payment depends on them) to leave conformance to a "looks right" check.

3. The Propose → Verify → Review pattern

This is the pattern we have been writing about, and ACCESS is the cleanest real-world instance of it we have seen:

1. Propose. An AI model (any model) drafts a care plan, generates a candidate FHIR bundle, maps a free-text diagnosis to a candidate ICD-10.
2. Verify. Deterministic services check it: terminology server validates the code is in the value set, rh-validator checks the resource conforms to the ACCESS profile, schema checks confirm the MBI is present and well-formed, scoring logic confirms the PROMIS response is valid against the instrument definition.
3. Review. A human (Clinical Director, informaticist, clinical QA) reviews only when risk warrants it: a low-confidence mapping, an out-of-range value, a rejected submission.

The point of the pattern is that it makes the model interchangeable. When the clinical knowledge lives in verified tools (the terminology server, the validator, the scoring tables), you can swap models, reduce cost, and maintain trust. Under ACCESS, that is not a nice-to-have. The payment depends on the outcome being proven, and proof is a deterministic property. "The model said so" is not a defensible submission record. A versioned, traceable, standards-conformant artifact is.

---

Why ACCESS rhymes with prior authorization

We have been here before. ACCESS is the chronic-care version of the same shift we are working on in prior authorization through the CodeX Prior Authorization in Medical Oncology use case.

In prior auth, the regulatory driver is CMS-0057-F, the 2027 interoperability deadline that converts FHIR-based prior authorization from "encouraged" to "compelled." The technical work is CRD, DTR, and PAS, FHIR APIs that make coverage criteria machine-readable, auditable, and submittable. The bottleneck is the same: the data is already in the record, but it cannot be used because it is not structured or coded consistently enough to round-trip through a conformant FHIR exchange.

ACCESS is the same thesis applied to a different part of the payment system. In prior auth, the obligation is on the payer to make criteria computable. In ACCESS, the obligation is on the participant to make outcomes computable. Both convert the same underlying infrastructure (FHIR, terminology, validation, structured clinical data) from a best practice into a compliance requirement with a clock.

The direction of travel is unambiguous. FHIR and computable clinical logic are moving from "encouraged" to "compelled." The organizations that build the operating layer now (terminology, conformance, deterministic validation, coded data at the source) will be the ones that can move on ACCESS, on prior auth, on MIPS, on HEDIS, on TEFCA, and on the payer API that shows up next year. The ones that defer will be rebuilding the same layer under deadline pressure, each time.

---

The market signal that matters

The most interesting number in the ACCESS announcement is not 150 organizations or 165 million members. It is the parenthetical: most of the accepted organizations have not previously served Medicare beneficiaries.

That means a population of companies (digital health platforms, virtual clinics, chronic care management vendors, remote monitoring companies) are about to build Medicare-grade clinical data infrastructure for the first time. They are about to discover that flexible charting does not produce conformant FHIR, that free-text diagnoses do not round-trip through ICD-10 value sets, and that a form response is not a scored PROMIS instrument.

That is a consulting and product opportunity, but more importantly it is a forcing function. The organizations that treat ACCESS as a one-off integration will rebuild the same layer for the next program. The organizations that treat it as the moment to invest in terminology, coded data, and conformance will have an asset that compounds.

The terminology maps you build for ACCESS are the same maps you need for HEDIS. The FHIR store you build for ACCESS reporting is the same store you query for a payer API. The validator you run before an ACCESS submission is the same validator you run in CI on every clinical artifact your team produces. One artifact, many obligations.

---

What we are doing about it

We are building the layers underneath ACCESS because they are the layers underneath everything else.

• ReasonHub: terminology search, validation, and expansion for SNOMED CT, LOINC, ICD-10-CM, RxNorm, and UCUM, plus the artifact lifecycle that manages concept-to-code mappings from draft to validated to published.
• rh: a Rust FHIR toolkit with a native validator built for CI, agent loops, and batch conformance checks before submission. The same validation that runs in a developer terminal runs in a GitHub Actions job and in an agent checking its own generated bundles.
• ReasonHealth Skills: domain-aware AI workflows that connect any AI harness to the terminology and conformance infrastructure, so generation is paired with deterministic validation by design.
• Vermonster consulting: the informatics and engineering work of turning flexible clinical data into coded, conformant, submittable artifacts. The data-sufficiency audit, the terminology mapping tables, the FHIR reporting layer, and the submission pipe. The work between "we have the data" and "we can prove the outcome."

If you are an ACCESS participant, or building for a participant, and you are looking at your data and realizing the API is the easy part, that is the right realization to have. The hard part is making your clinical data legible to a system that pays for results. That is the layer we build. We would rather talk to you early, when the data-sufficiency audit can size the work, than late, when the reporting window is closing.

---

How to follow the model

• Read the ACCESS model page. cms.gov/priorities/innovation/innovation-models/access is the authoritative source for the model overview, payment details, and participant requirements.
• Read the technical FAQ. cms.gov/priorities/innovation/access-technical-frequently-asked-questions covers eligibility, performance measurement, the FFS exclusion, and the care-coordination requirements.
• Read the FHIR IG. dsacms.github.io/cmmi-access-model is the draft Implementation Guide with profiles, operations, code systems, value sets, and example bundles per track.
• Talk to us. If you are scoping an ACCESS integration, whether you are the participant of record or the platform a participant builds on, the data-sufficiency pass is the place to start. We can map your data to the ACCESS measure set, identify the gaps, and build the terminology and conformance layer that makes your outcomes provable.

ACCESS is a 10-year test of whether outcome-aligned payment works. The policy question is important. The infrastructure question is more immediate: can your data prove the outcome? That is the bottleneck. That is the work. And it is the same work, with the same shape, that the next five programs will ask for too.