Somewhere in most of my client meetings there is a moment where the room goes quiet. I have just suggested that a product might carry clinical risk the team had not planned for, and I can see people doing the maths on what that means for their timeline. The questions come quickly after that. "Are you sure?" "We checked this at the start." "If we take that feature out of this release, can we push the deadline back?"

I completely understand the reaction. It feels like a delay, and delays are expensive when you are trying to get a good product to patients. But most of the time we are not looking at a new problem that has appeared out of nowhere. We are looking at a risk that was there all along, sitting just outside how the team had defined what their software is for.

That gap, between what a product is meant to do and what it actually does once real people start using it, is where a lot of clinical safety risk lives. And the earlier you go looking for it, the cheaper and calmer it is to deal with.

In this post you will learn why scoping clinical safety around your intended use can leave real risks uncovered, the one question I come back to again and again to find those risks early, and how to build this thinking into your product from the start rather than meeting it mid-delivery.

Why "we're only admin" or "we're not a medical device" can miss the risk

When I ask a team to think about clinical safety, the first instinct is often to explain why it does not really apply to them. I hear a few versions of this a lot, and each one is reasonable on the surface.

"We only handle admin, scheduling and messaging." I understand why that feels low risk. But administrative errors cause real harm all the time. Picture a patient who never gets the text inviting them in for a blood test, and that test would have shown a marker that needed a doctor quickly. Nothing clinical happened inside your software, and a patient was still harmed by the delay. The harm travelled through the workflow rather than through a diagnosis.

"We only provide decision support, we do not diagnose." Also fair, and the risk here is subtler. When a tool sits alongside a clinician often enough, people start to trust it, and that trust can quietly replace their own judgement. If your output is wrong just once and the clinician has stopped double checking, the influence your software has on that decision is very real, even though it never made the decision itself.

"We are not a medical device, so this does not apply." This is the one I most want to gently correct. Whether you are a medical device is a question for the MHRA. Clinical safety under DCB0129, the clinical risk management standard for manufacturers of health IT, is a separate question about whether your software could contribute to patient harm when it is used in care. A product can be a medical device and still need DCB0129. It can also be neither a device nor obviously clinical and still need it. The two things do not cancel each other out.

The pattern underneath all of these is the same. The team scoped safety around the job the product is designed to do, and the risk was hiding in what the product could do when something went wrong.

The question that finds the risk early

I do not expect founders and product teams to think like clinical safety officers. That is my job, and it took me years of clinical practice to build the instinct. But there is one question you can carry into any feature discussion that does most of the work for you.

Is there a plausible way a patient could be harmed if this behaves unexpectedly?

Not in normal use, when everything works as intended. When the integration fails, when the AI summary drops a detail, when the queue reorders and someone urgent slips down it, or when the wrong record loads. If you can describe a realistic path from your software misbehaving to a patient coming to harm, treat that as in scope for clinical safety and write down your reasoning. And if you genuinely cannot find one, document why you reached that conclusion, because that record matters too.

This is why I always say to think beyond your intended use. Your intended use tells you what the product is for. Clinical safety asks what happens when reality does not read the manual. Those are different questions, and the second one is the one that protects patients.

Making this a habit, not a late-stage scramble

The reason I care so much about timing is that this risk has a habit of surfacing at the worst possible moment. If you leave the question until an NHS buyer asks for your hazard log and your Clinical Safety Case Report, you are now redesigning features while you are mid-delivery, which is slow and stressful, and it costs far more than it needed to.

It is so much easier when the question rides along from the start. When someone proposes a feature, ask about the possible harm in the same breath as you talk about the user need. Keep a running note of the hazards you spot and what you have done about them, so your hazard log grows with the product instead of being reconstructed from memory much later. None of this asks you to become a clinical safety expert overnight. It asks you to stay curious about how your product could fail, and to write down what you find.

You have almost certainly done harder things than this. Building the product itself was harder. This is a lens you learn to keep switched on, and it gets easier every time you use it.

One question for your next sprint

If you take one thing from this, let it be a habit you can start on Monday. In your next design or sprint review, pick one feature and ask the room, out loud, "how could this harm a patient if it went wrong?" Then sit with the answers before you move on. That single question, asked early and asked often, is most of clinical safety in practice.

If you want to talk through where your own product sits and what the NHS will actually expect from you, I am running a free webinar, Ask Our CSO: Your Clinical Safety Questions, Answered, on 15 September from 12:30 to 1pm UK. Come with your own questions, because there is time to put them to me directly and get advice you can take back to your team. Register here. 

‍