What an audit trail is
The audit trail records events affecting a study and its data. A useful record carries at least five elements: the author, the action, the object, the timestamp, and — for a change — the value before and after.
Its function is not surveillance of people. It is to make it possible, months later, to answer a precise question: "did this value change after the freeze, and if so, why?" Without a log that question has no answer; with a modifiable log it has one that proves nothing.
What it must cover
- Creation and modification of any data value.
- Structural changes: adding, removing or redefining a variable.
- Study state changes: protocol lock, database freeze, reopening.
- Access and exports, with their scope.
- Human decisions resolving an ambiguity, with their justification.
ALCOA+: the reference criteria
The ALCOA acronym, extended to ALCOA+, summarises the properties expected of data under good practice. It is not a standard in the strict sense but a widely reused grid, including outside regulated settings.
| Property | What it requires | What defeats it |
|---|---|---|
| Attributable | It is known who produced the data | An account shared between several people |
| Legible | The data stays readable over time | An abandoned proprietary format |
| Contemporaneous | It is recorded at the time of the fact | Undisclosed retrospective entry |
| Original | The source is reachable, not a copy | A value retyped from a printout |
| Accurate | It matches what was observed | An untraced unit conversion |
| + Complete | Nothing was silently removed | A row deleted without trace |
| + Consistent | Event ordering is preserved | Timestamps that contradict each other |
| + Enduring | It outlives the project | A file on a departed resident's laptop |
| + Available | It can be produced on demand | No export possible without the vendor |
Why a modifiable log proves nothing
This is the point most discussions miss. A log is one more record in the system. If whoever can change a value can also change the log line describing that change, the log demonstrates nothing: it documents only the changes its author was willing to leave behind.
The classical remedy in computing is hash-chaining. Each log event is sealed by a cryptographic digest computed over the event content and the digest of the previous event. The events then form a chain: altering a past entry changes its digest, breaking the correspondence with every entry that follows.
That is the difference between "we changed nothing" — an assertion — and "here is an intact chain" — a verification.
Designing a useful audit trail
Record the reason, not only the fact
A log saying "value changed from 12 to 14" is complete and useless. A log saying "value changed from 12 to 14 — review of the 3 March report, the initial score had been entered from the wrong work-up" answers the question someone will ask.
Distinguish correction from update
Fixing a data entry error and recording a new measurement are two different acts producing the same change of value. Conflating them makes the log unreadable at the moment it would be useful.
Do not log the data itself
A log copying direct patient identifiers into every event creates a second personal-data store, often less protected than the first. The right granularity is the record's internal identifier, not its identifying content.
Make verification reachable
A chain that only its vendor can verify is barely better than an assertion. Verification must be exposed to the user, and its result legible without cryptographic expertise.
How AnzarSeha addresses it
AnzarSeha's log is hash-chained: each event is sealed by the digest of the previous one, and the state of the chain is displayed as a state of the study, not as an administration option.
- Every action carries its author, timestamp, object and — for decisions — its written justification.
- Protocol lock and database freeze are log events, dated and signed.
- Reopening a frozen database requires a stated reason, which is kept — reopening is not forbidden, it is expensive in traces.
- Chain integrity is recomputed and displayed; a break is visible without having to look for it.
- The log travels with the export, so whoever receives the dataset also receives its history.
What the audit trail does not do
- It does not validate the data: see data quality.
- It does not say where a value came from, only what happened to it: see provenance.
- It does not replace a backup: an intact log of a lost database restores nothing.
- It confers no compliance in itself. No log makes a study compliant; it only makes what was done verifiable.
Frequent questions
Is an audit trail needed for a retrospective record-based study?
Nothing requires it by regulation outside a trial setting. It stays useful for a practical reason: a retrospective study is built through back-and-forth between the record and the database, and that is precisely where values change without anyone remembering.
Is an audit trail enough to make a study GDPR-compliant?
No. Access logging is one of the expected measures, but compliance also rests on the lawful basis for processing, minimisation, informing data subjects and retention periods. The log is one element, not the proof.
What happens if the chain breaks?
The break is displayed and points to the link concerned. It does not destroy data: it signals that a past event no longer matches what was sealed, and that the discrepancy must be explained before publication.
Can a spreadsheet keep an audit trail?
The version history of an online spreadsheet records changes, which is already something. It carries no reason, no distinction between correction and update, and no sealing — and it is editable by anyone who can edit the file. See the spreadsheet comparison.