Software as a Medical Device: classification explained

Software sits on a line that is easy to cross without noticing. The same underlying algorithm can be a wellness product or a Class IIa medical device depending entirely on its intended purpose and the claims made about it. Founders usually discover which side of the line they are on after the claims are already on the website and in the app store listing, which is the expensive way round.

Classification depends on intended purpose, not technology

Two products can be technically almost identical and sit in completely different regulatory categories, because classification follows what the software claims to do, and what decision or action it drives, not the underlying code. A step counter that just counts steps is not a medical device. The same sensor data, claimed to detect atrial fibrillation, almost certainly is.

The three questions that actually decide classification:

1. What does the software claim to diagnose, monitor, treat or predict?
2. What decision or action does the output drive? Information for a clinician’s judgement sits differently to software that directly triggers treatment.
3. What happens if the software is wrong? Higher clinical consequence generally means higher classification.

Getting this wrong costs money in both directions

Over classifying adds regulatory burden a genuinely low risk product does not need. Under classifying means launching something that cannot legally be placed on the market as marketed, and finding that out after launch is far more expensive than a classification conversation before it.

IEC 62304 and the software lifecycle

Once software is confirmed as a medical device, IEC 62304 governs the 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 materially different from typical commercial software development documentation, and treating it as an afterthought is one of the most common reasons a SaMD file fails review.

AI specifically raises the stakes

AI driven diagnostic or decision support tools frequently sit at the higher end of classification, because of the clinical decisions they influence. This is exactly the profile UK and EU regulators are paying closest attention to, and the MHRA’s own AI Airlock programme exists specifically because AI as a medical device raises questions the existing framework was not built around.

Cybersecurity and post market surveillance are not optional extras

Software as a medical device carries ongoing obligations many 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 an unrevisited plan. Both need building into the file from the start, not added before submission.

Where to start

A free classification conversation before anything is published is the cheapest way to find out which side of the line your software sits on. Paul Rowden has built SaMD files across diagnostic, monitoring and clinical decision support software, and will tell you plainly where you stand.