Encrypt PHI Per Tenant With Envelope Keys
This is the deepest part of the foundation, and the good news is that nobody has to do anything for it to work. Every piece of protected health information in Veona — a name, a date of birth, a result value, a clinical note, an uploaded document — is encrypted before it is written down, and decrypted only when an authorised request asks for it. The encryption is keyed per facility, so even if someone walked off with the entire database, what they would hold is unreadable jargon, and no facility’s key can ever open another facility’s data. This page explains the model in plain language and shows the few places a person interacts with it.
Who / when: the encryption itself is the System’s job, running on every read and write with no human in the loop. An Administrator meets it only at the edges — confirming the key arrangement when a facility is set up, and (rarely, and very deliberately) rotating a key or off-boarding a tenant.
The words that make the rest make sense:
- PHI — Protected Health Information: the identifying and clinical details about a patient that the law most protects.
- Encryption at rest — the data is stored as ciphertext (scrambled), not plain readable text. A database backup, a stolen disk, or a leaked dump is gibberish without the key.
- Tenant — one facility (or facility group) and all of its data. Each tenant is cryptographically walled off from every other.
- DEK — Data Encryption Key: the single key, unique to your facility, that actually encrypts and decrypts your PHI.
- KEK / master key — Key-Encryption-Key: a higher key, held outside the database (in a key vault), that wraps — encrypts — your DEK so the DEK is never stored in the clear. This wrapping-a-key-with-a-key arrangement is what “envelope encryption” means.
- Key lease — the short window during which your facility’s DEK is unwrapped and held in memory to serve live requests, then expires.
- Crypto-shredding — destroying a facility’s DEK on purpose so that all of its ciphertext becomes permanently unreadable in an instant.
- System — when any authorised request needs your facility’s data (a staff member opens a chart, an analyser pushes a result, a background job runs a report), Veona unwraps your facility’s DEK once from the external key vault and holds it briefly in memory as a lease. Every read and write in that window is decrypted or encrypted with your key, never another facility’s.
- System — when the lease expires (a matter of minutes), the key is dropped from memory and re-authorised from the vault on the next request. Nothing is ever decrypted for an attacker who holds the database but has no live, authorised session — there is no session, so there is no unwrap.
- Administrator — you confirm the key arrangement for your facility under Admin → Settings. Cloud facilities use a Veona-managed per-facility key by default; regulated or enterprise facilities can bring their own key from their own key vault, so that if they revoke it, even Veona can no longer decrypt their data. On-premise installations hold the key on the facility’s own hardware.
- Administrator — to off-board a facility or honour a patient’s right-to-erasure of a whole tenant, the deliberate action is to destroy the key (crypto-shred), which renders that facility’s stored data permanently unrecoverable at once — a clean, provable erasure rather than a slow scrub of every table.
What happens next: with this in place, every other foundation inherits the same protection automatically. Files uploaded through the shared storage module are encrypted with your facility’s key (see Store Encrypted Files Used Everywhere); the audit trail is written under it (see Keep a Tamper-Evident Audit Trail of Patient-Data Actions); and a PDF a patient downloads is rendered fresh on demand from encrypted-at-rest data rather than sitting in a shared file. You never see a key, and you never type one — you simply work, and the protection is always on.