What a Good Audit Log Actually Records

An audit log is one of those features everyone assumes they have until the moment they need it. Then someone asks a specific question, who opened this patient's record last Tuesday, and the honest answer turns out to be we are not sure. A good audit trail is not a box ticked for a policy document. It is a truthful, detailed, tamper-resistant account of what happened in the system, built so that months later it can answer a question nobody thought to ask at the time.

The question an audit log has to answer

Every audit log exists to answer one shape of question: who did what, to which record, when, and from where. That sounds obvious, yet plenty of systems log something far weaker, a vague note that a record was viewed, with no reliable link to a person or a time you can trust. When the question is real, for instance a patient asking who has seen their data or an investigation into a suspected inappropriate access, the vague log is worthless.

A useful entry pins down the specifics. For a single access to a patient record it should capture, at minimum:

• The individual who performed the action, tied to their own account
• The exact action: viewed, created, edited, printed, exported, deleted
• The specific record or field affected, identified by UMR or equivalent
• The timestamp, precise and from a trusted clock
• The context: the device or location, and the session it belonged to

Notice the dependence on individual identity. This is where shared logins quietly poison the whole thing. If several people use one account, every line in the log names that account and none of them names a person. The audit trail is only ever as good as the identities underneath it, which is why individual accounts are a precondition for meaningful auditing, not a separate concern.

Reads matter as much as writes

Many systems dutifully log changes, a record was edited, a result was entered, and ignore reads. That is a serious gap in healthcare, because inappropriate access is usually about looking, not changing. The curious member of staff opening a colleague's record, or a public figure's, does not alter anything. They read. If the log only records writes, that access is invisible.

So a healthcare audit log has to treat viewing as an auditable event. Opening a record is an action worth recording, because the ability to say who has looked at this patient's data is exactly what patients and regulators expect. This is the kind of access tracking that workflows such as NABH lean on, and it is meaningless if reads go unlogged.

If your audit log only shows what changed, it is blind to the most common form of misuse, which is simply looking.

A log you cannot trust is not a log

An audit trail is only evidence if it cannot be quietly altered by the people it might implicate. If a user with enough access can edit or delete log entries, then the log proves nothing, because any incriminating line could have been removed. The integrity of the log is as important as its content.

That leads to a few design properties that separate a real audit trail from a decorative one.

• Append-only: entries are added, never edited or overwritten in place
• Separated from user control: no ordinary clinical or admin role can alter the log
• Retained for a defined period, long enough to be useful when a question arrives late
• Time-trustworthy: timestamps come from a reliable source, not an editable local clock
• Complete: security-relevant events are captured consistently, not selectively

Kōami records access and changes to patient data in an audit log built on these principles, so that the record of what happened is itself protected from casual tampering. The aim is simple to state: when someone finally asks the awkward question, the answer should come from a log that no one had the chance to tidy up first.

Logs are only useful if someone can read them

A perfect log that nobody can search is a filing cabinet nailed shut. The value of the trail is realised only when a person with the right authority can actually interrogate it: show me every access to this UMR in the last month, show me everything this user did on this date, show me who exported data last week. If answering those takes a database engineer and three days, the log will not be used, and unused controls decay.

So the trail needs to be queryable by the people responsible for oversight, with access to the log itself controlled and, ideally, itself audited. There is a neat recursion here: looking at the audit log is an action, and a mature system logs that too, because the people who can see everything are exactly the people whose access most deserves a record. Reviewing the log should be routine, not a thing that only happens after a crisis, because regular review is what turns a passive record into an actual deterrent.

What good looks like in practice

Put it together and a good audit log has a recognisable character. It names people, not shared accounts. It records reads as well as writes. It cannot be quietly edited by those it might expose. It keeps entries long enough to matter and stamps them with a time you can trust. And it can be searched by the right people quickly enough that it actually gets used. None of these on their own is exotic. The failures come from missing one, a log that captures changes but not views, or names accounts but not individuals, or holds rich detail that any admin can rewrite.

The test of an audit trail is never how it looks in a demo. It is the moment, maybe a year later, when a specific and uncomfortable question arrives and the log has to answer it plainly and completely. Build it for that moment, and it will serve every quieter purpose along the way. Build it for the policy checkbox, and it will fail you at exactly the moment it was supposed to help.