Patient data protected
by design, not by default.
Zdrovia's encryption architecture was designed from first principles — not added as an afterthought. Every record, image, and file is encrypted with the same standard used by governments and financial institutions, with keys held in a dedicated vault that is physically and logically separate from your data.
Every category of patient data — encrypted.
There is no two-tier system where some records are encrypted and others aren't. Every data type — from a quick clinical note to a high-resolution diagnostic image — receives the same AES-256-GCM treatment before storage.
Patient Notes & Treatment Records
Medical Images & Diagnostic Files
Patient Demographics
Consent Forms & Attachments
Clinical Charts & Care Plans
Chart Entries & Annotations
Three layers. Zero plaintext in storage.
The architecture is straightforward to explain, but difficult to circumvent. Data is encrypted before it moves, keys are stored separately from data, and everything lands in Canadian-controlled infrastructure.
Encrypted Before It Moves
Every piece of patient data is encrypted with AES-256-GCM before it leaves your browser or is written to disk. Raw data never touches our storage systems — only ciphertext does.
Keys Held in a Dedicated Vault
Encryption keys are managed by a dedicated key management server — separate from the data they protect. Even if our storage layer were ever compromised, an attacker would have ciphertext with no keys to open it.
Stored Encrypted in Canada
Encrypted files land in Canadian-based object storage. Patient records are partitioned by clinic — your data and another clinic's data can never cross paths, even at the infrastructure level.
From plaintext to protected storage.
Every file traverses this pipeline before a single byte reaches storage. Keys and ciphertext travel separate paths — neither is useful without the other.
Clinical Data
Patient notes, images, forms, chart entries
Generate DEK
Unique 256-bit Data Encryption Key per file
AES-256-GCM
Data encrypted with DEK + random nonce
Key Management Vault
DEK wrapped by master KEK — stored separately from data
BLAKE3 Hash
Cryptographic integrity fingerprint of ciphertext
Assemble Bundle
Wrapped key + ciphertext + BLAKE3 hash combined
Canadian Object Storage
Encrypted bundle stored — no plaintext ever written
Enterprise-grade encryption,
explained plainly.
You don't need to be a cryptographer to understand how your data is protected. Here's exactly what happens under the hood.
Two-Layer Key Architecture
Each file gets its own unique encryption key (a Data Encryption Key, or DEK). That key is itself encrypted by a master Key Encryption Key (KEK) stored in the KMS vault. To decrypt any file, both layers must authenticate — access to storage alone is worthless.
Authenticated Encryption (AES-256-GCM)
We use Galois/Counter Mode — a variant of AES-256 that doesn't just scramble data, it signs it. Any tampering with a stored file is cryptographically detectable before decryption is even attempted.
Per-File Integrity Hashing
After encryption, every file is hashed with BLAKE3 — a cryptographic checksum that lets us detect silent corruption or unexpected modification at any point in storage or transit.
Streaming Encryption for Large Files
Large uploads — imaging studies, video files, bulk exports — are encrypted in 64 KB chunks as they stream through the server. Files never need to be fully loaded into memory, which limits exposure and keeps performance high.
Clinic-Level Key Isolation
Every clinic has its own keyring — a completely separate set of encryption keys. There is no shared encryption state between organizations. A clinic can only decrypt its own data, and key operations are scoped to that clinic's context at the KMS level.
Secure Key Material Cleanup
Encryption key material is zeroed from memory immediately after use using a cryptographic zeroing library. Sensitive bytes don't linger in RAM waiting for a garbage collector — they're gone as soon as the operation completes.
Authentication built for healthcare workflows.
Credentials are handled by a hardened authentication layer that manages session tokens, key rotation, and access validation independently from business logic. Clinicians access only what their role requires. Every session is time-limited, signed, and revocable.
Sessions are cached in a distributed, in-memory store — not on disk — so revocation takes effect immediately across all infrastructure. There is no window between "logged out" and "actually logged out."
Secure Session Management
Sessions are cryptographically signed tokens validated on every request. Active sessions are cached in a distributed in-memory store — lookups are fast and constant-time.
IP & User Agent Binding
Each session records the originating IP and browser fingerprint. Anomalous session use — like a token appearing from a new device — is detectable before damage is done.
Short-Lived Credentials
Session tokens have enforced expiry. There is no such thing as a permanent credential in Zdrovia — tokens rotate, and expired sessions are immediately invalidated server-side.
Cryptographic Key Rotation
The public keys used to verify authentication tokens are fetched and rotated automatically. Stale keys are never trusted; the system refuses to start if it cannot establish a fresh trust anchor.
Patient records never leave Canada.
All patient data is stored on infrastructure physically located in Canada. Records are not routed through, replicated to, or accessible from servers outside the country. This matters for clinics operating under PIPEDA, provincial health privacy legislation, and patients who have a right to know where their most sensitive personal information lives.
Your practice. Your patients' data. Completely protected.
Join clinics already running on Zdrovia and stop worrying about whether your software is taking patient privacy seriously.