CloudHealthOffice
Current capability status and dated implementation/test evidence: Capability Reconciliation.
CloudHealthOffice is a source-available, Kubernetes-first healthcare payer
administration platform. It is built for teams modernizing claims, benefits,
eligibility, prior authorization, FHIR interoperability, and X12 operations
without treating a legacy Core Administration Processing System as the only
place business logic can live.
The project is licensed under BSL 1.1. Non-production use is permitted for
evaluation, development, testing, and staging. See LICENSE for the
exact terms. Third-party components and their licences are listed in
THIRD-PARTY-NOTICES.md.
Executive Summary
Health plans need modern APIs, event-driven operations, auditable adjudication,
and CMS-0057-F interoperability. Legacy CAPS platforms such as Facets, QNXT, and
HealthEdge remain operationally important, but they were not designed around
Kubernetes, FHIR R4, X12 event streams, or continuous benchmark evidence.
CloudHealthOffice is designed as a cloud-native payer platform that can be
deployed alongside existing systems, used to validate specific workloads, and
progressively expanded. Current evidence is strongest around local Kubernetes
claims adjudication, workflow scoring, pended-claim observability, and operator
console inspection through the Million Claim Challenge.
Reference backend and core connectors
CHO is the reference backend implementation behind the domain adapter contracts.
QNXT, Facets and HealthEdge use separate connectors implemented per payer
engagement, based on platform version/configuration, licensed interfaces,
solution architecture and hosting. Their interface templates are intentional
integration work, not evidence that the corresponding native workflow is missing.
A named connector is not working vendor connectivity until implemented and
accepted. See ADR 027 and the
core adapter QRE.
Who It Is For
- Health plan engineering teams evaluating CAPS modernization paths.
- Payer platform architects working with claims, benefits, eligibility, and
prior authorization systems.
- Healthcare interoperability teams implementing CMS-0057-F, FHIR R4, and X12.
- Contributors who want to work on production-oriented healthcare platform
infrastructure.
What Makes It Different
- Kubernetes-first: services, jobs, workflows, and local benchmark runs are
designed around containerized operation.
- Evidence-first: the Million Claim Challenge publishes reproducible command
lines, run summaries, validation outcomes, and raw artifacts instead of only
marketing claims.
- API-first: payer operations are exposed through service APIs, a Blazor
portal, and FHIR/X12 integration surfaces.
- Event-oriented: claims and operational workflows are structured for
asynchronous processing, durable audit trails, and future streaming analytics.
- Truthful scoring: paid, denied, pended, mismatched, unsupported, platform
failures, false pends, and payment deltas are separated.
Key Features
| Area | Current focus |
|---|
| Claims adjudication | Professional, institutional, and dental synthetic claims; workflow scoring; claim detail views; mass adjudication console |
| Benefit administration | Declarative benefit models, cost sharing, accumulators, service-category mapping, and plan versioning |
| Pricing and edits | Fee schedules, NCCI/MUE checks, claims scrubbing, COB, provider network checks, and prior-auth rules |
| Interoperability | FHIR R4 projections, X12 parsing/processing, terminology lookup, and CMS-0057-F readiness docs |
| Operations portal | Claims search, claim detail, mass adjudication runs, EDI transaction history (834/837), dashboards, work queues, and administrative surfaces |
| Deployment | Docker Compose, Kubernetes manifests, GitHub Actions, and deployment documentation |
| Benchmarks | 5K, 10K, 50K, 100K, and full 1,000,000-claim Million Claim Challenge evidence packets |
Platform Architecture
flowchart LR
Portal["Operations Portal\nBlazor Server"] --> Claims["claims-service"]
Portal --> Authz["authorization-service"]
Portal --> Benefits["benefit-plan-service"]
Portal --> Fhir["fhir-service"]
X12["X12 / EDI Inputs\n837, 834, 270/271"] --> Claims
Claims --> Pipeline["Adjudication Pipeline"]
Pipeline --> BenefitEngine["Benefit Engine"]
Pipeline --> FeeEngine["Fee Schedule Engine"]
Pipeline --> Ncci["NCCI Engine"]
Pipeline --> Cob["COB Engine"]
Pipeline --> Scrub["Claims Scrub Engine"]
Pipeline --> Persistence["Claim Persistence"]
Claims --> Events["Event Bus / Kafka-ready Topics"]
Authz --> Events
Benefits --> Events
Events --> Observability["Telemetry, Audit, Run Evidence"]
Fhir --> Cms["CMS-0057-F APIs"]
Persistence --> Portal
Start with docs/architecture/README.md for the
architecture map and component-level guides.
Screenshots And Evidence
The current public evidence comes from local Docker Desktop Kubernetes runs and
the Batch Adjudication page.
Screenshot placeholder structure for future documentation lives in
docs/assets/screenshots/README.md.
Million Claim Challenge
The Million Claim Challenge is the project’s benchmark and proof ladder. It is
not just a load test. It validates whether the platform reaches the right
disposition, preserves pended-claim observability, separates unsupported gaps,
and reports payment accuracy independently from workflow correctness.
Current published local evidence includes:
- Correctness baseline — full 1,000,000-claim corpus run (episode 15):
1,000,000 processed, zero platform failures, 129,981/130,000 workflow checks
matched, zero unsupported scenarios, and a payment-amount gate of
20,000/20,000 exact within one cent, at 123.81 claims/sec.
- Highest sustained throughput at 1M claims (episode 16), same corpus: 155.89 claims/sec
(P95 910 ms, P99 1,205 ms), 129,980/130,000 workflow checks, 19,982/19,982
payments exact within one cent. 122 claims became terminal after the
validator's 180-second observation window — post-run verification found all
1,000,000 terminal with zero dead letters, so episode 15 remains the strict
zero-failure baseline.
- 100,000-claim local Kubernetes run with zero platform failures, zero scoreable
workflow mismatches, zero unexpected pends across scoreable non-pend claims,
and 2,000 of 2,000 comparable payments within one cent.
- Operator-console evidence for completed run summaries, claim-level drilldown,
unsupported filters, payment evidence, and lifecycle timing.
Start here:
CMS-0057-F
CloudHealthOffice includes documentation and implementation surfaces for the CMS
Interoperability and Prior Authorization Final Rule. Use the canonical capability ledger for reconciled implementation status; the
readiness matrix adds requirement and deployment context.
Da Vinci Interoperability
Separate from the internal CMS-0057-F acceptance suite, the interoperability
harness runs CHO as the provider-side client against independent HL7 Da Vinci
reference payer implementations running in their own containers, pinned by image
digest. Today it shows a PAS $submit exchange, a CRD CDS Hooks exchange, and a
CRD → DTR chain in which CHO follows the questionnaire canonical the payer itself
returned into that payer's $questionnaire-package. It does not test CHO as the
payer server: no Inferno or reference-implementation run has exercised CHO's own
PAS, CRD or DTR endpoints yet (see the ePA gap matrix §9).
One command starts the pinned dependency, runs the scenario, writes sanitized
evidence to artifacts/interop/, and tears the stack down:
./scripts/interop/run.sh br-payer smoke # PAS $submit (BR-PAS-SUBMIT-001)
./scripts/interop/run.sh br-payer crd # CRD CDS Hooks (BR-CRD-001)
./scripts/interop/run.sh br-payer dtr # DTR $questionnaire-package (BR-DTR-001)
./scripts/interop/run.sh br-payer all # all three
Harness unit tests only — no Docker, no third-party code:
dotnet test tests/DaVinciInterop.Tests --filter Category=DaVinciInteropUnit
External scenarios are opt-in (CHO_INTEROP_ENABLED=1), so an ordinary
dotnet test never downloads or starts third-party code. The two evidence
streams are kept separate: an interoperability result never changes a CMS-0057-F
scenario status.
Quick Start
For the shortest path, use the current quickstart:
git clone https://github.com/aurelianware/cloudhealthoffice.git
cd cloudhealthoffice
docker compose --profile core up -d
curl http://localhost:5001/health/live
Then continue with:
Repository Layout
src/
services/ Microservices: claims, benefits, auth, FHIR, terminology, payment, etc.
engines/ Benefit, fee schedule, NCCI, COB, scrub, risk, encounter, prior-auth engines
portal/ Blazor Server operations portal
site/ Marketing and documentation website
fhir/ FHIR resources, projections, and conformance work
docs/
architecture/ Platform architecture and component guides
benchmarks/ Million Claim Challenge methodology and reproducibility
compliance/ CMS-0057-F and regulatory readiness
deployment/ Local, Docker, Kubernetes, and cloud deployment
domain/ Healthcare payer domain primers
developer/ Contributor and engineering onboarding
tests/ Unit, integration, and service-level test projects
Documentation Index
Contributing
CloudHealthOffice needs contributors who care about healthcare correctness,
operability, reproducibility, and privacy. Good first contributions include
documentation improvements, benchmark reproducibility notes, test coverage,
developer-experience fixes, and clearly scoped service bugs.
Never include PHI, production credentials, real patient data, real member data,
or real claim data in issues, discussions, examples, logs, screenshots, tests, or
pull requests.
Community
- Ask questions in GitHub Discussions.
- Report bugs with the GitHub issue templates.
- Report security vulnerabilities privately; see SECURITY.md.
- Propose roadmap or architecture changes through an issue or ADR.
Roadmap
The public roadmap is maintained in docs/roadmap/README.md
and separates implemented functionality, current work, next steps, future work,
and stretch goals. Planned capabilities are intentionally labeled as planned.
Status Notes
CloudHealthOffice is an active platform repository, not a packaged production
appliance. Some services are more mature than others. Current benchmark evidence
is local Kubernetes evidence, not a production cloud capacity claim. The docs
favor reproducibility and explicit gaps over inflated completeness claims.
