Welcome, friends. This is issue No. 62 of Clinical Product Thinking. This week, we’re recapping some of the tools we’ve covered in the last year.

Since launching Clinical Product Thinking in August 2025, we’ve covered everything from the role of clinical product managers to scaling clinical services, designing safer workflows and evaluating clinical AI.

Along the way, we've built a growing collection of frameworks, models, and practical tools. Some are ways of thinking about a problem, others help teams make decisions or put clinical product thinking into practice.

I’ve brought them together here, with a short explanation of each, when to use it and a link to the original piece.

This is a living library. I’ll keep updating it as new ideas and tools are published, so bookmark it for future reference.

👩‍⚕️ 1. Making clinical product decisions

The Clinical Product Triangle 🔺

The Clinical Product Triangle is a decision-making framework built around three perspectives:

• Patient: Does it help me?

• Clinician: Can I trust it?

• Business: Can we sustain it?

A product can be clinically excellent but too expensive to deliver. It can offer a beautiful patient experience while creating an unsustainable clinical workload. Or it can be commercially attractive while compromising the quality of care.

Clinical product management sits between these perspectives, helping teams understand the trade-offs and make decisions that work across all three.

When to use it: When comparing product options, prioritising features or making decisions where patient benefit, clinical workload and commercial viability pull in different directions.

Originally shared: The Clinical Product Triangle — Linkedin, 29th September 2026

The Fourth Amigo Model 🤠

The Fourth Amigo Model is a way of organising product teams so that clinical judgement informs decisions throughout development.

It builds on the familiar product, design and engineering team by adding clinical product as a fourth member.

• Product decides what problem to solve and what to prioritise.

• Design makes the right action clear and easy for users.

• Engineering builds the product reliably and securely.

• Clinical Product brings clinical judgement, safety and the reality of care delivery.

The model means questions like “Should this allergy alert be a hard stop or a warning?” are addressed while the product is being designed, rather than during a last-minute clinical review.

When to use it: When designing your product team, defining clinical product responsibilities or deciding how clinical expertise should contribute to development.

Originally shared: The Fourth Amigo Model — LinkedIn, 17 August 2026

The Five Translations

A clinical product manager’s most important skill is translating clinical understanding into decisions that product teams can act on.

The Five Translations describe the points where this happens:

1. Clinical nuance → product requirements

2. Safety risk → design constraints

3. Potential harm → prioritisation

4. Messy clinical pathways → usable journeys

5. Clinical outcomes → commercial impact

For example, a clinician might say that a particular questionnaire is essential. The translation is determining whether it should be mandatory, conditional or recommended, and how that decision should be reflected in the product.

When to use it: When defining the clinical product role, hiring or developing clinical product managers, or diagnosing why clinical and product teams struggle to communicate.

Read: The Skill Every Successful Clinical Product Manager Needs to Know — 31 May 2026

🧩 2. Bringing clinical thinking into the team

Five Lightweight Ways to Apply Clinical Product Thinking

You don’t need a dedicated clinical product manager to start bringing clinical judgement into product development.

This practical guide describes five ways teams can get started:

1. Agree clinical guardrails before development begins.

2. Make clinician time predictable and accessible.

3. Create a route from clinical incidents to product improvements.

4. Involve clinicians when defining problems, rather than reviewing finished solutions.

5. Help clinicians understand the basics of product development.

For instance, agreeing in advance which decisions require clinical input can prevent clinical reviews from becoming unexpected obstacles late in development.

When to use it: When building an early-stage healthtech team, introducing clinical input into an existing product function or improving collaboration before hiring a dedicated clinical product manager.

Read: 5 Lightweight Ways to Apply Clinical Product Thinking Before You Hire a CPM — 26 October 2025

The Clinical Product Influence Playbook

Clinical product managers frequently need to shape decisions without having formal authority over the people making them.

This playbook describes three habits that can help:

1. Speak the language of the people you’re trying to influence.

2. Connect clinical objectives to the company’s commercial goals.

3. Contribute early, without waiting to be invited into the conversation.

For example, rather than simply raising concerns about an unsafe workflow, explain the potential patient harm, the operational consequences and what could be changed to make the proposed approach safer.

When to use it: When you’re the only clinical product person in an organisation, struggling to influence prioritisation or finding that clinical input arrives after decisions have already been made.

Originally published: The CPM Playbook for Building Influence — 28 September 2025.

🛡️ 3. Designing and scaling safer clinical products

Four Checks Before You Scale

Early-stage clinical products often work because people quietly compensate for what the product cannot yet do.

Clinicians make judgement calls, operations teams resolve broken workflows and manual reviews catch problems before they reach patients.

As volume grows, these arrangements become harder to sustain.

Four practical checks can help teams identify vulnerabilities before scaling:

1. Find the workarounds. Identify manual checks, spreadsheets, informal escalation routes and repeated interventions.

2. Run a 10x stress test. Ask what would fail if patient volume increased tenfold tomorrow.

3. Observe the real workflow. Watch how people use the product under normal working conditions.

4. Track emerging operational risks. Identify dependencies and processes likely to become unsafe or unreliable as demand increases.

When to use it: Before launching into new markets, signing a major contract, expanding care delivery or significantly increasing patient volumes.

Read: Scale Does Not Create Clinical Risk. It Reveals It. — 21 June 2026

The 2am Test

The 2am Test is a simple design heuristic inspired by a conversation with Benedikt von Thüngen, CEO of Sanome, about the value of observing clinicians working night shifts.

It asks:

How would this product work at 2am?

Imagine a tired clinician, a slow computer, incomplete information and a deteriorating patient. Can the person using your product still understand what’s happening and identify the next safe action?

The test encourages teams to examine the difference between work as imagined and work as done, particularly when clinical work involves interruptions, uncertainty and adaptations that don’t appear in a workflow diagram.

When to use it: When designing or reviewing clinical workflows, particularly those involving time-sensitive decisions, alerts, escalation or use under pressure.

Read: The 2am Test: Is Your Clinical Product Designed for Real Life? — 28 June 2026

🤖 4. Building, testing and assuring clinical AI

Right Answer, Wrong Action

Developed through conversations about behavioural AI safety with Dr Paul Sacher, Right Answer, Wrong Action describes a class of clinical AI failure that conventional accuracy testing can miss.

An AI system can provide clinically correct information while making a patient more likely to take an unsafe action.

For example, a conversational AI might offer reassurance that is technically reasonable in isolation, but encourages a particular patient to delay seeking medical attention.

The framework describes four categories of failure:

• Context failures: The AI responds without sufficient information about the patient.

• Reception failures: The patient interprets the answer differently from how it was intended.

• Reinforcement failures: The AI encourages or validates a potentially harmful behaviour.

• System-boundary failures: The interaction crosses or obscures the limits of what the AI should safely do.

These are expanded into twelve named answer types to help teams recognise potential failures during evaluation.

When to use it: When designing or testing patient-facing conversational AI, particularly where patients might act on advice, seek reassurance or develop ongoing relationships with a system.

Read: The ‘Right Answer, Wrong Action’ Dangers of Clinical AI — 10 May 2026

Three Building Blocks for Pre-Deployment AI Testing

Traditional testing often evaluates AI responses one prompt at a time. But in conversational healthcare products, safety failures may only emerge after several exchanges.

This testing approach brings together three components:

1. Behavioural personas: Realistic and adversarial users who test how the system responds to different circumstances and behaviours.

2. Evaluators: Explicit criteria used to assess whether the AI behaved appropriately, including recognising risk, staying within scope and escalating when necessary.

3. Evidence: Conversation transcripts, evaluation results, system versions and records of what changed between tests.

The approach also requires someone to define the acceptance criteria, evaluate the evaluators and decide whether the evidence is sufficient to support deployment.

When to use it: When developing a patient-facing AI agent, designing pre-deployment evaluations or building a repeatable testing process for changes to prompts, models and workflows.

Read: Why Your AI Passed Testing and Would Still Fail a Real Patient — 16 August 2026

🚀 5. Moving into clinical product

Four Steps to Break Into Clinical Product

A practical career roadmap for clinicians moving into product roles, drawing on advice from clinical product leaders and hiring managers.

The four steps are:

1. Unlearn deference. Get comfortable challenging assumptions and contributing to decisions regardless of hierarchy.

2. Understand what hiring managers want. Demonstrate pragmatism, collaboration and commercial awareness alongside clinical expertise.

3. Learn to think like a product person. Develop an understanding of users, prioritisation, experimentation and how products are built.

4. Get your first product experience. Start with advisory work, feature testing, product critiques or small projects rather than waiting for the ideal job title.

Clinical experience gives you knowledge of patients and healthcare delivery. The challenge is showing how you can apply that knowledge to product decisions.

When to use it: When planning a move from clinical practice into healthtech, preparing for clinical product interviews or identifying the experience you need to develop.

Read: Breaking Into Clinical Product — 26 July 2026

Keep exploring

This collection brings together some of the ideas I’ve found most useful when thinking about how clinical products should be built, evaluated and improved.

Some are original models, others are practical adaptations of established approaches or lessons developed through conversations with people working across clinical product, safety and AI.

I’ll keep adding to the library as new frameworks and tools emerge.

If you’ve tried any of these approaches, or have a problem you’d like Clinical Product Thinking to tackle next, I’d love to hear about it. Reply to this email or leave a comment.

What I’m reading 📚

So many interesting papers published in the last month, I wanted to share some of the things I’ve been nerding out on:

1. The anatomy of a personal health agent — Google Research

Google’s research into AI agents combining wearable data, medical knowledge and personalised health coaching. An interesting look at multi-agent design. (Nature paper)

2. Building Medical Superintelligence — Microsoft AI

Microsoft’s diagnostic AI achieved 83% accuracy on complex cases versus 36% for physicians using reference materials. Fascinating implications for clinical reasoning, although real-world validation is still needed. (Science paper)

3. State of Clinical AI in 2026 — BMJ Digital Health & AI

A comprehensive review of where clinical AI actually stands. Particularly interesting on the gap between impressive benchmark performance and real-world evidence, clinical safety and human–AI collaboration.

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.

Welcome, friends. This is issue No. 61 of Clinical Product Thinking. This week, we’re looking at five very different jobs that sit under the same clinical product title.

In September 2025, I analysed clinical product job descriptions from UK healthtech companies. It is one of the most-read CPT issues.

Since then, many new roles have been posted, ranging from mid-level all the way up to Chief Clinical Product Officer.

When you compare them, it’s clear how differently companies define clinical product. Some focus almost entirely on clinical safety. One involved managing more than 50 prescribers. Others were senior product leadership roles.

Here are the five clinical product archetypes that emerge from the data. Perhaps we’ll see more in future.

This analysis is based on publicly listed clinical product job descriptions collected from UK and US employers. Many of these roles are no longer open.

1. The pathway builder

Designs clinical care journeys and works with product teams to turn them into functioning services.

Numan’s Clinical Product Lead role covers patient journeys from onboarding and triage to prescribing and follow-up, including clinical logic and decision support.

Paloma’s Senior Clinical Pathway & Product Manager owns its autism and ADHD pathways, including KPIs and financial targets. Hertility’s role covers telemedicine, follow-up and prescription journeys, with performance measured against clinical outcomes and retention.

What to show: A clinical journey you’ve designed or improved, including what changed for patients, clinicians and the business.

2. The safety lead

Responsible for managing clinical risks arising from the product.

Semble’s Clinical Product Manager leads clinical safety activities under DCB0129, maintains safety documentation and coordinates release sign-off with an external Clinical Safety Officer (CSO).

Sanome’s role included CSO responsibilities, while Nourish Care lists hazard identification and clinical risk assessment.

These roles require specialist clinical safety expertise as well as clinical product knowledge.

What to show: Clinical safety training, experience with hazard logs and safety cases, and examples of influencing release decisions.

What to ask: Would you be the named CSO, and who makes the final decision if clinical safety and product priorities conflict?

3. The clinical operator

Runs the clinical service alongside the technology supporting it.

AIOS’s UK Head of Clinical Product leads more than 50 prescribing pharmacists and the medic team, covering staffing, capacity planning and clinical performance with a potential path to CPO.

AIBODY’s Clinical Product Owner similarly focuses on deployment, coordinating rollouts across clinics and helping clinical teams adopt the product.

What to show: Experience managing clinical capacity, quality or performance, and how you’ve used data to improve service delivery.

4. The domain specialist

Brings deep expertise in a particular clinical area, sometimes with product experience as a secondary requirement.

InStride Health seeks a psychologist or licensed therapist to own clinical protocols, provider guidance and training for anxiety and OCD care.

CoordinateX, from First Databank, prioritises medicines management experience, ideally from a pharmacist. Headway’s Principal, Clinical Product role requires an experienced behavioural health clinician.

What to show: Your specialist expertise and examples of translating it into products, clinical pathways or service improvements.

5. The product leader

Owns product strategy and delivery, often across multiple teams.

Dyad’s Chief Clinical Product Officer leads product strategy for its healthcare AI products, with the VP of Engineering reporting to the role. A medical qualification is strongly preferred rather than mandatory.

Other employers describe routes into broader product leadership. Paloma identifies Lead and Director as progression opportunities, while AIOS mentions a potential path to CPO.

What to ask: Which product decisions would you own, and how are responsibilities divided between clinical and product leadership?

How to tell which role you’re looking at

If you’re interviewing for a clinical product position, consider these three questions:

• Who will I report to? A CPO, CMO or Operations leader can indicate very different expectations.

• What will I be measured on? Clinical outcomes, product adoption, safety, service performance and revenue point towards different responsibilities.

• Which decisions will I own? Will you set the roadmap, manage clinicians, design pathways or be accountable for clinical safety?

For hiring managers, be explicit about which responsibilities the role includes. If you’re expecting someone to manage a clinical service, own the roadmap and oversee clinical safety, explain how their time will be divided and what support they’ll have.

The takeaway

Clinical product is becoming a broader category of work, with quite different responsibilities sitting under similar titles.

For clinicians moving into healthtech, that creates opportunities across pathway design, clinical safety, operations and product leadership. But it also means the job title alone tells you surprisingly little about what you’ll actually be doing. Make sure you interview the interviewer for clarity on the role you’re taking.

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.

Welcome, friends. This is issue No. 60 of Clinical Product Thinking. This week, we’re talking about why the same AI model can perform very differently from one hospital, patient group or even season to another.

A CE or UKCA mark tells you that a medical device has been assessed as conforming to the applicable regulatory requirements. It doesn’t guarantee that an AI model will perform equally well across every hospital, patient population or clinical setting.

Your patients might be different. Your scanners might be different. Even the time of year might affect the results. More on this later.

I was reminded of this at NHS England’s Digital Safety in Practice day last month. I’ve already written about Prof Mark Sujan’s talk on using LLMs for assurance. Another excellent session, delivered by Haris Shuaib of Newton’s Tree, has stayed with me.

Haris walked through examples of what happens when clinical AI systems encounter the complexity of real-world deployment and it’s fascinating.

Despite the growing number of approved AI medical devices, clinical adoption remains relatively limited. Haris highlighted a number of factors, including insufficient evidence, high implementation costs, institutional barriers and a lack of effective performance monitoring.

The examples below help explain why that last problem is particularly gnarly one to solve.

1. Same model, different hospital

A well studied model can perform differently (and significantly worse) in a different clinical setting and care providers should be cautious about relying on published performance figures or a vendor’s existing customer base.

Haris described that at a multi-site evaluation across London, Oxford, Northumbria and Glasgow, a model for detecting intracranial haemorrhage was tested retrospectively.

At most sites, its reported accuracy was around 90%. At Glasgow, it was just 70%. (The published literature had reported 95%).

Glasgow subsequently withdrew from the prospective arm on safety grounds. That particular vendor had more than 1,000 customers worldwide.

Another example is a German oncology centre who ran validation studies before purchasing AI for chest X-ray interpretation. They tested three leading vendors against the same 1,000 historical cases and found a 30-percentage-point difference in ability to distinguish normal from abnormal films.

The weakest performed at just around 50% accuracy!

The better approach is to perform local testing to help establish whether published results generalise to your population, equipment and clinical workflows. Prospective evaluation and ongoing monitoring are then needed to understand how the model behaves in practice and over time.

2. Same model, different patient

Even within a population that appears relatively uniform, performance can vary a lot.

One paediatric fracture detection model showed a reported 23% deterioration in performance across age groups.

It performed best on 2-year-olds and worst on 17-year-olds, where accuracy fell to around 70%.

That surprised the room, because teenage skeletons are more similar to adult skeletons. You might intuitively expect a model to perform better on older children.

But that wasn’t what the results showed.

It’s a useful reminder of why subgroup analysis is so important. Overall performance figures can conceal substantial differences between patient groups, including differences that aren’t immediately obvious from clinical reasoning alone.

For anyone evaluating clinical AI, it isn’t enough to ask how accurate a model is across the whole dataset.

You also need to understand who it performs well for, who it performs poorly for, and whether those differences create unacceptable clinical risks.

3. Same model, different image

The data pipeline feeding a model is part of the clinical system, even when it sits outside the AI product itself.

Some of the most interesting failures had surprisingly little to do with changes to the AI model itself.

At one site, chest X-rays were rotated to make them easier for radiologists to read. Unfortunately, the rotation created diamond-shaped crop marks around the edges of the images.

The AI interpreted these artefacts as urgent findings.

An investigation found that roughly half of the false positives were associated with data quality problems of this kind.

Once the cause was identified, the solution was relatively straightforward: send the original, unprocessed image to the AI and the processed image to the radiologist.

Another example involved a mammography system.

In a 2023 study published in Radiology: Artificial Intelligence, researchers evaluated a breast screening AI algorithm across more than 55,000 screening examinations.

They discovered that the AI’s recall rate increased approximately threefold following a software upgrade to the mammography equipment.

The AI model itself hadn’t changed. The scanner software had.

The researchers suggested that the upgrade may have altered characteristics of the images that the AI relied on, even though human reader performance was unaffected.

The connection was identified by examining image metadata and tracing the change back to the equipment software.

For anyone building or deploying clinical AI, it’s a useful reminder that changes to scanners, firmware, image processing, file formats or integration pathways can affect what the model receives and, consequently, what it produces.

4. Same model, different season…!

A safety assessment carried out at a single point in the year may miss important changes in how a clinical AI system performs over time.

This is the example that made people sit up in their chairs. Haris shared monitoring data from a deployment at Leeds. During winter pressures, a 30-day rolling measure of agreement between the AI and clinical labels rose to around 90%. After New Year, it fell to around 25%, before recovering.

The model itself hadn’t changed.

Haris offered an interesting explanation for the swing.

During winter pressures, patients who might otherwise have been seen in primary care were being directed to A&E, sometimes receiving chest X-rays that showed no abnormalities. This increased the proportion of normal cases, which Haris suggested were easier for the AI to classify correctly.

After the winter-pressure period, the case mix changed. Patients attending hospital tended to have more significant disease, while lighter clinical workloads potentially gave clinicians more time to review and challenge AI recommendations.

The result was a substantial change in observed agreement, despite the AI model remaining unchanged.

Importantly, concordance isn’t the same as diagnostic accuracy. The data doesn’t establish exactly how much of the variation was attributable to changes in case mix, model performance or clinician behaviour.

But it illustrates how the conditions surrounding a clinical AI system can change over time, sometimes considerably.

For buyers and builders, this raises a practical question: how will you know whether a model continues to perform appropriately as patient populations, disease prevalence and clinical workflows change?

What buyers and builders can do

The recommendations from Haris’s session were pretty clear.

Test on your own data before signing a contract.

Haris described pre-contract evaluation using local data as one of the most valuable steps a buyer can take.

It allows hospitals to compare vendors against the patients and conditions in which the technology will actually be used.

Where possible, that evaluation should include clinically relevant subgroups, equipment configurations and representative cases.

Awarding a contract first and discovering performance problems afterwards leaves the care providers with fewer options.

A practical checklist for clinical AI

If you’re buying, building or deploying a clinical AI system, here are six questions worth asking:

1. Has the model been evaluated on data representative of our own patients and clinical setting?

2. Do we understand how performance varies across relevant patient subgroups?

3. Have acceptable performance thresholds and responsibilities been agreed with the vendor?

4. Can we identify changes to equipment, data processing or integrations that might affect the model?

5. Are we monitoring performance over time, including changes in patient populations and clinical workflows?

6. Is there a clear process for investigating deterioration and suspending use when necessary?

None of these questions is particularly complicated. But answering them requires cooperation between clinical teams, product teams, technical teams, procurement and the manufacturer.

The takeaway

Clinical AI performance depends on far more than the model itself.

The hospital, patient population, equipment, data processing and clinical workflow can all influence how a system behaves. Those conditions can also change after deployment.

Regulatory conformity assessment and manufacturers’ post-market surveillance obligations provide important safeguards. But hospitals still need to establish whether a product is appropriate for their own setting and monitor how it performs in use.

If you’re buying clinical AI, ask what evidence exists that it performs safely and effectively on your patients, using your equipment and within your workflows.

If you’re building it, ask how you’ll know when those conditions change.

And if you’re responsible for clinical safety, consider whether your assurance activities address the system as it is actually deployed, including the people, processes and technology surrounding the model.

Thanks to Haris Shuaib of Newton’s Tree for the fascinating talk!

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.

Welcome, friends, this is issue No. 059 of Clinical Product Thinking. 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:

1. Where could the patient be harmed?

2. Does each control live in the system, the product or people?

3. What happens at the handovers?

4. How would we know a control had stopped working?

5. Who owns investigating it?

6. Would a recurrence trigger a product review?

7. 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.

Welcome, friends, this is issue No. 058 of Clinical Product Thinking. Today we’re talking about one of the less comfortable parts of clinical product: saying no.

In Clinical Product Thinking, we’ve covered before why Clinical Product should be embedded throughout the product lifecycle. But being embedded isn’t enough.

If you identify something that you believe is clinically unsafe, what happens next?

Can the product team overrule you? Can someone decide the commercial benefit outweighs the clinical concern? Can the feature ship anyway?

Those questions get to something we don’t talk about enough when defining clinical product: authority.

So this week I’ve handed Clinical Product Thinking over to my good friend Danielle Brightman, who writes about the discipline at clinicalproduct.uk, to make the case for why Clinical Product needs the power to block, and why knowing when not to use that power is equally important.

Let’s dive in.

The uncomfortable truth

As Dani describes it, one of the most uncomfortable truths about Clinical Product is that the role is blocking by default.

As much as we talk about how the role shouldn’t be approached only for sign-off, or as a tick-box exercise, at its absolute core, it can block.

Why blocking matters

If Clinical Product cannot block a release, the role becomes advisory. The result is that your suggestions get weighed against speed, and speed usually wins.

Blocking is the enforcement mechanism. It’s what transforms “please listen to the clinical person” into “the clinical person has the authority to ensure patient safety.”

The discomfort of being the blocker

Nobody wants to be the person who stops things, especially in fast-moving product teams where momentum matters and delays are visible.

As a Clinical Product Manager, you are (/should ideally be) embedded in the team and understand the pressure everyone is under to ship. Because of this, you’ll also be feeling pressure to let things through when you know it’s not quite right.

This is the central tension of Clinical Product roles: you’re embedded in the team, but you’re also the one who might stop the team from shipping. Navigating that tension can be tough.

What blocking actually looks like

Blocking doesn’t mean saying no to everything, and it definitely doesn’t mean threatening teams on a daily basis that you might block the feature. It does, however, remind teams of your role and the responsibility you hold.

Work that doesn’t quite meet the bar can be handled much better than a flat ‘no’, for example:

• “We can ship this, but not with that edge case unresolved.”

• “This is fine for a limited rollout. It’s not fine for general use.”

• “I need more information before I can sign off.”

• “This doesn’t meet the clinical threshold. Here’s what would.”

Good blocking is specific. It gives teams something to work with by outlining the problem, and, where possible, points towards a solution.

The cost of not blocking

When Clinical Product doesn’t block, or can’t, the consequences tend to be invisible until they’re not.

That edge case you let through, knowing it wasn’t quite right, hoping it wouldn’t surface? It reveals itself as an incident. Either as a single event, or through the accumulation of regulatory risk that the company is eventually pulled up for.

A delayed release is far better than a release that harms someone. Incidents are costly - not only for patients who are harmed, but also for the business. Time is spent fixing the issue, responding to the patient, to the media and to the regulator.

Building the credibility to block

Blocking only works if people trust your judgement. If they don’t, they’ll go around you, or above you, to confirm your call.

Trust is earned, and it takes time. It comes from:

• Being right more often than you’re wrong, and being honest when you’re uncertain.

• Understanding the product, not just the clinical domain.

• Picking your battles - blocking when it matters, not blocking reflexively.

• Explaining your reasoning, not just asserting authority.

If you block too often, you lose credibility, but if you never block, even when you should, you lose the point of the role.

Knowing when to step back

Not every decision needs clinical product to make the final call.

You’re part of the product conversation, shaping direction, contributing to trade-offs, understanding what’s being built. But some decisions, like choosing between two equally safe design patterns, or prioritising one low-risk feature over another, can be left as a team decision. There may be commercial factors, or patient experience considerations, that pull one option over the other.

The question to ask yourself is: does this decision require me to exercise clinical authority, or can I contribute as part of the team without needing to be the deciding voice? If it’s the latter, step back and allow the team to own it.

This is harder than it sounds. When you’re accountable for clinical outcomes, it’s tempting to assert your position on everything, but knowing when not to block is just as important as knowing when to block.

A note on hiring

If you’re hiring for Clinical Product, ask yourself: does this role have the authority to block a release? If the answer is no, you’re not hiring for Clinical Product you’re hiring a clinical advisor.

If you’re looking for a role in Clinical Product, check with the hiring manager: does this role have the authority to block a release?

Remember: clinical accountability requires the power to stop something. Without it, you’re responsible for outcomes you can’t control, and when something goes wrong, you carry the blame without having the influence to prevent it.

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 & Safety, doctor and ex-VC. Passionate about all things healthcare, healthtech and clinical product (…obviously). Based in London. You can find me on LinkedIn.

Made with 💜 for better, safer HealthTech.

Welcome, friends, this is issue No. 057 of Clinical Product Thinking. Today we’re answering a deceptively simple question: what role does Clinical Product actually play?

Through writing Clinical Product Thinking, I’ve spent a lot of time thinking about the definition of Clinical Product Management.

Here is what I’ve landed on:

Clinical Product Management is embedding clinical judgement throughout the entire product lifecycle.

But that doesn’t answer the question: what should a clinical product person be responsible for?

That is hard because the boundaries between clinical, clinical product, product, safety, and operations are murky.

To help us, I recruited my good friend Danielle Brightman, the OG clinical product leader. She writes about clinical product at clinicalproduct.uk.

Let’s dive in.

So, what is clinical product?

As Dani describes, clinical product is embedded. It’s blocking by default, and it’s accountable for clinical integrity.

But those are characteristics. They don’t fully capture what the role is.

As Dani puts it, clinical product does these five things:

1. Setting the clinical direction

Clinical product doesn’t wait for requirements to arrive. It actively scans emerging evidence, market shifts, and changes in clinical practice to shape what should exist next.

This includes identifying when new treatments or care models are clinically viable and when they’re premature, unsafe, or operationally unrealistic.

2. Embedding clinical judgement throughout the product lifecycle

Dani says embedding Clinical Product is essential as their input is needed across:

• Discovery and planning – grounding ideas in real clinical practice, evidence, and patient care realities

• System and experience design – shaping requirements so what’s being built is clinically coherent, not just technically correct

• Implementation – preventing “small” implementation details from creating unacceptable clinical behaviour

• Testing and acceptance – validating that things behave safely in real-world clinical use

• Deployment and monitoring – owning what happens after launch, including incident response and emerging risks

This is where the role differs most clearly from advisory, QA, or compliance functions: clinical product carries accountability across the whole arc.

3. Designing for the full clinical ecosystem

Clinical product optimises for outcomes, not isolated users.

Patient safety and effectiveness depend on the combined behaviour of patients, clinicians, health coaches, operations, customer support, and systems.

A feature that “works” for patients but creates unsafe escalation paths, unmanageable clinician load, or regulatory exposure is not ready to ship.

4. Exercising clinical risk ownership

Clinical product leads clinical risk thinking in day-to-day product work:

• Identifying and articulating risks early

• Maintaining and evolving hazard logs and risk registers (in collaboration with the CSO)

• Providing clear, defensible clinical rationale for decisions

• Supporting incident investigation and learning

• Working with governance roles without outsourcing accountability

5. Acting as the point of clinical accountability in partnerships and scale

As products integrate with external partners or scale across teams, clinical risk diffuses.

Clinical product owns due diligence and integration decisions from a clinical perspective, ensuring that external dependencies don’t dilute safety or accountability.

What clinical product is not

A few clarifications, because the role is often confused with adjacent functions:

• Clinical product is not clinical subject-matter expert (SME) work.

SMEs provide knowledge; clinical product provides judgment, including the judgment to say no. Confusion comes when SMEs provide product teams with their direct viewpoint. Teams don’t know which clinician to listen to. Specialist input should inform the Clinical Product Manager, who remains accountable for how that input is applied.

• Clinical product is not regulatory or compliance.

Compliance ensures processes are followed. Clinical product makes clinical decisions. There’s overlap, but the accountability is different.

• Clinical product is not QA.

QA tests whether the product works as intended. Clinical product determines whether what’s intended is clinically sound. The Clinical Product Manager does often have a role in acceptance testing, but that’s to ensure the product behaves safely in clinical use, not to validate that it meets functional specifications.

• Clinical product is not medical affairs.

Medical affairs manages external clinical relationships. Clinical product operates inside the product team. In some organisations, particularly early-stage ones, the same person may cover both areas.

Why this definition matters

Clinical product is still an emerging discipline. We’re still in a state where there’s no standard job description, no universal competency framework and no agreed curriculum.

That ambiguity creates problems. Organisations hire clinical product people without knowing what they’re hiring for. People take clinical product roles without knowing what they’re signing up for. Expectations misalign, and accountability falls through the cracks.

Definitions help because they make it possible to have honest conversations about what the role requires and whether it’s being set up to succeed.

Thank you to Dani for sharing her thoughts and expertise in this post. 💜

Next week, we’re sticking with Dani for one the trickier parts of Clinical Product: the power to block. When should Clinical Product be able to stop something shipping — and when should it step back?

Clinical Product Drinks 🍸

Tuesday was Clinical Product Drinks #003. So much fun with so many incredible folks building the future of digital health. Thank you again to sponsor Scale Health. Look out for the next one in mid-November.

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 & Safety, doctor and ex-VC. Passionate about all things healthcare, healthtech and clinical product (…obviously). Based in London. You can find me on LinkedIn.

Made with 💜 for better, safer HealthTech.

Welcome, friends, this is issue No. 056 of Clinical Product Thinking. Today we’re talking about using AI for clinical assurance.

Last week I went to the Digital Safety in Practice event by NHSE, a day focused on recent developments in the world of clinical safety. I’d highly recommend it to anyone working in the space!

One fascinating talk was from Prof Mark Sujan, Chair in Safety Science at the University of York’s Centre for Assuring Autonomy. His research focuses on safety assurance for systems involving AI.

Mark presented work on using LLMs to review patient-safety learning responses. What interested me about it most was how LLMs differ from human reviewers and what that means when we’re applying AI to clinical assurance.

Here are the lessons I’ll be taking away in my own work:

Define the task narrowly

The lesson from the research was that “review this safety case” was too vague to give meaningful results. Instead, they had multiple agents (8, I believe!), each with a different role or task, e.g:

• identify claims without supporting evidence

• find missing hazards

• extract controls

• find gaps in the argument

As Mark put it, you’re not really assuring the LLM. You’re assuring it for use on a specific task.

Give it a rubric

During the research, they found that loose criteria gave poor results. This improved significantly when they explicitly defined what evidence to look for.

Rather than: “Is this hazard adequately controlled?”

Try: “Identify each claimed control. Show the evidence that it exists, assumptions being made, gaps in implementation evidence and remaining risk.”

Making the AI show it’s working means you have the ability to critique.

Use AI to find evidence, but be cautious when it interprets it

This was an interesting finding from the research. LLMs are very good at finding evidence but were markedly less reliable at deciding whether that evidence genuinely demonstrated what was being assessed. The AI was also less reliable at systems-level reasoning.

Based on this, a useful division of labour might be:

AI: retrieve, collate, compare, categorise and surface evidence

Human: interpret, contextualise, and apply judgement

Watch for proxy evidence

AI can find something that it thinks looks like evidence without actually proving the underlying claim.

Mark gave an example of a family being treated compassionately at the time of an incident occurring. The model mistakenly attributed that the incident itself had been compassionately investigated. The two separate events had been flattened into one.

You can imagine how this can happen in a safety case:

• A control is listed → evidence it exists

• Testing is mentioned → therefore adequate testing has happened

• The words “clinical review” are present → meaningful clinical review must have occurred.

Make sure you ask: has the AI found evidence of the thing itself or something that only resembles it?

Don’t just check whether you agree with the answer

The research showed a significant rate of false agreement. That is when a human and an LLM give the same overall assessment based on totally different reasoning.

Unfortunately, this increases the human review burden. Even when you agree with an AI’s answer. You still need to check the thread of reasoning it used to get there.

AI in the human loop

One person in the audience offered this phrase:

“AI in the human loop”, rather than “human in the AI loop”.

That’s where most of us are at with AI assurance today. Keep the clinical assurance process human-led, then use AI where it is particularly useful.

The strongest use cases here aren’t “tell me whether this is safe.”

They’re things like:

• Find every unsupported claim.

• Show me where evidence is missing.

• Compare this against a defined rubric.

• Surface inconsistencies for a human to investigate.

• Extract the evidence relevant to this specific assurance question.

For now, I like the idea of AI in the human loop: let AI do more of the searching, sorting, comparing and challenging, while keeping interpretation, judgement and accountability with the human reviewer.

If you’re using AI in clinical safety or assurance, I’d love to hear what you’re doing with it. Just hit reply to this email.

Clinical Product Thinking Events 😍

I would love to hear what kind of events you’d love to see next on the CPT calendar. Let me know in the poll below:

Clinical Product Drinks - Tuesday!🍸

Join the next clinical product drinks! A chance to meet other clinical product leaders and managers and share the good, the bad and the ugly. 👉 Sign up here.

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 & Safety, doctor and ex-VC. Passionate about all things healthcare, healthtech and clinical product (…obviously). Based in London. You can find me on LinkedIn.

Made with 💜 for better, safer HealthTech.

Welcome, friends, this is issue No. 055 of Clinical Product Thinking. Today we’re looking at a new report that could shape how clinical AI is regulated in the UK.

Last week, the National Commission into the Regulation of AI in Healthcare published its final report. It contains 44 recommendations for how the UK should regulate AI used in healthcare. Here are the 5 takeaways I think are particularly relevant for clinical product people:

Regulation needs to follow AI after launch

One of the key themes from the report is that regulating clinical AI systems doesn’t (or shouldn’t) stop when a product reaches the market.

AI performance can change depending on:

• the patient population

• data

• clinical setting

• changes to the underlying model

• human factors, like the way a clinician uses it

The report recommends a much stronger approach to ongoing monitoring and post-market surveillance. That includes monitoring for performance degradation and appropriate escalation before an incident occurs. They also suggest a unique device identifier should be explored as a potential mechanism for traceability within the patient record, enabling audit for particular devices.

My take: A CEO said to me last week that we should think about clinical safety as part of the product build. I couldn’t agree more. If clinical AI requires ongoing monitoring, traceability and escalation mechanisms after launch, those capabilities need to be designed into the product from the beginning.

Clearer boundaries on medical devices

The report recommends clearer boundaries on what counts as a medical device, including clarifying when software intended for administrative purposes, general wellbeing and certain forms of decision support is not a medical device.

Interestingly, it recommends greater consideration of the actual design and functionality of the product, alongside manufacturer claims and promotional materials, when determining intended purpose.

My take: This could become very relevant for clinical product teams working close to the medical device boundary. Focusing on what the software actually does rather than how it’s described means clinical product decisions become even more important.

AI needs a sensible way to change post-approval

Traditional medical-device regulation assumes that products are relatively stable. AI changes this paradigm. The Commission recommends clearer approaches to Predetermined Change Control Plans (PCCPs). These could allow manufacturers to agree the boundaries within which a product can change without going through lengthy review.

Staged authorisation for AI

Another particularly interesting recommendation is so-called staged authorisation. Rather than requiring a product to be fully proven before it enters real clinical environments, an AI medical device could initially be authorised for a tightly controlled deployment.

This solves a circular problem with AI regulation. The regulator wanting real-world evidence and real-world evidence requiring the product being cleared to use.

Safe product ≠ safe deployment

A medical device may meet the requirements for regulatory approval and still be deployed unsafely. The conditions into which it is deployed can materially impact safety.

Recommendation 26 says manufacturers should specify in pre-market submissions and risk management files the operational conditions needed for safe deployment and use.

Recommendation 28 strengthens this by stating allocation of responsibilities should be included in contracts between manufacturer and healthcare provider.

So, what changes?

For now, these are recommendations rather than new regulatory requirements.

However, they give us a useful indication of where UK regulations are heading: more lifecycle monitoring, more scrutiny of what products actually do, more flexibility for controlled change and greater focus on what happens when AI enters clinical practice.

Read the full report here.

Clinical Product Drinks 🍸

Join the next clinical product drinks! A chance to meet other clinical product leaders and managers and share the good, the bad and the ugly. 👉 Sign up here.

Resources

A collection of things I’ve been reading and will be attending. Say hi to me there! 👋

📅 Digital Safety Practitioners Course | 17th September | Sign up here

📅 Patient Safety & AI Workshop | 6th October | Sign up here

📅 Introduction to Medical Device Regulation for Software and AI Technologies | Webinar series with Hardian Health | 12th November | Sign up here

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 & Safety, doctor and ex-VC. Passionate about all things healthcare, healthtech and clinical product (…obviously). Based in London. You can find me on LinkedIn.

Made with 💜 for better, safer HealthTech.

Welcome, friends, this is issue No. 054 of Clinical Product Thinking. Today we’re talking about how to setup Claude for clinical safety work.

More and more clinicians working in clinical product are finding clinical safety is becoming part of their role. There’s an obvious overlap but clinical safety is a substantial discipline in its own right and doing it properly alongside a clinical product role can be a lot.

Over the past year, I’ve been experimenting with Claude to support parts of clinical safety work. The approach is built entirely from public material plus a folder structure that Claude can easily retrieve and reason over.

This is a set up, not a case study or an ‘automated CSO’. I’ve found it to be incredibly helpful and I hope you will too!

I’ve added all of the public documents I reference in this post into a folder. You can download them for your own system here*.

Let’s dive in.

Set up

Claude works best with clear instructions, real templates and standards and worked examples where available. Luckily in clinical safety many of these are already published and freely available.

In order to get going you’ll need Cowork in the Claude Desktop app (or Code, if you’re working there instead). Either allows you to give it access to a specific folder on your machine**. Suggest you limit it to one designated folder for security purposes.

The folder structure

Below is an example folder you might like to copy. For this kind of workflow, I prefer a structured folder than dropping all docs into Claude's context.

clinical-safety/
  ├── Instructions / CLAUDE.md
  ├── 01-standards/          (dcb0129, dcb0160, guidelines, training notes)
  ├── 02-templates/          (cscr, crmp, crms, hazard-log templates)
  ├── 03-system-context/     (overview, pathway, users-and-roles, integrations, boundaries)
  ├── 04-reference-materials/ (exemplar cscr, exemplar hazard log)
  ├── 05-working-documents/  (live hazard log, crmp, crms, cscr)
  ├── 06-approved-documents/  (signed off artefacts)
  └── 07-evidence/           (architecture, testing, decisions)

If you’re working across multiple products I would consider setting up subfolders with a consistent naming convention within 03, 05, 06 and 07 and be sure to reference this in your instructions file.

Instructions / CLAUDE.md

If you’re using Claude Code this is a CLAUDE.md file at the root of your folder, read automatically. If you’re using Cowork then this will sit in the project’s knowledge as a custom instruction.

I’m deliberately not sharing my exact CLAUDE.md because it contains system-specific instructions and assumptions. I also don’t think it’s valuable to treat this as a plug-and-play exercise: the value is in configuring your own clinical safety process and evidence. To give you a jumping off point you can find an example here.

01 Standards

The DCB standards, DCB0129 and DCB0160, are the primary source for the clinical risk management requirements. I keep the standards themselves here along with any NHSE implementation guidance or other authoritative guidance I can rely on.

If you have any clinical safety training materials, notes or transcripts from sessions you’ve attended you might want to drop those here.

02 Templates

This folder should include published templates for the main clinical safety artefacts so Claude doesn’t guess if you ask it to generate a document. Obviously if you or your company have a different template you’re following include them here.

You might also want to create your own templates for things you use frequently, such as a hazard workshop agenda template based on other sessions you or your company have delivered.

03 System context

Templates and standards tell Claude what a hazard log is supposed to look like. They don’t tell it what your system actually does. Giving Claude the context of the system you are reviewing will help it ground answers into your system reality.

You might want to add context about:

• System overview

• Clinical pathway

• Users and roles

• Integrations and data flows

• System boundaries

• Risk appetite and escalation

Please don’t add anything into Claude without considering privacy and your company’s AI use policies!

04 Reference materials

Claude will work best if it has a pattern it’s matching to. If you can and again with appropriate permissions, give Claude completed worked examples of any clinical safety artefacts you have available.

You could even decide to write these yourself for a hypothetical system so it has something to work with.

You’ll want to make sure in your instructions you tell Claude to use reference materials for structure, depth, specificity but NOT to copy system facts, hazards, controls or conclusions.

05 Working documents / 06 Signed off artefacts

This one is easy. Keep Claude’s live outputs separate from the source material it is using to produce them. That will help it distinguish what is background context and what is live output. Keeping signed off artefacts in a separate folder helps Claude know what is approved and can be relied on vs what is still in draft.

07 Evidence

Clearly your clinical safety argument should be based on evidence.

Use this folder for the material that supports what is written in the safety case: architecture diagrams, test results, screenshots, decision records and other evidence about how the system actually behaves.

I’d also tell Claude explicitly: absence of evidence is not evidence that a control exists. If you cannot find supporting evidence, flag it.

What this is good for (and isn't)

I have found this system to be incredibly helpful to me but clearly this is not a substitute for CSO judgement.

This can help you draft, check thinking, do a first pass. It can’t be held accountable if something goes wrong. A CSO still needs to make clinical risk judgements and take responsibility for the clinical safety process.

Clinical safety plays an incredibly important role and this system augments their expertise, it certainly doesn’t turn Claude into a CSO.

The next level

There’s another layer to this setup. That is turning recurring clinical safety tasks into Claude skills. This deserves its own post but if you’ve also been working on this hit reply and I’d love to compare notes.

Stay safe all 👷‍♀️

*Documents last checked September 2026. Clinical safety standards and guidance change so check for the most update to date versions.

**Before putting clinical or commercially sensitive information into any AI system, check your organisation’s approved tools, data-processing arrangements and AI policy. I am not recommending that any identifiable patient information is used in this setup!

How to Build Clinical AI Patients Actually Trust 🤖

Human oversight is only one piece of building clinical AI that people can trust. At the next Clinical Product Thinking panel, we’ll go broader: how do you design patient-facing clinical AI that is safe, useful and trusted by the people actually using it?

Join us on Tuesday 8th September at 7 pm, online, for a conversation with leaders building clinical AI products in practice. 👉 Sign up here.

Clinical Product Drinks 🍸

Join the next clinical product drinks! A chance to meet other clinical product leaders and managers and share the good, the bad and the ugly. 👉 Sign up here.

Resources

A collection of things I’ve been reading and will be attending. Say hi to me there! 👋

📅 Digital Safety Practioners Course | 17th September | Sign up here

📅 Patient Safety & AI Workshop | 6th October | Sign up here

📅 Introduction to Medical Device Regulation for Software and AI Technologies. | Webinar series with Hardian Health | 12th November | Sign up here

That’s all for this week. See you next time! 👋

🤝 Work with me | 📅 Attend an event | ✍️ Send a message

Written by Dr Louise Rix, Head of Clinical Product, doctor and ex-VC. Passionate about all things healthcare, healthtech and clinical product (…obviously). Based in London. You can find me on LinkedIn.

Made with 💜 for better, safer HealthTech.

Welcome, friends, this is issue No. 053 of Clinical Product Thinking. Today we’re talking about pre-deployment testing that goes beyond model accuracy.

Safety in clinical AI systems clearly requires more than “is the answer correct?”

We seem obsessed with AI hallucinations. We spend a lot of time testing the model, but patients encounter the whole system. That includes the data and context it receives, the interface, the workflow and the surrounding infrastructure and organisation deploying it.

As such, a clinical AI safety test suite needs to extend beyond the model itself. Today we’re diving into the new Nature review, “Safety and security of large language models in healthcare”. Read the full paper by Dr Jan and colleagues here.

“Our analysis shows that large language models can meaningfully support clinical workflows. Their safe use however cannot be taken for granted. Risks arise at many stages and must be addressed systematically,” says Dr Jan Clusmann.

The clinical AI safety test suite

As you’re designing your clinical AI safety test repository, you will want to consider the following:

1. Can you make it hallucinate?

Starting with the familiar failure mode. Rather than just assessing routine outputs to medical questions, testing should be adversarial. Actively give the model situations where the correct response is to acknowledge it doesn’t know.

Examples:

• Summarise a clinical guideline that doesn’t exist

• Give the name of a fictional study and ask it to summarise the results

• Ask about a non-existent drug and ask for its side effects

You’re looking for whether it invents evidence, makes up references, or fills in missing clinical facts.

The difficulty with AI is that a wrong answer may be polished, structured and clinically plausible, which makes it hard for humans to spot. A safer system should recognise when the available evidence is insufficient and communicate that uncertainty clearly.

2. Will it agree with a wrong clinician?

We’ve all experienced AI’s tendency towards sycophancy. In a clinical setting, excessive agreeableness can have dangerous consequences.

Consider designing a test where the evidence supports one conclusion, then have the user confidently suggest another.

Change the strength of the pressure from mild to strong, repeatedly disagree or get the user to state their seniority. Look at whether the model changes its recommendation because the person seems confident.

3. Does the same patient get the same answer?

The paper recommends testing specifically for reasoning consistency; that is, does the same underlying patient case receive the same answer when it is presented with different:

• wording

• order of information

• structured vs unstructured data

• input type e.g. referral letter vs consultation note

• abbreviated clinical language vs full sentences

This matters because real clinical inputs don’t arrive as standardised benchmark questions. Two different clinicians can document a clinical presentation in entirely different ways.

If the clinical facts haven’t changed, clinically irrelevant differences in how they are presented shouldn’t materially change the recommendation.

4. Does it perform equally well for different patients?

One I hope is already top of mind: does strong overall performance hide poor performance in particular patient groups? The paper recommends subgroup performance audits across categories such as:

• age

• sex

• ethnicity

• pregnancy

• language

• comorbidities

This is particularly important in clinical product because the population you validate the system on needs to reflect the population you intend to use it with.

5. Can it find important buried clinical facts?

Context degradation is the term for when performance deteriorates as the amount of information given to the LLM increases. If your product is intended to sit across large, longitudinal health records, this becomes particularly important to examine.

Design a test that presents the system with a long clinical history and place important facts at different points within it. Those could include:

• drug allergies

• pregnancy status

• red flag symptoms

• comorbidities

Test whether moving the information to different places within the record changes the weight the model gives it.

The information being available to the model doesn’t guarantee the model will reliably use it.

6. Do clinicians notice when it is wrong?

This is particularly important when human-in-the-loop is a key risk control because it tests human-AI interaction rather than model performance alone. I wrote about this in detail in last week’s post.

In a controlled setting, deliberately expose clinicians to a known error in an AI output and measure:

• whether they notice

• how long it takes

• the types of errors that are missed

• whether it impacts their clinical decision

A model that is wrong 2% of the time presents a very different safety profile if clinicians catch almost every error than if those errors routinely go unnoticed.

Additional technical tests

The paper also recommends a whole host of adversarial security and infrastructure tests. In practice, these will often be led by engineering rather than clinical product. These will typically include things like: prompt injection, jailbreaks, data leakage and resource exhaustion.

Clinical product may not own the technical execution of these tests, but should help determine the clinical consequences if they fail.

Testing doesn’t stop at deployment

Pre-deployment testing alone is insufficient. Once a system is live, teams also need to monitor for performance drift, understand how it is actually being used, educate users, and ensure incidents and near misses feed back into the product and its safety controls.

Clinical safety in AI systems is a longitudinal task, not a point-in-time exercise.

Would love to hear how you’re designing safe AI systems - just hit reply!

How to Build Clinical AI Patients Actually Trust 🤖

Human oversight is only one piece of building clinical AI that people can trust. At the next Clinical Product Thinking panel, we’ll go broader: how do you design patient-facing clinical AI that is safe, useful and trusted by the people actually using it?

Join us on Tuesday 8th September at 7 pm, online, for a conversation with leaders building clinical AI products in practice. 👉 Sign up here.

Clinical Product Drinks 🍸

Join the next clinical product drinks! A chance to meet other clinical product leaders and managers and share the good, the bad and the ugly. 👉 Sign up here.

Resources

A collection of things I’ve been reading and will be attending. Say hi to me there! 👋

📅 Digital Safety Practioners Course | 17th September | Sign up here

📅 Patient Safety & AI Workshop | 6th October | Sign up here

📅 Introduction to Medical Device Regulation for Software and AI Technologies. | Webinar series with Hardian Health | 12th November | Sign up here

✍️ Ambient voice technology: exploring the patient safety risks (Patient Safety Learning) | Article on Patient Safety Learning Hub | Read here

📑 Evaluating Multimodal LLMs for Inpatient Diagnosis: Real-World Performance, Safety, and Cost Across Ten Frontier Models | Paper | Read here

That’s all for this week. See you next time! 👋

🤝 Work with me | 📅 Attend an event | ✍️ Send a message

Written by Dr Louise Rix, Head of Clinical Product, doctor and ex-VC. Passionate about all things healthcare, healthtech and clinical product (…obviously). Based in London. You can find me on LinkedIn.

Made with 💜 for better, safer HealthTech.

Welcome, friends, this is issue No. 052 of Clinical Product Thinking 🎉. Today we’re talking about one of my favourite topics, clinical safety in AI systems!

There’s a trend I’m seeing a lot of when it comes to clinical safety, and that is human-in-the-loop as the (perceived) ultimate control.

“Of course it’s safe. A human reviewed it!” 🤦‍♀️

I hate to burst this bubble but human-in-the-loop is not, in itself, evidence that risk has been controlled. A human review alone does not tell you whether that human is actually preventing harm.

For instance, a human can be technically “in the loop” while having almost no meaningful ability to spot, understand or correct AI failure.

A recent review in Nature highlighted this along with two particularly relevant risks: automation bias and excessive delegation.

Both are increasingly important to understand and monitor as AI becomes embedded into routine clinical practice. Let’s dive in!

Human review: The least tested safety control

Many typical clinical workflows go like this: AI reviews and generates a recommendation, clinician reviews the AI’s output, clinician approves or edits the recommendation.

The safety case might say something like: “All AI outputs are reviewed by a qualified clinician.”

This leaves many unanswered questions:

• How obvious would an error be?

• How much time are they expected to complete the review in?

• What information do they have available?

• What happens when they disagree with the AI?

• When is the AI recommendation shown?

AI changes how humans make decisions

An AI recommendation is not a neutral action on humans. It’s changes the decisions they ultimately make and this has been shown in research.

People become more likely to accept a recommendation from an automated recommendation, particularly when the system is usually right. If a major error only happens 1 in 100 times it’s unlikely a human will be as vigilant when they’re reviewing the 99th case. This is called automation bias.

Factors that make automation bias more likely:

• The output is written confidently

• The clinician is busy

• The decision feels ‘routine’

• Checking the recommendation properly is cumbersome

The counterintuitive point here is as the AI becomes more reliable, clinicians may have fewer reasons to challenge it. That can make rare errors harder to catch because vigilance falls over time.

Humans gradually leave the loop

The Nature paper describes the concept of excessive delegation - that is humans shifting from active decision-makers towards passive overseers.

Take for instance a tool that uses AI to generate clinical letters. At launch the clinicians will likely scrutinise every sentence. Six months later that behaviour may have mutated into a cursory glance.

Nothing in the workflow has changed and there’s still technically a “human in the loop”. The nature of the oversight has changes substantially though.

This makes human oversight something you need to monitor post deployment rather than assume remains an effective control over time.

Automation bias changes how much weight a clinician gives the AI’s judgement. Excessive delegation changes how much of the judgement the clinician performs themselves.

Some AI errors are inherently hard for humans to catch

The thing about AI errors is they’re not always glaring hallucinations. An output can look totally reliable but contain one small clinically consequential mistake. For example:

• An allergy omitted from a summary letter

• An incorrect dose

• An inappropriate recommendation buried within an otherwise plausible output

So, what to do about it?

Design your clinical AI product with error detectability in mind, not just reviewability. For example:

• Highlight the parts that carry the greatest clinical risk, rather than asking clinicians to review everything with equal attention.

• Make high-risk facts easy to check against source data e.g. allergies, doses, abnormal results.

• Show the source where possible rather than showing only the AI interpretation.

• For the highest risk decisions, consider requiring explicit confirmation (although this needs to be traded off against user experience).

If human review is your control, test the control

At the risk of stating the obvious… if a human review is an important control, you need to test that control. What evidence do you currently have that the review works?

For instance, during testing you could deliberately introduce clinically significant AI errors and measure:

• Error detection rate

• Which error types are missed

• How long an effective review takes

• How performance changes under workload pressure

• If detection rate changes with clinician type, speciality, or other factor

Post-deployment, you could also monitor for evidence that review behaviour is changing over time e.g.

• Decreasing time taken to review

• Lower manual edit, override or challenge rates

• Convergence between AI and final clinician decisions

• Fewer requests for additional information or review of source material

The takeaway

If you’re using “human review” as a mitigation, I suggest you think about these 5 things before launch:

• 1. Detectability: Could the reviewer realistically identify the failure?

• 2. Information: Do they have everything required to check it?

• 3. Capacity: Do they have enough time and attention to do so?

• 4. Independence: Can they form their own judgement rather than simply accepting the AI’s?

• 5. Evidence: Have you demonstrated that the review actually prevents the harm you are relying on it to prevent?

We need to start thinking of ‘human-in-the-loop’ as a shorthand for workflow design. Not as evidence of a clinically safe system.

If clinician review is one of your risk controls, you need to evaluate that clinician-AI interaction in the same way you would evaluate the model itself. That’s how we’re going to build enduring, safe clinical AI.

How to Build Clinical AI Patients Actually Trust 🤖

Human oversight is only one piece of building clinical AI that people can trust. At the next Clinical Product Thinking panel, we’ll go broader: how do you design patient-facing clinical AI that is safe, useful and trusted by the people actually using it?

Join us on Tuesday 8th September at 7 pm, online, for a conversation with leaders building clinical AI products in practice. 👉 Sign up here.

Clinical Product Drinks 🍸

Join the next clinical product drinks! A chance to meet other clinical product leaders and managers and share the good, the bad and the ugly. 👉 Sign up here.

That’s all for this week. See you next time! 👋

🤝 Work with me | 📅 Attend an event | ✍️ Send a message

Written by Dr Louise Rix, Head of Clinical Product, doctor and ex-VC. Passionate about all things healthcare, healthtech and clinical product (…obviously). Based in London. You can find me on LinkedIn.

Made with 💜 for better, safer HealthTech.

Welcome, friends, this is issue No. 051 of Clinical Product Thinking 🎉. Today we’re talking about building and evaluating trustworthy conversational AI systems.

A few months ago, I wrote a piece on behavioural safety with Dr Paul Sacher, which is the idea that conversational AI can be clinically correct but still nudge a patient towards the wrong next action.

The difficulty is that this can happen over time and in subtle ways, which means it’s hard to pick up in testing.

For instance, a conversational AI system in mental health may stay within its guardrails for the first few messages, then begin to drift into therapeutic territory, offering reassurance where it should signpost and missing the moment to escalate an important deterioration.

So this week we’re covering how to think about pre-deployment testing for conversational AI and a tool, PromptSafe, that Paul and his team have built to make it scalable. Let’s dive in.

1. One-shot tests miss the failures that hurt users most

Most testing evaluates individual responses, but your AI system holds a multi-turn conversation.

In a one-shot test, you write a prompt and score the reply against predetermined criteria. But what that misses is behaviour over time. For example:

• The AI that avoids giving medical advice for nine turns and then concedes on turn ten

• The AI that escalates correctly when risk is stated bluntly, but not when it’s coded, minimised or wrapped in humour

• The AI that resists disordered-eating framing once, then softens after repeated emotional pressure

If your product is conversational, a suite of single-turn tests is a necessary but incomplete safety control. The important failure modes often appear late in a conversation or from a user who is different from any test case.

2. Three building blocks: personas, evaluators, evidence

As you’re building your pre-deployment testing suite, consider the following:

User personas

Your user personas should be a behavioural profile, not just basic demographic information.

Good testing should include two persona types:

• Realistic personas you define: age band, occupation, context that shapes how someone shows up. A part-time admin staff member working from home talks differently about symptoms than a warehouse operative on rotating shifts. That context is what makes the conversation flow like it’s with a real user.

• Adversarial personas designed to probe behaviours or failure modes you care about most. For example, someone who expresses suicidality, repeatedly pressures for reassurance, or tries to get the AI to cross its clinical scope.

You can do this manually, and you should start there. The limitation is scale: a team might manually work through five or ten conversations, while simulation lets you run hundreds of multi-turn interactions across different personas and failure modes. That matters because rare behaviours are much easier to find when you stop relying on a handful of hand-picked conversations.

Evaluators

Evaluators are structured criteria used to assess whether an AI system behaved as intended in a given interaction.

Evaluators should be checklists of observable behaviours. You are the expert on what good looks like for your use case. The job of an evaluator is to turn a transcript into a score and feedback against your standards.

A useful evaluator structure looks like this:

• Purpose: what is being assessed

• Application: when it applies (situation, topic, risk, phase of conversation, or user behaviour)

• Evaluation method: specific observable behaviours to check for success

If you cannot point at a turn in the transcript and say whether the criterion was met, the evaluator is too vague for good governance.

But there’s another layer here: you also need to evaluate the evaluator. Small changes in how an evaluator is worded can change the judgement it produces, particularly when an LLM is doing the scoring. Evaluator design is therefore a measurement problem in its own right: you need evidence that its outputs align with expert human judgement, rather than simply assuming the evaluator is right.

In health and mental health, starter evaluators might typically look like:

• Stays within non-medical device scope and avoids unsafe medical advice

• Recognises safeguarding signals and responds appropriately (including domestic violence, coercive control, elder abuse, financial exploitation)

• Escalates appropriately: clear, proportionate signposting without over- or under-escalating

• Resists sycophancy and inappropriate compliance

• Avoids unhelpful reassurance

• Demonstrates cultural and linguistic sensitivity

There are also emerging frameworks for structuring behavioural evaluation. The FAST framework is one example, developed by Paul and colleagues, which sets out a structured approach to evaluating conversational AI behaviour.

Evidence

When the auditor, CSO, or clinical governance committee asks “how did you test this?”, you need proof.

The evidence package you need includes:

• Full conversation logs, persona by persona, every turn

• Evaluator outcomes with what the AI did well, what needs attention, and the quotes that justify the score

• Which prompt / agent version each run was made against

• What changed when you fixed something and re-ran the same suite

And this shouldn’t happen once before launch. Every meaningful change to the system- a new prompt, model, tool, workflow or product feature- is an opportunity to introduce a regression. The real value of a reusable evaluation suite is being able to run the same tests again after every significant change and see what improved, what stayed stable, and what unexpectedly got worse.

That repeatability is difficult to maintain manually at scale, and is one of the reasons dedicated evaluation tooling starts to become useful.

3. Someone has to decide what “good enough” means

An untested AI system carries reputational risk. Once it is live, the organisation owns what it says.

In healthcare, the stakes go further than a chatbot inventing a discount. A system that steps outside its scope, or misses the moment to signpost to a healthcare professional, can cause clinical harm often without anyone noticing.

So who should be in the room when you design the test suite?

• Product: intended use, scope, what “helpful” is allowed to mean

• Clinical: which behaviours matter, which red flags, what escalation looks like

• Governance / CSO: what evidence the file needs, what “good enough to deploy” means in this organisation

• Engineering: how prompts and models are versioned, how re-runs stay comparable

What CPMs should do this week

Even if you are not ready for a full simulation platform, you can raise the bar immediately:

1. Pick three behaviours that would be unacceptable to fail in production. Write each as purpose → when it applies → observable behaviours to check. Avoid vague criteria like “be safe”. Use something testable, such as: “stays within non-medical-device scope; does not diagnose or prescribe; redirects to a clinician when symptoms need review.”

2. Write adversarial conversations that try to break those behaviours. Create realistic personas and run each over 5–10 turns. Score what worked, what failed, and capture the exact AI responses that justify your judgement.

3. Change the prompt and re-run the same tests. Version the prompt, make specific changes, then repeat the same personas and checks. If you cannot reproduce the test after a change, you cannot tell whether you improved the agent or simply got a different answer.

The takeaway

Patient-facing conversational AI doesn’t usually fail in one dangerous sentence or overtly wrong reply. It fails by starting off as helpful and accurate and then slowly drifting away from what it was ever designed to do.

Behavioural safety asks the question: did this interaction move the patient towards the right clinical action? Multi-turn adversarial testing is how you stress that question before deployment, with users you’ve designed to push exactly where your agent is weakest.

The next maturity step for clinical product teams is treating evaluation like a behavioural regression suite, not a checklist of single replies.

If you want to see how Paul and the Sacher AI team have embodied this approach in PromptSafe, you can explore the method and science behind it here. Paul has also kindly created a 20% discount for CPT readers with the code CPT20.*

*I don’t receive any affiliate commission from this, and this post isn’t sponsored. ☺️

Join the next panel 🎤

Sign up for the next Clinical Product Thinking panel event on building clinical AI systems that patients actually trust. Tuesday 8th Sept, 7 pm, online. 👉 Sign up here.

Subscriber perks 🤩

Enjoying Clinical Product Thinking? Check out subscriber perks like deep dives on breaking into clinical product, embedding clinical safety into product decisions, building safe AI systems and more. 👉 View perks here.

That’s all for this week. See you next time! 👋

🤝 Work with me | 📅 Attend an event | ✍️ Send a message

Written by Dr Louise Rix, Head of Clinical Product, doctor and ex-VC. Passionate about all things healthcare, healthtech and clinical product (…obviously). Based in London. You can find me on LinkedIn.

Made with 💜 for better, safer HealthTech.

Welcome, friends, this is issue No. 050 of Clinical Product Thinking 🎉. For issue 50, we’re going back to some of the fundamentals of clinical product management: what makes a product clinical, what the role actually does, and where it tends to go wrong.

Imagine you’re a clinical product manager at an EHR company.

The team is designing an alert for when a clinician prescribes a drug the patient is documented as being allergic to. There are three options you’re considering:

A — Hard stop. Prevent prescribing entirely with no override option. Maximum safety in theory, but potentially dangerous if the allergy record is wrong or outdated because you’ve removed clinician judgement.

B — Interruptive. A pop-up that forces a pause and justification before override. Preserves autonomy, but adds time, friction and cognitive load.

C — Passive. Show the allergy clearly without interrupting the workflow. Less alert fatigue, but a greater risk that it gets ignored.

Which would you choose?

Well sometimes, as the clinical person, you don’t get to choose at all. The decision is made without you and you’re brought in afterwards to sign it off. Ergo making you responsible for risk you had little influence over.

Clinical product management exists to close that gap. So let’s dive in.

1. What makes a product clinical?

My current working definition is this:

A clinical product is any product that influences clinical decisions, clinical workflows or clinical outcomes.

Influence is the key word here. A product doesn’t need to diagnose, prescribe or treat to be clinical.

What matters is whether the product influences something clinically meaningful: how a decision is made, how care is delivered or what happens to the patient.

If you’re wondering whether a product is clinical, ask:

What clinical decision, workflow or outcome could this product influence?

2. What clinical product management actually is

Clinical product management is still poorly-defined, but mine is:

Clinical product management is embedding clinical judgement throughout the product lifecycle.

This means being involved in shaping the product, rather than advising from the sidelines or reviewing it once it is ready to ship.

If we go back to the allergy alert example the clinical product decisions might include:

• When should prescribing be blocked?

• When should override be possible?

• What level of risk justifies interrupting a clinician?

• What information needs to appear in the alert?

• What happens if the allergy data are incomplete or wrong?

Each of those choices has clinical implications, even if they appear to be product, design or workflow decisions. Asking clinical product questions throughout the lifecycle might look like:

Discovery: Are we solving the right clinical problem? What clinical decision or outcome are we trying to influence? What evidence should inform the approach?

Design: Does this reflect how care actually happens? What clinical risks could the design introduce? What safeguards are proportionate?

Build and test: Has anything changed in implementation that affects clinical behaviour? What happens in edge cases, with missing data or when users behave unexpectedly?

Deploy and monitor: What clinical outcomes or safety signals should we monitor? Who responds if something goes wrong? What would trigger intervention or rollback?

3. Turn clinical judgement into product decisions

The text book definition of clinical decision-making is:

The evaluation of evidence and the application of relevant knowledge to select appropriate interventions, providing high-quality care and minimising patient harm.

Clinical product management takes that same reasoning and applies it to decisions about how a product should work. For example:

In clinical product, you’re not making a clinical decision for a single patient. You’re translating clinical judgement into the rules, constraints and behaviours of a product that may affect many patients.

4. So what makes a good clinical product manager?

I believe a strong clinical product manager needs three things:

Clinical scepticism + product optimism + commercial literacy

Clinical scepticism means questioning assumptions, looking for risk and asking what could go wrong. Product optimism means looking for new and creative ways to solve the problem rather than defaulting to the status quo. Commercial literacy means understanding how the business makes money, where costs sit and how product decisions affect viability.

Strong clinical product managers can hold all three together. They understand the clinical downside of commercial decisions and the commercial consequences of clinical ones.

Closing

Clinical product sits in the space between clinical judgement and product decisions.

Done well, it means clinicians are not just there to identify risk. They help shape what gets built, how it behaves, what trade-offs are acceptable and how success is measured.

That requires clinical scepticism, product optimism and commercial literacy and enough involvement in the product lifecycle to use all three.

For me, that is the core of clinical product management. Would love to know your thoughts! Just hit reply and let me know.

Join the next panel 🎤

Sign up for the next Clinical Product Thinking panel event on building clinical AI systems that patients actually trust. Tuesday 8th Sept, 7 pm, online. 👉 Sign up here.

Subscriber perks 🤩

Enjoying Clinical Product Thinking? Check out subscriber perks like deep dives on breaking into clinical product, embedding clinical safety into product decisions, building safe AI systems and more. 👉 View perks here.

That’s all for this week. See you next time! 👋

🤝 Work with me | 📅 Attend an event | ✍️ Send a message

Written by Dr Louise Rix, Head of Clinical Product, doctor and ex-VC. Passionate about all things healthcare, healthtech and clinical product (…obviously). Based in London. You can find me on LinkedIn.

Made with 💜 for better, safer HealthTech.

Welcome, friends, this is issue No. 049 of Clinical Product Thinking. This week we’re talking about the skill clinical people are often judged on but are rarely taught.

Something I hear from hiring managers a lot is that clinical product managers are often clinically excellent but struggle to explain the commercial implications of their decisions. This isn’t really surprising if you think about it.

For clinicians coming from public healthcare systems, we’ve often not had to think of healthcare in monetary terms. But in HealthTech, clinical decisions affect cost, capacity and revenue, while commercial decisions can change the care patients receive.

For example, say you decide to add a mandatory clinician review to a patient flow because you’ve judged it as high risk. The review may reduce clinical risk but it also changes the cost of serving every patient.

Or if the business has decided to trim consultation length to fit more reviews into the day: you’ve changed how much time there is to catch something potentially serious.

Either decision may be reasonable but if you only consider one side, the trade-off is made without fully understanding it.

Here are 4 principles to consider as you’re building commercial nous:

1. Make trade-offs visible

A clinical recommendation is incomplete if it only describes the clinical benefit.

Take the mandatory clinician review example we discussed above.

Clinically, it might catch a missed deterioration. Operationally, you’ve added time to the pathway and that’s where the commercial hit comes from: every review costs money to serve.

None of that means you should remove the review. But it does mean being explicit about what that cost is so that the team can see the decision properly.

For any meaningful product decision, write down:

• Clinical consequence: what could this improve or put at risk for patients?

• Operational consequence: what does it mean for clinicians, support teams or workflow?

• Commercial consequence: what does it mean for cost, capacity, revenue or renewal?

• Recommendation: which option do you support, and why?

Then, when you are presenting it, lead with the consequence most relevant to the decision-maker.

2. Users ≠ customers

The user is the person who interacts with the product. The customer is who pays for it.

In direct-to-consumer weight loss, for example, they’re the same person. Simple.

But in a lot of healthtech, they’re not. An employer buys the mental health benefit. The employee uses it. An insurer funds the chronic care programme but the patient lives it.

When users and customers are different, you need to consider what good looks like for both. A happy customer does not mean the product works well for the user. And sadly great clinical outcomes do not guarantee renewal if the payer can’t see their return.

For your product, write down who uses it and who pays for it. If they’re different, ask what the payer is motivated by. That will decide whether you survive contract renewal.

3. Understand unit economics

Unit economics answer one question: is each patient, or each customer, actually viable?

You definitely don’t need to build an entire financial model. But it is helpful to understand key terms when they come up. Three worth knowing at a minimum:

Customer acquisition cost (CAC): what it costs to acquire one customer.

Lifetime value (LTV): what that customer is worth over their lifetime. Most subscription businesses want LTV to be at least three times CAC.

Contribution margin (CM): what’s left from each patient after the variable costs of serving them. This is the one clinical people move most. Clinician time, medication cost, a manual review step: every one of those impacts the contribution margin. (Bonus points if you want to learn the difference between CM1, CM2 & CM3, more here).

So when you add a safety step, you’re not just adding safety. You’re changing the economics of every single patient.

One tip is to ask someone in finance or commercial to walk you through the business’s financial model, even if informally. Understand what drives revenue, what drives cost to serve, and where clinical decisions land.

4. The model matters

A monk once told me something that has stayed with me: “Advice doesn’t work in the abstract.” And neither do product metrics!

Engagement is not a universal good. Retention is not always the goal. What either one means depends entirely on the model.

In a fixed-fee contract, engagement protects renewal - the payer wants to see people using what they bought. But it also increases cost to serve.

In a usage-based model, engagement is the revenue.

And in some models, more engagement is a warning sign, not a win. If you’re optimising for return visits in mental health or chronic care, ask whether you’re building value or building dependency.

Adoption is not the same as revenue. Retention is not the same as good care. A strong clinical product person always knows which metrics actually matter in the clinical context. They also ask the harder question: could optimising those metrics ever work against the patient? If the answer to that is yes, consider that tension as your job to own.

The takeaway

Clinical product is about building things that are not only clinically safe but also commercially sustainable, because a company that runs out of cash can’t deliver great care.

You don’t need an MBA to be successful but you do need to speak enough commercial to build influence.

Want to learn more? Check out:

📎 50 Commercial Terms Every CPM Needs to Know

A practical cheatsheet covering business models, unit economics, revenue, retention and healthcare-specific terms. 💪

Join the next panel 🎤

Sign up for the next Clinical Product Thinking panel event on building clinical AI systems that patients actually trust. Tuesday 8th Sept, 7 pm, online. 👉 Sign up here.

Subscriber Perks 🤩

Enjoying Clinical Product Thinking? Check out subscriber perks like deep dives on breaking into clinical product, embedding clinical safety into product decisions, building safe AI systems and more. 👉 View perks here.

That’s all for this week. See you next time! 👋

🤝 Work with me | 📅 Attend an event | ✍️ Send a message

Written by Dr Louise Rix, Head of Clinical Product, doctor and ex-VC. Passionate about all things healthcare, healthtech and clinical product (…obviously). Based in London. You can find me on LinkedIn.

Made with 💜 for better, safer HealthTech.

Welcome, friends, this is issue No. 048 of Clinical Product Thinking. This week we’re looking at how clinicians can break into clinical product (a path I’d definitely recommend!)

In the recent Clinical Product Thinking × Numan webinar, co-hosted with Dani Brightman, Clinical Director at Numan, one question surfaced a lot:

How do I break into clinical product… especially without existing experience?

A clinical background gives you knowledge of patients, pathways and healthcare delivery more broadly. But it does not automatically show that you can work effectively in product.

Hiring managers need to be able to trust that you understand users, can work across disciplines, make proportionate decisions, test assumptions and can connect clinical value to commercial goals.

Our panel: Alice McGee, Senior Medical Advisor at Flo Health; Jamie Webb Smith, Chief Product and Technology Officer at Numan; and Lorenzo Espinoza, Director of Product at C the Signs, have all hired, interviewed and mentored clinicians making this transition.

This is what they advised clinicians to unlearn, demonstrate and practice if they want to be successful in getting a clinical product role:

1. Unlearn Deference

Alice had an interesting answer on what clinical people need to unlearn in order to be successful in clinical product:

“The biggest one is hierarchy. In hospitals and clinics there’s a very clear structure, you might be the most junior person on the team, and what the consultant says usually goes. In clinical product, that’s not the case. Sometimes the best ideas come from the person who’s just walked in the door with fresh eyes. You need to speak up and show your contribution.” Alice

Medicine can still default to deference, but clinical product requires the opposite: you need to contribute your perspective, challenge assumptions and definitely say when you think the team is heading in the wrong direction!

A clinical product team where everyone agrees too easily is unlikely to be examining the risks, trade-offs or alternatives closely enough.

👉 What to do about it:

• In your next meeting, ask the challenging question you’re tempted to swallow.

• Practise disagreeing constructively: “Here’s a risk I’d want us to consider” is more useful than staying silent.

• Stop waiting to be the most senior person in the room before you contribute.

2. What hiring managers are looking for

Lorenzo is currently hiring a Clinical Product Lead, so his screening criteria are worth writing down. Beyond the obvious clinical background relevant to the domain (for C the Signs, that means GPs, because they build for primary care), he described three qualities:

Pragmatism. Clinical product is about finding safer and better options that the team can work on, not simply identifying reasons why something can’t be done. The best clinical product people understand risk, explain it clearly and work with the team to find a proportionate way forward.

Commercial awareness. Clinical product shapes not just what gets built, but how it reaches people. You should understand who pays for the product, why customers choose it and what drives adoption.

Collaboration. Across product, engineering and commercial. Clinical product is a team sport, not single player mode.

And the bar is rising. Jamie has interviewed clinical product candidates for four years and has watched the pool mature:

“In the early days you saw a lot of clinicians who didn’t understand product and couldn’t express things in a customer-focused way. That’s changed a lot, people frame problems really well now, and the storytelling is getting better and better: using data, market understanding, telling a story about why something matters.” Jamie

What’s still rare, and therefore what sets you apart, is an experimentation mindset and genuine commercial understanding.

👉 What to do about it:

• Prepare a pragmatism story before your interview: a time you found a safe-enough path instead of blocking.

• Learn the commercial model of any product you talk about: who pays, how it’s adopted, why it wins. (Check out my commercial cheatsheet for CPMs here)

• Show an experimentation instinct: how you’d test a risky assumption cheaply, not just assess it.

3. Think like a product person

Building product nous is probably the number one priority for aspiring clinical product people. The panel’s recommended resources:

• 📖 Inspired by Marty Cagan. Lorenzo’s first product book and still his top recommendation.

• 📬 Lenny’s Newsletter. Jamie’s go-to. Deep, practical and absolutely tons of content to sink your teeth into!

• 🧑‍🏫 Consider getting a coach. Although not the cheapest option, it can super speed your learning:

“A few sessions with someone who’s lived it will crack your head open in a different way, very quickly, and show you different patterns of thinking.” Jamie

👉 What to do about it:

• Read Inspired this month. It’s the fastest way to learn the language of product.

• Subscribe to Lenny’s Newsletter and work backwards through the archive.

• Consider a few sessions with someone who’s done clinical product (not a generic careers coach)

4. Get your first bit of experience, even if small

The hardest part is the cold start: no clinical product experience, so no one hires you for clinical product. Alice’s advice is to create the experience for yourself:

“Try to get some type of advisory work, even if it’s voluntary, a few hours giving feedback, testing a feature. And think about all the health products you already use: your Apple Watch, your Oura ring, Apple Health. Reflect on the decisions behind those features, what you like and don’t like, and translate that into how you think.”
— Alice

You are more likely already surrounded by clinical products. Start critiquing them like you would if you were building them.

The good news is that these opportunities are becoming easier to find. Alice, who curates a weekly healthtech jobs roundup, has seen clinical product roles become far more clearly defined:

“We’re seeing more and more clinical product roles, head of clinical innovation, even chief clinical product officer. Before, those would have been called something else, or just ‘medical’. Now they’re better defined, with a clear scope and a clear value-add.” Alice

👉 What to do about it:

• Offer some voluntary advisory hours to a health tech startup: feedback, feature testing, a clinical sanity check.

• Do a product teardown of an app you use (Oura, Apple Health, a symptom checker).

• Follow Alice’s weekly roundups on Linkedin for current opportunities.

The takeaway

Breaking into clinical product is about showing how you can take your clinical knowledge and use it to understand users, identify risks early, work through constraints and help a multidisciplinary team make better product decisions. You do not need the title before you begin developing and demonstrating those skills.

If you’ve been thinking about making the move into clinical product management this might be your sign to take the leap.

Welcome to Subscriber Perks 🤩

I’m very excited to introduce subscriber perks: a growing library of resources for clinical product managers and people building clinical products or health tech companies.

What you’ll find:

• Deep dives on breaking into clinical product, embedding clinical safety into product decisions, building commercial knowledge and more

• Masterclasses on building safe clinical AI systems

• A guide to writing clinical product manager job descriptions that people can actually fill

• A database of European health tech VCs, grants and other funding opportunities

• A 30-minute clinical product advisory session with me for founding subscribers

👉 Check them out here.

That’s all for this week. See you next time! 👋

🤝 Work with me | 📅 Attend an event | ✍️ Send a message

Written by Dr Louise Rix, Head of Clinical Product, doctor and ex-VC. Passionate about all things healthcare, healthtech and clinical product (…obviously). Based in London. You can find me on LinkedIn.

Made with 💜 for better, safer HealthTech.

Welcome, friends, this is issue No. 047 of Clinical Product Thinking. This week: a recap on the third webinar in the series on clinical product management, co-hosted with Dani Brightman.

When we ran the first in-person event in January, clinical product was still hugely under-recognised in health tech. Six months on it feels like things are slowly starting to shift. Roles are being named properly. Job descriptions are looking less like a dog’s dinner. And the question is beginning to shift from “WTF even is clinical product?” to “how do we do clinical product well?” 🎉

This time we deliberately widened the panel. You told us you wanted more product and technology voices, so we brought them in:

• Dani Brightman — Clinical Director, Numan (pharmacist by training, now leading biggest clinical product team in UK)

• Lorenzo Espinoza — Director of Product, C the Signs (early-stage cancer detection; 13+ years in product, 7 in health tech)

• Jamie Webb Smith — Chief Product & Technology Officer, Numan (engineer by background, ~20 years in regulated fintech before health)

• Dr Alice McGee — Senior Medical Advisor, Flo Health (doctor by background, ex-founder of a health tech consultancy)

What came out was an interesting reflection: building products that touch health needs a new kind of product leader and the companies who don’t recognise this early will end up paying the price.

Let’s dive in.

First, what is clinical product?

The reason clinical product has lived in a grey area for so long is that nobody agreed where its edges were. Dr Alice gave her definition and it’s purposefully broad:

“To me, clinical product is any kind of product that relates to health in any way, from a full-blown medical device to anything that lets a user track their health data, symptoms or outcomes.”
— Dr Alice McGee, Senior Medical Advisor, Flo Health

That’s a deliberately wide net, and it should be. The tracker that looks harmless today is one intended-use statement away from being a regulated medical device tomorrow. If your definition of “clinical” only kicks in once something is obviously a device, you run a serious risk of getting caught out.

Why it’s having its moment

Jamie made an interesting parallel and it’s not one I’ve heard before:

“I came from fintech about 10 years ago. We saw a very similar thing, regulation started to move, it started to enable innovation, and there was a real push for the larger fintechs to break through. I think it’s a similar moment in health tech, and central to that innovation is clinical thinking.”
— Jamie, Chief Product & Technology Officer, Numan

That’s the same pattern: consumer health exploding, people taking their health into their own hands, and regulation maturing from a blocker into an enabler. Fintech went through exactly this a decade ago. The companies that broke through were the ones that took the regulated core seriously and built product muscle around it. In health tech, that regulated core is clinical thinking.

The cost of not having clinical product embedded

Lorenzo has led product teams both with and without embedded clinical product people, and he was blunt about the difference. When clinical is treated as an external advisor or part-time help, it breaks down in both halves of the product process: discovery and delivery:

“We spent weeks and months solving a problem that was not the right problem to solve.”
— Lorenzo, Director of Product, C the Signs

Without clinical thinking from the start, the team can spend months building a good solution to a problem that did not need solving.

Jamie gave a concrete example of this. A company was prescribing GLP-1 medication and, after a period, renewed those prescriptions. The team Jamie was working with built the renewal flow without enough clinical product input embedded:

“A few small but critical elements weren’t right, which meant we didn’t get the information we needed at the right time for clinicians to make a good prescribing decision. So they had to go back to the patient, which creates unnecessary cycles.”
— Jamie, Chief Product & Technology Officer, Numan

That small gap meant clinicians had to contact patients again before renewing the prescription. It added work for the clinical team, delayed treatment and gave patients another opportunity to drop out. A “small” clinical oversight showed up as a revenue problem. That’s the pattern many health tech founders underestimate.

Lorenzo also described what happens when the patient experience works but the clinician workflow does not.

“Time and again we see health tech innovation that basically dies at pilot stage, because the dynamics of patients, business and clinicians are not in sync.”
— Lorenzo, Director of Product, C the Signs

You can design a beautiful patient experience that becomes ugly the moment it hits the clinician’s workflow if the end-to-end experience hasn’t been mapped from each users view point.

👉 What to do about it:

• Embed clinical product discovery, not just delivery. Most wrong-problem failures happen before a line of code is written.

• Map the clinician journey alongside the patient journey. If a feature adds work for the person on the other side of the screen, you’ll find out at pilot, the worst possible time.

• Run an early “are we accidentally a medical device?” check on intended use and marketing language. It’s cheap now and painful later.

You do not have to be a clinician to develop clinical product judgement

One thing I loved was how quickly the “clinician or product person” framing fell apart. Dr Alice pointed out that some of her strongest colleagues at Flo have no clinical background at all:

“They’ve been in the space five, six, seven years. They’re not clinical by background, but they think in a clinical product mindset now, from absorbing years of feedback and user insight.”
— Dr Alice McGee, Senior Medical Advisor, Flo Health

And it runs both ways. Jamie described what happens when product, design, engineering and clinical genuinely mix:

“You start to get real magic. It’s almost like you create a common problem-solving brain between clinical, technology and design.”
— Jamie, Chief Product & Technology Officer, Numan

That’s what companies should aim for. Not a clinician who signs things off at the end, but a shared way of thinking that lets clinicians adopt product frameworks and lets product people develop clinical instincts. The best teams build a common brain.

Where clinical product should sit (Culture beats the org chart)

We spent a good chunk on reporting lines, and the honest answer is: several structures work.

• Lorenzo (C the Signs): clinical product reports into product; the Clinical Safety Officer sits outside product to keep an independent view.

• Dr Alice (Flo Health): a medical function reporting to the CEO (a Chief Medical Officer providing C-suite representation), with a named medical advisor assigned to each product initiative.

Both set ups can work, and as Jamie put it:

“What matters more than line management is alignment on how the company operates. Small cross-functional teams with a very clear problem to solve. If your operating model is broken, line management won’t fix it.”
— Jamie, Chief Product & Technology Officer, Numan

The real answer to “where should clinical product sit?” is inside the cross-functional team, from day zero. Reporting lines vary, but clinical product needs to be involved in the team’s day-to-day decisions rather than consulted shortly before release.

👉 What to do about it:

• Do not spend too long perfecting reporting lines while clinical product remains outside the day-to-day work. Put clinical expertise into the team that is investigating and solving the problem.

• Give clinical product a proper role in shaping the solution, rather than asking for approval after the main decisions have already been made.

• Whatever your structure, consider having an independent clinical safety view (a CSO outside the delivery team) so speed never quietly overrides safety.

The takeaway

Clinical product isn’t the bit where a clinician signs things off at the end. It’s a discipline. And it sits in one very particular place: between the patient, the business and the clinician.

Health tech is having its fintech moment. The teams that win it won’t be the fastest. They’ll be the ones who got clinical thinking into the room early, and built the common brain as a strategic advantage.

Introducing Subscriber Perks 🤩

I’m very excited to introduce subscriber perks: a growing library of resources for clinical product managers and people building clinical products or health tech companies.

What you’ll find:

• Deep dives on breaking into clinical product, embedding clinical safety into product decisions, building commercial knowledge and more

• Masterclasses on building safe clinical AI systems

• A guide to writing clinical product manager job descriptions that people can actually fill

• A database of European health tech VCs, grants and other funding opportunities

• A 30-minute clinical product advisory session with me for founding subscribers

👉 Check them out here.

That’s all for this week. See you next time! 👋

🤝 Work with me | 📅 Attend an event | ✍️ Send a message

Written by Dr Louise Rix, Head of Clinical Product, doctor and ex-VC. Passionate about all things healthcare, healthtech and clinical product (…obviously). Based in London. You can find me on LinkedIn.

Made with 💜 for better, safer HealthTech.

Welcome, friends, this is issue No. 046 of Clinical Product Thinking. This week: highlights from our Clinical AI panel, on where patient-facing AI fails when the model looks fine.

A few weeks ago I co-hosted a panel on building safe clinical AI systems with Dani.

If you only have a few minutes, here’s your tl;dr. If you want to dive deeper, the full recording is below.

On the panel:

• Dani Brightman — Clinical Director, Numan

• Dr Lucinda Scharff — Product Manager, Counsel Health (formerly Google Health / DeepMind)

• Dr Paul Sacher — Founder & CEO, Sacher AI

Let’s dive in.

A bot responded correctly but still failed clinically.

Dani gave an example from Numan’s customer care side. They built a bot to filter inbound patient requests and signpost people to the right clinical form. On paper, it worked well.

In practice, it missed what a human would have caught:

“Even though the bot was handling the inbound request correctly and providing the right signposting, the clinical team noticed that if the patient was also providing context, like they want to stop medication because ‘I’m having X side effect’, what should have happened is they escalate that ticket to a clinician to review it. The bot missed this important step”
— Dani Brightman, Numan

The bot completed the task but missed the clinical significance of the patient’s context.

A clinically correct model is not the same as better care

Dr Lucinda talked through a recent paper on using AI to detect cancer on chest X-rays. AI can flag lung cancer risk on a film, but the patient still needs someone to review the result, contact them, arrange the CT and provide follow-up care.

Faster diagnosis on an X-ray doesn’t automatically result in better patient outcomes if downstream dependencies haven’t been accounted for.

A useful signal with no reliable route to action means the product isn’t finished.

Behavioural harms are the hidden risk

Behavioural risk can create or amplify clinical risk, and they’re much harder to spot: sycophancy, erosion of patient agency and failure to escalate when a patient says they’re anxious, low or questioning whether to continue treatment.

Systems designed for engagement may keep chatting when the safe move is to refer the patient to a clinician.

“If you think about the scale of behavioural interventions that are happening through patient-facing AI, you can think of the whole thing as one massive behavioural intervention… that no one’s really monitoring.”
— Dr Paul Sacher, Sacher AI

Accuracy isn’t enough if the interaction nudges the patient towards an unsafe next step.

Safety is a team sport, not a clinician sign-off

A key point of the evening was about culture. Clinicians are essential to clinical AI teams, but safety can’t belong to them alone.

If the clinician is the person who turns up at the end to say yes or no, you get slow teams, frustrated clinicians, and products that treat clinical risk as a final check rather than a design concern.

The best teams build shared safety instincts early, in the model, the interface, the pathway, the escalation route, and the assumptions about how patients actually behave.

The takeaways

The evening’s themes:

1. Correct routing isn’t enough. The system must also recognise when additional context changes the appropriate next clinical step.

2. Models need pathways. A right answer still needs a route to action.

3. Measure behaviour, not just accuracy. The harms that scale are often patterns, not single unsafe statements.

4. Safety is designed in. Not bolted on at the end by a clinician.

🎥 Watch the full panel below. Dani, Dr Lucinda, Dr Paul and I go much deeper on clinical safety in AI products, friction as a safety feature, automation bias and what teams should measure before and after deployment.

For the full write-up with practical steps, read issue 041: How to Build Safe Clinical AI Systems.

Hiring spotlight 🚀

🇬🇧 Doccla are hiring a Head of Clinical Innovation. The role will be crucial in translating Doccla's clinical model into safe, evidence-based, and commercially impactful products and pathways. 👉 Apply here.

Join the next clinical product panel 🎤

📆 14th July, 7pm, online

The next clinical product panel is on 14th July and we’ll be covering the “clinical product gap” or why healthtech needs a new kind of product leader. 👉 Sign up here.

That’s all for this week. See you next time! 👋

🤝 Work with me | 📅 Attend an event | ✍️ Send a message

Written by Dr Louise Rix, Head of Clinical Product, doctor and ex-VC. Passionate about all things healthcare, healthtech and clinical product (…obviously). Based in London. You can find me on LinkedIn.

Made with 💜 for better, safer HealthTech.

Welcome, friends, this is issue No. 045 of Clinical Product Thinking. This week: highlights from our first panel, on where clinical judgement really belongs in a healthtech org.

A few weeks ago I co-hosted the first panel in a 3-part series organised with Dani. The full video is below. But if you only have a few minutes, your tl;dr is below:

I was joined by three leaders building clinical product at scale:

• Dr Anushka Mehrotra — Chief Medical Officer, Doctor Care Anywhere

• Dr Yath Prem — Medical Advisor, Flo Health

• Dani Brightman — Clinical Director, Numan

Three very different companies yet one shared conviction: clinical product isn’t a department you consult. It’s a discipline you build in.

Let’s dive in.

1. Clinical risk hides in the places non-clinicians don’t think to look

The panel circled back to this a number of times. The dangerous decisions can be the small product choices, the colour ranges on a blood pressure reading, a portal update that looks unchanged to the clinician on the other side, that quietly carry real clinical weight.

Anushka gave an example from Doctor Care Anywhere: an update had been made to the patient facing app, but the clinician interface looked the same. Everything was actually safe, but because it didn’t look like the clinicians expected they were worried the update hadn’t been made. The lesson: end-to-end mapping has to include every user’s perspective, not just the patient’s.

Dani put the principle plainly:

“In health tech, a product decision is a clinical decision when that product is shaping patient care.”
— Danielle Brightman, Numan

The trap: clinical risk doesn’t announce itself.

2. Involve safety early, or pay for it later

There’s a myth that clinical involvement slows teams down. The panel didn’t agree. Bring clinical judgement in late and you force everyone back to the drawing board, which is slower, not faster.

Dani built Numan’s clinical product function from zero to the largest team in the UK. Her take on accountability:

“If you can’t veto, then you can’t have the accountability, because that’s completely unfair. For you to hold the real weight of clinical safety, you also need to be able to say no at times, and know you’ve got backing for that.”
— Danielle Brightman, Numan

If you’re going to hold someone responsible for safety, they need the power to block. Anything less is a set-up.

3. Integrated, not consulted

Yath made the case for what 'integrated' actually means in practice. At Flo, medical advisors sit inside cross-functional squads with a dedicated PM, design, content and engineering, meeting almost daily.

“For Flo, it’s never a question of ‘should we listen to the medical advisor?’ It’s how do we work with the advisor from the beginning. It’s never a case of ‘shall we check with the medical advisor if this is okay’, the medical advisor is always in the conversation.”
— Dr Yath Prem, Flo Health

That’s the difference between clinical input as a gate and clinical input as a default.

4. How you communicate risk matters as much as spotting it

A practical takeaway came from Dani on communicating risk so that people listen:

“We’d say ‘this process means this patient might get a double dose,’ and leave it there, because we all knew the implications. But a non-clinical person didn’t really understand how bad that was. You need to take it further: this patient comes to moderate harm, hospitalisation, that’s irreversible. Then they’re like, ‘okay, that actually sounds quite serious.’”
— Dani Brightman, Numan

And pair it with the commercial reality: the litigation exposure, the payout costs, the drop-off. Do the research first so the risk is easy to prioritise.

When the answer is “too risky,” don’t stop at no. Anushka’s rule is pragmatic option building:

“There might be an option that’s too risky, but what’s the alternative? Is there something else that can be done that isn’t as risky, that helps to control some of that risk but still partially achieves what’s trying to be done?”
— Dr Anushka Mehrotra, Doctor Care Anywhere

The takeaways

The evening’s themes:

1. Integrated, not consulted. This phrase came up again and again.

2. The constant balance of clinical and commercial. Healthcare companies are still businesses. Both pillars have to be right.

3. Option building, not just blocking. “No” is rarely the end of the conversation.

4. A shared language. Different disciplines working together in high-risk, fast-paced environments all benefit when we speak each other’s vernacular.

Which is really just one idea, said a few different ways:

Clinical review is not a sign-off step. It is a design input.

🎥 Watch the full panel below. Anushka, Yath, Dani and I go far deeper than I’ve captured here, on reporting lines, scaling safely, and what founders get wrong before they scale.

Hiring spotlight 🚀

🇬🇧 Doccla are hiring a Head of Clinical Innovation. The role will be crucial in translating Doccla's clinical model into safe, evidence-based, and commercially impactful products and pathways. 👉 Apply here.

Join the next clinical product panel 🎤

📆 14th July, 7pm, online

The next clinical product panel is on 14th July and we’ll be covering the “clinical product gap” or why healthtech needs a new kind of product leader. 👉 Sign up here.

That’s all for this week. See you next time! 👋

🤝 Work with me | 📅 Attend an event | ✍️ Send a message

Written by Dr Louise Rix, Head of Clinical Product, doctor and ex-VC. Passionate about all things healthcare, healthtech and clinical product (…obviously). Based in London. You can find me on LinkedIn.

Made with 💜 for better, safer HealthTech.

Welcome, friends, this is issue No. 044 of Clinical Product Thinking. This week, we’re talking about the workflow we think we're designing for and the work that clinicians actually do.

Many clinical products are designed around the happy path: the patient follows the expected journey, the clinician has the information they need, the technology behaves as intended, and each step leads nicely to the next. It all looks perfectly represented on your Miro process map.

This is because most product discovery starts in the same way. We interview users, run workshops, map workflows and document requirements. These activities are useful and necessary. They help us understand how a service is supposed to operate.

The difficulty is that healthcare rarely behaves exactly as it is described.

Patients do not always follow the expected journey. Clinicians are interrupted, multi-tasking, overworked or all three. Information is missing. The computer is too slow to load.

By the time a workflow reaches a whiteboard, many of those details have disappeared.

Healthcare products are often designed around the happy path because the happy path is easier to see. It is neat, predictable and easy to describe.

Clinical work rarely is.

Work as imagined vs work as done

One of the most useful concepts from safety science is the distinction between work as imagined and work as done.

Work as imagined is how we think a process happens.

Work as done is what people actually do in order to get the job done.

The difference between those two things is often where the most valuable product insights are hiding.

A workflow diagram might show a clinician reviewing information in a single system before making a decision. In practice, they may be checking multiple systems, referring to notes written earlier in the day, asking a colleague for context and mentally prioritising several competing tasks at the same time.

The process on paper is not necessarily wrong. It is simply an incomplete picture.

The 2am test

During a recent panel discussion, Benedikt von Thüngen, CEO of Sanome, spoke about the importance of getting all of his staff to shadow clinicians on a night shift. Not just product managers, engineers as well.

Some parts of clinical work can only be understood by seeing them first-hand.

That image stayed with me because it provides a useful test for any clinical product.

How would this work at 2am?

How would it work when the clinician is tired, the computer is slow, the patient is deteriorating, and the next safe action still needs to be clear?

Pay attention to adaptations

Product teams sometimes describe these behaviours as workarounds, but I think it is more useful to think of them as adaptations.

Healthcare workers adapt systems constantly. They create routines, shortcuts and informal processes that allow them to continue delivering care in environments that are often busy and unpredictable.

The adaptation itself is not usually the interesting part. The reason it emerged is.

If somebody leaves the product to find information elsewhere, that tells you something about the product. If staff maintain a spreadsheet alongside the official system, that tells you something about the workflow. If people repeatedly ask colleagues for information that should be easy to access, that tells you something about how knowledge is organised.

The goal is not to eliminate every adaptation. Many exist for good reasons.

The goal is to understand what those adaptations are trying to achieve.

Closing thought

Clinical products are often evaluated against the happy path. Clinical work is delivered in the real world.

The gap between those two things is where many usability issues, workflow problems and safety risks emerge.

Understanding that gap is one of the core responsibilities of clinical product teams because products that fit naturally into real clinical work are far more likely to be adopted, trusted and used safely.

Hiring spotlight 🚀

🇬🇧 Manual are hiring a Medical Director. I caught up with Earim, CMO, on the role and this an incredible opportunity for a visionary clinician. 👉 Apply here.

🇬🇧 Alertive are hiring a Clinical Product Director. I chatted with Kevin about this position and they are looking for a product leader to help turn its hospital communications and alerting infrastructure into safe, specialist clinical workflows as customer demand grows. 👉 Apply here.

🇺🇸 Hinge Health are hiring a Clinical Product Consultant to help them transform MSK care. 👉 Apply here.

Join the next clinical product panel 🎤

📆 14th July, 7pm, online

The next clinical product panel is on 14th July and we’ll be covering the “clinical product gap” or why healthtech needs a new kind of product leader. 👉 Sign up here.

That’s all for this week. See you next time! 👋

🤝 Work with me | 📅 Attend an event | ✍️ Send a message

Written by Dr Louise Rix, Head of Clinical Product, doctor and ex-VC. Passionate about all things healthcare, healthtech and clinical product (…obviously). Based in London. You can find me on LinkedIn.

Made with 💜 for better, safer HealthTech.

Welcome, friends, this is issue No. 043 of Clinical Product Thinking. This week, we’re talking about scaling, safety and how to spot risks before they become incidents.

Last week I hosted an event at HLTH Europe on how to safely scale digital health. One of the big takeaways from the panel; Dani Brightman, Numan, Benedikt von Thüngen, Sanome and Dr Elle Clarke, Heim was this:

Scale doesn’t create risk. it reveals where it was already hiding.

Or more precisely: scale exposes weak points that were being silently patched by people, process and clinical judgement.

Scale doesn’t create risk. It reveals it.

As products scale, you’re not just handling more patients or more data.

You’re stress-testing whether your system actually works or whether it only looked like it worked because people were quietly holding it together.

At small scale, that gap is invisible.

You find:

• clinicians making judgement calls because SOPs aren’t fully clear

• ops teams fixing broken workflows in real time

• support repeatedly explaining things the product should have made obvious

• manual reviews catching errors the system itself is generating

This is the “invisible layer” of early success.

The hidden work behind early success

Early products almost always depend on invisible labour. And that’s not a mistake, it’s how to learn incredibly quickly.

But there is a catch.

At small scale, teams sit close to users. They absorb problems quickly. That can create the illusion that the product is more robust than it actually is.

Because:

• A workaround can solve a problem without solving the underlying cause.

• A manual review process can catch errors without improving the system that creates them.

• A person stepping in can protect patients without revealing that the product needs redesign.

The risk is not that teams do this.

The risk is not being aware that these workarounds exists.

Scaling safely requires changing the way you think about problems

In early-stage clinical products, clinicians are often operating at maximum capacity.

That makes it understandable that workarounds emerge without much time being spent stepping back to redesign the system itself.

But there’s an important shift that happens as you move towards scale:

Investigating problems properly and building better solutions takes time. It’s an upfront investment for a later payoff and it rarely happens by default.

That’s why teams either need to be:

• explicitly incentivised and supported to do this work, or

• structured with a dedicated function (like clinical product) whose job is to translate clinical friction into system improvements

Otherwise, the same people who are holding the system together day-to-day never get the space to redesign it.

Scaling safely means redesigning where work happens

When something breaks at scale, the instinct is often to add process.

But what actually matters is shifting where work sits:

From:

• human judgement under pressure

• manual interpretation

• repeated explanations

To:

• product design

• system logic

• clear escalation paths

• monitoring and feedback loops

This is the shift that determines whether scaling creates fragility or removes it.

Finding the risks before you scale

If you’re on the precipice of scale some useful exercises for you:

1. Find the workarounds

Ask your users:

• What do you check manually?

• What questions do people repeatedly ask?

• Where do you use spreadsheets, notes or other tools?

• What do you do outside the product to complete this task?

• What problems do you message team members about repeatedly to try to solve?

These workarounds are evidence of where the system can be optimised.

2. Run a 10x stress test

Take one important workflow and ask:

“What breaks if volume increases 10x tomorrow?”

Look at:

• response times

• manual reviews

• escalation processes

• points where a person has to intervene

• decisions that depend on individual judgement

Most fragility shows up here immediately.

3. Watch the real workflow, not ideal one

Spend time observing how people use the product in their normal environment.

Look for:

• where people pause

• where they create shortcuts

• where they ask colleagues for help

• where they interpret information differently

• where they leave the product to do something else

These often show where the product needs to change.

4. Track emerging operational risk explicitly

Teams usually track features they want to build.

They should also track areas that may become difficult as usage increases.

Examples:

• manual processes

• unclear escalation routes

• customer-specific variations

• inconsistent patient journeys

• data that is difficult to monitor

• features that create complexity without improving care

These are the areas most likely to become problems later.

A final reframing

Scaling a clinical product is often framed as an engineering or regulatory challenge.

But the panel made a different point: It’s actually a visibility problem.

At small scale, you can miss what’s broken because people are quietly fixing it.

At large scale, you can’t.

Which means the real work of scaling safely is not just building more product.

It’s removing dependence on invisible heroics and replacing them with systems that behave the same way at 10 patients as they do at 10,000.

Hiring spotlight 🚀

🇬🇧 Manual are hiring a Medical Director. I caught up with Earim, CMO, on the role and this an incredible opportunity for a visionary clinician. 👉 Apply here.

🇺🇸 Hinge Health are hiring a Clinical Product Consultant to help them transform MSK care. 👉 Apply here.

HLTH you were a vibe 😆

So great to see many of you in Amsterdam.

Join the next clinical product panel 🎤

📆 14th July, 7pm, online

The next clinical product panel is on 14th July and we’ll be covering the “clinical product gap” or why healthtech needs a new kind of product leader. 👉 Sign up here.

That’s all for this week. See you next time! 👋

🤝 Work with me | 📅 Attend an event | ✍️ Send a message

Written by Dr Louise Rix, Head of Clinical Product, doctor and ex-VC. Passionate about all things healthcare, healthtech and clinical product (…obviously). Based in London. You can find me on LinkedIn.

Made with 💜 for better, safer HealthTech.