Software / SaMD
Software as a Medical Device (SaMD)
Software sits on a line that is easy to cross without noticing. The same algorithm can be a wellness product or a Class IIa medical device depending on what it claims to do, and that decision drives classification, clinical evidence and the route to market. Great Britain still classifies under the old directive rules while the EU MDR uses Rule 11, so the same software can land in a different class in each market. Founders usually discover which side of the line they are on after the claims are already published, which is the expensive way round.
Classification comes first, always
Whether software is a medical device at all, and which class it falls into, depends on its intended purpose, the claims made about it, and what decision or action it drives. Two products that look almost identical technically can sit in completely different regulatory categories because of how they are described.
Getting this wrong in either direction costs money: over classifying adds unnecessary regulatory burden, under classifying means launching something that legally cannot be placed on the market as marketed.
IEC 62304 and the software lifecycle
Once software is confirmed as a medical device, IEC 62304 governs the software development lifecycle: planning, requirements, architecture, detailed design, implementation, verification, and maintenance, each with documentation a Notified Body or the MHRA can actually review. This is different in kind from typical product development documentation, and treating it as an afterthought is one of the most common reasons a SaMD file fails.
Cybersecurity and post market surveillance
Software as a medical device carries ongoing obligations most hardware manufacturers do not face in the same way: cybersecurity risk management through the product lifecycle, and post market surveillance that has to actually track real world performance rather than exist as a plan nobody revisits. We build both into the file from the start rather than bolting them on before submission.
Questions we get asked
Is my app or software definitely a medical device?
It depends entirely on its intended purpose and the claims made about it, not on the underlying technology. A free classification conversation before anything is published is the cheapest way to find out.
Does AI in my software change the classification?
It can. AI driven diagnostic or decision support tools frequently sit at the higher end of classification because of the clinical decisions they influence, which is where the UK and EU regulators are paying most attention.
What does IEC 62304 actually require in practice?
A documented, traceable software development process from requirements through to maintenance, proportionate to the software safety class. We assess what you already have against it before saying what is missing.
Guides on Software and SaMD
Not sure where you stand on this?
Book a free consultation, or start with a fixed fee Gap Assessment. No pitch. If it's already handled, we'll tell you that.
Free download
Get the 2026 to 2028 Deadline Survival Kit
A plain English map of every MDR, IVDR and EUDAMED date, and what to do before each one. Sent straight to your inbox.
No spam. Unsubscribe in one click. We never share your details.
Related services
UK Responsible Person
Your registered UK Responsible Person for the MHRA. We hold your file, handle registration and stand as your point of contact in Great Britain.
EU Authorised Representative
Your EU Authorised Representative based in Cork. One partner covers both the UK and the EU after Brexit, on a single contract.
CE and UKCA Marking
Technical files and design dossiers built to pass. More than 500 CE technical files built and approved.