Deployment & Operating Models — How Cloud Health Office Runs

Four models

One platform, several ways to run it.

Health plans differ on infrastructure ownership, cloud governance, internal engineering capacity, vendor-management policy, and how much operational control they intend to keep. Cloud Health Office is designed to adapt to those requirements rather than force a single model on every payer.

Payer-controlled cloud deployment

Available

Cloud Health Office is deployed into the health plan's own approved Azure, AWS, or GCP environment. PHI stays inside the plan's boundary and the plan owns the environment and the data permanently. This is the model the public repository, Helm charts, and deployment documentation support today.

Infrastructure: Owned by the health plan — subscription, network, and data.
App operations: Typically the plan's platform team, with implementation support available.
Integrations: Run inside the plan's network to the core, clearinghouse, and identity provider.
Engineering: A cloud platform capability the plan already runs; Kubernetes familiarity helps.
Security review: The plan's own review, against source it can read before signing anything.
Planning: Landing zone, private networking, identity, secrets, observability, and backup.

Payer-controlled does not mean the plan is on its own: Aurelianware can help plan, deploy, and operate inside an environment the plan owns.

Aurelianware-managed deployment

By engagement

Cloud Health Office is deployed into a payer-controlled or otherwise agreed cloud environment while Aurelianware provides some or all of the operational support. What Aurelianware operates is written down per engagement rather than assumed.

Infrastructure: Usually the health plan's cloud account, or another environment both parties agree.
App operations: Aurelianware, to the extent the engagement defines.
Integrations: Jointly designed; connectivity and credentials remain under the plan's control.
Engineering: Lower internal capacity required than a self-operated deployment.
Security review: Access model, privileged operations, and audit logging agreed before access is granted.
Planning: Deployment automation, upgrades, monitoring configuration, release coordination, incident support, environment management.

Scope, responsibilities, and support hours are defined per engagement. This is not a published managed-service package with standard service levels.

Hybrid / shared-responsibility operation

By engagement

A split model for plans that want to keep control of the perimeter while handing application operations to the people who build the software. This is a possible operating pattern, shaped to the plan, not a fixed package.

Infrastructure: The health plan owns the cloud account and the network.
App operations: Aurelianware manages application deployment, releases, and troubleshooting.
Identity & policy: The health plan controls identity, access, and security policy.
Adjacent systems: Implementation partners or incumbent vendors own the systems they already own.
Security review: Boundary of responsibility documented so incidents have a clear owner.
Planning: A responsibility matrix agreed up front, covering releases, monitoring, and escalation.

SaaS operated by Aurelianware

Under evaluation

A software-as-a-service model operated by Aurelianware would suit organizations that want to minimize infrastructure ownership. It is under evaluation and is not offered today. Nothing here should be read as a commitment to availability, timing, or terms.

Infrastructure: Would be operated by Aurelianware.
App operations: Would be operated by Aurelianware.
Open questions: Data residency, tenant isolation enforcement, BAA terms, and security attestations are exactly the questions being worked.
Today: Plans that want minimal infrastructure ownership should talk to us about the managed or hybrid models above.

Free local evaluation is available in every case. Clone the repository and run Cloud Health Office on local Docker Desktop Kubernetes, read the source, walk the First Claim journey, and reproduce the Million Claim Challenge. No license is required to evaluate. Local quickstart →

Decision framework

Comparing the models on the dimensions that actually decide it.

The right operating model depends on your organization's cloud standards, security requirements, engineering capacity, procurement process, and desired level of operational control. A payer-controlled deployment is not automatically simpler, and a hosted model is not automatically better.

Typical ownership by operating model
Dimension	Payer-controlled cloud	Aurelianware-managed	Hybrid / shared	Hosted SaaS (under evaluation)
Infrastructure ownership	Health plan	Health plan or agreed environment	Health plan	Aurelianware (proposed)
Operational responsibility	Health plan	Aurelianware, per engagement	Split, per responsibility matrix	Aurelianware (proposed)
Cloud governance	Plan's existing standards apply directly	Plan's standards, with agreed vendor access	Plan's standards at the perimeter	Vendor governance, subject to review
Integration control	Health plan	Jointly designed	Jointly designed	Contractual, over defined interfaces
Release management	Health plan schedules upgrades	Aurelianware coordinates with the plan	Aurelianware proposes, plan approves	Vendor release cadence (proposed)
Security review	Source and environment both reviewable	Source reviewable; vendor access reviewed	Source reviewable; boundary reviewed	Would require vendor attestations
Observability	Plan-owned telemetry stack	Configured by Aurelianware into the plan's stack	Shared dashboards, plan-owned data	Vendor-provided (proposed)
Support model	Plan's team, with support engagement optional	Aurelianware incident support, per engagement	Split by responsibility matrix	Vendor support (proposed)
Procurement complexity	License plus internal cloud spend	License plus services agreement	License plus scoped services agreement	Subscription plus BAA (proposed)
Internal engineering required	Highest	Lower	Moderate	Lowest (proposed)
Data & network boundary	Entirely inside the plan's boundary	Inside the plan's boundary, vendor-operated	Inside the plan's boundary, split operations	Crosses into a vendor boundary

“Proposed” entries describe how a hosted model would be structured if it is offered. They are design intent under evaluation, not a description of something a payer can buy today.

Before you choose

Questions worth answering first.

These are the questions that decide the operating model in practice. Working through them is a normal part of an implementation or deployment-planning engagement.

Security & governance

Who is allowed to hold privileged access?

Whether a vendor may hold operational credentials in your environment, under what logging, and with what break-glass procedure, usually decides between self-operated and managed models before any technical factor does.

Data

Where must the data live, and who may see it?

Data residency, tenant isolation, encryption key ownership, and BAA terms shape which models are even reviewable by your security and compliance teams.

Capacity

Does your platform team have room for another workload?

A plan with a mature Kubernetes practice and spare capacity should probably operate it. A plan without one should not pretend otherwise — that is what the managed and hybrid models are for.

Network

How will this reach the core and the clearinghouse?

Private endpoints, on-premises connectivity, and clearinghouse routing determine where the software has to sit far more than any preference about hosting does.

Operations

Who is paged at 2 a.m., and for what?

Incident ownership, escalation, and the boundary between application and infrastructure failures should be written down before go-live, not discovered during one.

Procurement

What can your procurement process actually execute?

A model that your vendor-management policy cannot approve is not an option, however good the architecture is. It is better to find that out in week one.

Discuss the right operating model → Implementation services Trust & security

License

Source-available, licensed for production.

Source-available under BSL 1.1. Evaluate and run locally for free. Production use requires a license. Deploy in your cloud or as a managed tenant.

The CMS-0057-F API implementations ship in the repository. Implementation, core mapping, prior-auth workflow, and Platform Engagement (claims / payments / core replacement) are paid.

Commercial licensing →

What “production” means today

Cloud Health Office is ready to deploy in your cloud as a compliance layer beside QNXT, Facets, or HealthEdge. The first production tenant is under discussion; the evidence and source are already public.

First production deployment terms

Terms for an early production tenant.

A production Layer 1 deploy in your cloud is a low-friction entry. For an early production tenant, license terms can be waived — in exchange for engineering partnership and a reference.

Terms

Waived platform license

Platform license terms can be waived for the first production tenant. You still own your cloud environment and your data permanently.

Terms

Direct engineer access

Work side by side with the engineers building the platform while you deploy the CMS-0057-F surface and map it to your core.

Terms

Reference partnership

In return, we ask to reference the deployment. Implementation, core mapping, and Platform Engagement remain scoped, paid work.

Deployment is a conversation, not a checkbox.

Tell us how your organization runs cloud workloads and we will tell you which model actually fits.

Discuss the right operating model → Get the evaluator pack Explore Professional Services

Please do not send PHI, member data, claim data, production credentials, or other sensitive production information through the contact form.