What it does
The Patient Access API already exists at most obligated payers: it's the FHIR endpoint that lets a member connect a third-party app, via SMART App Launch, to pull their own claims, encounters, and clinical data, a CMS-9115-F requirement from 2020.
CMS-0057-F doesn't replace it. It extends it. Starting January 1, 2027, that same API also has to expose prior-authorization information: whether a request is pending, approved, or denied, and, when it's denied, the specific reason.
Practically, this means the prior-auth workflow, wherever it actually lives internally (a UM platform, a TPA, a homegrown queue), needs a FHIR-facing integration into the Patient Access API's data layer, not just a portal a member can log into.
Who calls it
Third-party applications a member has authorized: a personal health record app, a chronic-condition management app, or their new provider's patient portal, using OAuth 2.0 and SMART App Launch to request access on the member's behalf.
The member has to opt in; nothing is pushed to an app without their authorization, and they can revoke that access at any time.
Technical standards
| Standard | Version | Notes |
|---|---|---|
| HL7 FHIR | 4.0.1 | Base data format for every resource the API exposes. |
| US Core / USCDI | STU 6.1.0 · USCDI v3 | Defines the clinical data profiles: conditions, medications, labs, and more. |
| SMART App Launch | 2.0.0 | OAuth 2.0-based authorization flow for third-party apps. |
| Da Vinci PDex | STU 2 | Payer Data Exchange implementation guide. Adds claims/encounter data and, now, prior-auth resources. |
Already have a Patient Access API? You're not done.
The 2020 mandate covered clinical and claims data. CMS-0057-F requires wiring your prior-authorization system into that same endpoint: a new integration, not a config change, even on a platform you've already deployed.
Ready to see where you stand?
Every requirement on this page is one line item in our free CMS-0057-F readiness survey.