Is Your Software a Medical Device?
Determining whether standalone software, a mobile app, or an artificial intelligence module qualifies as Medical Device Software (MDSW) or Software as a Medical Device (SaMD) is an intricate regulatory milestone. Under the official European Commission MDCG 2019-11 and MDCG 2021-24 guidelines, boundaries between general health applications and regulated medical technologies are tightly enforced. This interactive qualification engine applies the formal 5-step structural criteria to help manufacturers validate their product’s intended purpose. Use this tool to quickly screen your software’s functional data parameters and establish a definitive compliance baseline under the EU MDR and IVDR frameworks.
Updated 14th May 2026
Try Our Interactive SaMD & MDSW Qualification Tool
Does your product process input data to create output data using a set of instructions (an algorithm)?
Legal Disclaimer: Patient Guard does not accept legal responsibility for the use of this tool. Any information provided should be checked by a qualified professional before determining the legal status of your product.
Classified as SaMD? What’s Next?
Confirming that your digital application or algorithm meets the definition of Medical Device Software (MDSW) under MDCG guidelines is a major milestone, but it changes your entire development and commercialization roadmap. Standalone software cannot simply be launched onto app stores or commercial servers without meeting strict legal frameworks.
To bring your SaMD/MDSW product to market legally in the UK and Europe, you must immediately address these three pillars:
1. Identify Your Regulatory Classification Pathway
MDSW rarely qualifies as a low-risk Class I device anymore. Under MDR Annex VIII (Rule 11), if your software provides information used to make diagnostic or therapeutic decisions, or monitors vital physiological parameters, it will likely scale sharply into Class IIa, Class IIb, or Class III. This classification determines whether you can self-declare compliance or if you require a formal audit by a third-party Notified Body or Approved Body.
2. Implement an ISO 13485 Quality Management System (QMS)
Medical software development must follow rigorous, traceable controls. You need to establish a QMS—typically certified to ISO 13485—that incorporates lifecycle management standards specifically designed for digital health, including:
IEC 62304: Software Lifecycle Processes (governing software design, development, and maintenance).
ISO 14971: Application of Risk Management to Medical Devices (identifying software hazards, bugs, and data anomalies).
IEC 82304-1: Health Software (governing general product safety and security).
3. Compile Your Technical Documentation & Clinical Evaluation
Before you can apply a CE or UKCA mark, you must build a comprehensive Technical File. For software, this requires an extensive Clinical Evaluation Report (CER) that proves your algorithms are scientifically valid, achieve the stated clinical performance, and remain secure against cybersecurity threats.
FAQs
What is the difference between SaMD and MDSW?
(Software as a Medical Device) is a global term popularized by the IMDRF, referring to software intended for medical purposes that runs without being part of a hardware medical device. MDSW (Medical Device Software) is the specific legal term used under the EU MDR and IVDR. It encompasses not only standalone software (SaMD) but also software that drives or influences a physical medical device, provided it has its own independent medical purpose.
Does a mobile health app always count as a medical device?
No. Under MDCG 2019-11, if an app is merely intended for general wellness, fitness tracking, lifestyle logging, or purely educational purposes, it is not a medical device. However, the moment your app claims to diagnose, prevent, monitor, or treat a specific pathological condition, or uses specific patient data to calculate risk or clinical dosages, it crosses the line into a regulated medical device.
If my software is just a modules within a larger system, does the whole platform need qualification?
Not necessarily. MDCG guidelines explicitly support the concept of modular software. If your platform contains large components that are purely administrative (e.g., patient scheduling or billing modules) alongside a specific medical module (e.g., an AI diagnostic algorithm), you can isolate and qualify only the specific medical module as an MDSW. This prevents your entire non-medical infrastructure from falling under rigorous medical device manufacturing regulations.
Does software that simply transfers or stores medical data require registration?
No. Software that is limited to the pure transmission, storage, archival, or "simple search" of data (meaning it doesn't manipulate, alter, or interpret the information) is considered administrative infrastructure. It does not perform an independent action on data for the clinical benefit of an individual patient, meaning it is not qualified as MDSW.
What harmonized standards must my software comply with once qualified?
Qualified MDSW must satisfy strict lifecycle, safety, and risk frameworks. The three core international standards you must build your software development lifecycle around are EN IEC 62304 (software lifecycle processes), EN ISO 14971 (risk management for medical devices), and EN IEC 82304-1 (general product safety and security requirements for health software).
Can qualified Medical Device Software still be classified as Class I?
While it is technically possible for software to be Class I under Rule 11(c) (if it doesn't drive therapeutic/diagnostic decisions or monitor vital signs—such as a simple communication tool or certain fertility trackers), the vast majority of qualified MDSW is automatically upgraded to Class IIa, Class IIb, or Class III under Rules 11(a) and 11(b). This means a self-declaration pathway is rare, and most software developers will strictly require a formal Notified Body audit before market launch.
