The question behind the term
Ordinary logs answer operational questions; an audit trail answers who accessed or changed sensitive state under which authority. Copying patient content or secrets into either system creates a second uncontrolled disclosure surface.
A reviewable approach
Record opaque resource references, actor, purpose, policy decision, outcome, time and correlation. Append evidence before returning a sensitive result, prevent normal runtime mutation and verify each tenant’s sequence and integrity chain.
- Minimize the event body
- Audit denied and successful sensitive actions
- Separate audit reader from application runtime
- Define corrections as new entries
The boundary to keep visible
A hash chain is tamper-evident, not tamper-proof. Database owners can replace state unless checkpoints, access separation, backups and independent reconciliation extend the boundary.
Design the evidence event before the dashboard
For a sensitive read or change, record an actor reference, verified role and tenant context, action, opaque resource reference, decision, outcome, time and correlation ID. Record denied attempts as well as successful actions when they matter to the review. Do not copy a patient narrative, password, message body or secret into the event merely to make a log more searchable.
An audit entry should be attributable and ordered within a stated scope. A correction belongs in a new event, preserving the original and the reason for change. Verify that an ordinary application runtime cannot rewrite earlier entries; then test what an administrator or database owner could still replace. Hash chaining helps detect some changes but does not by itself stop a privileged actor from replacing the chain and its starting point.
References and further reading
Frequently asked questions
Does a hash chain make an audit trail tamper-proof?
No. It can make changes detectable within its verified scope. Independent checkpoints, privilege separation and restore tests are needed to extend that evidence boundary.