Three things CMS-0057-F adds to the Patient Access API (and what each one requires)

If your organization was subject to the original Interoperability and Patient Access Final Rule (CMS-9115) rule, you already have a Patient Access API. That’s a reasonable head start. It is not the same as being ready for January 2027.

CMS-0057-F builds on what you already have with three new requirements: prior authorization (PA) data must appear in the patient’s record, decisions must be updated within one business day, and payers must track and report API usage metrics.

None of these are trivial to add to a working implementation, and the parts that look simple on paper tend to get complicated quickly in practice.

This guide covers each of those requirements in detail, plus two areas that fall outside them but consistently catch teams out: authentication and testing.

What CMS-0057-F adds to the Patient Access API

The three new requirements:

• Prior authorization data in the patient record, specifically pending and active PA decisions for items and services (drugs under Medicare Part D are excluded)
• A one-business-day update requirement: when a PA decision is made, the patient’s record must reflect it within one business day
• Usage metrics reporting: payers must track how their Patient Access API is being used and report that data to CMS

The first two are data and pipeline problems. The third is a governance and instrumentation problem. They each need different work, and the temptation is to underestimate all three.

Adding prior authorization data: what it takes

The requirement is to surface PA data through the ExplanationOfBenefit (EOB) resource using the CARIN Blue Button IG. The data needs to reflect pending requests, active approvals, and denials for items and services.

The drugs exclusion sounds simple until you try to implement the filter logic. Part D drug claims go through a different adjudication path than medical benefit items, and the data structures in your source systems may not cleanly distinguish between them.

We see this come up repeatedly in implementations: the boundary between ‘drug under Part D’ and ‘drug under the medical benefit’ is not always obvious in the underlying data, and getting the filtering right requires careful mapping work upfront.

A few things to verify before assuming your existing EOB mapping covers this:

• Does your PA data source include the full status lifecycle (pending, approved, denied, modified)? Some source systems only retain final decisions.
• Can your system’s prior authorization identifiers map directly to the FHIR Claim and Explanation of Benefits (EOB) resources without losing any data in the process?
• Does the adjudication data include the relevant clinical codes (procedure, diagnosis, drug) at the level of specificity the IG requires?

USCDI v3 alignment also matters here. Patient Access under CMS-0057-F requires conformance with USCDI v3 data elements, which is a step up from USCDI v1 that most CMS-9115 implementations were built against. If your FHIR resources were mapped to older US Core profiles, you may have gaps to close before the PA data layer even becomes the focus.

The one-business-day update requirement

This is where most of the pipeline work lives. A one-business-day SLA on PA decision updates means your integration from the adjudication system to the FHIR server must be near-real-time, or at minimum run on a schedule that reliably meets the window.

In practice, this means:

• Batch jobs that run nightly are unlikely to consistently meet the requirement, particularly for decisions made later in the business day
• Event-driven updates from the adjudication system are preferable, but require your source system to emit events reliably when a PA status changes
• You need a monitoring layer that can detect when a PA decision has been made and confirm the FHIR record was updated within the window

The requirement also applies to modifications, not just initial decisions. If a PA approval is modified or a denial is appealed successfully, the patient’s record needs to reflect that within one business day as well. Make sure your event capture covers status transitions, not just initial decisions.

Usage metrics reporting

This one tends to get deferred until late in the implementation, which creates a problem: you need to have been capturing data in order to have something to report.

CMS requires payers to report Patient Access API usage data annually. The specific metrics include the number of unique patients accessing data, the number of third-party applications accessing the API, and data on app registration and usage patterns.

The details of what to capture and how to format it for submission are defined in the regulation, but the practical implication is that your API gateway or FHIR server needs to be instrumented to log this from the point your implementation goes live.

SMART on FHIR and authentication: the part that takes longer than expected

The Patient Access API requires patient-facing authentication, which means SMART on FHIR standalone launch. This is where implementations consistently run into more complexity than anticipated.

The specific requirements under CMS-0057-F include support for SMART App Launch 2.0, which introduces changes to the authorization flow compared to the SMART 1.0 implementation many CMS-9115 APIs were built on. The differences include revised scope syntax, updated token introspection behavior, and tighter requirements around refresh token handling.

A few areas that tend to create problems:

• Scope granularity: SMART 2.0 introduces more granular patient-scoped access, which requires your authorization server to correctly interpret and enforce finer-grained permissions. If your auth layer was built for SMART 1.0, this is a meaningful refactor, not just a configuration change.
• App registration: CMS requires payers to allow third-party apps to register and access the Patient Access API. The process for how apps are registered, verified, and granted access needs to be operationally defined and technically implemented.
• Token lifetimes and refresh logic: Patient-facing access patterns differ from provider-facing. Patients may not log in frequently, which means refresh token behavior needs to be handled carefully to balance usability and security.
• Identity matching: When a patient authenticates, you need to reliably match their identity to their record in your system. If your member identity layer is not clean, this creates patient safety risks beyond just the technical implementation.

Testing and validation: confirming you meet the requirements

The most common mistake at this stage is testing against a sandbox that does not reflect production data complexity. A Patient Access API that works cleanly with synthetic data will often surface problems the first time it runs against real member records with messy code mappings, duplicate identities, or incomplete PA histories.

A few things worth building into your testing plan:

• Test the drugs exclusion filter with edge cases, specifically drugs covered under the medical benefit rather than Part D, and confirm they appear correctly in the PA data
• Simulate late-in-day PA decisions to confirm the one-business-day SLA is reliably met across your full operational window
• Test SMART authorization with at least two or three real third-party apps, not just your own test client
• Validate USCDI v3 conformance against the published test scripts, not just against your own interpretation of the IG
• Confirm that your usage logging is capturing the right events before switching to a production environment

The Touchstone platform supports Da Vinci IG conformance testing and is worth running before go-live. The work you put in here also carries forward: the identity resolution, authorization infrastructure, and data governance processes you build for Patient Access are the same foundations you will need for Provider Access, Payer-to-Payer, and the PA API.

If you are working through what your current implementation covers and where the gaps are, the CMS-0057-F Readiness Checklist is a useful starting point.

If you are building on Firely Server and Firely Auth, both are built for exactly this type of implementation: SMART App Launch 2.0, usage logging, and CARIN conformance are all supported.

And if you want to talk through your specific situation, we’re happy to run through it with you.