CMS Interoperability Rule Compliance: What Your Data Architecture Must Support

Introduction

CMS-9115-F (Interoperability and Patient Access Final Rule) changed the architecture obligations for Medicare Advantage plans, Medicaid managed care, CHIP, and Qualified Health Plans. It is not a vague policy requirement — it specifies exact APIs, [FHIR](/terms/FHIR) implementation guides, data elements, and response time requirements. Plans that are not compliant face civil monetary penalties.

As of 2026, the rule's scope has expanded: prior authorization APIs (CMS-0057-F) are now in scope, and payer-to-payer data exchange requirements have active enforcement timelines. This guide maps each rule requirement to the specific data architecture components your team must build.

---

Rule Components and Architecture Requirements

1. Patient Access API (Required)

What it requires: A FHIR R4 API that allows patients to access their own health data — claims, encounters, clinical data, and formulary information — through a third-party app of their choosing.

FHIR implementation guide: HL7 CARIN Consumer Directed Payer Data Exchange (CARIN IG for Blue Button)

Required FHIR resources:

Architecture requirements:

• FHIR R4 server with SMART on FHIR authorization (patient-facing scopes)
• All EOB resources must include claim-to-clinical code mappings (ICD-10, CPT, NDC)
• API must respond within CMS performance benchmarks (typically < 2 seconds for patient-scoped requests)
• Must be available to third-party apps on a non-discriminatory basis (no blocking)

Data model impact: Your adjudicated claims must be mapped to FHIR ExplanationOfBenefit resources. This requires:

{
  "resourceType": "ExplanationOfBenefit",
  "id": "claim-12345",
  "status": "active",
  "type": {"coding": [{"system": "http://terminology.hl7.org/CodeSystem/claim-type", "code": "professional"}]},
  "patient": {"reference": "Patient/member-67890"},
  "billablePeriod": {"start": "2024-03-15", "end": "2024-03-15"},
  "insurer": {"reference": "Organization/payer-001"},
  "provider": {"reference": "Practitioner/npi-1234567890"},
  "outcome": "complete",
  "item": [{
    "sequence": 1,
    "productOrService": {"coding": [{"system": "http://www.ama-assn.org/go/cpt", "code": "99213"}]},
    "servicedDate": "2024-03-15",
    "adjudication": [{"category": {"coding": [{"code": "benefit"}]}, "amount": {"value": 150.00, "currency": "USD"}}]
  }],
  "total": [{"category": {"coding": [{"code": "benefit"}]}, "amount": {"value": 150.00, "currency": "USD"}}]
}

---

2. Provider Directory API (Required)

What it requires: A publicly accessible FHIR R4 API providing accurate provider directory information — updated within 90 business days of a change.

FHIR implementation guide: DaVinci PDEX Plan Net

Required FHIR resources: Practitioner, PractitionerRole, Organization, OrganizationAffiliation, Location, HealthcareService, InsurancePlan, Network, Endpoint

Architecture requirements:

• Provider directory data must be sourced from your provider master (MDM)
• 90-business-day update requirement means your MDM-to-FHIR pipeline must be near-real-time, not monthly
• NPI validation against NPPES is required — invalid NPIs must be flagged and not exposed in the directory

Data pipeline requirement:

Provider MDM → Change Data Feed → FHIR Transformer → FHIR Server (Plan Net)
                                                     → Directory accuracy audit log

---

3. Payer-to-Payer Data Exchange (Required)

What it requires: When a member transitions from one payer to another, the old payer must send the member's clinical and claims history to the new payer upon request.

FHIR implementation guide: DaVinci PDEX (Payer Data Exchange)

Data elements required:

• Claims history (5 years)
• Clinical data from prior coverage period
• Prior authorization history

Architecture requirements:

• Bulk FHIR export capability (to send population-scale data to receiving payer)
• Member consent and authorization tracking (member must have consented to the exchange)
• Receiving payer endpoint directory (so you know where to send the data)

This requires a consent data model:

CREATE TABLE governance.payer_exchange_consent (
  consent_id            VARCHAR(36)   NOT NULL,
  enterprise_member_id  VARCHAR(36)   NOT NULL,
  receiving_payer_id    VARCHAR(50)   NOT NULL,
  receiving_payer_fhir_endpoint VARCHAR(500),
  consent_granted       BOOLEAN       NOT NULL,
  consent_granted_at    TIMESTAMP,
  consent_expires_at    TIMESTAMP,
  data_scope            VARCHAR(100), -- CLAIMS, CLINICAL, PHARMACY, PA
  PRIMARY KEY (consent_id)
);

---

4. Prior Authorization API (CMS-0057-F)

What it requires: FHIR-based PA APIs that allow providers to submit PA requests and receive decisions electronically. Required for MA, Medicaid, CHIP, and QHPs effective January 2026.

FHIR implementation guide: HL7 FHIR Da Vinci PAS (Prior Authorization Support)

Required capabilities:

• Receive PA requests via $submit operation (FHIR Task or ClaimResponse-based)
• Return real-time decisions where possible
• Return decisions within 72 hours (standard) / 24 hours (urgent)
• Provide specific denial reasons using X12 denial reason codes

---

Architecture Checklist

Before claiming CMS interoperability compliance, verify:

• Patient Access API exposes all 5 years of adjudicated claims as FHIR EOB
• SMART on FHIR patient-facing authorization flow implemented and tested
• Provider Directory API updated within 90 days of any provider data change
• Provider NPI validation against NPPES running continuously
• Payer-to-payer bulk FHIR export capability exists and tested
• Member consent model built for payer-to-payer exchange
• PA API ($submit) endpoint deployed and connected to UM system
• PA turnaround time monitoring active (72/24 hour thresholds)
• All FHIR resources validated against required Implementation Guide profiles
• Audit logging active on all Patient Access API requests

---

Key Takeaways

• CMS interoperability rules are architectural mandates, not policy suggestions. Each API has specific FHIR implementation guides with required resources and response formats.
• The Patient Access API requires claims-to-FHIR EOB mapping. If your claims data model cannot produce compliant ExplanationOfBenefit resources, it requires remediation before the FHIR layer.
• The 90-day provider directory update requirement demands a near-real-time MDM-to-FHIR pipeline. Monthly provider updates are insufficient.
• Payer-to-payer exchange requires member consent infrastructure. Build the consent data model before building the exchange pipeline.
• Validate your FHIR resource structure against CMS implementation guides using the HL7 Parser before deploying to production endpoints.