What this is, and who it is for
The audit trail is the record of what happened in the system: who did what, to which record, when, from what value to what value and why. It is written by the system in the same transaction as the change it describes, cannot be edited, and is protected by a hash chain that makes any insertion, removal or alteration detectable. This page is how to read it, filter it, export it and check that it is intact.
| You need | To |
|---|---|
audit.read | Read the study's trail (a site person reads their own site) |
audit.verify (Auditor, Organization Admin) | Run the chain verification |
export.run | Export the whole trail |
org.audit.read (Organization Admin) | Read the organization's own trail (Review organization access and audit) |
Held by: Organization Admin, Project Manager, Clinical Research Associate, Data Manager, Medical Officer, Sponsor Manager, Auditor, Principal Investigator, Clinical Research Coordinator, Site Monitor, Clinical Data Coordinator, Regulatory Manager (audit.read).
Held by: Organization Admin, Auditor (audit.verify).
Where to find it
A study has two trails, each its own page, so that test activity is never read beside production's:
- Study → Audit Trail (at the study level): the study's own record: versions and sign-offs, its state, design changes, amendments, study documents.
- Audit Trail inside a workspace (UAT or Live): subjects, records, queries, sites, deviations, the workspace's team.
What you can do
- Read. Tiles show the number of Events, Signed events, events Today (since midnight) and in the Past hour; the counts come from the server, not from the page. Below them, the events newest first, a page at a time.
- Filter by event type, by person (actor), by participant, by time window, and whether to show the access, sign-in and system events too (access decisions and refusals, sign-ins, and system events), which are hidden by default. The raw record of each change request is never listed here.
- Open an event for its detail: the record, the person, the time, the earlier and the new value with the reason, the signature if there is one, and its place in the chain.
- Verify the chain. Walk the audit hash chains and confirm no event has been inserted, removed or altered: the Verify chain integrity button (for the Auditor and the Organization Admin) walks every chain of the organization and reports valid or the point at which a chain breaks. The result is shown beside the count it vouches for and in each event's detail.
- Export the whole trail (Export CSV (whole trail)), as the audit part of a package; it appears in the study's Exports when ready (Export data).
- In a closed UAT cycle's view, the trail is narrowed to the dates of the cycle, and says so.
- Exports the whole trail as a CSV file.
Every option
What an event is
Every event has a type (form.field_modified, query.raised, study.state.changed and so on; all of them are on Audit events), a time, the person (or system), the study and, where it applies, the site, participant, visit, form and field. A change to a value carries the earlier value, the new value and the reason. A signature carries its meaning and the signer. The wording of each type on the screen is the one used in that page.
What the chain gives
Each event is chained to the one before it by a hash, in a sequence kept in the database, and the chain is anchored outside the table. The platform walks it periodically and alerts the operator if it no longer verifies; the Auditor can walk it on demand. A failure names where it breaks; it does not say who caused it.
Reading by role
- Auditor: reads everything of the study and verifies the chain; changes nothing.
- Data manager, monitors: read to follow a correction or a query.
- Site staff: their own site only.
What the system records
Reading the trail leaves no entry: the audit trail records changes, sign-ins, signatures, locks and refusals, not reads. Exporting the trail is an export and is recorded as one (export.requested, export.completed, export.downloaded), and a refused attempt to read it is recorded as an access decision (authz.decision). See Audit events.
What you cannot do, and why
- Edit or delete an event. The application cannot update or delete an event; the table refuses it.
- Hide a change. A change and its event commit together or not at all.
- Read another study's or organization's trail.
- See UAT and Live in one list.
- Prove that a change was right. The trail shows what was done, by whom, and why they said they did it.
Compliance Q&A
Yes. Every change writes an event in the same transaction, with the person, the server's time, the earlier and new value and the reason; events cannot be updated or deleted; they are chained, and the chain can be verified on demand and is checked by the platform.
Evidence: server/src/modules/platform/audit and shared/audit (events written in the change's transactionappend-onlyhash chainchain verification)audit events form.field_modified and others
Yes. It can be read and filtered on screen and exported whole as CSV (or as a part of an Excel or ODM-XML package).
Limits: a database administrator with access to the database host is outside the application's protection; the hosting controls cover that (Security and hosting).
Evidence: client StudyAuditTrail (filters, export CSV whole trail)server exports package part audit (needs audit.read)
Related
Audit events · Review organization access and audit · Export data · Audit trail and evidence · Auditor