Software as a medical device (SaMD): qualification, classification and IEC 62304 life cycle
...from code to CE marking
What is it and who does it apply to?
Software as a medical device (SaMD) is software with a medical purpose that works on its own: an app, an algorithm, a cloud service that diagnoses, monitors, predicts or supports clinical decisions. It differs from software embedded in a device, which is assessed as part of that device, and from management or administrative software, which is not a medical device.
It applies to digital health start-ups, to manufacturers with software modules in their devices, to clinical artificial intelligence companies and to any manufacturer that buys third-party software and must validate it before using it in production or in its quality system.
At MeDev we qualify and classify the software, build the IEC 62304 life cycle together with your team without breaking the way you develop, and validate the third-party software that affects the product or quality.
What the regulation requires
Qualification (is it a medical device?) follows guidance MDCG 2019-11; classification is set by MDR rule 11, which places most clinical decision software in class IIa or higher and therefore under a notified body. For in vitro diagnostics the IVDR applies with its own rules.
The life cycle is documented under IEC 62304, with safety classes A, B and C that scale the requirements; IEC 82304-1 covers stand-alone health software; ISO 14971 risk management; IEC 62366-1 usability; and guidance MDCG 2019-16 cybersecurity, required by the MDR as a general safety and performance requirement.
If the software includes artificial intelligence, it may also be a high-risk AI system under the European Artificial Intelligence Regulation, with additional obligations best integrated into the same file.
What we do at MeDev
Qualification and classification
Qualification report (MDCG 2019-11), risk class under rule 11 and conformity assessment route.
IEC 62304 life cycle
Development plan, requirements, architecture, SOUP, verification, software risk management and maintenance, according to the safety class.
Third-party software validation
Production and quality-system software and SOUP components, validated in line with ISO 13485 and proportionally to risk.
How we work
- 1
Qualification and class
We determine whether your software is a medical device, its risk class (rule 11) and its IEC 62304 safety class, with a report setting the conformity route.
- 2
Development gap analysis
We review how you develop today (agile, DevOps, tools) against what the standard requires and map your process instead of replacing it.
- 3
Life cycle and risks
We document the development plan, requirements, architecture, SOUP, verification, software risk management, usability and cybersecurity.
- 4
Validation and file
Validation of your own and third-party software, and assembly of the technical file ready for the notified body.
Frequently asked questions
Is my app a medical device or just a wellness app?
It depends on the purpose the manufacturer gives it. If it diagnoses, monitors, predicts or supports clinical decisions, it is a medical device even if it runs on a phone or in the cloud; if it only informs or encourages healthy habits, it is not. Guidance MDCG 2019-11 provides the decision tree to qualify it.
Which class does software get under MDR rule 11?
Rule 11 classifies software by the impact of the information it provides: class IIa by default when it supports diagnostic or therapeutic decisions, IIb if those decisions may cause serious harm and III if they may cause death or irreversible deterioration. Class I is left for residual cases.
What is IEC 62304 safety class A, B or C and who decides it?
The manufacturer decides it based on the harm a software failure could cause: A if no harm is possible, B if non-serious harm is possible and C if serious harm or death is possible. The higher the class, the more activities, documentation and verification the standard requires.
We develop in agile: is that compatible with IEC 62304?
Yes. The standard requires activities and documentation, not a waterfall model. Sprints are mapped to the life-cycle activities (planning, requirements, architecture, implementation, verification, release) and documentation is produced continuously rather than at the end.
What is SOUP and what do I have to document?
Software of unknown provenance or from third parties built into your product: libraries, frameworks, operating systems. IEC 62304 requires identifying each component, justifying its use, assessing the risks it introduces, setting its functional and performance requirements and controlling its versions and updates.
Do I have to validate the software I use in production or in the quality system?
Yes. ISO 13485 requires validating software that affects the product or quality, such as the traceability ERP, machine software or the document management system, proportionally to risk. It is one of the most common audit non-conformities and a validation we perform frequently.
Is cybersecurity part of the technical file?
Yes. The MDR requires IT security as a general safety and performance requirement, and guidance MDCG 2019-16 details what to document: threat analysis, security controls, vulnerability management and updates throughout the life of the device.
My software uses artificial intelligence: does that change anything?
It remains a medical device under the MDR and, in addition, it may be a high-risk AI system under the European Artificial Intelligence Regulation, with extra obligations on data governance, transparency and human oversight. It pays to design the file with both frameworks in mind from the start.
Related news
EHDS Regulation 2025/327: CE marking becomes mandatory for EHR systems
The EHDS Regulation (EU) 2025/327 makes CE marking mandatory for electronic health record systems: deadlines, requirements and who is affected.
ANVISA publishes two guidance manuals for the regularisation of medical devices
ANVISA publishes two manuals for regularisation in Brazil: notification of class I and II materials (RDC 751/2022) and IVD products (RDC 830/2023).
ISO 10993-3:2026 - New edition
New 2026 edition of EN ISO 10993-3 on biological evaluation: genotoxicity, carcinogenicity and reproductive toxicity of medical devices.
