Software as a Medical Device: Part 2 for CPMs

Your weekly newsletter on all things clinical product and building better healthcare 🏥

This is Clinical Product Thinking 🧠, your weekly newsletter featuring practical tips, frameworks and strategies from the frontlines of clinical product.

Hello friends, this is issue No. 012. Today, we’re following up on our intro to software as a medical device regulations and covering more foundational topics CPMs need to know.

Last week, we covered device classification and regulatory bodies/standards. However, once you’ve crossed the line into “we are a medical device”, you need to start thinking about your regulatory engine:

• the Quality Management System (QMS)

• the technical file

• the clinical evaluation

…and how they quietly change your day-to-day as a Clinical Product Manager.

QMS: Your New Operating System

A Quality Management System (QMS) is the formal way you prove to regulators that you are building safe, consistent products in a controlled, repeatable way.

For medical devices, the recognised international standard for QMS is ISO 13485.

You don’t need to memorise the clauses, but you do need to understand what a QMS changes for product.

Before QMS

• Specs live in Notion, Jira and random Google Docs

• Decisions live in people’s heads and Slack DMs

• Releases are: ‘we think this is safe because it passed testing’

After QMS

• Requirements, risks, tests and releases are traceable

• Changes follow a controlled process

• Evidence is collected deliberately because it feeds the technical file (more on this later)

For a Clinical PM, the key QMS concepts are:

• Document control: product specs, risk assessments, usability reports all have owners, versions and approvals.

• Design controls: you can map from intended use → user needs → system requirements → tests.

• Change control: ‘we’ll just tweak that algorithm’ becomes ‘we’ll raise a change, assess risk and impact, then implement and re-verify.’

As a CPM, you don’t need to run the QMS, but you do need to stop treating it as a compliance tax and start treating it as essential.

A QMS is basically good product practice…just done properly, every time.

The Technical File: Your Regulatory Single Source of Truth

If the QMS is the operating system, the technical file (called the design dossier for Class III devices) is the project folder for the device itself.

It’s what your Approved/Notified Body will actually read.

At a high level, it has to prove four things:

1. What the device is and what it’s for

2. That it is safe and performs as intended

3. That you understand its risks and have controlled them

4. That you can keep it safe over time

In practice, that means sections like:

• Intended use and device description

  • The one-sentence intended use statement

  • High-level architecture (including software for SaMD)

• Design and manufacturing information

  • Requirements, architecture, implementation overview

  • For software: IEC 62304 artefacts (lifecycle, versioning, change history)

• Risk management file (ISO 14971)

  • Hazards, hazardous situations, harms

  • Risk controls and evidence they work

• Clinical evaluation (MEDDEV 2.7/1 Rev. 4 style)

  • State of the art

  • Clinical data (own, literature, equivalence)

  • Benefit–risk conclusion

• Usability and human factors (IEC 62366)

  • How you designed for real users

  • Summative testing of critical tasks

• Verification and validation*

  • Test plans and reports

  • Performance metrics (especially for algorithms)

• Post-market surveillance and PMS/PMCF plans

  • How you will monitor safety and performance post-launch

*As you get deeper into regulatory writing, you’ll see two annoyingly similar terms a lot: verification and validation. In simple terms:
Verification asks, ‘Did we build it correctly?’
Validation asks, ‘Did we build the correct thing?’

Clinical Evaluation: Proof That the Thing Actually Helps

Regulators do not accept ‘we think this works’ as a safety strategy.

A clinical evaluation is the structured way you answer three questions:

1. What does the device claim to do, in which patients and settings?

2. What is the current state of the art?

3. Does your device’s benefit–risk profile stack up against that?

The blueprint is MEDDEV* 2.7/1 Rev. 4, which both UK and EU still use as a core reference.

*MEDDEV is simply the name for the EU’s guidance documents. They were created to help manufacturers and regulators interpret the medical device regulations in practice, and mainly applied to the old MDD, which the UK still follows under UK MDR. For the newer EU MDR, these have largely been replaced by the Medical Device Coordination Group (MDCG) guidelines.

In practical terms, a clinical evaluation will include:

• Intended purpose and claims

  • The exact language you use in instructions for use and marketing

  • The outcomes you imply (e.g. “reduces readmissions”, “improves diagnostic accuracy”)

• State of the art

  • How the condition is currently diagnosed/treated/monitored

  • Alternative technologies and their performance

• Clinical data for your device

  • Literature on equivalent devices or similar algorithms

  • Your own data from studies, pilots, real-world use

  • Clear methods and limitations

• Benefit–risk assessment

  • Synthesised conclusion: is the device safe and clinically beneficial relative to standard practice?

⚙️ Practical Steps for Clinical PMs

If you want to get good at the regulatory engine, here’s where to start:

1. Get clear on your intended use

Make it one sentence. Make it crisp. Make it defensible.
Everything downstream depends on this.

2. Map user needs → requirements → risks → tests

Build a simple traceability flow in a Google Sheet or Notion.
If you can trace it, you can defend it.

3. Treat pilots as evidence-gathering, not feature tests

Decide upfront:

• What outcomes are we measuring?

• What data will be usable in the clinical evaluation?

4. Start your risk thinking early

Before you design the feature, ask:
“What are the realistic clinical risks and how will design mitigate them?”

5. Always ask: “What claim are we making?”

And: “Where will this live in the clinical evaluation?”
This single question will save you from over-claiming and under-proving.

6. Make friends with QA/RA

They’re not blockers, they make you faster in the long run.
Regularly sync on:

• intended use

• risks

• evidence

• design changes

• upcoming audits or reviews

7. Don’t wait for ISO 13485 to behave like you’re in ISO 13485

Good product hygiene becomes regulatory hygiene. If you do it early, you’ll never fear audits or submissions.

Master this engine, and you don’t just ship compliant products, you ship products that clinicians trust, patients rely on and regulators respect.

Further Reading 💡

Bookmark these docs for future:

• MHRA Guidance on Medical Device Standalone Software – The UK’s key SaMD document

• MEDDEV 2.1/6 – Qualification & Classification of Standalone Software

• MEDDEV 2.7/1 Rev. 4 – Clinical Evaluation

• MDCG 2020-1 – Clinical Evaluation of Medical Device Software

---

Clinical Product Dinner 💁‍♀️

With Dr Dom Pimenta, CEO & Founder of Tortus AI. Truly a masterclass on how to build regulated AI products at pace. Look out for the write-up coming next week!

The next Clinical Product Thinking event will be in January. Stay tuned here.

---

Hiring Spotlight 🚀

Dr Arun Notaney, founder and CEO of GP Automate, is hiring a Head of Product.
I caught up with Arun about the role. He’s a practising GP partner who’s built an impressive organisation automating primary care workflows. This position would be perfect for an experienced, product-leaning CPM. 👉 Apply here.

---

From the Community 💡

A few highlights from the Clinical Product community this week 👇

• Post | 2025: The State of AI in Healthcare: By Menlo Ventures, how AI is being adopted across healthcare settings.

• Post | Will AI will transform Healthcare through the back door?: By Dr Keith Grimes, a write up on the recent Co-Pilot launch in the NHS and thoughts for patient safety.

---

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.