SaMD or not? How to tell if your software is a medical device
You have built a health app. Users like it. Then someone asks: “Is this a medical device?” The answer decides your roadmap, your budget, your timeline and your quality system. Getting it wrong is expensive in both directions. We see this question at Thaumatec almost every week, so here is how we approach it.
It starts with intended purpose
Regulators do not care what technology you use. They care what you say the software is for.
Under the EU MDR, software is a medical device if the manufacturer intends it for a medical purpose, such as diagnosis, monitoring, prediction, prognosis or treatment. The FDA and the IMDRF use similar logic and call it Software as a Medical Device (SaMD).
Intended purpose comes from your website, your marketing, your app store description and your user manual. If your materials say “detects arrhythmia,” you have made a medical claim. The code does not need to change for that to count.
Quick self-check
- Does the software process patient data to produce new medical information? A risk score or an abnormal result flag usually qualifies. Storing or displaying data usually does not.
- Does it influence a clinical decision? Software that suggests a diagnosis or a dose is in scope.
- Does it control or affect another medical device? If it adjusts an insulin pump, it is part of the device system.
- Does a medical claim appear anywhere in your materials? One sentence can change your status.
If you answered yes to any of them, plan for regulation.
- Typically not a medical device
- General wellness apps (step counters, meditation, sleep tips)
- Software that only archives, transfers or searches records
- Administrative tools such as scheduling and billing
The line moves quickly. A wellness app that starts to “detect early signs of depression” has crossed it.
Typically a medical device
- Algorithms that analyze ECG, imaging or lab data
- Apps that calculate dosing or treatment plans
- Software that monitors vital signs and triggers clinical alerts
- AI-based diagnostic support tools
Under MDR Rule 11, most decision-support software lands in Class IIa or higher. That means a Notified Body review, and many teams are surprised by it.
Why early classification pays off
Classification drives everything that follows: the IEC 62304 software lifecycle, ISO 13485 quality system, ISO 14971 risk management, clinical evaluation and cybersecurity documentation.
Find this out after launch and you face rework. Retrofitting traceability, risk files and verification evidence into a finished codebase is slow and costly. Find it out before the first sprint and you design for it from day one.
So you have SaMD. What now?
This is where Thaumatec comes in. Regulated medical software is all we do, so we can support you at every stage:
- Before development: we review your intended purpose and help you work out your likely classification under MDR/IVDR and FDA rules, so you know what you are signing up for.
- During development: we build your software in line with IEC 62304, with risk management, requirements traceability and cybersecurity built into the process instead of added at the end.
- After release: we keep it running. That covers maintenance, updates, monitoring and post-market surveillance support, which regulators expect for the whole life of the product.
You get one partner from the first idea to the long-term operation of the product, and your own team can stay focused on the clinical and business side.
What to do next
- Write down your intended purpose in one clear paragraph.
- Check it against MDR Rule 11 and the MDCG 2019-11 guidance. For the US, review the FDA’s guidance on device software functions and clinical decision support.
- Compare your marketing claims with that paragraph. Remove anything you cannot support.
- Talk to someone who has done this before you commit to an architecture.
Not sure where your software sits? Get in touch with Thaumatec. A short conversation now can save you months later.