Why does health data access emphasise auditing over prevention, and what does that require architecturally?
Show the full answer Hide the answer
What is being tested
Whether you understand an inversion of the usual security posture, and its architectural consequences.
Why the inversion
Blocking access can cost a life. A clinician treating an unconscious patient must be able to see their record even without a pre-existing relationship. An access control strict enough to prevent all inappropriate access will also prevent some necessary access.
So the emphasis shifts to deterrence and accountability: access is permitted, comprehensively logged, and reviewed afterwards, with consequences for inappropriate use.
Break-glass access is the mechanism — immediate, logged in detail, and reviewed. It must be designed deliberately, because the alternative is clinicians sharing credentials to work around the control, which destroys the audit trail entirely. That is the classic security-usability failure with unusually severe consequences here.
What it requires architecturally
1. Audit logging on the read path, not just on writes. Every access to a record, with who, when, what and where possible why.
This is unusual and it has a real performance and storage cost that must be designed for rather than discovered — a high-read system logging every read is a substantial write workload of its own.
2. Immutable, tamper-evident audit storage, separate from the application's own database, so the application cannot alter it. Patients frequently have a right to see this log.
3. Consent evaluated at the point of access, not checked at collection and forgotten. Consent is granular (this provider, this category), dynamic (it can be withdrawn), and must be a queryable service in the request path — which adds latency to every access.
4. Retention measured in decades, which changes storage, format and migration planning: the data will outlive several generations of technology, and the format must remain readable.
5. Degraded modes as a clinical-safety requirement. A system clinicians depend on has patient-safety implications when unavailable, so offline procedures are not an operational nicety.
The conflict to resolve
Deletion rights against retention obligations, resolved field by field — anonymise identity attributes, retain the clinical record with a pseudonymous reference. Record-level thinking makes it look unresolvable.