Technical Deep Dive: API Infrastructure for ACCESS Builders

Written with the help of my trusty CTO Hadi Javeed: An interactive technical guide is also available at TechyPolicy.com and will be updated as CMS releases final specifications.

The Four APIs You’ll Need to Build

This is Part 12 of a 12-part Techy Surgeon operator series on the CMS ACCESS Model. To navigate this series start to finish, check the archives if you’re a subscriber or check out this page on Techy Policy.

Building for ACCESS? RevelAi Health helps teams stand up the AI-powered care coordination + reporting infrastructure required to operate in models like ACCESS so you can focus on the clinical protocols and care delivery. Staff your virtual care organization with AI agents that reach out on your team’s behalf to collect PROMs, improve outcome aligned payment capture, and update your referral partners.
→ Book a demo: Here | Contact us by email: Here

The ACCESS Model mandates a modern, API-driven data exchange framework built on HL7 FHIR R4.0.1. Per the RFA, participants must support FHIR-based interfaces for both CMS integration and care coordination. Here’s what we know:

API Purpose Status Eligibility API Verify Medicare coverage & model eligibility Anticipated — CMS to publish specs Alignment API Enroll beneficiary to your organization Anticipated — CMS to publish specs BCDA API Retrieve Medicare claims data (Part A/B/D) ✅ Confirmed — Live at bcda.cms.gov Reporting API Submit outcome measures to CMS Anticipated — CMS to publish specs

Note on “Anticipated” APIs: The RFA describes the functionality these APIs must provide, but CMS has not yet published endpoint specifications. The BCDA is the only API currently operational.

---

What this means in practice

ACCESS isn’t asking applicants to “support interoperability” in the abstract — it’s hard-wiring model operations into a small set of APIs that drive the full loop: verify eligibility → align the beneficiary → (optionally) pull claims context → report outcomes via a FHIR-based interface. CMS also signals a forthcoming Implementation Guide with operational specs, data submission standards, and technical workflows, meaning the shape of the work is already clear even if every endpoint isn’t public yet.

Why the “anticipated” APIs still matter today

Even before CMS publishes the final endpoints for Eligibility, Alignment, and Reporting, the RFA is explicit about the functions those interfaces must support — and that’s enough to start building the internal framework:

• Enrollment state + auditability (who’s eligible, who’s aligned, when that status changes)

• Baseline + recurring outcomes capture (PROMs and clinical measures over time)

• FHIR-native reporting designed for standardized data elements and validation

• Care-coordination data flow that can generate structured clinical updates for the broader care team

The teams that wait for perfect specs will ship late. The teams that treat “FHIR-first outcomes reporting” as a product surface will be ready when CMS flips the switch.

Build-now checklist (no CMS endpoints required)

If you’re building for ACCESS in 2026, there are a few moves you can make right now without waiting on CMS:

• Stand up an internal FHIR R4 layer that cleanly represents your outcomes data and maps to standardized data exchange expectations (including patient/population API norms).

  ACCESS RFA

• Design your OAP measure engine: baseline capture, scheduled follow-ups, provenance, timestamps, and “submission readiness” state per beneficiary. (Payment is downstream of measurement performance.)

  ACCESS RFA

• Plan your outbound care-update pipe: ACCESS requires proactive electronic updates to PCPs/referrers at defined moments (initiation, completion, escalation) and expects connectivity to a bidirectional HIE (or equivalent) within 12 months.

  ACCESS RFA

• Get BCDA-ready: it’s the one interface already confirmed as available for aligned beneficiaries’ claims data, and it’s the fastest way to start building the “care coordination + monitoring” muscle while the other APIs are still forthcoming.

  ACCESS RFA

Bottom line

In ACCESS, interoperability isn’t optional, it’s a critical part of the operating system. If you can’t move data cleanly, you can’t coordinate care effectively, and you can’t reliably report outcomes… which means you can’t reliably get paid.

Paid subscribers: links to BCDA resources, a 6-step build workflow, and real FHIR Observation examples (PHQ-9), plus the NotebookLM RFA companion and downloadable guides.

Screenshots of the technical resource guide here below. we have broken down the workflow and API expectations into six concrete steps. Right now, many of the APIs have yet to be developed by CMS or released to applicants.