ZKELETON
// Architecture

Two systems. Two sources. Two purposes. Zero new connections.

Zkeleton is an isolated environment inside the payer's VPC. It reads the same CMS-0057 clinical data the compliance pipe receives, and produces a unified clinical dataset merged with the payer's own claims, member, and authorization history. The compliance pipe is untouched. The core is untouched.


YOUR VPCCMS-0057clinical exchangeCompliance pipeyour existing build→ adjudication, MLR, auditZKELETON BUBBLENormalize → Match → Merge+ claims + member + auth historyvalue returnsIntelligencepayer teamszero new connections

Flow 1 · not Zkeleton

Compliance

Clinical data from the CMS-0057 exchange lands in the payer's existing claims system for prior authorization and adjudication. Legally required. Zkeleton has no connection to this flow.

Flow 2 · Zkeleton

Your environment

The same clinical data is read in parallel into Zkeleton's private bubble. Inside the bubble, it merges with the payer's own claims history, member records, and authorization history to produce a unified clinical dataset the payer controls.


Stages

What happens inside the bubble.

.01

Parallel read

Zkeleton subscribes to the same CMS-0057 clinical data stream the compliance pipe consumes. No new external data sources. No new data rights. The payer's compliance build is untouched.

.02

Normalize

Incoming clinical resources are normalized against a common FHIR R4 schema. Coding systems are reconciled. Data types are validated. The output is a consistent, queryable representation of the inbound stream.

.03

Member match

Each clinical record is probabilistically matched to a member in the payer's existing roster. Match confidence is preserved on every record. Unmatched records are flagged, not discarded.

.04

Merge with history

Matched clinical data joins the payer's own claims, member, and authorization history inside the bubble. The result is a single longitudinal dataset per member that the payer has not been able to assemble inside the core.

.05

Intelligence out, data in

Payer teams query the merged dataset from inside the bubble. Results, signals, and models leave the bubble through controlled egress. Raw clinical data does not.

.06

The environment opens

With the unified dataset in place, the bubble hosts work beyond your own teams: governed exports, resident workloads, evidence studies, coverage proof. Same gate, same audit, your terms.


// The environment opens

The bubble is the beginning, not the end.

Once the unified dataset exists behind the gate, the environment becomes a place others come to work, on your terms, at your pace, with every byte logged. Existing vendors receive governed exports instead of opaque extracts. New workloads bring their compute to your data instead of taking your data to their cloud. Nothing about the containment story changes: raw data stays inside, intelligence leaves, and you see all of it.

What your environment can host, simplified viewThe Zkeleton environment sits inside a gated boundary with audit ticks at every port. Below it, four relationships: existing vendors receive a governed export, resident workloads bring compute in and send results out, evidence studies send queries in and receive aggregates out, coverage proof brings consented data in and proof out.YOUR ENVIRONMENTZKELETONgoverned exportcompute inresults// EXISTINGVENDORS// RESIDENTWORKLOADSqueriesaggregatesconsented dataproof// EVIDENCESTUDIES// COVERAGEPROOF

Boundaries

What Zkeleton does not do.

  • Not a compliance suite. Payers build their own CMS-0057 pipes. Zkeleton runs in parallel.
  • Not claims adjudication. No connection to the core claims system. No influence on payment.
  • Not an AI model. Payers bring their own models. The bubble is a safe environment to run them on unified data.
  • Not shared infrastructure. Each payer gets an isolated bubble inside their own VPC. No vendor cloud aggregating clinical data.