CMS outlines Access Model APIs, eligibility and alignment rules, and data‑reporting requirements

Centers for Medicare & Medicaid Services officials provided implementation guidance for the Access Model’s technical interfaces and data reporting requirements during a CMS office hour, noting key deadlines and operational rules for prospective participants.

Nora Connor, Access Model co‑lead at the CMS Innovation Center, and Pooja Nair, co‑lead, described the model as a voluntary, nationwide 10‑year demonstration beginning July 5, 2026, that uses an outcome‑aligned payment (OAP) option to support technology‑enabled care. "The goal is to help your implementation teams understand how data needs to be submitted, what the APIs are designed to do, and how to align with the technology standards required for participation and performance measurement in the access model," Connor said.

Why it matters: participation in Access requires technical readiness and adherence to standardized data flows. CMS said participants must use FHIR‑based standards for electronic health information exchange, submit required clinical and patient‑reported outcome data through the Data Reporting API (the only accepted method), and establish two‑way connectivity to a health information exchange within 12 months of the model start (deadline: July 5, 2027).

APIs and workflow: CMS described four core APIs. The Eligibility API performs a pre‑check of Medicare coverage and returns eligibility result codes; the Alignment API assigns an eligible beneficiary to a participant and specific clinical track; the Unalignment API supports permitted removals from alignment; and the Data Reporting API accepts baseline, quarterly and end‑of‑period OAP measure bundles. All four APIs use an asynchronous submit‑and‑poll pattern (POST a request, extract a submission‑status URL from the content‑location header, then GET the status until the final response is returned).

Key technical inputs and result codes: participants must supply an assigned participant ID, payer ID (Original Medicare), and patient information conforming to the US Core Patient profile (identifier, name, gender; date of birth optional but recommended). Track codes map to the four clinical tracks (ECKM, CKM, BH, MSK). CMS highlighted common result codes (eligible; not eligible — not Medicare; not eligible — receiving excluded services such as hospice; not eligible diagnoses; randomized control group) and directed implementers to the Access Implementation Guide for full value‑set definitions.

Alignment, switching and unalignment: the Alignment API requires condition parameters and a boolean is_provider_referral flag. CMS stressed the model’s 3‑month lock‑in: a patient can request a switch after three months, but the new participant must verify switch eligibility via the Eligibility API, capture explicit patient consent, and submit an alignment request indicating the switch_consent_attestation. CMS noted an exception: because of clinical overlap, patients may switch between the Early Cardio‑Kidney‑Metabolic (ECKM) and Cardio‑Kidney‑Metabolic (CKM) tracks before the lock‑in ends. Unalignment is limited to four reason codes (geographic relocation, loss of contact, patient initiated post‑lock‑in, and no longer clinically eligible) and must include an ICD‑10 code and a short narrative when using the clinical‑ineligibility reason.

Data reporting and measure timing: the Data Reporting API will accept OAP measure bundles for aligned patients. CMS reiterated that the Data Reporting API is being finalized and is subject to change, but data submission requirements are accurate. Reporting cadences and clinical validity windows differ by track: patient‑reported outcome measures (MSK and behavioral health) generally require a 15‑day clinical validity window; MSK PROMs and pain measures are reported at baseline, quarterly and end‑of‑period; behavioral health uses PHQ‑9 and GAD‑7 as the required instruments for the first 18 months (through Dec. 31, 2027); ECKM and CKM tracks require baseline and periodic blood pressure and weight data and have specific windows for labs (LDL, HbA1c, eGFR, urine albumin‑to‑creatinine ratio) with some lab windows up to one or two years depending on the measure. CMS also allows certain end‑of‑period measures to be submitted early (up to 180 days for some tracks; up to 90 days early for certain ECKM/CKM measures to support early success reporting).

Operational notes and next steps: CMS will create automatic FHIR subscription notifications initially for unalignment events and may expand subscriptions (data due dates, renewal reminders) based on feedback. The office hour presenters pointed to the Access Implementation Guide and the Request for Applications (RFA) for detailed value sets and asked participants to use the Q&A and help‑desk channels for outstanding technical clarifications. CMS emphasized that, unlike other CMMI models, Access requires data submission via the Data Reporting API only; there are no alternative reporting routes.

The next procedural steps CMS cited include publishing the implementation guide and operations manual, making an API test environment available to participants for code development and testing later in the spring, and posting slides, transcript and recording to the Access Model web page.