How to Secure PHI in a Healthcare Application: Encryption, Access Control, Audit Logs and Data Isolation

Whole-database encryption at rest (via managed, provider-native encryption) is table stakes, not the interesting decision. The real question is whether specific highly sensitive fields (SSNs, certain behavioral health or substance use data with extra legal protection, payment information) warrant field-level encryption on top of that - an additional layer that protects the specific field even if broader database access is somehow compromised, at the cost of added complexity for querying and indexing that field. Make this decision field by field, based on sensitivity and legal requirements, not as a blanket policy in either direction.

Access control should default new roles to minimum necessary access, with elevated access as an explicit, logged, and ideally time-bound action rather than a standing default - the principle of least privilege only works if it's the default, not something added after the fact. Enforce this at the application layer and, where the database supports it, reinforce it structurally (row-level security policies that make it difficult to accidentally query across a boundary you shouldn't, rather than relying solely on every application code path remembering to filter correctly).

Logging that PHI was accessed isn't enough if the logs aren't practically queryable - a common real gap is teams that log every access event but have no efficient way to answer 'who has viewed this specific patient's record in the last 90 days' during an actual security review or incident, because the logs were designed for storage, not for being queried under time pressure. Design audit logging with the actual questions a security review or incident response will need to ask, and validate that those queries are fast and practical before you need them under pressure, not after.

For a platform serving multiple healthcare organizations, tenant isolation is its own distinct access control problem, separate from user-level RBAC - every query touching PHI needs to be scoped to the correct tenant, ideally enforced structurally (database-level row-level security keyed to tenant ID) rather than relying on every engineer remembering to add a tenant filter to every query. A single missed tenant filter in one code path is a cross-customer PHI exposure, which is a categorically more serious failure than a single user seeing data outside their own role - this is worth the extra structural enforcement effort.