Software as a Medical Device (SaMD) Explained: MDR, Rule 11 & ISO Standards

Software as a Medical Device (SaMD) is becoming increasingly important in the European MedTech sector. Recent estimates put the market value at €440 million in 2024, with projections reaching €1.4 billion by 2033. But this growth brings challenges too: MDR requirements, Rule 11 classification and rising certification costs pressure teams unfamiliar with regulated software development.

This raises a practical question:
How can MedTech companies navigate the classification and compliance of SaMD without causing delays, uncertainty or unnecessary costs?

This article provides a structured overview of software as a medical device (SaMD) under the EU Medical Device Regulation (MDR). It explains terminology, Rule 11 classification, required standards, development expectations, typical applications and market challenges, providing an essential guide developing software as a medical device (SaMD).

What Is Software as a Medical Device (SaMD)?

The International Medical Device Regulators Forum (IMDRF) defines Software as a Medical Device (SaMD) as software that performs a medical function independently of any hardware. This includes programmes running on general-purpose hardware, such as computers, tablets, smartphones or cloud systems.

In the European Union, however, the term 'SaMD' is not used in legislation. Instead, the Medical Device Regulation (MDR) classifies such products as Medical Device Software (MDSW). According to MDCG 2019-11, software qualifies as a medical device if its intended purpose meets the MDR definition, regardless of whether it is standalone or linked to another device.

In practice, this means that diagnostic tools, monitoring applications, therapeutic algorithms and clinical decision support systems are all regulated as medical devices. Examples include AI imaging tools, symptom assessment apps and mobile software that supports diagnosis or treatment decisions.

-> In short: SaMD is standalone software performing a regulated medical purpose under the EU MDR.

Software as Medical Deivce (SaMD) Under the EU MDR: Rule 11

The EU MDR regulates software as a medical device under the broader term 'medical device software' (MDSW). Rule 11 of Annex VIII defines how software is classified, taking into account its intended medical purpose and the clinical risk of the decisions it influences. Most SaMD is classified as Class IIa or higher, meaning that the involvement of a Notified Body is the norm rather than the exception.

Most SaMD products fall into Class IIa or higher, which means Notified Body involvement becomes a standard requirement rather than an exception. Higher classifications, such as Class IIb and Class III, are common when the software influences clinical decisions or affects patient safety. This makes early regulatory planning essential.

Before SaMD can be placed on the European market, it must obtain a CE mark. This requires evidence of safety and clinical performance, risk management and documentation aligned with IEC and ISO standards. It also requires a structured post-market surveillance plan. The revised MDCG 2019-11 Rev.1 (2025) guidance confirms that any software performing a medical purpose must follow the full MDR pathway, regardless of whether it is standalone or connected to a device.

-> In short: Nearly all SaMD fall under MDR Class IIa or higher, requiring Notified Body assessment.

Compliance and Standards for Software as a Medical Device (SaMD)

Developing software as a medical device requires meeting MDR expectations for safety, performance and lifecycle management. Compliance with international standards ensures reliable software that can withstand regulatory scrutiny during CE marking. These standards are:

IEC 62304

Defines how medical software must be planned, designed, implemented, tested, released, and maintained. It assigns a safety class (A, B, or C) based on potential clinical harm, which determines how much evidence manufacturers must provide.

ISO 13485

Establishes the quality management requirements for the development and maintenance of medical devices. It ensures that all processes, from design controls to change management, are documented and consistent, which is essential during Notified Body audits.

ISO 14971

Defines how manufacturers must identify, evaluate and control risks throughout the software lifecycle. It ensures that safety-related decisions are justified and traceable, which is a core expectation under the MDR.

IEC/TR 80002-1

Explains how to apply ISO 14971 specifically to software. It translates software-specific hazards into clear risk control requirements, supporting the MDR need for structured verification and post-market monitoring.

Step by Step Preparing SaMD for MDR Compliance and Certification

Companies developing software as a medical devices need a clear, structured preparation phase before development begins. The following steps outline what MDR expects and what organisations should do in practical terms.

Step 1. Define the Intended Purpose and Confirm MDR Classification

The classification of MDRs depends entirely on their intended medical purpose and the clinical risk of the decisions the software influences. According to Rule 11, most SaMD are classified as Class IIa or higher, which makes the involvement of a Notified Body mandatory.

-> You write down exactly what the software does medically. This determines the device class and regulatory workload.

What To Do:

Write a one- or two-sentence intended purpose.
Check Rule 11 to see if the software is Class IIa, IIb, or III.
Document the reasoning, you will need it during certification.

Step 2. Map the Regulatory Pathway Early

The conformity assessment route defines whether you need a Notified Body, what regulatory route is required and how the CE marking process will be reviewed.

-> You need to know the process you must follow and who must approve your device.

What To Do:

Identify if a Notified Body is required (almost always for SaMD).
Map the CE marking steps and expected documentation.
Create a realistic timeline, including NB review delays.

Step 3. Align Your Quality Management System (ISO 13485)

ISO 13485 ensures that the processes involved in design control, documentation, supplier management and change management are repeatable and auditable.

-> Your internal processes must match what MDR expects. Without this, a device cannot be approved.

What To Do:

Ensure your QMS follows ISO 13485 or plan to upgrade it.
Define responsibilities for regulatory, quality, technical and clinical activities.
Set up document control and approval workflows.

Step 4. Define the Software Lifecycle According to IEC 62304

IEC 62304 outlines the development, testing, release and maintenance activities necessary for software for medical devices, categorised by safety class.

-> You need a structured development plan that shows how the software is built and tested.

What To Do:

Select a lifecycle model aligned with IEC 62304.
Assign the software safety class (A, B, or C).
Plan the documentation and testing depth required by that class.

Step 5. Establish a Risk Management Approach (ISO 14971)

ISO 14971 requires the systematic identification, evaluation, control and verification of software-related risks throughout the product's lifecycle.

-> You must prove the software will not harm patients or clinicians.

What To Do:

Define your risk management process.
Use IEC/TR 80002-1 to guide software-specific hazard analysis.
Update risk files continuously as the software evolves.

Step 6. Define the Clinical Evaluation Strategy

Even software for medical devices requires clinical evidence demonstrating safety and performance for MDR. This evidence can be derived from literature, clinical data or real-world observations.

-> You must show that the software works, is safe and provides a clinical benefit.

What To Do:

Decide how to generate evidence (studies, literature, evaluations).
Align claims with available data.
Plan how to update evidence after launch.

Step 7. Address Cybersecurity, Interoperability and GDPR

SaMD must incorporate cybersecurity controls and data protection measures, as well as interoperability frameworks such as HL7 FHIR.

-> Your software must be secure, connected properly and compliant with data protection rules.

What To Do:

Document cybersecurity measures (access control, encryption, logging).
Plan how updates and patches are handled.
Ensure GDPR compliance for all personal data handled by the device.

Step 8. Prepare the Technical Documentation From Day One

The technical file (also known as the design dossier) must include information on architecture, risk management, verification, clinical evidence, cybersecurity and PMS plans.

-> You must collect the right documents while you build the software.

What To Do:

Define the structure of the technical file early.
Decide which tools you use for traceability and documentation.
Fill documentation gradually during development.

Bonus: Typical Software Pitfalls to Avoid

If these preparation steps are not handled early and consistently, predictable issues will appear during development and certification.

Starting without a clear intended purpose or MDR class.
Leaving documentation until the end of the project.
Misunderstanding how much evidence Rule 11 requires for SaMD.
Missing risk controls or incomplete architecture documentation.
Not planning clinical evaluation early enough.

Conclusion: Preparing Software as a Medical Device That Meets MDR

Although software as a medical device offers strong potential for diagnostics, monitoring and treatment, it also brings with it regulatory responsibilities that many organisations underestimate. The MDR requires a clear intended purpose, correct classification, and a structured development process supported by evidence and risk management.

Predictable approval depends on early preparation, such as correctly defining the device, aligning development with IEC and ISO standards, and building documentation as the software evolves. When these elements are in place from the outset, certification becomes more manageable and delays are less likely.

MedTech organisations that treat SaMD as a continuous lifecycle, rather than a one-time build, are better positioned to stay compliant, release updates safely and support long-term maintainability. With the right preparation, SaMD can be developed safely and in a certifiable way for the European market.