Audit logging

In one line

An application log helps you debug. An audit log answers a question a patient, a regulator, or a court will ask: "who accessed my record, when, and why?" They are different artefacts with different rules, and conflating them is the mistake.

Why health is different

In most software, logs are for engineers. In health, the audit log is a legal instrument and sometimes the central evidence in a case.

The scenario is concrete and common: a patient is a public figure, or a staff member, or the ex-partner of someone who works there. They ask: who has opened my file? You must be able to answer, precisely, months later. Hospitals have dismissed staff on exactly this evidence, and those dismissals have survived tribunals because the log was good.

That's why read access is auditable in health and almost nowhere else. Your bank doesn't log every clerk who glanced at your balance. A hospital must log every clinician who opened a chart — because in health, looking is the violation. Nothing was changed. Nothing was stolen. The snooping is the harm.

What a real audit entry holds

• Who — an individual, not a shared account. wardnurse destroys the whole thing.
• What — which patient, which resource, and whether it was read or written.
• When — a trustworthy, synchronised timestamp.
• Where — workstation, IP, ward.
• Why — the purpose, and for break-glass the stated reason.
• Result — allowed or denied. Denied attempts matter enormously and are usually dropped.

FHIR AuditEvent models this, and IHE's ATNA profile is the interoperable pattern for shipping audit records to a central repository — which matters, because an audit log stored only on the machine that produced it is worth very little.

The rules that make it evidence

Append-only. If it can be edited, it proves nothing. In an insider case, the first thing a motivated person modifies is the log.

Separate from the thing it audits. An admin who can alter the database must not be able to alter its audit trail. Different store, different credentials, different privileges. Otherwise your log records only what your most powerful attacker permitted it to.

Synchronised clocks. Reconstructing a sequence across three systems whose clocks disagree by minutes is how a timeline becomes an argument. NTP is a security control here.

Retained for the legal period. Which is years — usually longer than your infrastructure lives. Plan for the log outliving the system.

Never log the payload. This is the one that bites: an audit entry recording that the psychiatric note was read is correct. One recording the note itself has just created a second copy of the sensitive data, in a system with weaker controls, retained longer. Log the reference, never the content.

The uncomfortable truth

Most audit logs are written and never read.

They are collected diligently, stored expensively, and consulted only after an incident — by which point you're reconstructing, not preventing. The log satisfied the auditor and protected nobody.

The mature version is proactive review: automated flags for the patterns that indicate snooping — a clinician accessing a patient with no care relationship, someone sharing a surname with the accessing user, access to a VIP record, a burst of records opened in sequence, activity at 3am from a ward the person doesn't work on.

That's a small amount of SQL over data you already have, and almost nobody runs it. It's the single highest-value security work available in most hospitals.

The India note

Under DPDP, for any access you should be able to name the consent artefact that permitted it and the purpose claimed. That makes the audit log the practical bridge between the consent architecture and reality — consent without an audit trail is a promise; consent with one is a control you can demonstrate.