Blogs
The CMS Interoperability and Patient Access Final Rule (CMS-9115-F) is a landmark regulation aimed at improving interoperability and patient data access in the U.S. healthcare system. For payers such as Medicare Advantage plans, Medicaid, CHIP, and Qualified Health Plan (QHP) issuers understanding and complying with 9115-F is essential to remain operationally compliant and to support new paradigms of patient-centered care.
Historically, health data has been siloed among providers, payers, and systems, making it difficult for patients and providers to access comprehensive health information.
The 21st Century Cures Act (2016) and related policy initiatives pushed for greater electronic access, transparency, and prevention of “information blocking.”
CMS used its regulatory authority to require payers to open up access to claims, clinical, provider directory, and payer-to-payer data exchange via APIs.
The goal: “liberate patient data” so patients, providers, and third-party apps can integrate and use health information more flexibly and rapidly.
The rule applies to CMS-regulated payers:
• Medicare Advantage (MA) organizations
• Medicaid Fee-for-Service (FFS) and managed care
• CHIP programs
• Qualified Health Plan (QHP) issuers on Federally-facilitated Exchanges (FFEs)
Exclusions: Some dental-only plans or certain QHP issuers (e.g., FF-SHOP) may be exempt depending on plan types and coverage.
The CMS-9115-F rule introduces several obligations for payers. Below are the main APIs and data exchange requirements:
API / Functionality | What Must Be Provided | Applicable Entities / Notes | Effective Dates / Comments |
Patient Access API | Allow patients to access claims & encounter data, cost, and a subset of clinical data (that payer maintains) via third-party apps | Applies to MA, Medicaid, CHIP, QHP issuers (excluding some dental-only plans) Centers for Medicare & Medicaid Services+4Centers for Medicare & Medicaid Services+4Centers for Medicare & Medicaid Services+4 | Patient Access API must be implemented starting Jan 1, 2021 (for QHP issuers, for plan years beginning Jan 1, 2021) Centers for Medicare & Medicaid Services+2HHS.gov+2 |
Provider Directory API | Make provider directory data publicly available via an API | Applies to payers (MA, Medicaid, CHIP). QHP issuers already must publish directory in machine-readable format. Centers for Medicare & Medicaid Services+2HHS.gov+2 | Must implement by Jan 1, 2021 for many payers Centers for Medicare & Medicaid Services+2HHS.gov+2 |
Payer-to-Payer Data Exchange | At a patient’s request, exchange their clinical data (the US Core Data for Interoperability, USCDI v1) from prior payer to new payer | Helps patients port health history across insurers Centers for Medicare & Medicaid Services+4Centers for Medicare & Medicaid Services+4HHS.gov+4 | Process must be in place starting Jan 1, 2022 (for QHP, plan years beginning Jan 1, 2022) |
Dual-Eligibles) | Increase frequency of state ↔ federal data exchange (e.g. “MMA files”) | For beneficiaries eligible for both Medicare & Medicaid Centers for Medicare & Medicaid Services+3Centers for Medicare & Medicaid Services+3Centers for Medicare & Medicaid Services+3 | Requires daily exchange from April 1, 2022 Centers for Medicare & Medicaid Services+1 |
Information Blocking / Public Reporting | CMS can publicly report providers who may be “information blocking” and track compliance transparency | Affects clinicians, hospitals, etc. under interoperability programs Centers for Medicare & Medicaid Services+1 | From late 2020 onward for performance years 2019+ Centers for Medicare & Medicaid Services+1 |
Digital Contact Information | Payers/providers must publish/maintain digital endpoints (e.g. a FHIR API endpoint or Direct address) in the National Plan & Provider Enumeration System (NPPES) | Facilitates discovery of API endpoints for data exchange Centers for Medicare & Medicaid Services+2HHS.gov+2 | Public reporting of providers who do not list digital contact info started around 2020 Centers for Medicare & Medicaid Services+1 |
Admission/Discharge/Transfer (ADT) Notifications | Hospitals must electronically send event notifications (admit, discharge, transfer) to another facility or provider to support care coordination | Indirectly relevant to payers for care coordination and downstream data flows Centers for Medicare & Medicaid Services+1 | Rule applies 12 months post-publication for applicable hospitals HHS.gov+1 |
Together, these mandates require payers to open up and standardize data access, providing real-time access for patients, enabling smoother transitions between plans, and improving coordination across stakeholders.
To meet the mandates, payers must adopt specific data, security, and interoperability standards. The key ones include:
CMS requires FHIR Release 4.0.1 as the foundational standard for APIs.
Payers must expose certain FHIR resources (e.g., Claim, Encounter, Coverage, Patient, etc.) consistent with Implementation Guides (IGs).
CMS references several IGs for different API domains:
CARIN Consumer Directed Payer Data Exchange (Blue Button) IG
Da Vinci PDex (Payer Data Exchange) IG
US Core IG (baseline resources)
Da Vinci Drug Formulary IG, Plan Net IG, CRD (Coverage Requirements Discovery), DTR (Documentation Templates & Rules), PAS (Prior Authorization Support), PCDE (Payer Coverage Decision Exchange), Bulk Data (Flat FHIR)
These IGs define exact structures, required elements, constraints, and interactions to ensure interoperability and consistency.
USCDI version 1 is the required data set for clinical data exchange under CMS-9115-F (for payer-to-payer and patient access)
Payers must expose the data elements they maintain from USCDI v1.
To secure data access, the following protocols are required:
SMART on FHIR + OAuth 2.0: Used by apps to request access tokens and access FHIR resources.
OpenID Connect: Adds an identity layer on top of OAuth to authenticate users reliably.
These ensure that third-party apps can securely obtain patient authorization and access data via the payer’s APIs.
While the rule took effect in 2020, CMS acknowledged implementation challenges (especially amid COVID) and initially exercised enforcement discretion for Patient Access API and Provider Directory API for some payers from Jan 1, 2021 through July 1, 2021.
After July 1, 2021, CMS began enforcing those API requirements formally.
Jan 1, 2021: Start date for Patient Access and Provider Directory API for many payers.
Jan 1, 2022: Payer-to-Payer data exchange must be supported.
April 1, 2022: Daily state-federal data exchange required for dual-eligibles.
CMS continues to publish guidance, FAQs, best practices, and state letters to help payers comply.
Noncompliance may lead to CMS sanctions, denial of plan approval, or public reporting of non-conforming behavior.
Public reporting mechanisms and scrutiny (information blocking) heighten reputational risk.
Implementing CMS-9115-F is non-trivial. Below are common challenges payers need to prepare for:
Legacy Systems & Data Silos
Many payers have older systems not designed for API-based access, making mapping, extraction, and real-time access difficult.
Data Quality & Completeness
Payers may not maintain full clinical datasets (e.g. EHR-based lab values) or may have incomplete records; mapping to USCDI may expose gaps.
Identity Matching & Member Linking
Ensuring that a patient’s identity in the payer system corresponds with API requests is complex (e.g. across multiple systems).
Security & Privacy Risks
Exposing APIs, integrating third-party apps, and managing authorization tokens introduce potential vulnerabilities if not handled securely.
Consent Management & User Controls
Patients should be able to control what data third-party apps access. Ensuring appropriate consent protocols is essential.
Inter-Plan Data Exchange Logistics
For payer-to-payer exchange, handling diverse systems, formats, and protocols will require coordination, standards negotiation, and governance.
Scalability & Performance
APIs must support potentially high volumes of requests (e.g. thousands of patients using apps simultaneously) without performance degradation.
Governance, Monitoring, &and Audit Trails
Payers will need logging, audit, and monitoring to ensure compliance, detect abuse, and handle disputes.
Keeping Pace with Evolving Standards
As FHIR, USCDI, IGs, and related standards evolve, payers must adapt their implementations and maintain backward compatibility.
Costs &and Resource Commitment
Building, testing, securing, and maintaining APIs, —along with staff, infrastructure, and oversight, —requires significant investment.
To successfully align and stay compliant by 2025, payers should consider the following strategic roadmap:
Gap Assessment & Readiness Audit
Analyze current systems and data holdings against CMS requirements (claims, clinical, directory, etc.).
Identify missing data, technical gaps, identity matching issues, and legacy constraints.
Adopt a Modular, API-First Architecture
Use middleware or API gateways to abstract legacy systems and provide consistent FHIR-based interfaces.
Decouple internal systems from external API logic.
Leverage Implementation Guides & Reference IGs
Use HL7 FHIR IGs (CARIN, Da Vinci PDex, US Core, etc.) as blueprints, not invent custom solutions.
Engage in industry implementation communities (HL7, Da Vinci, CARIN) for updates and best practices.
Invest in Identity, Consent, & Security Frameworks
Use OAuth 2.0 + SMART on FHIR + OpenID Connect for secure authorization.
Build robust consent management, revocation, and user auditing.
Data Normalization & Mapping to USCDI
Map internal data to USCDI version 1 (or later versions), ensuring consistency across members.
Cleanse, enrich, and reconcile data gaps before exposing to patients or other payers.
Develop Robust API Infrastructure & Scalable Platform
Use API gateways, rate limiting, monitoring, logging, and SLAs.
Stress-test with scalability and latency benchmarks.
Partner with Third-Party Application Developers
Support app developers via sandboxes, test data, developer portals, and clear documentation.
Require attestation of privacy practices from third-party apps.
Governance & Audit Processes
Establish internal governance, compliance teams, audit trails, and incident response protocols.
Monitor API usage, detect anomalies, and perform regular security reviews.
Education & Change Management
Train personnel, clinical partners, provider networks on how data flows, APIs, and new processes.
Update contracts and SLAs to reflect new interoperability responsibilities.
Iterate, Expand & Prepare for Future Enhancements
Some payers may only maintain limited clinical data (e.g. lab claims, not full EHR), so they must clearly communicate what subset of USCDI they support.
Implementing payer-to-payer exchange is especially challenging due to varying system maturity across insurers.
Enforcement and oversight may intensify over time; early compliance and readiness mitigates regulatory risk.
Patient expectations are rising. Apps and digital health vendors will demand seamless experiences.
The healthcare ecosystem (providers, states, HIEs) may push for more integrated data flows. Payers that lead may gain competitive advantage.
The CMS-9115-F rule (Interoperability and Patient Access Final Rule) marks a turning point in U.S. health data access policy. For payers, it is not just a regulatory compliance exercise but an opportunity to modernize systems, improve member engagement, and integrate into a more open, connected healthcare environment.
By 2025, payers should already be well into full compliance, exposing Patient Access APIs, Provider Directory APIs, supporting payer-to-payer exchanges, and ensuring robust security, identity, and governance frameworks. The payers who anticipate challenges, adopt modular and standards-based architectures, and partner proactively with the app ecosystem will be best positioned to thrive in this new interoperable era.
Scale smarter. Scale faster. ScaleHealthTech.
Book a personalized session and see how we can accelerate your digital journey.
Schedule a Meeting