CMS-0057-F Compliance Checklist for 2027

The January 2027 deadline for CMS-0057-F API requirements is now less than ten months away. If your organization is a Medicare Advantage plan, Medicaid managed care organization, CHIP managed care entity, Medicaid or CHIP fee-for-service program, or a Qualified Health Plan (QHP) issuer on the federally facilitated exchanges, you need to have four FHIR-based APIs operational by January 1, 2027.

This is not a soft target. CMS has been clear that enforcement will follow the same patterns established with the original Patient Access API rule (CMS-9115-F). Non-compliance means potential enforcement actions, public reporting of compliance status, and reputational damage that can affect enrollment and provider relationships.

This guide provides a comprehensive compliance checklist, a quarterly implementation timeline, and practical guidance for the technical teams building these APIs.

What Is CMS-0057-F?

CMS-0057-F, formally titled the “CMS Interoperability and Prior Authorization Final Rule,” was published in the Federal Register on January 17, 2024. It is the most significant expansion of healthcare interoperability requirements since the original Patient Access API rule (CMS-9115-F) in 2020.

The rule has two major compliance milestones:

• January 1, 2026 (already in effect): Operational provisions for prior authorization, including 72-hour turnaround for urgent requests, 7-day turnaround for standard requests, and requirements to provide specific reasons for denials.
• January 1, 2027: API requirements, including four FHIR-based APIs that impacted payers must make available to patients, providers, and other payers.

This guide focuses on the January 2027 API requirements, since the operational provisions should already be in place.

Who Must Comply

CMS-0057-F applies to a specific set of payer organizations. Understanding whether and how the rule applies to your organization is the first step in compliance planning.

Impacted Payer Types

Payer Type	Description	Regulatory Authority
Medicare Advantage (MA) Organizations	Private insurers offering Medicare coverage under Part C	42 CFR Part 422
Medicaid Fee-for-Service (FFS) Programs	State Medicaid programs that pay providers directly	42 CFR Part 431
Medicaid Managed Care Plans	Managed care organizations (MCOs), prepaid inpatient health plans (PIHPs), prepaid ambulatory health plans (PAHPs)	42 CFR Part 438
CHIP Fee-for-Service Programs	State Children’s Health Insurance Programs with FFS delivery	42 CFR Part 457
CHIP Managed Care Entities	Managed care plans serving CHIP populations	42 CFR Part 457
QHP Issuers on FFEs	Qualified Health Plan issuers on the federally facilitated exchanges (marketplace plans)	45 CFR Part 156

Who Is Not Covered

The rule does not apply to:

• Commercial (employer-sponsored) health plans not on the exchanges.
• Medicare fee-for-service (traditional Medicare), though CMS has separate initiatives for that population.
• State-based exchange QHP issuers that do not use the federal platform (though many states are adopting similar requirements).
• Standalone dental plans or vision plans.

If your organization falls into any of the covered categories, even partially, the API requirements apply to the covered lines of business.

The Four Required APIs

CMS-0057-F mandates four distinct FHIR R4 APIs. Each serves a different audience and data exchange purpose. All four must be operational by January 1, 2027.

1. Patient Access API

The Patient Access API gives enrollees (patients) direct access to their health data through third-party applications of their choosing. This is an expansion of the original Patient Access API required under CMS-9115-F.

What’s new in CMS-0057-F (beyond CMS-9115-F requirements):

• Prior authorization information. The Patient Access API must now include data about pending and completed prior authorization decisions, including the status, the items or services requested, and the reason for any denial.
• USCDI data elements. The API must support the United States Core Data for Interoperability (USCDI) v1 data classes and elements, aligning with the data available through certified EHR technology.

Technical requirements:

• HL7 FHIR R4 (4.0.1)
• SMART on FHIR for patient-facing authorization
• Must support the HL7 CARIN Blue Button Implementation Guide (C4BB) for claims and encounter data
• Must support US Core profiles for clinical data
• Must include ExplanationOfBenefit resources for claims data
• Must include prior authorization status and details

Key FHIR resources:

• Patient
• ExplanationOfBenefit
• Coverage
• Condition
• Observation
• Procedure
• MedicationRequest
• ClaimResponse (for prior auth decisions)

2. Provider Access API

The Provider Access API enables payers to share patient clinical and claims data with in-network providers who have a treatment relationship with the patient. This is a new API not required under the predecessor rule.

Purpose: Providers treating a patient should have access to the payer’s longitudinal view of that patient’s health data, including claims, encounters, and clinical data gathered from other providers. This helps reduce duplicative testing, improve care coordination, and inform clinical decisions.

Technical requirements:

• HL7 FHIR R4 (4.0.1)
• SMART on FHIR Backend Services authorization (system-to-system, no patient interaction)
• Must support the Da Vinci PDex (Payer Data Exchange) Implementation Guide
• Must support the Da Vinci HRex (Health Record Exchange) Implementation Guide
• Must include USCDI v1 data elements
• Must support Bulk FHIR operations for population-level data access
• Must include attribution/roster-based access control (payers share data only for attributed patients)
• Opt-out mechanism for patients who do not want their data shared

Key FHIR resources:

• All Patient Access API resources, plus:
• Group (for patient attribution/rosters)
• Provenance (data source tracking)

Important nuance: The Provider Access API uses a different authorization model than the Patient Access API. Patient Access uses patient-facing SMART on FHIR (authorization code flow). Provider Access uses SMART Backend Services (client credentials flow), since the data exchange happens system-to-system without patient interaction at the time of the request.

3. Payer-to-Payer API

The Payer-to-Payer API facilitates the exchange of patient health data between payers when a patient changes health plans. When a patient enrolls in a new plan, the new plan can request the patient’s data from their previous plan(s).

Purpose: Patients frequently change health plans, especially in Medicaid and marketplace populations. Each time they switch, their new plan starts with limited health history. The Payer-to-Payer API ensures continuity of data across plan transitions, supporting better care coordination and reducing gaps in care.

Technical requirements:

• HL7 FHIR R4 (4.0.1)
• SMART on FHIR Backend Services authorization (payer-to-payer, system-to-system)
• Must support the Da Vinci PDex Implementation Guide
• Must support the Da Vinci HRex Implementation Guide
• Must include claims and encounter data, USCDI v1 clinical data, and prior authorization data
• Must include a five-year lookback period for data exchange
• Patient must provide consent (opt-in) for the data exchange to occur
• Requesting payer must verify current enrollment of the patient

Key FHIR resources:

• All Patient Access API resources, plus:
• Consent (patient authorization for data exchange)
• Task (to manage data exchange workflow between payers)
• Organization (identifying requesting/responding payers)

Implementation challenge: The Payer-to-Payer API requires establishing trust relationships between payer organizations. You need to verify that a requesting payer is legitimate, that the patient is actually enrolled with them, and that the patient has consented to the data exchange. The Da Vinci HRex Implementation Guide provides a framework for this, but the operational setup (directories, certificate management, trust agreements) is significant work beyond the API development itself.

4. Prior Authorization API (PARDD API)

The Prior Authorization API (also called the Prior Authorization Requirements, Documentation, and Decision API, or PARDD) is the most operationally complex of the four APIs. It enables providers to discover prior authorization requirements, submit prior authorization requests electronically, and receive decisions through a FHIR-based workflow.

Purpose: Prior authorization is one of the most burdensome administrative processes in healthcare. Providers spend hours per week on phone calls, fax submissions, and portal navigation to get authorization for services. The PARDD API automates this process, enabling EHRs and practice management systems to check requirements and submit requests programmatically.

Technical requirements:

• HL7 FHIR R4 (4.0.1)
• Must support the Da Vinci Prior Authorization Support (PAS) Implementation Guide, version 2.1.0
• Must support the Da Vinci Coverage Requirements Discovery (CRD) Implementation Guide
• Must support the Da Vinci Documentation Templates and Rules (DTR) Implementation Guide
• Must provide a machine-readable list of items and services requiring prior authorization
• Must accept electronic prior authorization requests via FHIR
• Must return decisions (approved, denied, pended) via FHIR
• Must include specific denial reasons (not just “denied” with no explanation)
• Must support real-time (synchronous) and asynchronous decision workflows

Key FHIR resources:

• CoverageEligibilityRequest / CoverageEligibilityResponse
• Claim (for PA request submission)
• ClaimResponse (for PA decision)
• Bundle (for PAS request/response bundles)
• QuestionnaireResponse (for DTR-collected documentation)
• Questionnaire (for DTR templates)

The Da Vinci trio: The Prior Authorization API relies on three interconnected Da Vinci Implementation Guides that work together:

1. CRD (Coverage Requirements Discovery): Triggered from the EHR during order entry. The payer’s CRD service responds with coverage requirements, including whether prior authorization is needed, what documentation is required, and links to relevant forms.
2. DTR (Documentation Templates and Rules): When documentation is required, DTR provides smart forms (FHIR Questionnaires) that pre-populate with data from the EHR and guide the clinician through required documentation.
3. PAS (Prior Authorization Support): Submits the prior authorization request electronically and receives the decision. PAS v2.1.0 uses FHIR Claim resources (not X12 278) as the submission format, though the payer’s internal adjudication may still use X12 internally.

Da Vinci Implementation Guides: The Technical Foundation

The CMS-0057-F APIs are built on a set of HL7 Da Vinci Implementation Guides. Understanding these IGs is essential for your development team.

Required Implementation Guides

Implementation Guide	Version	Used By
Da Vinci PDex (Payer Data Exchange)	STU 2.0.0	Patient Access, Provider Access, Payer-to-Payer
Da Vinci HRex (Health Record Exchange)	STU 1.1.0	Provider Access, Payer-to-Payer
Da Vinci PAS (Prior Authorization Support)	STU 2.1.0	Prior Authorization API
Da Vinci CRD (Coverage Requirements Discovery)	STU 2.0.0	Prior Authorization API
Da Vinci DTR (Documentation Templates and Rules)	STU 2.0.0	Prior Authorization API
CARIN Blue Button (C4BB)	STU 2.0.0	Patient Access (claims/encounter data)
US Core	STU 5.0.1 (or later)	All APIs (clinical data profiles)

IG Conformance Testing

HL7 provides reference implementations and test tooling for the Da Vinci IGs. The Da Vinci Project’s testing infrastructure includes:

• Touchstone: HL7’s conformance testing platform, which includes Da Vinci-specific test scripts.
• Inferno: ONC’s testing tool, which includes modules for US Core and other IGs.
• Da Vinci Reference Implementations: Open-source reference servers and clients that demonstrate correct IG behavior.

We strongly recommend integrating conformance testing into your CI/CD pipeline, not saving it for the end. Run Inferno and Touchstone tests against your APIs regularly during development.

Quarterly Implementation Timeline

With less than ten months until the January 2027 deadline, every quarter counts. Here is a realistic implementation timeline.

Q1 2026 (January - March): Gap Analysis and Planning

Objective: Understand your current state and build your implementation plan.

• Inventory existing APIs. If you already have a Patient Access API from CMS-9115-F, assess its conformance with the updated CMS-0057-F requirements (prior auth data, USCDI alignment).
• Conduct a gap analysis. For each of the four required APIs, document what you have, what you need to build, and what you need to change.
• Select your FHIR server platform. If you do not already have a FHIR R4 server, evaluate options: HAPI FHIR (open source), Smile CDR (commercial), Microsoft Azure Health Data Services, Google Cloud Healthcare API, or AWS HealthLake.
• Select or confirm your Da Vinci IG vendor/approach. Will you build in-house, use a vendor solution (Availity, Change Healthcare, Rhyme), or take a hybrid approach?
• Assemble your project team. You will need FHIR developers, an integration architect, a compliance/regulatory lead, a project manager, and testing resources.
• Establish your testing environment. Set up a FHIR sandbox, obtain test data (synthetic, not production), and configure connectivity to Da Vinci reference implementations.
• Create your project plan. Detailed milestones, resource allocation, risk register, and executive reporting cadence.

Q2 2026 (April - June): API Development

Objective: Build the core API functionality and begin integration testing.

• Patient Access API enhancements. Add prior authorization data to your existing Patient Access API. Validate USCDI v1 data element coverage. Update ExplanationOfBenefit resources.
• Provider Access API development. Implement SMART Backend Services authorization. Build the attribution/roster-based access model. Implement Bulk FHIR export operations. Build the patient opt-out mechanism.
• Payer-to-Payer API development. Implement the trust framework for payer identification and verification. Build the consent management workflow. Implement the five-year lookback data retrieval. Build the Task-based data exchange workflow.
• Prior Authorization API development. Implement CRD hooks (CDS Hooks integration with EHR vendors). Build DTR questionnaire hosting and rendering. Implement PAS request/response workflow. Build the prior authorization requirements list.
• Begin Da Vinci IG conformance testing. Run Touchstone tests against each API. Run Inferno US Core tests. Document and address failures.
• Set up monitoring and logging. Every API call must be logged for compliance auditing. Implement response time monitoring (CMS expects reasonable performance).

Q3 2026 (July - September): Integration Testing

Objective: Test with real trading partners and validate end-to-end workflows.

• Connectathon participation. Participate in HL7 Da Vinci Connectathons to test interoperability with other payer and provider implementations.
• Provider Access API testing with providers. Coordinate with your largest in-network provider organizations to test the Provider Access API with their EHR systems.
• Payer-to-Payer API testing with payers. Coordinate with other payers to test the Payer-to-Payer data exchange workflow. This requires mutual trust agreements and technical connectivity.
• Prior Authorization API testing with EHR vendors. Test CRD, DTR, and PAS workflows with major EHR vendors (Epic, Oracle Health, athenahealth). Each vendor has their own Da Vinci certification timeline.
• Performance testing. Load test your APIs to ensure they can handle expected volumes. Patient Access APIs at large payers may receive thousands of requests per day.
• Security assessment. Conduct a security review of all four APIs. Verify OAuth 2.0 implementation, TLS configuration, input validation, and data access controls. Address any OWASP Top 10 vulnerabilities.
• Address conformance test failures. Re-run Touchstone and Inferno tests. All critical test failures must be resolved.

Q4 2026 (October - December): UAT, Hardening, and Go-Live

Objective: Final validation, security hardening, and production deployment.

• User acceptance testing (UAT). End-to-end testing of all four APIs with stakeholders from compliance, clinical operations, and provider relations.
• Third-party security audit. Engage an independent security firm to audit your API infrastructure, with specific attention to PHI access controls and HIPAA compliance.
• Documentation. Complete API documentation for external consumers (providers, payers, third-party app developers). Publish developer portals with sandbox access.
• Compliance review. Final regulatory review with your compliance team. Document how each CMS-0057-F requirement is met. Prepare for potential CMS audits.
• Production deployment. Deploy all four APIs to your production environment. Implement phased rollout if possible (start with a subset of providers or products).
• Monitoring and alerting. Configure production monitoring dashboards, alerting thresholds, and on-call rotations for API issues.
• Communication. Notify providers, downstream payers, and third-party app developers that your APIs are live. Provide onboarding documentation and support contacts.
• Post-launch support plan. Staff a support team for the first 30-60 days after go-live to handle issues, onboarding questions, and unexpected edge cases.

Common Pitfalls

Having guided multiple organizations through CMS interoperability rule implementations, we have seen the same mistakes repeatedly. Avoid these.

1. Drug Prior Authorization Confusion

CMS-0057-F applies to medical (non-drug) prior authorizations. Prescription drug prior authorization is governed by a separate CMS rule for Part D plans. However, the lines are blurry for drugs administered in clinical settings (e.g., infusion drugs covered under medical benefit). Clarify which prior authorization categories fall under your CMS-0057-F obligation and which are Part D.

2. Underestimating the Payer-to-Payer API Complexity

The Payer-to-Payer API looks simple on paper: receive a request, send data. In practice, it requires establishing trust relationships with potentially hundreds of other payers, managing patient consent, verifying enrollment, handling data format variations, and managing the five-year lookback retrieval from your claims warehouse. Start this work early.

3. USCDI Data Element Gaps

The USCDI v1 data classes include clinical notes, lab results, vital signs, procedures, medications, allergies, conditions, immunizations, and more. Many payers do not have all of these data elements readily available in a FHIR-ready format. You may need to map and transform data from your existing claims data warehouse, clinical data repository, or pharmacy benefit systems. Conduct a thorough data element inventory early in Q1.

4. Consent Management for Payer-to-Payer

The Payer-to-Payer API requires patient consent (opt-in). Building a compliant consent management system that captures, stores, and enforces patient consent preferences across your systems is a non-trivial project in itself. It needs to integrate with member portals, call center systems, and the API authorization layer.

5. EHR Vendor Readiness for CRD/DTR/PAS

Your Prior Authorization API does not work in isolation. It requires EHR vendors to implement the CDS Hooks (for CRD), SMART on FHIR app launch (for DTR), and PAS submission workflows on their end. Major EHR vendors are at various stages of Da Vinci implementation readiness. Epic, Oracle Health (Cerner), and athenahealth all have Da Vinci roadmaps, but timelines vary. Do not assume your provider partners’ EHR systems will be ready just because yours is.

6. Testing with Synthetic Data Only

Synthetic data is essential for early development, but it does not capture the edge cases in real-world claims and clinical data. Plan for testing with de-identified production data (or production-like data) in your later testing phases. Real claims data has missing fields, unexpected values, and format variations that synthetic generators do not replicate.

7. Ignoring the Directory Problem

To exchange data with other payers (Payer-to-Payer API) and providers (Provider Access API), you need to know who they are and how to reach them technically. There is no single national directory of all payer FHIR endpoints. The Da Vinci HRex IG provides a framework, and organizations like CMS and CAQH are working on directories, but expect to do manual work establishing connectivity with your trading partners.

Relationship to CMS-9115-F

If you are already compliant with CMS-9115-F (the original Patient Access and Provider Directory API rule from 2020), you have a foundation to build on. Here is how the two rules relate:

Requirement	CMS-9115-F (2020)	CMS-0057-F (2024)
Patient Access API	Required (claims, encounter data)	Required + enhanced (add prior auth data, USCDI alignment)
Provider Directory API	Required	Requirement continues
Provider Access API	Not required	New requirement
Payer-to-Payer API	Not required	New requirement
Prior Authorization API	Not required	New requirement
Prior Auth operational requirements	Not required	Required (72hr/7day turnaround, specific denial reasons)

If your CMS-9115-F Patient Access API is working, you need to enhance it (add prior authorization data, verify USCDI coverage) rather than rebuild it. The three new APIs (Provider Access, Payer-to-Payer, Prior Authorization) are net-new development.

How Saga IT Can Help

CMS-0057-F compliance requires deep expertise across FHIR API development, Da Vinci Implementation Guides, healthcare data integration, and regulatory compliance. Our team has been working with FHIR since the DSTU2 days and has direct experience with Da Vinci IG implementations.

Our CMS-0057-F Services

• Compliance gap analysis. We assess your current state against all CMS-0057-F requirements and deliver a detailed remediation roadmap with effort estimates.
• FHIR API development. We build production-grade FHIR R4 APIs on the platform of your choice (HAPI FHIR, Smile CDR, Azure Health Data Services, AWS HealthLake, or Google Cloud Healthcare API).
• Da Vinci IG implementation. We implement PDex, HRex, PAS, CRD, and DTR conformant interfaces, including CDS Hooks integration and SMART on FHIR authorization.
• Integration testing. We help you test with trading partners, participate in Da Vinci Connectathons, and validate conformance with Touchstone and Inferno.
• Data mapping and transformation. We map your existing claims warehouse and clinical data repository to FHIR resources, ensuring USCDI data element coverage.
• Security and compliance review. We assess your API security posture and help you prepare for CMS compliance audits.

Related Services

• CMS Interoperability Consulting — Our full CMS interoperability compliance practice.
• FHIR API Integration — FHIR R4 API development, implementation guide conformance, and SMART on FHIR authorization.
• Healthcare Interoperability — Broad interoperability consulting across HL7 v2, FHIR, X12, and CDA.

Next Steps

The January 2027 deadline is real, and the scope is significant. If you have not started yet, the time to begin is now. Here is what we recommend:

1. Determine your obligation. Confirm which of your lines of business fall under CMS-0057-F.
2. Assess your current state. What do you have from CMS-9115-F? What gaps remain?
3. Prioritize the Prior Authorization API. It is the most complex of the four and has the longest development timeline due to EHR vendor dependencies.
4. Engage trading partners early. The Payer-to-Payer and Provider Access APIs require coordination with external organizations. Start those conversations in Q1.
5. Get help if you need it. If your team does not have FHIR and Da Vinci IG expertise in-house, bring in specialists early rather than late.

Ready to start your CMS-0057-F compliance journey? Contact us for a compliance assessment and we will help you build a realistic plan to meet the January 2027 deadline.