Compliance & Modernization Layer for Legacy Payer Core Systems
Source-available payer infrastructure • Available for technical evaluation and pilot deployments.
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.
Claims, financial operations, provider operations, and interoperability remain independently deployable while sharing security, events, and operational evidence.
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.
Three budget questions. Same platform. You enter where this year’s money already is.
What can we buy this year against the 1 Jan 2027 CMS-0057-F clock while QNXT, Facets, or HealthEdge stays the system of record?
CMS-0057-F FHIR APIs in your Azure, AWS, or GCP. Your core stays authoritative. Buy this against the 2027 mandate so the compliance spend is not a throwaway sidecar.
Which one operational domain do we peel off the core without a rip-and-replace program?
Move one domain (prior auth, provider, eligibility, or claims intake) onto Cloud Health Office. The core remains system of record for everything not cut over. Reversible.
When, if ever, is Cloud Health Office the claims ledger?
Cloud Health Office becomes the ledger for claims, benefits, and payments. Only when you choose. Not a big-bang HealthEdge-style program, and not a claim that a live QNXT book has already moved.
Layer 3 is a path, not a completed QNXT replacement reference. Named cores remain adapter-based and configured per payer during onboarding.
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 →
Source-available EDI and FHIR infrastructure for payer compliance, modernization, and claims administration workflows.
Inside the Platform
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
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
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.
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 SalesReference 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.
The reference design uses the following logical-isolation controls. Their effectiveness must be verified in each deployed environment:
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/interactive-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 readinessThe platform is one part of the decision. Deployment and operating models covers who owns the infrastructure and who operates the application in each model — payer-controlled cloud (available today), Aurelianware-managed and hybrid shared-responsibility operation (by engagement), and a hosted service (under evaluation).
Cloud Health Office Professional Services covers the work around it: CMS-0057-F readiness assessment, implementation, core administration advisory, vendor and SOW technical review, and fractional payer architecture leadership. A health plan does not need to purchase or deploy Cloud Health Office in order to engage Professional Services.
Start with a technical evaluation or pilot against your own requirements. Expand only after conformance, security, integration, and operating results are verified.