January 1, 2027. That's the deadline for CMS-0057-F compliance: FHIR-based APIs for patient access, provider access, payer-to-payer data exchange, and prior authorization must be live and auditable.

That sounds like it's a long way off. It isn't.

Most healthcare organizations are behind. Surveys show slow implementation progress across the industry, and nearly half of healthcare organizations lack centralized compliance oversight. The technical requirements are specific, the audit standards are strict, and the gap between "we have APIs" and "our APIs are compliant" is wider than most teams realize.

This checklist breaks down what CMS-0057-F and related rules actually require from your API platform, so your team can identify gaps now instead of scrambling in Q4.

What CMS-0057-F Requires

The CMS Interoperability and Prior Authorization Final Rule (CMS-0057-F) applies to Medicare Advantage organizations, Medicaid managed care plans, CHIP managed care entities, and Qualified Health Plan issuers on the federal exchanges. It mandates four FHIR R4 APIs:

Patient Access API. Patients access their own claims, encounter, and prior authorization data through third-party applications.
Provider Access API. In-network providers retrieve patient data for treatment and care coordination.
Payer-to-Payer API. Payers exchange patient data when members switch plans, ensuring continuity of care.
Prior Authorization API. Prior authorization requests and decisions are processed through a standardized FHIR interface, replacing fax-and-phone workflows.

Public reporting on prior authorization metrics began January 1, 2026. All four APIs must be fully operational by January 1, 2027.

The Rules That Stack on Top

CMS-0057-F doesn't exist in isolation. Two other regulatory frameworks add requirements that affect how you build, secure, and manage these APIs.

ONC HTI-1 Rule. Certified health IT must support USCDI v3 using FHIR US Core 6.1.0. This rule also requires certified API developers to publish FHIR service base URLs publicly. If your APIs serve certified health IT, HTI-1 compliance is a prerequisite, not an add-on.

SMART on FHIR authorization. Both CMS-0057-F and HTI-1 expect OAuth 2.0 authorization following the SMART on FHIR framework. This means scope-based access control, where each third-party application requests specific FHIR resource permissions. Patient-facing apps request patient-level scopes. Provider-facing apps request system-level scopes. Every access grant must be auditable.

The practical implication: your API platform doesn't just need to serve FHIR data. It needs to manage which applications can access which data, enforce scope boundaries, and log every access decision.

The Compliance Readiness Checklist

Use this checklist to assess where your API platform stands today. Each item maps to a specific regulatory requirement.

FHIR API implementation

Patient Access API serves claims, encounters, clinical data, and prior authorization data via FHIR R4
Provider Access API is available to in-network providers with appropriate access controls
Payer-to-Payer API supports member data exchange on plan transitions
Prior Authorization API accepts and returns FHIR-based prior auth requests
All APIs conform to US Core 6.1.0 profiles and USCDI v3 data classes
FHIR service base URLs are published and discoverable

Authorization and scope management

OAuth 2.0 authorization server supports SMART on FHIR scopes
Patient-level scopes are enforced for patient-facing applications
System-level scopes are enforced for provider and payer applications
Scope grants are granular: applications only access the FHIR resources they request, not everything
Application registration captures scope requirements before access is granted
Scope changes trigger re-authorization or re-approval

Application registration and partner management

Third-party applications register through a defined process (manual or Dynamic Client Registration)
Registration captures application purpose, requested scopes, and developer organization
Terms of service and data use agreements are accepted and recorded before access is granted
Approval workflows exist for production access (sandbox access can be immediate)
Application credentials can be issued, rotated, and revoked without manual intervention from your engineering team

Audit logging and access tracking

Every API access event is logged with timestamp, user/application ID, source IP, request method, and data categories accessed
Audit logs are immutable: entries cannot be modified or deleted
Logs distinguish between patient-authorized access, provider access, and payer-to-payer exchange
Access to sensitive data categories (demographics, pharmacy, lab results, clinical notes) is tracked at the category level
Logs can be queried and reported on for compliance audits
Retention policies meet CMS and state-level requirements

Operational readiness

API uptime and performance meet SLA commitments for all four mandated APIs
Error handling returns meaningful FHIR OperationOutcome responses
Rate limiting protects APIs without blocking legitimate clinical workflows
Sandbox environment mirrors production for third-party application testing
Documentation is complete, accurate, and accessible to registered developers
A process exists to communicate API changes, deprecations, and downtime to connected applications

Where Most Teams Have Gaps

The FHIR APIs themselves are usually the furthest along. Most teams that have started work have focused on the data layer: getting FHIR resources served correctly. That's necessary, but it's the easier half of the problem.

The gaps that surface during audits are almost always in three areas:

Scope management. Teams have OAuth working, but scopes are coarse-grained or not enforced at the FHIR resource level. An application that requests access to Observation resources shouldn't get access to Patient demographics. If your authorization server treats scopes as all-or-nothing, you have a compliance gap.

Audit logging. Logs exist, but they don't capture the granularity regulators expect. "Application X made a GET request" is not sufficient. "Application X accessed pharmacy data for Patient Y at 14:32 UTC from IP 10.0.0.1" is what auditors look for. If your logs can't answer "who accessed what data, when, and why," they won't pass review.

Application lifecycle management. There's no structured process for registering, approving, monitoring, and revoking third-party application access. Applications get registered manually, credentials are shared over email, and nobody has a clear picture of which applications are active, which are dormant, and which should have been decommissioned months ago. This is the same ad-hoc integration problem that hits every API program, but in healthcare the regulatory stakes make it a compliance risk, not just an operational one.

What to Do Next

Run through the checklist above with your team. Mark each item as done, in progress, or not started. The items you haven't started are your priority list between now and January 2027.

If the biggest gaps are in scope management or application registration, those are the areas where manual processes break down fastest under compliance pressure. Managing FHIR scopes across dozens of third-party applications by hand is a compliance problem waiting to surface in an audit. Automating the application lifecycle, from registration through scope approval to production access, is how you close that gap without scaling your team.

For teams building or re-evaluating their API partner management infrastructure, Apiable handles application registration, scope-based access control, approval workflows, and audit logging out of the box, with pre-built integrations into existing API gateways. Book a demo to see how it maps to your compliance requirements.

January 2027 Is Closer Than You Think: Healthcare API Compliance Readiness Checklist