CMS-0057-F prior authorization without replacing your X12 backend
Redix converts between existing X12 278 prior authorization transactions and FHIR R4 / Da Vinci PAS, so payers, TPAs, clearinghouses, and processors can add the FHIR side alongside their current transaction stack. Connecting to your systems depends on your interfaces and is scoped with you.
CMS-0057-F API requirements generally begin January 1, 2027, for impacted payers; timing depends on payer category. Operational provisions took effect in 2026.
X12 278 ⇆ FHIR PAS Da Vinci PAS RMap intermediate format option On-prem / Docker
Built on the same Redix engine used in production by a national US pharmacy organization to migrate 100+ healthcare conversion scripts.
Not a covered entity but inheriting PAS traffic? See Handling PAS traffic without changing your backend.
Who It's For
One suite for payers, providers, clearinghouses, and platform vendors under CMS-0057-F.
Health Plans
Medicare Advantage organizations, Medicaid and CHIP programs and managed care plans, and QHP issuers on the Federally-facilitated Exchanges: the payers CMS-0057-F applies to.
Providers & Health Systems
Organizations integrating PA workflows into EHR/RCM and provider access APIs.
TPAs & Clearinghouses
Organizations processing prior authorization on behalf of health plans.
Platform Vendors
EHR, RCM, and integration vendors adding CMS-0057-F prior authorization capabilities to their stack.
Performance Specifications
Designed for mission-critical healthcare infrastructure, built around the Redix native C core engine with FHIR mapping layers for PAS workflows.
Performance
Performance depends on the input, mapping, hosting environment and integration; measure it during evaluation.
Data sovereignty
Can run in the agreed customer environment
Validated Processing
Validation and transformation workflows
Native C Core
No JVM overhead or GC pauses
What's In The Suite
Core components for a CMS-0057-F prior authorization API in one suite. X12 278 ↔ FHIR conversion is available today; CRD, DTR and PAS workflows are shown as demonstrations; connecting to your systems is implementation work scoped per customer.
Prior Authorization API (PAS) and Supporting API Demonstrations
- Prior Authorization API — PAS $submit and $inquire with simulated decisions (demonstrated)
- Patient Access API workflow (demonstrated on sample data)
- Provider Access API workflow (demonstrated on sample data)
- Payer-to-Payer API workflow (demonstrated on sample data)
- Production integration scoped per customer
Da Vinci IG Support
- Da Vinci PAS ($submit and $inquire; updates and cancellations are sent through $submit, as the guide defines)
- CRD-aligned support (coverage requirements discovery)
- DTR-aligned support (templates/rules integration)
- SMART on FHIR app launch for DTR (demonstrated in a public test environment)
- ClaimResponse and FHIR Provenance (resource origin) in converted output
X12 & RMap Conversion
- X12 278 ↔ FHIR PAS bundles (bidirectional)
- RMap ↔ FHIR (simplified internal format option)
- FHIR Provenance (resource origin)
Deployment planning
- On-premises / private cloud deployment, assessed per customer
- Single-pass conversion architecture
- Conversion deployment options include on-premises and Docker; Kubernetes requirements are assessed per customer. Helm charts are not currently provided.
- Database options assessed per deployment
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.
X12 278 to FHIR Conversion
Conversion between X12 278 and FHIR R4 Da Vinci PAS bundles in both directions for supported content, built on the Redix native C engine with a FHIR mapping layer. Published samples can be evaluated in both directions in the public converter; testing customer inputs requires an evaluation key and a supported input.
Inbound: X12 278 to FHIR
Convert existing X12 278 prior authorization requests and responses to FHIR format, including Provenance resources that record where each resource came from.
Outbound: FHIR to X12 278
For validated PAS FHIR workflows, convert FHIR PAS bundles to X12 278 for legacy backend systems. Provider-generated PAS FHIR fixtures can be reviewed during evaluation.
Published samples can be converted in both directions in the public converter. Customer files require an evaluation key and a supported input.
Why latency matters: In a real-time prior authorization workflow, the conversion layer should add as little latency as possible. Redix’s native C core engine has no JVM overhead, and the FHIR mapping layer is designed for low-latency processing. Conversion timing is not the whole authorization decision time; measure performance for your inputs and environment during evaluation.
For Payers and Integration Teams
For payers, vendors, and integration teams building CMS-0057-F prior authorization solutions, Redix can run as the X12 278 to Da Vinci PAS FHIR conversion layer behind your API architecture. This lets organizations modernize FHIR workflows while preserving existing X12 and UM infrastructure.
REST API Integration Surface
Redix can run as more than a file conversion tool. The same X12 278 ↔ Da Vinci PAS FHIR conversion can run as a REST API conversion layer behind a payer, vendor, or integrator architecture.
Redix can expose the conversion through REST APIs, hosted in the Redix sandbox for evaluation or deployed behind your own API gateway, on your servers or in Docker.
Scope: Redix is the conversion engine behind the workflow, not the payer's public CMS-0057-F API gateway, OAuth2/SMART authorization layer, or utilization-management decision engine. Redix converts; your platform orchestrates.
Try the Conversions
For current sample conversions, use the public X12 278 / FHIR converter or the Swagger API explorer. The public demo key accepts registered Redix samples only. Testing your own supported, de-identified files requires an evaluation key. Do not upload production PHI. Copy-and-run examples will be restored after public-endpoint testing.
Conversion Fidelity Report
For evaluation and implementation, Redix can produce a Conversion Fidelity Report for each conversion: which X12 segments were recognized and the conversion’s own validation checks.
The report is a segment inventory and validation summary, enough to verify a conversion end to end without exposing field-level mapping internals.
Validation & QA
The tested sample conversion output passed validation against Da Vinci PAS profiles for CMS-listed PAS 2.0.1 and 2.1.0, with 2.2.1 available as a forward-looking validation target. Reverse FHIR → X12 278 conversion is round-trip tested on Redix sample bundles.
A Redix FHIR audit/QA step complements standard FHIR validators during conversion, catching structural issues that schema validation alone can miss.
Choose the path that fits your existing infrastructure. Keep running X12, start fresh with FHIR, or plan a broader implementation.
How You Can Adopt
Option A: FHIR-First Path
Build PAS workflows on FHIR. Use RMap as a simplified internal format to generate PAS bundles without standing up a full X12 278 stack.
- RMap → FHIR conversion
- Simplified internal format
- Faster path for new implementations
Option B: Hybrid Bridge
Keep X12 278 workflows running. Add FHIR outputs for trading partners who need them.
- X12 278 ↔ FHIR bridge
- Preserve existing EDI
- Gradual migration
Option C: Customer-Specific Implementation
Discuss a customer-specific implementation using Redix conversion capabilities and the demonstrated API workflows. Production scope, security and integrations are agreed separately.
- Redix X12 + RMap conversion
- Demonstrated API workflows as a starting point
- Production scope agreed separately
CMS-0057-F Timeline
Key milestones based on the CMS-0057-F final rule schedule.
(varies by payer type)
milestones
(varies by payer type)
Want to see the workflow in action? Try the Da Vinci PAS demo with sample data (no PHI). Or explore the full Live Sandbox.
Live Sandbox Tools
PAS Prior Authorization Demo
Preview the ePA workflow with sample data — CRD, DTR, PAS submit, simulated approval
SMART Launch — DTR Walkthrough
SMART on FHIR launch, pre-filled DTR questionnaire, simulated PAS submission
X12 to FHIR
HIPAA EDI to FHIR R4 bundles
FHIR to RMap
FHIR R4 to tabular format
X12 to RMap
HIPAA to tabular intermediate
CMS-0057-F Documentation
Platform Overview
What CMS requires and how Redix covers it.
Architecture
Technical architecture for your engineering team.
Test Workflow
Step-by-step integration and testing guide.
Compatibility Matrix
Responsibility mapping against CMS-0057-F requirements.
API Reference
Endpoints, authentication, and code samples.
Licensing
AnyToAny Engine
Required. Core conversion engine providing the single-pass architecture, IFD/OFD processing, and runtime environment.
CMS-0057-F Suite
This package. X12 278 ↔ Da Vinci PAS FHIR conversion, an RMap to FHIR option, and adjacent API support, with CRD, DTR and PAS workflow demonstrations. Integration with your systems is scoped per customer; licensing the suite does not by itself make a payer compliant.
HIPAA Package
Optional add-on. HIPAA X12 to FHIR conversion for 837, 835, 270/271, 276/277, 834, 820 transactions.
Modular pricing. The AnyToAny Engine is the core product required for all conversions. Each module is licensed separately based on your requirements. Request an evaluation to discuss your implementation.