This is Clinical Product Thinking 🧠, a weekly newsletter featuring practical tips, frameworks and strategies from the front line of clinical product.
Welcome, friends. This week, we’re talking about clinical governance, quality, clinical safety and operations and why the pathway itself is Queen.
When you work in Healthtech, this question comes up a lot: is this a clinical governance issue, a quality issue, a clinical safety issue or an operations issue?
The answer is often some of each. These functions don’t have clean boundaries, and trying to draw them perfectly may be the wrong task.
To help us try and solve this riddle, I caught up with Kiran Jones, Clinical Governance and Safety Lead at Numan, whose background spans aerospace, lean manufacturing and clinical safety. She described the four functions as ones that “interface and are messy in the middle”, and that she has yet to find a framework that separates them cleanly.
Our conversation reinforced something I have been thinking about: the clinical pathway that cuts across these functions deserves more attention than the organisational lines between them.
Here are six practical lessons from our discussion on managing clinical risk across products, people and processes.
1. Stop trying to put governance, quality, safety and operations into perfect boxes
Kiran doesn’t think there’s a clean separation between these disciplines. So instead, she focuses on what problem each one is trying to solve:
Clinical governance: how do we oversee, assure and improve clinical care?
Digital clinical safety: could the technology contribute to patient harm?
Quality: are we delivering care to the standards we expect?
Clinical operations: can we deliver that care reliably every day?
But these are heuristics. They help you decide who needs to be in the room for a given decision, and in a small company the answer may be the same person four times. 😆
2. The clinical pathway is cross-cutting
The problem with trying to separate governance, quality, safety and operations is that patients don’t experience care according to our organisational structures.
They experience a clinical pathway.
Take a patient being prescribed medication through a digital service. Clinical governance establishes how prescribing is overseen, quality defines the standards of care, clinical operations makes sure the service can deliver it, and digital clinical safety considers how the technology could contribute to harm.
But what happens when something goes wrong between those functions? Perhaps an abnormal result is reviewed but never acted upon, or a prescription is issued without a required monitoring check.
The risk may involve several disciplines, and no single team or system necessarily has a complete view.
This is particularly relevant to digital clinical safety, which typically starts with a defined health IT system. A clinical pathway, however, might involve a patient-facing app, an electronic patient record, a prescribing system, a pharmacy, messaging, email, manual checks and people following SOPs.
Every component could work as designed while the overall pathway still creates risk.
That is why system-level clinical safety is necessary but not always sufficient. You also need to look at what happens between systems, teams and processes, particularly where information, responsibility or the patient themselves moves from one part of the service to another.
3. When should a safety control move into the product?
Clinical services often rely heavily on people and process controls: SOPs, training, manual checks and professional judgement. Sometimes that is appropriate. Sometimes it is simply where the control ended up first.
If the same risk recurs, it is worth asking whether the control could be made more reliable by changing the product itself: a hard eligibility gate, mandatory field, warning, branching logic, confirmation step or escalation route.
That does not mean automating every clinical judgement. Human controls are often necessary precisely because care is nuanced. But controls that depend on somebody remembering the right SOP, noticing the right information or completing the same manual step perfectly every time deserve scrutiny.
The useful question is not simply, “Do we have a control?” It is, “Is this control sitting in the right place?”
4. The handovers are often where the risk lives
Take a patient with an abnormal blood result. The lab sends the result, the clinical system receives it, a clinician reviews it and a message to the patient is generated, with each step working as designed. The patient never reads the message.
Whose risk is that? It could sit with the clinical pathway, the messaging product, the SOP, monitoring, escalation, governance or digital clinical safety. In practice, it sits at the handovers between them.
Safety assessments that stop at the boundary of one piece of software can miss some of the highest-risk parts of a digital care pathway, which are the handovers.
Kiran’s way of finding them comes from lean manufacturing: put the entire patient pathway on a wall. Include the screens, and also the humans, the inboxes, the manual checks, the handovers and the places where somebody waits for somebody else.
The purpose is to make the invisible parts of the pathway visible. Digital teams tend to map product screens and clinical teams tend to map SOPs, and neither view necessarily shows the whole system of care.
5. Repeated human error should trigger a product investigation
One question we discussed is when does a clinical incident become a product problem.
A single error may not tell you much about where the underlying cause sits. However, when several clinicians make the same error at the same point in the pathway, treating it purely as a training problem becomes harder to defend. At that point, it makes sense to look at the interface, how information is presented, defaults, workflow, handovers, decision support, workload and the SOP itself.
Repeated human error is often information about the system.
Kiran described an approach in which recurring incidents around the same pathway step trigger a broader review by a clinical product lead, covering the interface as well as the SOP. The useful idea is the shift a threshold creates: recurrence moves the question from what one person did to what is happening in that part of the pathway.
6. Clinical safety capability should sit closer to product decisions
One organisational model I find interesting distributes some clinical safety capability into clinical product, so the CSO is no longer someone who appears at the end of the process to approve documentation.
Clinical product leads are trained to read hazard logs, contribute to hazard analysis and recognise when a product change alters clinical risk. The CSO keeps the formal role and oversight, and safety reasoning happens closer to the product decisions themselves.
The benefits are real. Hazards are identified earlier, the company depends less on one person, and safety becomes part of how the product is built.
So are the risks. Accountability can blur. Competence will be uneven across the team. People may assume that training makes them a CSO, and different leads may apply different risk tolerances to similar problems.
If you adopt this model, write down what the CSO still owns, how you check consistency across product areas, and when a clinical product lead must escalate.
The takeaway
For any clinical pathway you work on, ask:
Where could the patient be harmed?
Does each control live in the system, the product or people?
What happens at the handovers?
How would we know a control had stopped working?
Who owns investigating it?
Would a recurrence trigger a product review?
Does this change alter our clinical safety argument?
The organisational boundaries will stay messy. The patient experiences the pathway, so that is where the safety thinking needs to go.
That’s all for this week. See you next time! 👋
🤝 Work with me | 📅 Attend an event | ✍️ Send a message
Written by Dr Louise Rix, Clinical Product, AI, doctor and ex-VC. Passionate about all things healthcare, healthtech and clinical product (…obviously). Based in London. You can find me on LinkedIn & Instagram.
Made with 💜 for better, safer HealthTech.