Software as a Medical Device Regulation: 101 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. 011. Today, weâre diving into software as a medical device for those new to regulation.
If youâre a Clinical Product Manager (CPM) stepping into the world of software as a medical device (SaMD) regulation can feel like, and quite frankly is, an entirely new language.
Acronyms everywhere. Risk classifications. Conformity assessments. Clinical evaluation reports. Itâs like starting on the wards all over again.
But hereâs the thing: If you want to build software that has clinically meaningful functionality, regulation needs to be your best friend, not your enemy.
Weâll start with the fundamentals today, your orientation before diving into the juicier SaMD topics with experts like Benedikt von ThĂŒngen (Sanome), Kieran McLeod (Heidi Health) and Dr Dom Pimenta (Tortus AI).
What counts as a medical device?
A medical device, including software, is any product intended for human use that diagnoses, monitors, or treats a disease or injury, supports or replaces body functions or provides information for clinical decisions.
The critical word here is intended.
Itâs your productâs intended use, not its features, that determines whether itâs a device.
đ A wellness app that tracks steps? Probably not a device.
đ An app that analyses gait data to detect Parkinsonâs? Almost certainly is.
If your product influences clinical decision-making, diagnoses or interventions, best to assume itâs a medical device until proven otherwise.
The MHRA has a handy flowchart for SaMD classification. Bookmark it for whenever that âdo we need to be regulated?â debate comes up again.
Building a digital mental health product? Be sure to check out the new MHRA guidance here.
There are some nuanced differences for digital mental health companies that wonât be covered in this post.
How are devices classified?
In the UK and EU, devices are classified by their level of risk into four main classes:
It wonât be a surprise that the higher the class, or risk, the greater the regulatory scrutiny and the more evidence youâll need.
Class I devices are currently self-certified and donât need an approved body (more on this next). This means companies can often achieve class I in around 3 months.
Who regulates and what standards apply?
In the UK, the MHRA (Medicines and Healthcare products Regulatory Agency) oversees devices. They designate approved bodies to carry out conformity assessments to check that your device meets the required safety and performance standards. In the EU, these are called notified bodies.
There are nine approved bodies listed in the UK. You can find them here. Weâre a big fan of the folks at Scarlet, who specialise in software and AI.
For software and digital health, youâll hear these key frameworks a lot:
EU MDR / UK MDR 2002: Core device regulation. (More on this below)
ISO 13485 (Medical Device Quality Management Systems): This is foundational for your quality processes and procedures, covering product development and delivery, document management, competence and training and quality assurance. Think of it as the operating system of your product.
ISO 14971 (Medical Device Risk Management): Outlines considerations for risk management, particularly concerning clinical and patient safety and provides a framework for addressing these risks. Fun fact: the DCB standards originate from this ISO so youâll find similarity in the principles.
Some more letters and numbers youâll hear often:
DCB0129/0160 (Clinical Safety): Products are assessed to ensure clinical safety measures are in place and that organisations undertake clinical risk management activities. This includes compliance with standards like DCB0129 for manufacturers i.e. startups.
IEC 62304 (Medical Device Software Lifecycle): Specifies requirements for structuring your software lifecycle, including verification and validation, usability and risk management.
IEC 62366 (Usability Engineering): Defines how to design and evaluate your product to ensure it can be used safely and effectively by intended users, focusing on human factors and user interface design.
You donât need to memorise them but you do need to know they exist and what function they serve in the product lifecycle.
đ Finding this post useful? Please consider restacking it to help build the Clinical Product community. đ
Side bar: EU vs UK
Youâll notice reference both the EU MDR and UK MDR above. Hereâs why:
Before Brexit, the UK followed the EU Medical Devices Directive (MDD). After Brexit, it retained this framework through the UK Medical Devices Regulations 2002 (UK MDR 2002), which are now maintained and enforced by the MHRA.
The EU MDR (Regulation (EU) 2017/745) came fully into effect in 2021, introducing stricter requirements for clinical evidence, safety, and post-market surveillance. At present, Great Britain continues to recognise CE-marked devices until 30 June 2030 (thereâs also a possibility the MHRA will introduce the concept of indefinite recognition for CE-marked devices in the UK).
This means:
If your product is marketed in both the UK and EU, youâll need to comply with both MDRs and refer to both in your technical file (more about this next week).
The safest approach is to design to EU MDR standards (theyâre stricter) and adapt as needed for UK requirements.
âïž Practical takeaway for new CPMs
Bookmark the MHRAâs guidance. Youâll use it often to check whether a feature tips your product into medical device territory.
Clarify your intended use early. This single statement is vital in determining your productâs risk class, evidence requirements and regulatory pathway.
Know your class. If youâre in Class IIa or higher expect deeper scrutiny, clinical evaluation and an external conformity assessment.
Understand who regulates you. If you operate in both the UK and EU, youâll need to align with both UK MDR and EU MDR frameworks.
Familiarise yourself with key standards. ISO 13485 (quality), ISO 14971 (risk) and IEC 62304 (software lifecycle) will shape how your team designs, tests and documents the product.
Donât fear the letters and numbers. Youâre not meant to master them overnight, just know what they govern and who in your team owns them.
đ± Building a wellness app or medical device and not sure about regulation or classification? Iâve built an AI Head of Regulatory*.
đ Send me your URL or a description and Iâll share a free regulatory assessment.
In next weekâs post, weâll dive into the engine room of regulation, your QMS, technical file and the evidence that brings it all to life.
*This isnât a generic customGPT. Itâs custom-built in Cursor, designed as an AI regulatory co-pilot trained on UK MDR, EU MDR, and DCB standards to give tailored classification and compliance guidance.
Join the Next Event đ
đ 12th November - Clinical Product Dinner: Regulation Without Killing Innovation
With Dr Dom Pimenta, CEO & Founder of Tortus AI, empowering clinicians with advanced AI through their Class I medical device - sold out in just a few days.
If you missed out, donât worry the next event is in Jan. 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 đ
25 Nov | Hash It Out: Regulating AI in Healthcare | London, UK: Hosted by Hale House, in partnership with Assuric. This event will cover the future of AI healthcare regulation. (đ Say hi to me there!)
Post | New online NHS hospital service by 2027, PM to promise: BBC News reports that the UK Prime Minister will announce an NHS online hospital service within two years to help cut waiting times.
Post | To SaMD or not to SaMD: A new whitepaper by Avegen and 8FoldGovernance explores how embracing Software as a Medical Device (SaMD) early can unlock scalable, evidence-based digital health innovation.
Post | Digital Health Technology Compliance With Clinical Safety Standards In the National Health Service in England: A JMIR study finds that across Englandâs NHS, over 14,000 digital tools are in use, but only 17% meet DCB0129/DCB0160 standards while ~70% lack assurance, posing major safety and legal risks.
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.
Very informative as always. Thanks for sharing Louise.