Version control for humans: how clinics actually update a procedure

01

A version number tells you a document changed

It does not tell you that a person changed.

Document control and change control are different jobs and they get confused constantly. Document control is numbering, approval, effective dates, archive. It answers the auditor. Change control is what happens to the hands doing the work. It answers the patient.

The gap between the two is full of copies. Every printout, every laminated card, every screenshot sitting in a group chat, every induction pack a manager keeps on a personal drive is an uncontrolled copy, and it will outlive the document it came from. If you have ever walked a site and found three generations of the same form in one drawer, you already know that the archive is not where old versions go to die. They stay in circulation until somebody physically removes them.

So the first design rule is boring and it does most of the work. Distribute a link, never a file. A file becomes a copy the second it lands in an inbox, and after that you have no idea where it went.

The register can be current while the drawer is not.

02

Why the old version keeps winning

Two reasons, and neither of them is disobedience.

The first is reach. The old version is closer to the hands than the new one. That is a physical problem with a physical fix.

A revision needs a stopping instruction as well as a new instruction. Identify the old behaviour or document being retired, the approved replacement and the person who confirms removal. Sending a notice is not evidence that the previous process has stopped.

Read that as a drafting instruction. A revision that only deletes a step will fail quietly, because the step was doing something for somebody, even if only reassurance. Say what replaces it. If the answer is nothing, say that explicitly and say why, because silence gets filled by whatever people did before.

There is also a version of this you should treat as feedback rather than resistance. If the new procedure is slower at the same staffing level, the site will keep the old one and you will find out at audit. That is not a compliance failure. It is a drafting failure with a delay on it.

03

How often should a procedure be reviewed?

Fixed cycles are a floor, not a method.

I would give each procedure a review date and a named owner for earlier signals, such as a clinical requirement changing or an incident exposing a gap. A scheduled review should record its result even when no revision is needed.

For a clinic, run both. Keep a slow calendar so nothing sits unexamined for years. Then write a short list of triggers that force a review immediately, whatever the calendar says. A reported incident. A regulatory change. A new device or consumable. A supplier substitution. A complaint pattern. The third time a site asks permission to do it differently.

One more point that gets missed. A review that ends in no change is a real outcome and it has to be recorded, because an unrecorded review is indistinguishable from neglect. Confirmed current, on this date, by this person, next look in eighteen months. That single line closes more audit questions than a rewrite would.

04

The change note

Here is the format I use, and it fits on one page per revision. Call it the change note. It lives with the procedure, not in an email.

What changed. The old sentence and the new sentence, next to each other. Not a summary of the change. The actual text.

Why now. The trigger. An incident, a rule change, an audit finding, a request from a site. If nobody can name the trigger, the revision is a preference.

What stops today. The specific behaviour that ends. This is the line most people leave out, and it is the one that decides whether anything happens.

Who has to know. Named roles, not all staff. All staff means nobody in particular.

What will look different. The artefact that changes next week. A new field on a form, a different photograph angle, a timestamp that now sits before another one. If nothing observable changes, you cannot tell later whether the revision took.

Retired by. The date every old copy is gone, and the name of the person who confirms it. Removal is a task with an owner, or it does not happen.

Monday version of this: take the procedure you most recently changed, write those six lines for it, then go and find the old copies. The second half is the test.

05

Say what changed inside the document

A reader should be able to see in ten seconds whether the part they care about moved.

My change record labels each instruction as added, modified, unchanged or removed. It states the reason and the approving owner. This gives the reader a practical way to see what the new version requires without comparing two entire documents.

The amount of detail should fit the procedure. Keep the change labels clear. A version history table at the top of the document, showing date, version, what changed, why, and who approved it, turns a document into something an auditor can read at a glance and a new starter can trust.

06

What you hold and what you do not

You do not control whether the regulator moves the line next quarter. You do not control staff turnover erasing the training you delivered in March, a supplier discontinuing the consumable your procedure names by brand, or whether the busiest site has the ten minutes your revision quietly assumes.

What you control is narrow and it is enough. How few procedures you keep, because a smaller set is a set you can actually maintain. Whether the work area holds only the current version and the old copies are physically gone. Whether every revision names a behaviour that stops and a person who owns the removal. Whether reviews that change nothing get written down. And whether you treat the third identical deviation request as an exception or as the document telling you it is wrong.