Cloud Health Office Platform
Compliance & Modernization Layer for Legacy Payer Core Systems
Source-available payer infrastructure • Available for technical evaluation and pilot deployments.
Compliance First. Modernization on Your Terms.
Cloud Health Office is a source-available collection of payer services, APIs, workflow definitions, and a Blazor operations portal. It is designed to run alongside an existing core admin system and is currently available for technical evaluation and security-reviewed pilots. Production readiness, compliance, integrations, and operating performance must be validated for each payer environment.
Benchmark
Matched
Exact
Stage
Four payer domains. One evidence path.
Claims, financial operations, provider operations, and interoperability remain independently deployable while sharing security, events, and operational evidence.
What Runs Today — and What Doesn't Yet.
This page documents the platform's building blocks. Availability differs by capability: some run today, while production integrations, SLAs, and customer validation remain pilot- or roadmap-scoped. We'd rather draw that line clearly than blur it.
Usable now: the claims adjudication, pricing, and fee-schedule engines are implemented and inspectable in the repository — including the free fee-schedule lookup and claims-repricing tools that run on the same code.
Pilot-scoped: payer deployments start with a CMS-0057-F compliance layer alongside your existing core, then modernize domain by domain on your timeline. Your system of record stays authoritative until you choose to cut over a domain.
Roadmap: subscription packaging, update cadences, and public production SLAs for the data and API services are still being completed.
Claims Adjudication Proof, Measured Locally
The Million Claim Challenge validates the platform under pressure by reporting throughput, tail latency, platform reliability, and deterministic healthcare workflow correctness together. The latest published Cloud Health Office run is a 1,000,000-claim local Kubernetes validation -- the full target this benchmark series was built around -- not a production cloud benchmark.
This local result is not a production-cloud capacity claim. Part 15 remains the strict zero-platform-failure 1M baseline; Part 16 measures the faster platform-owned asynchronous path and discloses its fixed observation-window limitation. Read Part 16 · See the benchmark methodology →
Core Capabilities
Source-available EDI and FHIR infrastructure for payer compliance, modernization, and claims administration workflows.
Real-Time Prior Authorization
- 278 Health Care Services Review
- Configurable workflow and decision routing
- Automated claims adjudication systems correlation
- Audit-event capture
- Automated workflow routing
Claims Processing
- 837P/I/D (Professional, Institutional, Dental)
- Automated X12 validation
- Real-time status updates
- Deterministic replay endpoint
- PHI-redacted Application Insights
Eligibility Verification
- 270/271 eligibility workflows
- Clearinghouse adapter interfaces
- Environment-specific performance testing required
- Backend system correlation
- No public production SLA yet
Claim Status
- 276 claim-status inquiry
- 277 claim-status response
- Real-time status tracking
- Historical lookup capabilities
- NCPDP and HIPAA format support
Appeals Integration
- 277 RFAI automated generation
- 275 Attachment processing
- Deadline tracking and notifications
- Audit-event capture
- Configurable regulatory deadline rules
Security Reference Architecture
- Private-endpoint deployment patterns
- HSM-backed Key Vault Premium
- DCR-based PHI redaction
- Immutable audit logs (7-year retention)
- Managed-identity support
Premium Billing & ACH
- Monthly premium invoicing per sponsor group
- NACHA/ACH file generation (CCD format)
- EFT draft lifecycle: Pending → Settled / Returned
- Stripe ACH integration with webhook processing
- Batch billing runs with audit trail
Inside the Platform
Portal Walkthrough With Seeded Data
These screens are from the functional Blazor portal using synthetic development data. They demonstrate implemented workflows and user-interface coverage; they are not customer production metrics, a production reference deployment, or proof of regulatory compliance.
Platform Architecture
Service-Oriented Claims Administration Architecture
The repository includes independently deployable .NET services, calculation engines, X12 workflows, and FHIR APIs designed for Kubernetes. The architecture supports integration with systems such as QNXT, Facets, or HealthEdge, but each connector and production topology requires customer-specific validation.
Financial Operations
End-to-End Payer Financial Lifecycle
Accounts receivable, capitation management, premium billing with NACHA/ACH, and fee-for-service payment runs with 835 ERA generation — all native to the platform.
Screenshots below show seeded demo data from a local development tenant, not a live customer environment.
See How It Works With Your Core System
Review the intended augmentation model, current implementation, and long-term modernization roadmap.
Pilot the CMS-0057-F API surface alongside your existing core. Scope, security, conformance, integration effort, and deployment timing are established during technical discovery.
For Health Plans → Contact SalesArchitecture Overview
Reference infrastructure uses Argo Workflows on AKS, Service Bus, Data Lake Gen2, and containerized services. The repository provides deployable building blocks, not a universal production configuration.
Deployment Components
- Argo Workflows on AKS: Kubernetes-native workflow orchestration for all EDI transaction types
- Service Bus: Event-driven architecture with topics for pub/sub patterns
- Data Lake Gen2: Hierarchical namespace for organized PHI storage
- Integration Account: X12 schema validation and trading partner agreements
- Key Vault Premium: HSM-backed key management with soft-delete + purge protection
- Application Insights: Telemetry with DCR-based PHI redaction
- Private Endpoints: No public IP addresses exposed
Multi-Tenant Architecture
The reference design uses the following logical-isolation controls. Their effectiveness must be verified in each deployed environment:
- Dedicated Argo workflow templates per payer
- Isolated Service Bus topics and subscriptions
- Separate Data Lake containers with hierarchical paths
- Individual trading partner configurations
- Zero shared secrets or configuration
Reference Deployment Workflow
The CLI can generate a payer-specific starting point. A production deployment still requires architecture review, security validation, integration testing, data migration planning, observability, and operational acceptance.
# Step 1: Run onboarding wizard (5 minutes)
node dist/scripts/cli/payer-onboarding-wizard.js
# Step 2: Generate infrastructure and workflows (10 minutes)
node dist/scripts/cli/payer-generator-cli.js generate -c payer-config.json
# Step 3: Deploy to Azure (25 minutes)
cd generated/your-payer/infrastructure && ./deploy.sh
# Step 4: Configure trading partners (10 minutes)
./configure-hipaa-trading-partners.ps1
# Example only: timing varies; this does not constitute production readinessReady to Modernize Your Payer Operations?
Start with a technical evaluation or pilot against your own requirements. Expand only after conformance, security, integration, and operating results are verified.