Regulatory Basis: CMS 9115-F (Patient Access Rule) and CMS 0057-F (Interoperability & Prior Authorization Rule – updated requirements)
Why It Matters
Patients increasingly receive care across fragmented systems. Their claims history, coverage details, medication fills, and clinical summaries are often locked in payer databases. The Patient Access API gives members secure, real-time access to their own data through third-party apps of their choosing. This supports transparency, care coordination, self-management, and a modern consumer experience— all without requiring workflow changes inside the EMR.
Patient Experience
- Easy access to claims, coverage, medications, and encounter history through mobile apps.
- Transparent view of benefits, cost share, prior auth status, and care gaps.
- Ability to carry history across payers as coverage changes.
- Consistent, app-based access tailored to literacy and language needs.
Developer & App Experience
- SMART on FHIR and OAuth 2.0 authentication with delegated patient consent.
- Access to PDex profiles for ExplanationOfBenefit, Coverage, Clinical resources, and Formulary.
- Consistent token flows, refresh, scopes, and well-defined API documentation.
- Ability to build consumer apps that integrate payer data into wellness, cost, and navigation tools.
Technical & Standards Alignment
- FHIR R4: Patient, Coverage, ExplanationOfBenefit (PDex), Encounter, Claim, MedicationDispense, Observation, FormularyDrug, InsurancePlan.
- SMART on FHIR Launch for third-party member-selected applications.
- OAuth 2.0 / OpenID Connect for app authorization and consent.
- Bulk data optional for large developer use cases.
- Follows the Da Vinci PDex Implementation Guide for payer-side profiles.
Governance & Compliance
- Meets CMS 9115-F and 0057-F requirements for availability, uptime, reporting, and app registration.
- Explicit patient-driven consent with clear permission scopes.
- Audit logs for disclosures, app access, denied/approved tokens, and revocations.
- Minimum Necessary enforcement and separation between payer-sponsored vs third-party apps.
- Sandbox and public documentation required for developer onboarding.
Value by Audience
Patients:
- Control over their own data.
- Reduced administrative effort when changing providers or health plans.
- Unified view of medications, claims, benefits, and clinical summaries.
Clinicians / Care Teams:
- Patients arrive with more complete histories and medication fill data.
- Better reconciliation and care planning with less guesswork.
IT & Architecture:
- Standards-based interoperability using FHIR profiles.
- Reduced custom portal integrations; APIs become the contract.
- Clear governance, metadata, and versioning.
Payers:
- Compliance with federal mandates for patient access.
- Lower call center burden with member self-service.
- Modern, API-driven foundation supporting future consumer applications.
Capabilities
- Real-time patient-authorized access to claims, coverage, and clinical data.
- Formulary & drug tier lookup.
- Provider Directory (Plan-Net) integration.
- Status endpoints and availability reporting (0057-F).
- Patient consent capture, token management, and session lifecycle controls.
- Provenance metadata, last-updated timestamps, and audit trails.
Da Vinci Alignment
For detailed implementation specifications, see the Da Vinci Payer Data Exchange (PDex) Implementation Guide, which defines data structures, profiles, and FHIR interactions for payer-side Patient Access APIs.
Optional Alternative Approaches
Depending on organizational maturity, alternative or supplemental patterns include standalone SMART apps, payer-hosted patient portals, or simplified per-patient query models—each providing member access without requiring complex ingestion pipelines.