CMS-0057-F / Da Vinci PAS compliance without replacing your X12 backend

Redix bridges existing X12 prior authorization workflows into FHIR R4 and Da Vinci PAS v2.1.0, so payers, TPAs, clearinghouses, and processors can meet CMS-0057-F API requirements without rewriting their transaction stack.

Compliance deadline: January 1, 2027. API requirements for impacted payers begin January 2027. Some operational provisions begin in 2026 (varies by payer type).

Prior Auth API Patient Access API Provider Access API Payer-to-Payer API Da Vinci PAS v2.1.0 X12 278 FHIR R4

X12 278 ⇆ FHIR PAS Da Vinci PAS v2.1.0 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

Medicaid, Medicare Advantage, and commercial payers under CMS-0057-F mandate.

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 compliance 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.

<150ms

Typical end-to-end processing latency

Data sovereignty

Runs on your infrastructure, with no SaaS dependency

Validated Processing

Validation and transformation workflows

Native C Core

No JVM overhead or GC pauses

What's In The Suite

Core components for CMS-0057-F compliance in one suite.

Prior Authorization API (PAS) + Supporting APIs

  • Prior Authorization API — PAS submit, inquire, cancel, status/decision
  • Patient Access API workflow support
  • Provider Access API workflow support
  • Payer-to-Payer API workflow support

Da Vinci IG Support

  • Da Vinci PAS v2.1.0 ($submit, $inquire, $cancel, $update)
  • CRD-aligned support (coverage requirements discovery)
  • DTR-aligned support (templates/rules integration)
  • ClaimResponse + Provenance tracking

X12 & RMap Conversion

  • X12 278 ↔ FHIR PAS bundles (bidirectional)
  • RMap ↔ FHIR (simplified internal format option)
  • FHIR Provenance audit trail

Enterprise Ready

  • On-premises / private cloud deployment
  • Low-latency, high-throughput (single-pass architecture)
  • Docker & Kubernetes support
  • SQL Server, Oracle, PostgreSQL options

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

Bidirectional conversion between X12 278 and FHIR R4 Da Vinci PAS bundles, built on the Redix native C engine with a FHIR mapping layer.

Inbound: X12 278 to FHIR

Convert existing X12 278 prior authorization requests and responses to FHIR format, including Provenance resources for audit trail compliance.

curl -X POST "https://demo.redix.com/api/v2/hipaa-to-fhir/278-request" \
  -H "X-API-Key: demo-key-12345" \
  -F "file=@prior_auth_request.x12"

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 validated during technical review.

curl -X POST "https://your-redix-host/api/v2/fhir-to-hipaa/278-request" \
  -H "X-API-Key: <evaluation-or-deployment-key>" \
  -H "Content-Type: application/fhir+json" \
  -d @fhir_claim_bundle.json

Reverse FHIR to X12 access is scoped for private technical review or deployment evaluation.

Why latency matters: In a real-time Prior Auth workflow, the conversion layer must add negligible latency. A provider's EHR sends the request, the payer API processes it, and the decision returns — all while the patient is still in the exam room. Redix's native C core engine has no JVM overhead. The FHIR mapping layer is designed for low-latency processing in modern API deployments.

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.

Working Code Examples

Python examples for the three core conversion operations.

Convert X12 278 Request to FHIR (with Provenance)

from redix_client import RedixClient

client = RedixClient(
    base_url="https://demo.redix.com",
    api_key="demo-key-12345"
)

# Convert X12 278 Request to FHIR
result = client.post("/api/v2/hipaa-to-fhir/278-request",
    files={"file": "/path/to/278_request.x12"}
)

# Result contains FHIR Claim bundle with Provenance
fhir_bundle = result["fhir_bundle"]
print(f"Resource Type: {fhir_bundle['resourceType']}")
print(f"Entries: {len(fhir_bundle.get('entry', []))}")

# Extract Provenance for audit trail (CMS-0057-F requirement)
for entry in fhir_bundle.get("entry", []):
    resource = entry.get("resource", {})
    if resource.get("resourceType") == "Provenance":
        print(f"Recorded: {resource.get('recorded')}")
        print(f"Activity: {resource.get('activity', {}).get('coding', [{}])[0].get('display')}")

Convert X12 278 Response to FHIR ClaimResponse

# Convert X12 278 Response to FHIR ClaimResponse
result = client.post("/api/v2/hipaa-to-fhir/278-response",
    files={"file": "/path/to/278_response.x12"}
)

fhir_response = result["fhir_bundle"]
for entry in fhir_response.get("entry", []):
    resource = entry.get("resource", {})
    if resource.get("resourceType") == "ClaimResponse":
        print(f"Status: {resource.get('status')}")
        print(f"Outcome: {resource.get('outcome')}")
        # CMS-0057-F requires specific denial reasons
        if resource.get('outcome') == 'error':
            for error in resource.get('error', []):
                print(f"Denial Reason: {error.get('code', {}).get('text')}")

Convert FHIR PAS Bundle to X12 278 (Scoped Reverse Direction)

import json

# Load a validated FHIR PAS bundle for a scoped reverse-conversion review
with open("fhir_claim_bundle.json", "r") as f:
    fhir_bundle = json.load(f)

# Full pipeline: FHIR to X12 278 in one call
x12_result = client.post("/api/v2/fhir-to-hipaa/278-request",
    json=fhir_bundle,
    headers={"Content-Type": "application/fhir+json"}
)

# Submit X12 278 to legacy authorization system
x12_content = x12_result.get("x12_content")

Reverse FHIR to X12 access is scoped for private technical review or deployment evaluation.

Try it live: Forward X12 278 to FHIR endpoints are available in the Swagger API explorer with the demo API key demo-key-12345 and sample X12 278 files. Reverse FHIR to X12 access is scoped for private technical review or deployment evaluation.

Conversion Fidelity Report

For evaluation and implementation, Redix can produce a Conversion Fidelity Report for each conversion: which X12 segments were recognized and whether the resulting PAS FHIR output validates cleanly.

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

Redix outputs are validated 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 validated.

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 deploy the full suite.

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: Full Suite

Prior Auth API + adjacent workflow APIs, conversion, and audit/provenance for full CMS-0057-F coverage.

  • Prior Auth API + adjacent workflow APIs
  • X12 + RMap conversion
  • Provenance audit trail

CMS-0057-F Timeline

Key compliance milestones based on the CMS-0057-F final rule schedule.

Jan 1, 2026
Operational requirements start
(varies by payer type)
Mar 31, 2026
Initial public reporting
milestones
Jan 1, 2027
API requirements start
(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.

Licensing

AnyToAny Engine

Required. Core conversion engine providing the single-pass architecture, IFD/OFD processing, and runtime environment.

CMS-0057-F Suite

This package. Prior Authorization API / Da Vinci PAS v2.1.0 workflows, X12 278 to FHIR conversion, RMap to FHIR option, and adjacent workflow API support.

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.