Healthcare

Nobody asks about the audit log during a demo

Access control and audit trails are the least demonstrable parts of regulated software — and close to impossible to retrofit convincingly. A note on why they go in first.

In two years of building clinical software, one question has never come up during a demo and has come up in every serious procurement conversation:

Who touched this record, and when?

It is a boring question. It is also the one that decides whether a system can be used at all in a regulated setting, and it is remarkably difficult to answer honestly if nobody asked it at the start.

Why retrofitting doesn’t work

Adding an audit trail late is technically possible. You add a table, you write to it from the places that matter, you build a filter. A week of work, maybe two.

What you cannot add late is the part that matters: completeness.

An audit trail is only worth anything if it is impossible to act without being recorded. That property comes from the shape of the system — every write passing through a path that logs — not from remembering to call a logging function in the right places. Retrofitted logging covers the paths someone thought of. The gap is invisible until an auditor finds it, and by then the honest answer is “we believe it is complete”, which is not an answer.

An audit log that covers most actions is not a partial audit log. It is a system that cannot tell you what happened.

Roles that match the job, not the abstraction

The instinct in early design is to build flexible permissions: granular rights, composable, everything configurable. It feels safer because it forecloses nothing.

In practice it produces a system nobody can reason about. Twenty toggles across eight resources means somebody eventually grants a combination nobody intended, and no one can say with confidence who can currently see what.

The alternative is fewer roles, each mapped to an actual job someone does.

In the pathology system we built, there are four:

  • Doctor — reports on cases, signs results
  • Lab assistant — processes material, records workflow stages
  • Registrar — registers referrals and patients
  • Administrator — manages staff, departments and access

Four roles cover the real organisation. The question “can a lab assistant see this?” has an answer that fits in one sentence, which means it can be verified rather than believed.

The three properties worth building first

Every action is attributable. Not “a record was updated” but “this person updated this record at this time”. Attribution without a person is a log, not an audit trail.

Access is granted by someone accountable. Accounts get created by an administrator who is themselves logged. Nobody appears in the system because they were added to a spreadsheet.

The log is filterable in the way it will actually be queried. By person, by date range. An audit trail you cannot search is a compliance artefact rather than a tool, and when an incident happens the difference is measured in days.

GDPR as a constraint on the data model

The phrase “GDPR compliant” usually describes a document. What matters in engineering terms is narrower and more concrete.

Where does personal data live, and can you enumerate every location? Can you delete a person completely, including from derived tables and backups, without breaking referential integrity? Does an export contain what a subject access request requires and nothing beyond it?

These are data model questions, and they are cheap to answer at design time and expensive afterwards. Deciding after eighteen months that patient identifiers should not have been denormalised into six tables is not a refactor — it is a migration with clinical risk attached.

The part that is genuinely hard

None of this is technically difficult. It is difficult to prioritise, because it is invisible in every conversation where the software is being sold.

A scheduling screen demos well. An audit filter does not. Roles that map cleanly to jobs look like a limitation next to a permission matrix. So the work gets deferred, and deferral is the same as never, because by the time it becomes urgent the system has already been built around its absence.

We build it first. Not out of unusual discipline — out of having watched what the alternative costs.

We do this for a living.

Data pipelines at 99.9% uptime and the AI agents that run on them. Estonian company, engineering team in Ukraine. Small senior pods, no account managers.

Talk to an engineer

More notes