CMS-0057-F System Architecture.
Deployment models, core components, integration patterns, and security considerations for solution architects.
Looking for the compliance suite? CMS-0057-F Compliance Suite · Want to try the workflow? PAS Demo
Deployment Models
On-Premises
- Your data center
- Full infrastructure control
- Air-gapped deployment assessed per customer
Private Cloud
- AWS / Azure / GCP VPC
- Your cloud account
- No shared tenancy
Containerized
- Docker image available for the conversion services (the PAS workflow service is not packaged)
- Kubernetes deployment assessed per customer
- Helm charts not currently provided
Core Components
FHIR R4 Server
REST/FHIR API service
Conversion Engine
AnyToAny Engine
Storage Layer
SQLite / SQL Server / Oracle
Auth Layer
Authentication method, identity provider and operating responsibilities are agreed for the deployment
Integration Patterns
Provider to Payer
- Submit PA via FHIR PAS
- Convert X12 278 to FHIR
- CRD/DTR workflow support
Payer Backend
- Legacy X12 278 systems
- FHIR facade layer via Redix PAS
- RMap intermediate format
- RMap to FHIR alternative path
Authentication
- API key support (deployment-specific)
- OAuth 2.0 via an identity provider agreed for the deployment
- SMART on FHIR: App Launch demonstrated for DTR in a public test environment; production EHR registration and system-to-system security agreed per deployment
Where SMART on FHIR fits. SMART on FHIR is the authorization layer between the EHR and the apps it launches. In a prior authorization workflow it has two roles: App Launch, where the clinician opens the DTR questionnaire from the EHR and the app receives a limited, patient-scoped token; and Backend Services, where systems authenticate to each other without a user (for example, payer API access defined by the Da Vinci guides). CDS Hooks for CRD is a separate interface, and an EHR access token does not authorize calls to payer PAS endpoints.
Demonstrated (public test environment)
- SMART App Launch 2.0 EHR launch from the SMART Health IT sandbox
- Authorization code with PKCE; patient-read scope only
- Synthetic patient name and date of birth pre-filled into a Total Knee DTR questionnaire
- Simulated PAS submission and status
Customer Deployment Work
- App registration with each EHR, with client authentication agreed with the EHR vendor
- System-to-system security for payer APIs (for example SMART Backend Services), agreed per deployment
- The payer's questionnaire content and pre-fill rules (CQL)
- HTTPS hosting, token handling and audit arrangements in the agreed environment
What Is / Is Not Redix
| Capability | Redix Provides | Customer Provides |
|---|---|---|
| FHIR API Infrastructure | API framework + workflow components | Connect data sources + policies |
| X12 278 Conversion | Bidirectional | — |
| Data Storage | SQLite default | Enterprise DB optional |
| Clinical Decisions | — | Your PA rules |
| Existing EDI Systems | — | Your integration |
| Identity Provider | Authentication method, identity provider and operating responsibilities are agreed for the deployment | |
| Provenance (resource origin) | FHIR Provenance in converted output | — |
| Access and event audit logging | Conversion request logging in the Redix API | Retention, access-event logging and SIEM integration, defined for the deployment |
Security & Data Sovereignty
Security Layer
- TLS 1.2+ encryption for all traffic
- API key support (deployment-specific; an API key alone does not establish production PAS/HRex security)
- OAuth 2.0 via an identity provider agreed for the deployment
- Conversion request logging; access and event audit logging, retention and SIEM arrangements are defined for the deployment
- FHIR Provenance (resource origin) in converted output
Data Sovereignty
- Self-hosted conversion engine — runs in the agreed customer environment
- The conversion engine can run in the agreed customer environment
- External services, data flows and deployment dependencies are defined for each integration
- Full infrastructure control
- Air-gapped deployment assessed per customer
Related Documentation
Platform Overview
What CMS requires and how Redix covers it.
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).