A CMS rule requiring impacted payers (Medicare Advantage, Medicaid managed care, CHIP managed care, and QHP issuers on FFEs) to implement four FHIR-based APIs for prior authorization and data access. API requirements begin January 1, 2027.

What are the four required APIs?

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. Da Vinci PAS API: PA submission, inquiry, update, and cancel via FHIR.

What is the compliance deadline?

API requirements begin January 1, 2027. Operational requirements (expedited and standard PA decision timeframes) started January 2026. Public reporting milestones began March 2026.

AnyToAny Format Data Conversion

Q: What is the Redix CMS-0057-F Prior Authorization Suite?

A software suite that provides the four CMS-mandated FHIR APIs — Patient Access, Provider Access, Payer-to-Payer, and Da Vinci PAS — plus bidirectional X12 278 to FHIR conversion, CRD coverage requirements discovery, and DTR documentation templates. Version 2026.1.

Q: Who is required to comply?

CMS-0057-F mandates apply to payers only — Medicare Advantage organizations, Medicaid managed care plans, CHIP managed care entities, and Qualified Health Plan issuers on federally-facilitated exchanges. Providers are clients and users of these APIs, not hosts.

Q: What Da Vinci PAS operations are supported?

Da Vinci PAS v2.1.0 (STU 2) with four operations: $submit (submit PA request), $inquire (check PA status), $cancel (cancel PA request), and $update (update existing PA). Every response includes ClaimResponse with Provenance tracking.

Q: What about CRD and DTR?

CRD (Coverage Requirements Discovery) uses CDS Hooks to let providers check whether PA is required at point of care. DTR (Documentation Templates and Rules) uses FHIR Questionnaires to collect required documentation. CRD and DTR are provider-side value-add tools defined by Da Vinci Implementation Guides — not CMS-mandated, but they help providers submit better PA requests and reduce denials.

Q: What are the deployment options?

On-premises (your data center, air-gapped option), Private Cloud (AWS/Azure/GCP VPC, your account, no shared tenancy), and Containerized (Docker images, Kubernetes ready, Helm charts). 100% self-hosted — PHI remains in your environment.

Q: What is the processing performance?

Less than 150ms typical end-to-end processing latency. Native C engine with single-pass architecture — no JVM overhead or garbage collection pauses. 99.999% production uptime.

Q: What databases are supported?

SQLite (default), SQL Server, Oracle, and PostgreSQL.

What is CMS-0057-F?

A CMS rule requiring impacted payers to implement four FHIR-based APIs for prior authorization and data access. The rule applies to:

Medicare Advantage organizations
Medicaid managed care plans
CHIP managed care entities
Qualified Health Plan (QHP) issuers on federally-facilitated exchanges

API requirements begin January 1, 2027.

What is the Redix CMS-0057-F Prior Authorization Suite?

A software suite (version 2026.1) that provides the four CMS-mandated FHIR APIs plus conversion and workflow tools:

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
Da Vinci PAS API — PA submission, inquiry, update, and cancel via FHIR

Also includes bidirectional X12 278 to FHIR conversion, CRD coverage requirements discovery, and DTR documentation templates.

Who is required to comply?

CMS-0057-F mandates apply to payers only, not providers. All four APIs are payer obligations. Providers are clients and users of the PAS and Provider Access APIs — they do not host them.

What is the compliance timeline?

January 2026 — Operational requirements start (expedited and standard PA decision timeframes)
March 2026 — Initial public reporting milestones
January 1, 2027 — API requirements start (all four APIs must be live)

What Da Vinci PAS operations are supported?

Da Vinci PAS v2.1.0 (STU 2) with four operations:

$submit — submit a prior authorization request
$inquire — check PA status
$cancel — cancel a PA request
$update — update an existing PA

Every response includes a ClaimResponse with Provenance tracking for audit traceability.

What about CRD and DTR?

CRD (Coverage Requirements Discovery) uses CDS Hooks to let providers check whether PA is required at point of care. Supports order-select, order-sign, appointment-book, encounter-start, encounter-discharge, and order-dispatch hooks.

DTR (Documentation Templates and Rules) uses FHIR Questionnaires to collect required documentation with pre-populated data fields.

CRD and DTR are provider-side tools defined by Da Vinci Implementation Guides — not CMS-mandated, but they help providers submit better PA requests and reduce denials.

What standards does the suite conform to?

FHIR R4 (4.0.1) — base interoperability standard
Da Vinci PAS v2.1.0 — Prior Authorization Support IG
US Core 3.1.1 — US healthcare profiles
SMART on FHIR 2.0 — authorization framework
CDS Hooks — CRD integration

What are the deployment options?

On-Premises — your data center, full infrastructure control, air-gapped option
Private Cloud — AWS/Azure/GCP VPC, your cloud account, no shared tenancy
Containerized — Docker images, Kubernetes ready, Helm charts available

100% self-hosted. PHI remains in your environment with no cloud dependencies or external processing.

What is the processing performance?

Less than 150ms typical end-to-end processing latency. Native C engine with single-pass architecture — no JVM overhead or garbage collection pauses. 99.999% production uptime.

What databases are supported?

SQLite (default — no separate database server required)
SQL Server
Oracle
PostgreSQL

What are the adoption paths?

Option A — FHIR-First: RMap to FHIR for organizations without X12 infrastructure. Generate Da Vinci PAS FHIR bundles directly from CSV.
Option B — Hybrid Bridge: Keep X12 workflows, add FHIR outputs alongside existing EDI systems.
Option C — Full Suite: All four APIs plus conversion plus audit and provenance tracking.

How does build vs. buy compare?

Time to production: 12+ months in-house vs. weeks to few months with Redix
FHIR expertise: Hire/train 3–5 specialists in-house vs. reduced requirement with API-first approach
X12 278 conversion: Build from scratch vs. built on the AnyToAny Engine
Da Vinci PAS conformance: Interpret IG, build, and test vs. aligned to v2.1.0
CMS audit readiness: Build audit trail system vs. FHIR Provenance built-in
Estimated cost: $1M–$2M+ internal build vs. licensed software

Can I try it before purchasing?

Yes. The Live Sandbox provides several CMS compliance tools:

CMS PAS 278 tool — submit and inquire PA requests via Da Vinci PAS
X12 to FHIR converter — convert X12 278 to FHIR R4 bundles
ePA Workflow Demo — end-to-end CRD → DTR → PAS → approval → payment
Swagger API Explorer — interactive API documentation with live "Try it out"

No API key required. Do not upload PHI.

What are the licensing requirements?

AnyToAny Engine — required core product
CMS-0057-F Suite — four mandated APIs plus PAS conversion
HIPAA Package — optional add-on for full X12 transaction support (837, 835, 270/271, 276/277, 834, 820)

Modular pricing — add only the components you need.

CMS PAS Compliance Suite FAQ.

Related