The audit trail

This page is for registered managers and coordinators. It covers what the audit trail records, how to open it, how to read a line, and what makes it tamper-evident.

What is recorded

Every change to a care record and every look at one.

Changes. When a record is created, the line lists what it was created with. When it is changed, the line lists exactly which fields moved and from what to what. A save that changed nothing writes nothing. Removing a record and restoring one are both their own lines.

Reads. Opening a client, a visit, a care plan, a medication or an incident writes a line. So does opening a list of care records: the clients list, the incident log, the rota, timesheets, the reports, the alerts inbox, even the audit trail itself. A list line carries the filter that was on screen, so it says which records were on the page, not just that a page was opened.

Corrections. Amending a delivered visit, voiding a medication answer, or closing, reopening or editing a closed incident all write a line carrying the reason that was required at the time.

What a line carries

• Who. The person’s account name and photo. If their account is gone, the line reads “Former colleague” rather than nothing. Where the platform acted by itself, for example the overnight rota generator or an automatic alert, the actor reads “The platform”.
• When. To the second.
• What it was about, and what that record was called at the time. The name is frozen into the line rather than looked up now, so a line about a client whose name has since changed still reads correctly, and still reads correctly after the record itself is destroyed.
• What moved, as before and after values.

Opening the trail

Go to Settings, then Audit trail. Owners, admins, registered managers and an inspector; the office and support workers are not offered it.

The page is headed Audit trail, with “Every change to a care record, and every look at one” underneath, and the newest line first.

Four filters:

• A date range, with presets for the last 7 days, the last 4 weeks, this month, a custom range, and all time. All time is the default, because the first question rarely has a date on it.
• Search, which matches what a record was called.
• What happened: created, updated, removed, restored or viewed.
• About: client, visit, visit worker, person, leave, org holiday, care plan, medication, med administration or incident.

Export CSV downloads exactly the lines your filters have selected. Exporting is itself a line in the trail.

Reading a line

Each row is a sentence, not a field dump. For example: somebody added a client, somebody opened a client, somebody changed a client’s phone number from one value to another, somebody viewed the incident log, somebody recorded a dose as given, somebody amended a visit with a reason, or the platform raised an alert.

Names in the sentence are links, so you can go from the trail to the record and back. If the record no longer exists, the name reads as plain text rather than a link that would go nowhere.

Press Details on a row to see the full before and after: the old value struck through, the new value after it.

The page refreshes itself every half minute, because the trail grows on reads too and nothing you do would otherwise tell the page to look again.

One client’s timeline

To read the trail for one person rather than the whole organisation, open the client and choose the Timeline tab. It shows every change to that person’s record and every time it was opened, newest first, paged with Newer and Older.

The timeline reaches everything that hangs off the client, not just the client row: their care plan and its tasks, medication, absences, care team, incidents, care schedules, their visits, who was seated on them, doses and checklist ticks. Removed entries are included.

The Timeline card is shown to those who read the trail: coordinators and an inspector. Support workers do not see the tab.

Why it cannot be edited

Three separate walls, so getting past one is not enough:

1. The platform itself refuses to update or delete an audit line. There is no code path that does it.
2. The database refuses too, with its own rules, so a line cannot be changed even by something writing to the database directly.
3. Each line is sealed against the line before it, per organisation. Change or remove any line and every seal after it stops matching.

The third is what makes the trail tamper-evident rather than merely append-only: an administrator with database access can still be caught. A command walks the chain and reports any break. Run it after restoring from a backup and before an inspection.

A break is an incident to be investigated and reported, not a thing to fix. Do not try to repair the seals.