CMS-0057-F Platform Overview.
What the rule requires and where Redix fits: available conversion, demonstrated workflows, and implementation work scoped per customer.
CMS-0057-F API requirements generally begin in 2027 for impacted payers; exact timing and applicability depend on payer category. Operational provisions began in 2026. This document provides an executive overview of CMS-0057-F implementation requirements.
Looking for the compliance suite? CMS-0057-F Compliance Suite - Want to try the workflow? PAS Demo
Key distinction. CMS requires impacted payers to host the required APIs. Providers are users of PAS and Provider Access API, not hosts. Regulatory responsibility stays with the payer. This is critical for implementation planning.
What CMS-0057-F Requires
Core API Suite
- Patient Access API - Members access PA history and coverage data
- Provider Access API - Providers query PA status and patient data
- Payer-to-Payer API - Consent-based data exchange when members switch plans
- Prior Authorization API - PA requests, status and decisions via FHIR. CMS recommends the HL7 Da Vinci CRD, DTR and PAS implementation guides for this API.
Operational Requirements
- Expedited PA decisions within CMS-defined timeframes (payer-type dependent)
- Standard PA decisions within CMS-defined timeframes (payer-type dependent)
- Public reporting / metrics required beginning in 2026
Scope note. Provider Directory API is required for certain payer types under CMS interoperability rules; it is not included in this suite at this time.
Primary integration path: X12 278 to FHIR. For organizations without existing X12 infrastructure, RMap to FHIR is supported as an alternative input path.
Where Redix Fits in the Core APIs
Redix provides X12 278 ↔ FHIR conversion behind your FHIR API, with demonstrations of the surrounding workflows. Each card separates what is available, what is demonstrated on sample data, and what is implementation work scoped per customer.
Da Vinci PAS
- Available: X12 278 ↔ Da Vinci PAS FHIR conversion, with Provenance in converted output
- Demonstrated: $submit and $inquire with simulated decisions. In the PAS standard, updates and cancellations are sent through $submit.
- Implementation work: production PAS service, security and payer-system integration
Patient Access API
- Demonstrated: member access to PA history, claims and EOB on sample data
- Implementation work: production hosting, data sources and member authentication
Provider Access API
- Demonstrated: PA status and patient data queries on sample data
- Implementation work: attribution-based access control and provider authentication
Payer-to-Payer API
- Demonstrated: consent records and bulk export ($export) on sample data
- Implementation work: member consent management and coverage-transition processes
CRD - Coverage Requirements
- Demonstrated: CDS Hooks order-sign and order-select with sample coverage rules
- Implementation work: coverage rules for your plans and integration with each EHR
DTR - Documentation Templates
- Demonstrated: FHIR Questionnaire packages, and a SMART on FHIR launch with pre-filled fields in a public test environment
- Implementation work: your questionnaire content, pre-fill rules (CQL) and EHR registration
Where SMART on FHIR fits. SMART on FHIR is the standard way an EHR launches a third-party app and grants it limited, authorized access to the current patient's record. In the DTR workflow it lets the questionnaire open from the clinician's EHR with patient details already filled in. The SMART DTR walkthrough shows this working in a public test environment: a real SMART App Launch (authorization code with PKCE) from the SMART Health IT sandbox, synthetic patients only, patient name and date of birth pre-filled into a Total Knee questionnaire, and a simulated PAS submission. A customer deployment adds registration with each EHR, client authentication agreed with the EHR vendor, system-to-system security for the payer APIs (for example SMART Backend Services), and the payer's own questionnaires and pre-fill rules.
Who Deploys What
Understanding regulatory responsibility is critical for implementation planning.
| API | Payer Hosts | Provider Role |
|---|---|---|
| Patient Access API | Required | N/A |
| Provider Access API | Required | Client only |
| Payer-to-Payer API | Required | N/A |
| Prior Authorization API (CMS recommends the Da Vinci CRD, DTR and PAS guides) | Required | Client only |
One Suite, Two Use Cases
Payers Use the Suite To
- Convert between X12 278 and FHIR for the Prior Authorization API (available)
- Evaluate the PAS, CRD, DTR and access-API workflows on sample data (demonstrated)
- Plan hosting of the required APIs, with production hosting, security and integration scoped per customer (implementation work)
- Support X12 278 integration where required. Published samples can be evaluated in the public sandbox; evaluation of customer inputs requires an evaluation key and supported input; integration and adaptation requirements are reviewed separately.
Illustrative Provider Workflow
These activities describe an intended connected deployment, not a production workflow supplied by today's demonstration. Required payer services, provider/EHR connectivity and supported conversion paths must be confirmed and scoped for each deployment.
- Submit PAS via payer-hosted APIs, using X12 278 to FHIR as the primary workflow
- Use RMap to FHIR as an alternative path when X12 is not available
- Call payer's CRD to check if PA is required
- Call payer's DTR to get required forms
- Submit and inquire PAs (updates and cancellations sent through $submit)
- Track ClaimResponse + Provenance
Implementation Timeline
Exact dates and API applicability vary by payer type.
(varies by payer type)
milestones
(varies by payer type)
Evaluate Redix for Your Platform
Whether you are building a custom prior authorization gateway, integrating with an existing portal, or looking for an OEM translation component, we can help you scope the correct boundaries for your CMS-0057-F architecture.
Published samples can be evaluated in the public sandbox, in both directions. Evaluation of customer inputs requires an evaluation key and supported input; integration and adaptation requirements are reviewed separately.
Related Documentation
Architecture
Technical architecture for your engineering team.
Test Workflow
Step-by-step integration and testing guide.
Compatibility Matrix
Detailed compliance mapping against CMS requirements.
API Reference
Endpoints, authentication, and code samples.
Product Page
CMS-0057-F Prior Authorization Suite overview.
PAS Demo
Try the Da Vinci PAS workflow with sample data (no PHI).