Clinicians as Builders: How Claude Code Changes Everything
The people who understand the problems finally have the tools to build the solutions
This is Clinical Product Thinking 🧠, a weekly newsletter featuring practical tips, frameworks and strategies from the frontlines of clinical product.
Welcome, friends, this is issue No. 035 of Clinical Product Thinking. This week we’re diving deep into Claude Code and the clinicians-as-builders movement.
The next generation of clinicians will practise medicine through the products they build, not just the patients they see… Dr Keith Grimes via Bitelabs
Until now most healthcare innovation has happened at a distance from the people experiencing the pain points. That space is starting to collapse.
On Thursday, I joined the Claude Code for Healthcare talk by Anthropic, where clinicians were building tools live on stage. Each product built by someone who has felt the problem and now had the ability to act on it.
This shift is worth paying attention to.
The rate-limiting step is moving
The bottleneck in building products has typically been engineering capacity. Claude Code and tools like it are quietly moving it somewhere much more interesting.
As one of the speakers put it: “The rate limiting step is no longer learning HTML or JavaScript. It’s: do you understand the problem well enough?”
The implication of this is big. Clinical insight, the thing CPMs and practising clinicians have always brought, has just become way more valuable, not less.
Signal: Problem selection is now the scarce skill. Prototyping is becoming commodity. Production still isn't.
Pocket knives over platforms
One of my favourite framings from the talk was the “pocket knife” analogy. Plenty of clinical problems can be solved by a small, focused tool that does one thing brilliantly, without reaching for a Swiss Army platform every time.
A few examples from the demos:
A newborn note generator that could be adapted for Saudi newborn screening, a Californian paediatric practice, or a UK neonatal unit with small tweaks. This was built live during the call!
An air quality dashboard, one built for patients, clinicians and public health authorities. The fun twist: make it Gen Z and add main character energy.
Pre-visit tools that gathered patient history in plain language and translated it into a clinically structured summary, and post-visit tools that walked patients through their diagnosis, medications and follow-up in language they could actually use.
Same underlying pattern each time: small tools, doing focused work, built by the people who feel the pain directly.
Where I get cautious
I want to hold two things at once here. First, this is a genuine shift. Clinicians have never had this much creative latitude over their own tooling.
Second, a prototype is still a long way from a product. Some risks to put on your radar:
Shadow IT creeping into clinical settings. A clinician who emails around an HTML file containing patient data has just created a governance incident, however elegant the tool. Privacy, security and audit trails do not disappear because the build was easy.
Local optima masquerading as solutions. A tool that is perfect for one clinician’s workflow can be almost impossible to generalise, maintain or safely scale. Brilliant in one pair of hands. Risky across a department.
Problem expertise being mistaken for product expertise. Feeling the pain is necessary but not sufficient. Good product still requires prioritisation, usability research, workflow integration, behavioural insight and commercial thinking.
Compliance being underplayed. As far as compliance goes the talk seemed to conclude: “Ask Claude, then ask a lawyer” which is a very incomplete regulatory strategy. DCB0129/0160, UK MDR, EU AI Act classification, DPIAs, supplier due diligence, data processing agreements: none of these become optional because the build was faster.
Signal: Build has democratised. Governance has not.
The distribution problem nobody solved
The demos were compelling. The deployment story was thinner.
Even if a clinician prototypes a tool in an afternoon, getting it safely used across a department, a practice or a trust remains genuinely hard. APIs help. FHIR helps. TEFCA in the US and the interoperability work happening here in the UK help. But the real blockers tend to be structural: procurement cycles, vendor lock-in, information governance committees, local IT politics, and the question of who carries the responsibility when the tool does something unexpected in production.
Distribution remains an unsolved layer.
Practical takeaways
If you work in or around clinical product and you haven’t tried Claude Code yet, I highly recommend giving it a go. You can use it via the terminal (scarier but more powerful) or via the browser or desktop app (friendlier starting point).
The hardest part is just getting started. If you don’t know where to begin, steal this:
I’m a clinical product manager building a [one-line product description, e.g. “post-natal symptom tracker for women in the first six weeks after birth”]. I want to draft a PRD.
Before we start, help me write a clear intended use statement in one sentence, covering who uses it, in what setting, for what clinical purpose, and what it explicitly does not do. Ask me any clarifying questions you need to get this right.
Once we have the intended use, draft a PRD that includes:
Problem statement and user personas (both clinician and patient)
Intended use and out-of-scope uses
Clinical risk considerations and likely hazards
MHRA medical device classification assessment with reasoning
Evidence plan (what we’ll need to demonstrate the tool works)
Success metrics framed as clinical outcomes, not engagement
Open questions and assumptions that need validating with users
Where you’re uncertain, flag it clearly rather than guessing. Where clinical or regulatory nuance matters, err on the side of caution and tell me what you’d want a CSO to verify.
If you start building your own tools, let me know how you get on (just hit reply) and please, no patient data!
The clinician builder moment is arriving. Clinical product is how it gets to real patients safely.
Join the next clinical product panel 🎤
In May, June and July Danielle Brightman and I are hosting 3 panel events spanning the most pressing questions in clinical product management. Tickets have been going fast. 👉 Sign up here.
Join us at HLTH Europe 🇪🇺
Danielle Brightman and I are running a panel event on clinical product with two incredible guest speakers. If you don’t know about HLTH, it’s the health tech conference you absolutely cannot miss.
👉 Register your interest for the panel here.
🎟️ Get your HLTH ticket here. (Use code: HE26PP_CPT250 for €250 off your ticket!)
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.
Join the next clinical product coffee & chat ☕️
Trialling a new format over the next 3 months, a monthly small group chat where we discuss what’s coming up for you in clinical product and your most pressing questions.
