AuroraMed v0.2.0 is a synthetic-data pilot. See exactly what's built →

Trust Center

Architecture: pilot versus design

The pilot runs in the cloud. The designed system adds an on-site server, a ledger of hashes and a ladder of safe degradation. The diagram marks which is which.

AuroraMed target architecture Clinic with sealed terminals connected to a closed on-site server. The server sends encrypted, signed backup bundles to cloud storage. Only hashes, consent records and audit records are written to a federated ledger. Everything shown is the design; the current pilot runs on a cloud hub. CLINIC (closed on-site loop) live feed live feed live feed Sealed thin-client terminals and tablets: no local patient data On-site server (one cabinet) Patient records · app tier · interface engine Local database = operational primary Audit chain · policy decisions · key custody DESIGNED · not yet built Wired printerno network print path Local backup DBsyncable replica Clinic supplies its own power and internet. Offline: the server keeps care running, including printing. encrypted, signed bundles Cloud backup hubStores ciphertext; clinic-to-clinic sync where allowedRead-side limiter trip pauses sync only, never care hashes · consent · audit only Federated ledger (spheres)One sphere per clinic or network; bridges between spheresPatient records are never written here Today: pilot cloud hubWorker + Durable Object per facility + D1 databaseSynthetic data only · v0.2.0IN THE PILOT

Solid elements run in the pilot. Dashed elements are designed and not built.

The pilot Pilot

  • Electron client and a tablet web build, over HTTPS and secure WebSockets.
  • A Cloudflare Worker with one Durable Object per facility for live fan-out and timers.
  • One database with a clinic identifier on every tenant table (test-enforced).
  • Additive-only migrations. Plain SQL behind one file to ease a later on-site port.

The design Designed

  • A closed on-site server per clinic, cabinet-sized for small sites.
  • A federated ledger per clinic or network holding only hashes, consent and audit events.
  • Three backup copies on two media with one offsite and one offline; verified restores.
  • Server-to-server transfer in three streams with hybrid post-quantum key exchange.

Safe degradation ladder

From normal operation down to full local-only. A design proposal. Thresholds are open decisions.

Safe-mode ladder (design)Six levels from normal operation to total site loss. At each level care continues locally as far as possible; cross-site features are reduced first. L0 NormalEverything available L1 WAN downFull local care; sync and ledger writes queue; cross-site transfers wait L2 Ledger downLocal care and local audit chain; high-risk actions need manual multi-person approval L3 Server partialRemaining node carries care; less critical modules go read-mostly L4 Server downDowntime mode: read-only emergency data set, paper forms, back-entry later L5 Site lostAlternate site with restored replica; paper until restored

Not met today

The specification requires local operation without the network. The pilot is cloud-only, and a network outage stops alerts and messaging. This is a known defect, not fixed.

Architecture questions?

The help center has answers to the hard ones.

Search the help center
See the synthetic-data demo first.Request a demo