Version control for a clinical procedure works when three things are true at the same time: only one version is reachable at the point of work, every revision says plainly what changed and what to stop doing, and one named person is accountable for removing the old copies. Numbering the file is the easy part. The hard part is that a new version is a behaviour change wearing a document's clothes, and most update processes are built to publish rather than to change what anybody does on a Tuesday afternoon.

I have written procedures that were technically live for months while the site carried on doing the previous thing. Nobody was defying anything. The old laminated card was on the wall, the new document sat in a folder somebody had to remember to open, and the wall won.

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.

A version number tells you a document changed. It does not tell you that one person changed what they do.

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.

The second is harder. Stopping something is not the same task as starting something. A 2024 overview in Implementation Science pulled together 46 systematic reviews on de-implementation, the work of getting established clinical practices reduced or removed, and two of its findings translate directly to procedure updates. The strategy group that performed most consistently was changing the infrastructure and the workflow rather than informing people about the change. And replacing a practice with a defined alternative tended to work better than simply asking for less of it.

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.

The evidence on how fast written guidance decays is worth knowing. A study in JAMA on the clinical practice guidelines issued by the Agency for Healthcare Research and Quality found that around half were out of date within roughly six years, and a 2012 systematic review in Implementation Science reports that same survival analysis alongside the fact that most guideline handbooks settle on three years as a sensible update interval. That review argues for something better than a calendar: a monitoring arrangement that watches for signals telling you an update is needed, since some subjects move much faster than others.

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.

There is a published model for this. CheckUp, a checklist for reporting updated clinical guidelines published in PLOS Medicine in 2017, sets out sixteen items across three areas: how the updated version is presented, editorial independence, and the method behind the update. The presentation items are the ones worth taking wholesale. They ask that the updated version be clearly distinguished from the previous one, that each recommendation be labelled as new, modified, unchanged or deleted, and that the changes come with a justification.

That is more discipline than most guideline publishers manage, and far more than most clinic manuals attempt. You do not need all sixteen items for a procedure governing how a room is prepared. You do need the labelling. 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 one version is reachable at the point of work and the rest 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.

Do that and the version number starts to mean something. Skip it and you will have a clean document register, a satisfied auditor, and clinics doing exactly what they were doing before you arrived.

Questions people ask

How do you manage SOP version control in a healthcare setting?

Make one version reachable at the point of work, state inside every revision what changed and what to stop doing, and name one person accountable for removing the old copies. Distribute a link rather than a file, because a file becomes an uncontrolled copy the moment it lands. Record the approval, the effective date and the next review date on the document itself.

How often should clinical procedures be reviewed?

Run a calendar and a trigger list together. Most guideline handbooks propose a three year cycle, and research in JAMA on national clinical practice guidelines found about half were out of date within roughly six years. A calendar catches slow decay. Named triggers catch events: an incident, a regulatory change, new equipment, a complaint pattern, or repeated requests to deviate.

Why do staff keep using the old version of a procedure?

Usually because the old version is still physically easier to reach, or because the new one costs more time at the same staffing level. Removing a step is also harder than adding one. Evidence on stopping established clinical practices suggests that changing the workflow and offering a defined replacement works better than simply asking people to do less of something.