Overview
The Patient Access API is a CMS-mandated FHIR R4 API through which health plans must make members' data available to third-party patient-facing applications. It was established by the CMS Interoperability and Patient Access Final Rule (CMS-9115-F) with compliance dates beginning July 2021 and has been progressively expanded by subsequent rules including CMS-0057-F (2024 Prior Authorization Final Rule).
Covered plans include Medicare Advantage, Medicaid and CHIP managed care, and Qualified Health Plans on the federally-facilitated exchange. Commercial self-insured plans are not directly covered but many voluntarily offer comparable functionality.
The API exposes several data categories. Claims data includes adjudicated claims and encounter records, typically dating back five years. Clinical data includes the USCDI data set — allergies, medications, lab results, vital signs, procedures, diagnoses — sourced from the plan's clinical-data assets or from linked provider data. Provider directory data describes the plan's contracted provider network. Formulary data describes prescription-drug coverage rules and preferred drug lists. Coverage data describes the member's plan terms.
Authorization follows SMART on FHIR patterns. Members authenticate with their health plan account, the app requests scopes, and the member grants or denies. No plan-approval step is required for the app itself — members control the decision to grant access, and plans cannot discriminate against apps that meet technical-integration standards. This patient-authorization-only model was a significant regulatory design decision intended to prevent plans from gating app choice.
Use cases include personal health-record apps, care-management apps that aggregate data from multiple plans, AI-driven symptom and condition apps, research-participation apps, and patient-advocate apps that help members with benefit questions. The app ecosystem has grown since the rule's effective date though adoption remains modest relative to the underlying data volume.
Compliance requirements have tightened over time. Plans must meet technical performance standards, support specific US Core and CARIN Blue Button profiles, maintain provider-directory data freshness, and publish documentation meeting CMS requirements. CMS-0057-F added reporting requirements and operational metrics that plans must publish publicly.
For RCM and health-plan operations, the Patient Access API is an ongoing capital-investment obligation. Plans must maintain the infrastructure continuously — outages or data freshness issues can trigger CMS enforcement. App ecosystem partnerships, vendor-supplied infrastructure, and internal FHIR platform investment are all common approaches.
Patient Access API is one of the compliance areas where documentation discipline determines audit outcomes more than policy sophistication. Practices that invest in clean Patient Access API records, consistent fhir api workflows, and auditable fhir r4 evidence come out of OIG, RAC, and MAC audits with materially smaller recoupment exposure than practices with equivalent policies but weaker paper trails.
From a board-reporting standpoint, Patient Access API belongs in the compliance committee's quarterly dashboard. The reporting line should include volume, exception rate, and any open remediation action; reviewers tie Patient Access API metrics to the broader compliance program KPIs so an emerging Patient Access API risk surfaces before it becomes a formal finding. Pairing the Patient Access API trend with fhir api gives the committee a single view of whether the control environment is strengthening or drifting.
Industry benchmark
CMS-9115-F compliance date: July 2021 for covered plans. Monthly API call volume across covered plans: hundreds of millions. Third-party app ecosystem: growing but modest, with several hundred registered apps.
Worked example
A Medicare Advantage member uses a symptom-check app that requests Patient Access API scopes. The member authenticates with their plan account, grants read access to claims and clinical data, and the app pulls their medication history, recent labs, and claims. The app uses this context to provide personalized triage recommendations.
Frequently asked questions — Patient Access API
Which plans must support the Patient Access API?
Medicare Advantage, Medicaid and CHIP managed care, and Qualified Health Plans on the federally-facilitated ACA marketplace. Commercial self-insured plans are not directly covered but many participate voluntarily.
Do plans approve individual apps?
No. Members authorize apps directly through SMART flows; plans cannot gate app access if the app meets technical standards. This design choice was intended to prevent plans from restricting member app choice.
What data is in scope?
Claims and encounter data (typically 5 years), USCDI clinical data, provider directory, formulary data, and coverage information. The scope has expanded with subsequent rules and continues to grow.
Disclaimer
This glossary entry is operational reference for revenue-cycle and medical-billing professionals. It is not legal, clinical, or contractual advice. Industry benchmarks cite named public sources where available; always verify against the current guidance from the authority body before relying on a number in a contract, policy, or compliance filing.