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

Trust Center

Architecture deep-dive

Diagrams for the pilot as it runs today and for the design that is still ahead. Solid outlines run in the pilot; dashed outlines are designed and not built.

1. The pilot as built

Pilot architectureClients (Windows app and tablet browser) connect over HTTPS and secure WebSockets to a cloud hub made of a Worker, one Durable Object per facility and one database with a clinic identifier on every tenant table.ClientsWindows portable appsandboxed, 3 IPC channelsTablet browsersame interfaceCloud hubWorkerroutes, auth, policyDurable Objectone per facility:live fan-out, timersDatabase (SQLite)clinic_id on everytenant tableNot presentHL7 / FHIR / DICOMno live connectionsOn-site servernot startedLedgernot startedIn the pilotDesigned, not builtSimulatedDecision / caution

Diagram: the v0.2.0 pilot. One shared hub serves four synthetic tenants; cross-tenant access was refused in every test.

  • Field-level AES-GCM encryption for national IDs, MFA secrets and registration change history, under a hub secret.
  • Sessions are random 256-bit bearer tokens stored only as hashes, and are revocable.
  • Migrations are additive only, and a unit test forbids dropping or deleting.
  • SQL sits behind one file to ease a later on-site port; only three files are hosting-specific.

2. The designed clinic

Designed clinic architectureA clinic has a closed on-site server holding the operational database, sealed terminals as thin clients, wired printers on a closed loop, an interface engine for external systems, and encrypted sync to a cloud replica and a ledger client.Clinic floorSealed terminalsinput-only thin clientsTabletsalerts, messagingWired printersclosed loopOn-site serverOperational databasethe primary copyInterface engineHL7, FHIR, DICOM, X12Ledger clientqueues writesOutside the clinicCloud replicaencrypted backup copySphere ledgerhashes, consent,audit roots onlyOther clinicssync if profile andconsent allowIn the pilotDesigned, not builtSimulatedDecision / caution

Diagram: the designed small-clinic deployment. Larger sites use multi-node clusters. None of this is built.

  • The on-site database is the operational primary; the cloud copy is an encrypted backup replica. That inversion is what lets the clinic keep working when the cloud is unreachable.
  • Patient records are never written to the ledger, so correction and deletion rights can be honoured where law allows.
  • Sync bundles are signed, hash-chained and encrypted, with gapless sequence numbers and replay protection.

3. Network zones

Network zonesNine zones with deny-by-default flow rules separate egress, management, application, data, ledger, home node, terminals, devices and guests.Edge and controlZ1 EgressmTLS tunnel endZ2 Managementjust-in-time accessZ9 GuestisolatedCoreZ3 ApplicationZ4 DataZ5 Ledgerledger client onlyZ6 Home nodeEndpointsZ7 Terminals802.1X on portsZ8 Devicesvia a device gatewayIn the pilotDesigned, not builtSimulatedDecision / caution

Diagram: the zone model. Flow rules are in the design document; no network has been built to it.

4. Key hierarchy and data protection

Key hierarchyRoot key protects the master key, which protects sphere keys, which protect compartment keys, which protect data encryption keys; destroying keys is how cryptographic erasure works.Root keyHSM or secure elementMaster KEKSphere KEKCompartment KEKData key (DEK)per record setIn the pilotDesigned, not builtSimulatedDecision / caution

Diagram: envelope encryption in the design. Rotation intervals are open; the pilot has one hub key and no rotation.

  • Small sites may use a TPM-sealed or smartcard custody; the large tier calls for an HSM with a validated level still to be confirmed.
  • Erasing a patient means destroying the keys by quorum, writing a tombstone and verifying the data is undecryptable. Whether that counts as erasure is pending legal opinion.

5. Audit, backup and safe degradation

Ledger anchoringAudit entries are hash-chained per node, batched into a tree, and the batch root is anchored to the ledger so later tampering is detectable.Audit entriesBatch treeBatch rootLedger anchorIn the pilotDesigned, not builtSimulatedDecision / caution

Diagram: designed. The pilot has a hash chain and a verify button but no batching or anchor.

Backup pattern 3-2-1-1-0Three copies, on two media, one off-site, one immutable or offline, and zero verification errors, with each backup range hashed and anchored.3 copies2 media1 off-site1 immutableor offline0 errorsverified restoresIn the pilotDesigned, not builtSimulatedDecision / caution

Diagram: the pattern. There is no backup in the pilot.

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

The safe-degradation ladder, from normal operation down to full local-only. A design proposal; thresholds are open.

6. Transfer, limiter and the parts we cannot yet vouch for

Three-stream transferServer-to-server clinical transfer is authorised by a ledger transaction, then split across three simultaneous streams with decoy traffic and secret sharing so no single stream carries decryptable content.Authority record +ledger transactionSplit intothree streamsDecoys + secretsharingReassemble andverify commitmentIn the pilotDesigned, not builtSimulatedDecision / caution

Diagram: designed. Key exchange is hybrid classical and post-quantum in the design, and is not implemented or independently evaluated.

Least mature parts

The analog timing layer, camera-resistant screens and sealed terminals are untested hardware ideas. The design’s own goal is “unharvestable, not unhackable”, and we make no claim about their effectiveness. The read limiter’s window lengths and quotas, the scroll-lock threshold and the multi-key threshold are open decisions.

Read the security whitepaper · Security answers in the help center

Walk through the architecture with us

We will show what runs today and what is still a plan.

Request a demo
See the synthetic-data demo first.Request a demo