Regulated systems · 4 min read
Design the audit trail before the feature
Compliance built onto a schema is a report. Compliance built into one is evidence. A surveyor can tell the difference, and so can an engineer.
There is a predictable moment in any clinical software project where somebody asks whether it is compliant. It usually arrives late, and it usually arrives as a request for a report.
By then the answer is already determined, and it was determined by a schema decision made months earlier by someone who was not thinking about surveys at all.
The distinction that matters is between a system that records what happened and a system that can reconstruct what happened. A table with a last_modified column and a user id records the present state and the last person to touch it. It cannot tell you what the record said on the Tuesday in question, who read it, or whether the value that is there now was ever different. You can bolt an audit table onto that later, and it will faithfully capture everything from the moment you added it, which is precisely the period nobody is asking about.
Designing it in from the start costs very little. An append-only event table, a decision about what constitutes an access rather than a write, and a retention policy written down while the people who understand the clinical context are still in the room. The expensive version is the same work done under time pressure, against live data, by somebody reconstructing intent from code.
The hand hygiene system is the clearest case I have. The category standard is badge-and-beacon proximity sensing, which infers hygiene events from where a badge was. It is cheaper to build and it produces a number. It also produces a number that is derived rather than observed, and a derived compliance figure is the first thing an external surveyor challenges. We built direct event capture instead, wrote the event model before anything else, and put the audit trail in the schema on day one.
When DNV surveyed, the questions were about the event model and the retention policy. Those questions had answers because they had been decided deliberately rather than inherited from whatever the ORM did by default.
The general form of the rule: anything you will be asked to prove later should be a first-class part of the data model, not a view over it. Access logging, retention, and evidence are cheap on day one and expensive the month before an inspection, and the month before an inspection is exactly when you will be asked.