Cloud Health Office Release Notes
Source-available payer platform history. Security-scanned release process.
36 Microservices. 9 Adjudication Engines.
CMS-0057-F Readiness — Evidence Before the Deadline
V4 At A Glance
V4 — SaaS Architecture Foundation
V4 delivered multi-tenant isolation, security hardening, cloud portability, and a developer-first API experience. Current security posture should always be evaluated from the latest dependency and secret scans.
Multi-Tenant SaaS Isolation
Tenant isolation patterns for payer evaluation and customer-owned deployments.
- TenantContextService maps Azure AD tenant to CHO tenant
- X-Tenant-ID header injection on all API calls
- Cross-tenant data leakage prevention
- Dynamic tenant name display with demo/production badges
Security Hardening
Dependency, secret, and configuration hardening across the release process.
- 59 package updates across all services
- CVE-2024-43485 (System.Formats.Asn1 RCE) fixed
- CVE-2024-21907 (Newtonsoft.Json) fixed
- Global transitive dependency enforcement
Cloud Portability
Cloud-agnostic infrastructure with dual-provider support.
- IDocumentStore<T> abstraction layer
- Azure Cosmos DB (production)
- MongoDB / DigitalOcean (65% cost savings)
- 3-click GitHub Actions deployment toggle
OpenAPI 3.1 Specifications
Full API documentation with interactive Swagger UI for all FHIR endpoints.
- Patient Access API spec (CARIN Blue Button)
- Provider Access API spec (Da Vinci PDex)
- Claims Scrubbing API spec with ROI metrics
- Interactive Swagger UI viewers
Developer Quickstarts
From zero to first API call in under 30 minutes.
- CMS-0057-F Compliance quickstart (15 min)
- Patient Access API quickstart (30 min)
- Claims Scrubbing API quickstart (20 min)
- Code examples in JavaScript, Python, C#
SFTP Trading Partner Integration
Direct SFTP connectivity for EDI file exchange with trading partners.
- Multi-tenant SFTP endpoint provisioning
- 837/835/277 transaction folder structure
- Azure Key Vault credential storage
- Dental claims EDI support
Platform Overview
The full Cloud Health Office platform as of V4.
| Component | Count | Details |
|---|---|---|
| Microservices | 36 | C# / .NET 8, multi-tenant, Cosmos + MongoDB dual-repo |
| Calculation Engines | 9 | Benefit, Fee Schedule, NCCI, COB, Risk Adjustment, Encounter, Claims Scrub, Capitation, Operating Mode |
| X12 Parsers | 5 | 275, 276, 277, 278 (Python), 834 (Node.js) |
| FHIR R4 APIs | 5 | Patient Access, Provider Access, Payer-to-Payer, Prior Auth, Provider Directory |
| Argo Workflows | 17 | Claims adjudication, EDI ingest, enrollment import, RFAI |
| Portal Pages | 60 | Blazor Server + MudBlazor, Microsoft Entra ID (multi-tenant) |
| CI/CD Workflows | 20 | GitHub Actions — build, test, deploy, security scan |
| Claims Scrubbing Rules | 20+ | Data completeness, ICD-10/CPT format, NPI Luhn, POS, filing limits |
Pricing
Cloud Health Office V4 is priced per member per month (PMPM) across Platform Engagement — payer-scale relationships organized into three layers: Layer 1 — Compliance Accelerator (CMS-0057-F surface alongside legacy core), Layer 2 — Progressive Modernization (domain-by-domain Augment or Replace), and Layer 3 — Full CAPS Platform (cloud-native end-to-end). Pilot-scoped terms; founding-partner relationships negotiated per engagement.
Public Tools, Transactional Services, and Managed Data Services are available alongside Platform Engagement for developers, integrators, and small plans with specific data needs.
CMS-0057-F Readiness Status
Cloud Health Office provides implemented CMS-0057-F readiness surfaces with FHIR R4, US Core, and Da Vinci Implementation Guide coverage that still require payer-specific validation before production use.
| Requirement | Implementation | Deadline | Status |
|---|---|---|---|
| Patient Access API | FHIR R4 — Claim, EOB, Coverage, Patient, Encounter | January 1, 2027 | |
| Provider Access API | FHIR R4 — Claim, EOB, Patient, Condition, Observation | January 1, 2027 | |
| Prior Authorization API | FHIR R4 + CDS Hooks — real-time PA decisions | January 1, 2027 | |
| Payer-to-Payer API | FHIR R4 — bidirectional member data exchange | January 1, 2027 | |
| Provider Directory API | FHIR R4 — Practitioner, Organization, Location, Network | January 1, 2027 | |
| USCDI v1/v2 | US Core profiles, Da Vinci IGs (PDex, PAS, CRD, DTR, HRex) | January 1, 2027 |
Full readiness documentation: CMS-0057-F Readiness Guide →
V3 Features (Included)
V4 includes all V3 features: multi-cloud deployment, Argo Workflows orchestration, and Kubernetes-native infrastructure.
Multi-Cloud Deployment
Deploy on Azure AKS, AWS EKS, or GCP GKE with unified Helm charts, Argo Workflows, and HashiCorp Vault.
Argo Workflows
17 Kubernetes-native workflow DAGs for claims adjudication, EDI ingest, enrollment import, and RFAI.
ClaimRiskScorer
ML-powered fraud/abuse detection with PyTorch risk scoring (0-100) and custom ZZZ segment in 277.
Migration Wizard
Blazor web app for legacy system migration with 95%+ auto-match mapping and one-click API cutover.
V2 Features (Included)
V4 includes the V2 FHIR surfaces as part of the CMS-0057-F readiness path, with payer-specific validation still required before production use.
Patient Access API
FHIR R4 API enabling patients to access claims, encounters, and clinical data within 1 business day of adjudication.
Provider Access API
Real-time patient data access for providers with proper authorization and consent management.
Prior Authorization API
Automated prior auth with 72-hour urgent and 7-day standard response tracking via FHIR R4 + CDS Hooks.
Payer-to-Payer API
Bulk FHIR export for bidirectional member data exchange during enrollment transitions.
Quick Start
Get Cloud Health Office running in your environment.
# Clone and run
git clone https://github.com/aurelianware/cloudhealthoffice.git
cd cloudhealthoffice
docker compose --profile core up -d
# Verify
curl http://localhost:5001/health/live
# Or deploy with Helm (Azure/AWS/GCP)
helm install cloudhealthoffice ./infrastructure/helm/cloudhealthoffice
# Run the test suite
npm install && npm test
Deploy instantly to Azure:
Deploy to Azure →Docker Compose for local evaluation (first run builds images, typically 10–20 minutes; instant on repeat runs). Kubernetes deployment requires customer-specific cloud, identity, security, and data validation.
Documentation
Quickstart
Run the platform locally with Docker Compose, or deploy to Kubernetes/Azure.
Read Guide →Architecture
System design, service interactions, and the 10-step claims adjudication pipeline.
Read Guide →CMS-0057-F Compliance
Regulatory readiness mapping with FHIR R4 implementation details.
Read Guide →Deployment Guide
Deployment reference for Azure and Kubernetes with environment-specific validation.
Read Guide →Evidence-Backed Payer Platform
36 microservices. 9 adjudication engines. 5 FHIR R4 APIs.
CMS-0057-F readiness surface. Security-scanned. Deployable to customer-owned cloud infrastructure after payer validation.