CMS Interoperability and Patient Access Final Rule

What the authority record establishes

CMS-9115-F requires specified payers to maintain FHIR-based Patient Access APIs for claims, encounter, cost, and maintained clinical data, and establishes other interoperability and provider-notification provisions.

Binding on affected entities according to program, provision, and date

The exact official title, issuing body, jurisdiction, version or application record, and linked source define the scope of this page. Readers should not transfer the authority's status to a commercial product or infer transaction-, patient-, system-, site-, or organization-specific applicability from this summary.

Why it matters to this market

The rule created a durable payer API market while leaving data scope, patient authorization, app privacy, testing, operations, and implementation-guide choices as material implementation decisions.

Affected operating stages

• Data Inventory
• API Implementation
• Patient Authorization
• Third-Party App Access
• Testing
• Monitoring
• Metrics

Capabilities to examine

FHIR Server And Repository

Ask how the system or service identifies the controlling source and version, applies customer-specific interpretation, handles exceptions, preserves human judgment, and retains evidence for FHIR server and repository.

FHIR API Gateway And Orchestration

Ask how the system or service identifies the controlling source and version, applies customer-specific interpretation, handles exceptions, preserves human judgment, and retains evidence for FHIR API gateway and orchestration.

FHIR Profile And Implementation-Guide Support

Ask how the system or service identifies the controlling source and version, applies customer-specific interpretation, handles exceptions, preserves human judgment, and retains evidence for FHIR profile and implementation-guide support.

SMART On FHIR Authorization

Ask how the system or service identifies the controlling source and version, applies customer-specific interpretation, handles exceptions, preserves human judgment, and retains evidence for SMART on FHIR authorization.

Provider Directory And Endpoint Discovery

Ask how the system or service identifies the controlling source and version, applies customer-specific interpretation, handles exceptions, preserves human judgment, and retains evidence for provider directory and endpoint discovery.

Consent, Authorization, And Data Segmentation

Ask how the system or service identifies the controlling source and version, applies customer-specific interpretation, handles exceptions, preserves human judgment, and retains evidence for consent, authorization, and data segmentation.

Payer And Claims Data Exchange

Ask how the system or service identifies the controlling source and version, applies customer-specific interpretation, handles exceptions, preserves human judgment, and retains evidence for payer and claims data exchange.

Operational Monitoring And Exception Management

Ask how the system or service identifies the controlling source and version, applies customer-specific interpretation, handles exceptions, preserves human judgment, and retains evidence for operational monitoring and exception management.

Affected buyer audiences

• impacted health plans
• state Medicaid and CHIP programs
• payer API vendors
• healthcare providers
• consumer application developers

Implementation questions

• Which entities, products, populations, transactions, systems, sites, or jurisdictions are actually within scope?
• What is binding, what is guidance, and what is a technical or consensus standard?
• Which publication, adoption, effective, application, transition, and enforcement dates differ?
• Who owns legal, clinical, quality, regulatory, policy, or operational interpretation?
• How will a source revision affect open work and historical decisions?

Interpretation boundary

Applicability, data maintained, API behavior, and compliance depend on the rule text and program-specific facts.