Confessions of an Accidental CSO

Why DCB0160 isn't what I'd have written

I'm not a Clinical Safety Officer (CSO) by inclination: that was what Digital Services Prevention Portfolio needed, and it also meant if I did the CSO task, I could help with the design of Rubie, something I wanted to do so much it hurt. How bad could being a CSO be? Turns out, pretty bad.

The Regulations Themselves

The regulations (DCB0160) are long, repetitive and resist easy comprehension, and I expect are not often read. This could be me: my mind blurs when a document has bullets that include "Classification now includes risk as a component, in line with the NHS Digital Clinical Safety standards. This is important to note.", and I'm wondering "is it?" and "why", "what does that even mean? I see the words and know all of them, but…" I suppose my mind isn't that of a CSO. I am a clinician. Surely that ought to be helpful?

But is any clinician really a natural Clinical Safety Officer? What is the task? It is to predict what careful software designers did not predict, whatever the changing clinical world brings. If you don't get it right you will not know until it goes wrong. What then? In that context it is disturbing that the only 2 requirements to be a CSO are professional registration and training in clinical safety: there's a course and some reading, so about a day. More training is available, but how do you teach prophecy?

The document starts, with the now obligatory structure, with a helpful reference (NPFIT-FNT-TO-TOCLNSA-1793.05), contents and revision history, a list of referenced documents, a mind-numbing glossary and you are on page 9 before the overview. Discouragingly this is the specification, not the implementation guidance, which means you are still reading the short (22 page) not the long (160 page) document.

The process then feels as though the task is to "Do 160" not primarily to think through the process and make it safe. This doesn't mean the regulations are badly written, or wrong. They address a legal need, to protect against blame by exhaustively proving you acted in a particular way. It also allows the legalistic attribution of blame, and legal fees. Charles Dickens pointed out in Bleak House, "The one great principle of the English law is, to make business for itself." — that's certainly how it feels. Such tight bureaucratic constraints are brittle constructions.

Where I think Clinical Safety should start

For me, coming into it from the clinical world, it felt so alien and un-clinical that I wonder even now if I'll ever be any good at efficiently running through the process.

This is a central issue for me. To a clinician, clinical safety doesn't start with legislation, it starts with people. Imagining in detail the things that happen to 'Participants' in screening is where I would start. What could go wrong? How can we reduce that possibility.

How does following a legalistic framework allow us to ensure safety? Is that even possible? What I want to do is think through the pathway with people doing it in the unit. If we bring in new software for them to use then how will it change their practice (not national practice) with their equipment (not standard equipment), and how it replaces extra safety steps they have introduced with A4 pro-formas and well-worn habit. What does using this new thing do to their safety system at St. Agnes the Hapless Breast Unit? I need to find a way to prompt myself and others to think this through as thoroughly as possible.

That is exactly what the legislation is designed to help us do. But who, in this context, is it helping? The local CSO may not be (through no fault of their own) the right person to do this.

How Does Clinical Safety work now?

It is difficult to know where to start with DCB0160 without long training: 200 pages are hard to immediately absorb. It probably gets easier having run through it a lot of times (thankfully I haven't yet). Who ends up with the admin task that is 0160? It won't be clinicians doing the thing you are trying to make safe. Instead it will be CSO experts (very high quality experts in my experience so far, me excepted) who don't know the clinical pathway when they start and cannot know the nuances but are really good at the legislation. They have templates sitting on their cloud accounts ready to go. They have categorised risk before the process is even described to them into subdivisions they can fill in at a meeting.

It is hard enough to reason out the possible risks if you live the clinical pathway, never mind if you read about it in an office some distance away. To counter this, DCB0160 appropriately insists on the importance of Hazard Workshops — or as I think of them, conversations about the pathway with people who are aware of it, to consider the possible risks. Hazard workshops should have people who do the coal-face work in the room. This hasn't always been true in my experience. Sometimes the administrative lead, or a Superintendent with few clinical hours per week, or no regular clinical duties at all, is doing their best in a hard pressed unit to stand in for the team. This meeting should allow full expression of all possible doubts or worries those living and breathing the system have considered, with their colleagues' help, before the meeting starts.

CSO task number 1: produce categories and template documents (?)

The job of categorising into Hazard Number, Hazard, Cause, Effect, Harm, Initial Risk, Cause level (severity, likelihood, risk, justification) and annotating these risks is less important than the job of thinking them through and addressing them with appropriate actions or changes that will work in St. Agnes. Yet because DCB0160 requires an output on a spreadsheet with risk categorised, control, and residual overall hazard level rating with a status and owner, inevitably the meeting is taken up with a description of the definitions of these things first, then a run-through of hazards often suggested by the CSO who may or may not have good grasp of the actual work done.

It felt to me in these meetings as though the clinical team were onlookers trying to contribute in the gaps left for them, not leading discussion and not reasoning through themselves.

A framework built for a different era

DCB0160 was last revised in 2018, for software that arrived as a finished, largely static product — one big analysis, one meeting, one hazard log to track afterwards. That model suited systems that didn't change much once deployed. It suits far less well the incremental, constantly-morphing software we now build. And the truth is: we can't predict everything, however careful the process. Unpredicted clinical issues happen regardless — which makes staying alert and pathway-focused more important than ever, not less.

What Should Change?

So what do we do? It is easy to criticise but hard to improve. One individual cannot hope to redesign clinical safety. As a minimum, the 160 process needs to focus on the consequence of deploying by seeing the locality it is used as an essential element of the process. We need to test in context to see risks. The software must have been tried out, perhaps in a sandbox environment, not described schematically, and most especially not to exclusively non-clinical people.

The scale of scrutiny should be commensurate with the scale of change (so small tweaks need different scrutiny, unless escalated, compared to whole system re-writes).

Lower the bar to encourage near miss reporting: Whilst DCB0160 already has a hazard log process, finding ways of encouraging a reporting culture matter. Reporting near misses is not that easy. We should consider adding an "I've got a concern" button on every page, or have some other easy access, to let individuals tell us in their own words of any issues as they think of them. It would be ideal for concepts to improve safety to be suggested and encouraged even without a near-miss.

Continuously safe: Most importantly the system of making things safe needs to be clinical first, agile in implementation, easy to understand and to comment on, less a big once-off process and more a continuous background check.

We need to be much better at sharing knowledge of risk. How exactly? I'm not sure but developing new solutions is, I believe, necessary.

Jim Steel — July 2026