Healthcare Data Protection

Definition

Health data carries obligations that differ from other sensitive data in a specific way: access must be permissive enough that care is not obstructed, which shifts the control emphasis from prevention to auditing and accountability.

The distinguishing requirements

Break-glass access. A clinician treating an unconscious patient must be able to see their record even without a pre-existing relationship. Blocking that could cost a life. So the architecture provides emergency access that is immediate, logged in detail, and reviewed afterwards — deterrence and accountability rather than prevention.

This is a genuine inversion of the usual security posture and it must be designed deliberately.

Comprehensive audit. Every access to a record, not just modifications, recorded immutably with who, when, what and — where possible — why. Patients frequently have a right to see this log.

Consent, granular and dynamic. A patient may consent to sharing with one provider and not another, to one category of data and not another, and may withdraw. Consent must be a queryable service consulted at the point of access, not a flag checked at collection.

Safety-critical availability. A system clinicians depend on has patient-safety implications when unavailable. Degraded modes and offline procedures are a clinical-safety requirement, not an operational preference.

Interoperability with standards you do not control, and with legacy systems that cannot change.

The architectural consequences

• Audit logging on the read path, which is unusual and has a real performance and storage cost that must be designed for.
• Consent evaluation in the access path, adding latency to every request.
• Immutable, tamper-evident audit storage, separate from the application's own database.
• Retention measured in decades, which changes storage, format and migration planning — the data will outlive several generations of technology.
• Deletion that conflicts with retention obligations, resolved field by field.

Failure scenarios

• Access controls so strict that clinicians share credentials, which destroys the audit trail entirely — the classic security-usability failure with severe consequences here.
• No break-glass path, so an emergency produces an unlogged workaround.
• Audit logs mutable or stored where the application can alter them.
• Consent checked at collection and never enforced at use.
• No offline or degraded procedure for a system clinicians depend on.

Interview question

"Why does health data access emphasise auditing over prevention, and what does that require architecturally?"