The CMS ACCESS Model is moving full steam ahead, with the first performance period launching on July 5, 2026. CMS recently released the draft ACCESS Model API Implementation Guide (v0.9.1) and hosted a technical office hours webinar to answer pressing developer questions.
Overall, the webinar and office hours were beneficial; it summarized the key points of the API implementation guide saving time that would otherwise be spent digging through all their documentation. Email notifications are lacking, and several Q&A topics requested a webhook method (CMS calls a participant’s API), indicating that many participants want to automate those notifications.
If your organization is planning to deliver technology-supported chronic care under this new outcome-aligned payment structure, your engineering teams are likely diving into these specifications right now. Here is a breakdown of what we learned from the Implementation Guide (IG) and office hours, and advice for fast-tracking your technical readiness.
Spoiler alert: there are some substantial hurdles and challenges. We strongly recommend getting started sooner rather than later.
Key Takeaways from the Implementation Guide and Office Hours
The new IG provides the technical blueprints for how participants will interact with CMS. All API interactions are built on the FHIR R4 standard and demand enterprise-grade security utilizing the OAuth 2.0 Client Credentials flow via SMART App Launch Backend Services.
CMS outlined four primary APIs that participants will use: Eligibility, Alignment, Unalignment, and Data Reporting (which will be detailed in a future release).
During the recent technical office hours, CMS shed light on a few vital operational workflows:
- Asynchronous processing is mandatory: ACCESS APIs use an asynchronous request-response pattern to accommodate CMS processing times. Rather than an immediate confirmation, clients receive an HTTP 202 response and must implement a submit-and-poll workflow using the $submission-status operation. CMS representatives recommended an initial wait of 5-10 seconds, followed by polling every 10-30 seconds with a recommended timeout duration of 5 minutes.
- Event notifications via e-mail: When a patient is successfully aligned, the system automatically creates FHIR subscriptions. These subscriptions are only enabled to send unalignment emails to participants. This means you’ll need to be prepared to consume alerts via email and act on them manually. CMS is also considering adding future push notifications for critical upcoming deadlines, such as the 60-day baseline reporting window, the 70-110-day quarterly reporting windows, and alignment renewals.
- Webhook support: While automated unalignment notifications are currently email-only, CMS noted during the Q&A that they will evaluate adding webhook support in the future to allow software to handle unalignments on the provider’s behalf.
Technical hurdles for ACCESS participants
For healthcare technology companies and providers, these specifications present a substantial integration challenge. To successfully participate, your system must support a bidirectional integration pattern.
Your engineering team will need to build a durable asynchronous polling engine capable of managing timeouts and exponential backoffs. Furthermore, you will need to manage per-organization CMS credentials using complex asymmetric key pairs (JWT assertions) to obtain access tokens.
Beyond connectivity, participants face a massive orchestration hurdle. Clinical measures and patient-reported outcomes (like the PHQ-9, GAD-7, and blood pressure readings) must be mapped to specific FHIR profiles and submitted strictly within tight clinical validity windows. Building a stateful engine to track each patient’s enrollment date, calculate when their baseline and quarterly submissions are due, and extract only the “new” values from your EHR or assessments database requires significant custom development.
Accelerating your ACCESS integration with an Interop Partner
Building and maintaining the ACCESS integration is a nontrivial effort. It might make sense to bring on a partner to stand up the integration quickly and support it over time as requirements evolve, so your team can focus on patient care. If you consider the partnership route, we have lots of advice for how to choose the right partner.
Redox specializes in solving these exact interoperability and orchestration challenges. We are already supporting customers planning to participate in ACCESS. The TL;DR for our thinking so far:
- Streamlined authentication: We implement the SMART Backend Services token flow on behalf of customers, securely storing, managing, and rotating the required credentials for each participant organization.
- Automated polling & routing: We abstract away the complexity of the asynchronous $submission-status polling engine. We handle the repetitive polling, timeouts, and exponential backoffs, delivering the final, definitive result straight to the customer’s system.
- FHIR data translation: Once CMS publishes the final Data Reporting API specs, we can map the customer’s internal clinical data and assessments (which we already support in our internal models) into the required Person-Centered Outcomes (PCO) HL7 FHIR Implementation Guide profiles for seamless submission to CMS.
- Time-window orchestration: Leveraging our time-windowed polling capabilities, we can help orchestrate customer patient-level reporting schedules. We can run scheduled jobs to identify which patients are in their baseline or quarterly reporting windows and transmit only the necessary, updated clinical values to CMS.
The best part is that the infrastructure base is already available. We just need to customize the “last mile” to meet specific organizational requirements.
In closing, applications for the model’s first performance period must be submitted via the Participant Portal by April 1, 2026. If your organization is preparing to join the ACCESS Model, the time to build your technical infrastructure is now.
Contact us today to discuss how we can serve as your interoperability partner to CMS, removing the technical friction of FHIR APIs, asynchronous polling, and clinical data mapping.