1. Introduction: What is SaMD?
Definition of SaMD
Software as a Medical Device (SaMD) refers to software that is intended to perform medical functions without being part of a hardware medical device. It operates independently of any physical device, meaning it does not require embedded systems in medical hardware to serve its purpose. SaMD may be used to diagnose, monitor, prevent, or treat disease, or to support clinical decisions by healthcare professionals or patients. The core characteristic of SaMD is that its primary intended use has a direct medical purpose, and it achieves this through software alone.
Regulatory Context and Evolution
The concept of SaMD gained formal recognition with increased digital health adoption and was standardized by the International Medical Device Regulators Forum (IMDRF). The IMDRF defines SaMD as “software intended to be used for one or more medical purposes that perform these purposes without being part of a hardware medical device.” Under previous European legislation, namely the Medical Device Directive (MDD 93/42/EEC), software was not consistently regulated, and many applications remained self-certified under Class I. However, the EU Medical Device Regulation (MDR 2017/745) brought significant clarity by explicitly including software in the definition of a medical device and introducing specific rules for classification and conformity assessment.
Examples and Scope of SaMD
SaMD encompasses a wide range of digital tools, including mobile health apps, AI-powered diagnostic platforms, software used for image analysis, patient data interpretation systems, and therapeutic monitoring applications. For instance, an app that analyzes ECG data to detect arrhythmias or software that guides insulin dosing based on glucose trends qualifies as SaMD. On the other hand, general wellness apps or lifestyle trackers without direct clinical utility typically fall outside the regulatory definition. The scope of SaMD also extends to systems integrated with cloud platforms, artificial intelligence, machine learning, and real-time decision-support tools, making it a rapidly evolving and highly impactful area of digital health.
Software as a Medical Device (SaMD) refers to software intended to be used for medical purposes without being part of a hardware medical device. It can diagnose, monitor, treat, or support clinical decisions. Examples:
- AI-based diagnostic tools (e.g., skin cancer detection apps)
- Mobile ECG analysis apps
- Cloud platforms for managing insulin dosage
Under the Medical Device Regulation (EU) 2017/745 (MDR), the treatment of SaMD has fundamentally changed compared to the previous Medical Device Directive (MDD 93/42/EEC).
2. Key Regulatory Changes Under MDR Affecting SaMD
Expanded Definition of Medical Devices
Under the previous Medical Device Directive (MDD), the inclusion of software as a medical device was somewhat ambiguous and often inconsistently interpreted. The MDR (EU 2017/745), however, explicitly includes software within its scope in Article 2(1). It clarifies that software, whether standalone or integrated into a medical device, falls under the regulation if it has a medical purpose such as diagnosis, monitoring, prediction, prognosis, treatment, or alleviation of disease. This expanded and formalized definition eliminates uncertainty and ensures that SaMD is appropriately regulated for safety and performance.
Introduction of Rule 11 – Stricter Classification Criteria
One of the most impactful changes for SaMD is the introduction of Rule 11 in Annex VIII of the MDR, which governs classification. Previously, many SaMD products were classified as low-risk Class I under MDD, allowing manufacturers to self-certify. Under Rule 11, most software used to provide information that supports clinical decision-making is now classified as Class IIa or higher, depending on the potential impact of device failure on the patient. Software that influences critical clinical decisions or life-supporting systems may be classified as Class III. This reclassification significantly increases the regulatory obligations for manufacturers, including the need for Notified Body (NB) assessment.
Mandatory Involvement of Notified Bodies
Due to the shift in classification, most SaMD manufacturers can no longer rely on self-declaration of conformity. Instead, they must undergo conformity assessment procedures involving a Notified Body. This includes submission of comprehensive technical documentation, regular audits, and possibly on-site inspections. The involvement of Notified Bodies adds a layer of external scrutiny, extending the time and cost to market. For many companies, especially startups, the challenge lies in navigating the capacity constraints and prolonged review timelines currently experienced across the EU.
Enhanced Clinical Evaluation Requirements
MDR places a much stronger emphasis on clinical evaluation for all classes of medical devices, including software. Manufacturers are now required to provide robust clinical evidence that demonstrates the safety, performance, and clinical benefits of the SaMD. This evaluation must follow guidelines set out in Annex XIV, which may include clinical investigations, scientific literature, and post-market data. For novel or AI-powered software, generating this level of evidence can be difficult, especially when real-world data or adaptive algorithms are involved. Ongoing clinical evaluation is also required through Post-Market Clinical Follow-up (PMCF) activities.
Strengthened Post-Market Surveillance Obligations
The MDR introduces significantly more rigorous post-market surveillance (PMS) obligations, especially for SaMD. Manufacturers must establish a PMS plan and regularly collect, analyze, and act on data about the performance of their device after it has been placed on the market. This includes implementing a proactive PMCF strategy to gather ongoing clinical evidence, especially for software that evolves over time. These activities must be documented and used to update the clinical evaluation, risk management, and labeling as needed, ensuring that the device continues to meet safety and performance requirements throughout its lifecycle.
Cybersecurity and Software Lifecycle Management
Cybersecurity and lifecycle management are now formal regulatory requirements under the MDR. SaMD manufacturers must identify and mitigate cybersecurity risks during software development and maintenance. This includes establishing secure update mechanisms, access control, data protection measures, and incident response protocols. Additionally, MDR mandates that manufacturers apply principles of software lifecycle management (aligned with IEC 62304) and document all changes and updates. If a software update introduces new functionality or alters risk profiles, it may require reassessment by the Notified Body. These provisions aim to address increasing concerns over data breaches and system vulnerabilities in connected medical devices.
Greater Documentation and Technical File Expectations
MDR requires detailed and structured technical documentation for SaMD, outlined in Annexes II and III. The technical file must include information on device design, software architecture, risk analysis, validation and verification activities, clinical evidence, usability engineering, and labeling. Every element of the software, from algorithm logic to human-machine interface testing, must be traceable and verifiable. This level of documentation is a significant leap from MDD requirements and demands cross-functional collaboration between software developers, clinical experts, and regulatory teams. The rigorous documentation process ensures that SaMD can be systematically evaluated and continuously improved.
| Aspect | MDD (93/42/EEC) | MDR (2017/745) | Implication for SaMD |
|---|---|---|---|
| Definition of a Medical Device | Loosely interpreted; software wasn’t explicitly detailed | Explicitly includes software (Article 2(1)) | Clear inclusion of standalone software under regulation |
| Classification Rules | Most software classified as Class I | Introduced Rule 11 (Annex VIII) for software | Vast majority of SaMD now Class IIa, IIb, or III |
| Conformity Assessment | Class I devices self-certified | Class IIa+ require Notified Body review | No more self-certification for most SaMD |
| Clinical Evaluation | Clinical data not strictly required for Class I | Extensive clinical evaluation, even for software | Increased evidence burden, especially for AI/ML |
| Post-Market Surveillance (PMS) | General monitoring | Enhanced PMS + PMCF with mandatory reporting | Ongoing clinical evidence required post-launch |
| Cybersecurity Requirements | Minimal | Specific requirements for software updates, risk management, and data security | Greater technical file and update compliance burden |
3. Reclassification Impact: Rule 11 of MDR
Introduction to Rule 11 under EU MDR
Rule 11 is a specific classification rule introduced in Annex VIII of the EU Medical Device Regulation (MDR 2017/745), which deals exclusively with software used in healthcare settings. This rule represents a significant shift from the older Medical Device Directive (MDD), under which many software applications were often treated as low-risk (Class I) and allowed to be self-certified. The introduction of Rule 11 aims to address the evolving complexity and criticality of software-based technologies, especially as artificial intelligence (AI), machine learning (ML), and data-driven tools become central to patient care.
Scope and Interpretation of Rule 11
Rule 11 classifies software based on the potential consequences of its intended use. If software is intended to provide information used to make decisions for diagnostic or therapeutic purposes, it is generally classified as Class IIa. If such decisions could lead to serious deterioration of health or surgical intervention, the software is classified as Class IIb. If the decisions could result in death or irreversible health deterioration, the software is considered Class III. Only software that does not have such clinical decision-making influence, like simple wellness or lifestyle applications, may remain in Class I. This risk-based reclassification framework means that the vast majority of clinical software must now go through more rigorous regulatory review.
Impact on Manufacturers and Product Portfolios
The reclassification under Rule 11 has had a profound impact on software developers and manufacturers. Previously, many software tools were developed and marketed with minimal regulatory oversight. Now, due to the higher risk class designations, Notified Body (NB) involvement is mandatory for most software products. This significantly increases both the cost and time-to-market for software developers. As a result, many small- and medium-sized enterprises (SMEs) are either exiting the EU market, postponing development plans, or limiting the scope of their software to avoid falling into higher risk classes. The need for detailed technical documentation, robust clinical evidence, and strict post-market surveillance further adds to the burden.
Examples of Reclassified Software Products
To illustrate the effect of Rule 11, consider the following examples: a mobile app that monitors glucose levels and provides alerts to adjust insulin dosage would now likely be classified as Class IIb due to its role in life-sustaining decisions. An AI-powered tool that analyzes medical imaging for cancer diagnosis could fall into Class III, given the high impact of incorrect decisions. Conversely, a software that tracks general fitness or reminds patients to take medications without analyzing input data might remain in Class I. These reclassifications reflect a shift from the previously oversimplified regulatory model to a more nuanced, risk-oriented approach.
Strategic and Operational Challenges
From an operational perspective, Rule 11 has forced companies to invest in regulatory affairs expertise, update their quality management systems (QMS) to comply with ISO 13485, and adopt software lifecycle processes in line with IEC 62304. In many cases, firms are also revisiting their clinical evaluation strategies, especially for AI and ML tools, which require real-world evidence and algorithm transparency. Furthermore, each major software update may necessitate a reassessment of classification and potential re-certification, particularly if new features change the risk profile. This adds a layer of complexity that many firms, especially in the digital health and healthtech startup space, find difficult to manage without significant resources.
Conclusion and Industry Outlook
In summary, Rule 11 has redefined the regulatory landscape for software as a medical device in the European Union. While it aims to ensure greater patient safety and accountability, it has also created considerable challenges for the industry. The shift from Class I to higher classifications has resulted in more stringent scrutiny, longer approval timelines, and increased regulatory costs. Moving forward, firms that adapt early by incorporating regulatory planning into the product design phase, investing in clinical validation, and maintaining robust documentation practices will be best positioned to succeed under the new regime.
Rule 11: A Game-Changer
“Software intended to provide information which is used to take decisions with diagnosis or therapeutic purposes is classified as class IIa (or higher depending on severity of consequences).”
| Function | MDR Class | Implication |
|---|---|---|
| Simple fitness tracker | Class I | Self-certifiable |
| Software for diagnosing or suggesting therapy | Class IIa or IIb | Requires NB review |
| Life-supporting decisions (e.g., dosage of chemotherapy) | Class III | Highest scrutiny |
🔺 Impact: 70–90% of software previously in Class I under MDD is now Class IIa or higher, requiring full technical documentation and Notified Body involvement.
4. Clinical Evaluation & Real-World Evidence
Definition and Purpose of Clinical Evaluation
Clinical evaluation under the EU MDR is a systematic process to continuously generate, collect, analyze, and assess clinical data to verify the safety and performance of a medical device throughout its lifecycle. For Software as a Medical Device (SaMD), this involves demonstrating that the software performs as intended for the defined medical purpose and that its use does not pose unacceptable risks to patients or users. Clinical evaluation is a mandatory component of the conformity assessment process and is critical for obtaining and maintaining CE marking under MDR.
Sources of Clinical Data for SaMD
Clinical data used in the evaluation of SaMD can come from various sources. These include clinical investigations conducted specifically for the software, scientific literature reviewing equivalent devices or clinical outcomes, and post-market clinical follow-up (PMCF) data. While literature and equivalence were commonly used under the previous MDD, MDR imposes stricter requirements, especially regarding claims of equivalence. Manufacturers must now provide detailed technical, clinical, and biological justification to use equivalence, which is often difficult for software due to rapid technological changes and unique algorithms.
Role of Real-World Evidence
Real-World Evidence (RWE) plays a growing and important role in clinical evaluation under MDR, especially for SaMD products that use adaptive algorithms or machine learning. RWE includes data collected from sources such as patient registries, electronic health records, remote monitoring devices, or software usage logs. For SaMD, RWE helps demonstrate ongoing performance, clinical benefit, and safety under real-use conditions. MDR supports the use of RWE as part of post-market clinical follow-up, helping manufacturers generate updated clinical data without conducting new randomized controlled trials (RCTs), which are often impractical for software products.
Clinical Evaluation Report and Notified Body Scrutiny
The output of the clinical evaluation process is the Clinical Evaluation Report (CER), which summarizes all evidence supporting the device’s safety, performance, and benefit-risk profile. The CER must be comprehensive, scientifically valid, and aligned with the latest standards (such as MEDDEV 2.7/1 Rev. 4 and MDCG guidance). For SaMD, notified bodies scrutinize CERs closely, especially regarding the validation of clinical claims, software functionality, and the link between intended use and demonstrated outcomes. Inadequate CERs are one of the leading causes of MDR certification delays for software products.
Ongoing Clinical Evaluation and PMCF Requirements
Under MDR, clinical evaluation is not a one-time activity; it must be maintained throughout the life of the device via post-market surveillance (PMS) and post-market clinical follow-up (PMCF). PMCF is a continuous process that updates the clinical evaluation using real-world data. For SaMD, PMCF often involves monitoring algorithm performance, user behavior, incident reports, and new scientific findings. It also includes trend reporting and analysis of software performance updates. Manufacturers are expected to include a PMCF plan and regular updates as part of their technical documentation, ensuring ongoing compliance with MDR and enabling proactive safety monitoring.
Under MDR:
- SaMD needs clinical evaluation based on Annex XIV.
- Clinical data can come from:
- Clinical investigations
- Literature
- Real-world performance data
🔍 AI-based or adaptive algorithms often lack traditional clinical trials, making compliance challenging. PMCF becomes a key method to gather ongoing performance data.
5. Cybersecurity and Software Lifecycle Requirements
Regulatory Basis for Cybersecurity in Medical Device Software
Under the EU MDR (2017/745), cybersecurity is explicitly recognized as a critical component of medical device safety and performance, especially for Software as a Medical Device (SaMD). Article 5, Annex I (General Safety and Performance Requirements) outlines that manufacturers must address potential risks associated with cybersecurity threats throughout the device’s entire lifecycle. This is a shift from the older MDD, where cybersecurity was not explicitly mandated. MDR also cross-references harmonized standards such as ISO 14971 (risk management) and IEC 62304 (software lifecycle), which form the foundation of a robust cybersecurity strategy.
Design and Development Stage: Built-in Security
During the design and development phase of SaMD, manufacturers are required to implement security-by-design principles. This means anticipating and mitigating risks related to unauthorized access, data manipulation, malware infection, and unintended interactions with other systems. Developers must document the software architecture and explain how data is processed, stored, encrypted, and transmitted. Authentication protocols, secure user access, data integrity checks, and intrusion prevention measures must be incorporated as part of the core functionality—not as optional features. The software design documentation, part of the Technical File, must include threat modeling and risk mitigation strategies.
Validation and Risk Management
Software validation under MDR includes a cybersecurity risk assessment as an integral part of overall risk management. Using ISO 14971 in conjunction with IEC/TR 80001-2-2 or IEC 81001-5-1 (for health IT systems), manufacturers must identify and analyze cyber vulnerabilities and their impact on patient safety. Risks should be evaluated based on probability and severity, and residual risks must be justified and documented. For Class IIa and above, these assessments are scrutinized by the Notified Body during conformity assessment. Validation also includes penetration testing and verification that the security controls function as intended in realistic use conditions.
Update Management and Change Control
Under MDR, software is considered a dynamic product. Every update, patch, or configuration change must go through a documented change control process. This includes assessing whether the update introduces new cybersecurity risks, alters intended use, or impacts safety or performance. Significant changes may require Notified Body re-evaluation, especially for higher-risk classes. Manufacturers are expected to establish a process for software version control, backward compatibility management, and end-of-life planning. Update mechanisms—whether manual or automatic—must be secure and validated, and their effects on system functionality must be fully traceable.
Post-Market Surveillance and Vigilance
Cybersecurity risk does not end at market launch. MDR requires manufacturers to maintain continuous post-market surveillance (PMS) with a strong focus on cybersecurity incidents, such as breaches, data leaks, or ransomware attacks. If a cybersecurity vulnerability is discovered post-launch, it may trigger Field Safety Corrective Actions (FSCAs), reportable under the EU vigilance system. Manufacturers are also expected to perform periodic penetration testing, monitor known vulnerabilities via databases like NIST NVD, and update their Software Bill of Materials (SBOM). PMCF (Post-Market Clinical Follow-up) reports should include information on software performance and emerging cyber risks.
Interoperability and Third-Party Components
Many SaMD solutions rely on third-party components or platforms, such as cloud infrastructure, open-source libraries, or APIs. MDR holds the legal manufacturer responsible for ensuring that these components meet cybersecurity standards. This requires thorough vetting of vendors, licensing compliance, and continuous monitoring for vulnerabilities in dependencies. The integration of these components must be validated for safety and performance. Manufacturers must also provide users with clear instructions on safe usage environments, device configurations, and restrictions on interfacing with unauthorized systems.
Documentation and Transparency Obligations
Manufacturers must include cybersecurity-related information in the technical documentation submitted to Notified Bodies, as well as in the information provided to end users. This includes user manuals, intended use statements, installation requirements, and warnings about potential cybersecurity risks. Additionally, manufacturers should create a cybersecurity white paper or appendix detailing their security architecture, risk assessments, response strategies, and regulatory compliance references. Transparency is essential not only for regulatory compliance but also for building trust with healthcare providers and patients who rely on the device’s digital infrastructure.
Under MDR + IEC 62304 + ISO 14971:
- Software developers must define, validate, and document:
- Intended use and clinical claims
- Risk management across lifecycle
- Update mechanisms and revalidation processes
- Security measures (encryption, access control)
⚠️ Every update to a Class IIa or higher device may require Notified Body re-review if it impacts functionality or safety.
6. Documentation and Technical File Requirements
Overview of Technical Documentation Requirements
Under the European Union Medical Device Regulation (EU MDR 2017/745), manufacturers of Software as a Medical Device (SaMD) are required to prepare and maintain comprehensive technical documentation that demonstrates conformity with all applicable general safety and performance requirements (GSPRs). This documentation, often referred to as the “technical file” or “design dossier,” must be structured according to Annexes II and III of the MDR. Unlike under the previous MDD, the MDR places far greater emphasis on software-specific information, including functionality, risk control, and lifecycle management.
Software Description and Intended Purpose
The technical file must begin with a clear description of the software, including its name, version number, intended medical purpose, intended user, and target patient group. The intended use should align with the device’s functionality and risk classification under Rule 11. This section must also specify whether the software is standalone or part of a hardware device, whether it runs on third-party platforms (e.g., mobile apps), and how it interacts with other systems. Any claims about clinical benefit must be reflected consistently across the labeling, instructions for use (IFU), and clinical evaluation.
Design and Development Process
Manufacturers must document the full software development process in accordance with IEC 62304, the harmonized standard for medical device software lifecycle processes. This includes providing the software architecture, design specifications, modular decomposition, data flow diagrams, and traceability matrices linking requirements to design outputs and test results. Each version of the software must be properly versioned, with documented controls over source code and changes. For SaMD using AI or machine learning algorithms, manufacturers must also document training datasets, validation methods, and safeguards for algorithm performance.
Risk Management Documentation
A core requirement under the MDR is demonstrating compliance with ISO 14971 for risk management. Manufacturers must conduct a thorough risk analysis specific to the software, identifying hazards related to incorrect outputs, data security breaches, interoperability issues, and user interface errors. Risk control measures must be detailed and justified, including verification evidence. Importantly, software-specific risks such as algorithmic bias, failure modes, and cybersecurity vulnerabilities must be evaluated throughout the lifecycle. All residual risks must be clearly documented along with a benefit-risk justification.
Verification and Validation Evidence
The technical file must contain evidence that the software has been verified and validated against its intended purpose and performance claims. This includes software unit testing, integration testing, system testing, and user acceptance testing. For higher-risk software (Class IIa and above), test protocols and results must be documented comprehensively. Validation should include testing in simulated or clinical environments where applicable. The testing must demonstrate that the software performs reliably under anticipated use conditions and is free of critical bugs or vulnerabilities.
Clinical Evaluation and Performance Data
MDR mandates that the clinical performance of the SaMD be supported by appropriate clinical data, which must be included in the technical documentation. This can include results from clinical investigations, literature reviews, or post-market clinical follow-up (PMCF) data. For novel or high-risk software, clinical investigations may be necessary to support performance claims. Manufacturers must prepare a Clinical Evaluation Report (CER) that justifies the clinical benefit and safety of the software in relation to its intended use.
Post-Market Surveillance and Update Management
The technical file must also detail the manufacturer’s Post-Market Surveillance (PMS) plan and procedures for software updates and version control. This includes mechanisms for collecting and analyzing real-world performance data, managing user feedback, and triggering corrective or preventive actions. For each update, manufacturers must document change impact assessments, re-validation activities, and any resulting modifications to risk profiles or clinical performance. All software changes must be logged, versioned, and traceable, especially for Class IIb and III devices where re-certification may be required.
Cybersecurity and Data Protection Measures
MDR-compliant technical files must include a dedicated section on cybersecurity, describing how the software protects data integrity, confidentiality, and availability. This includes encryption standards, user authentication, access control, and measures against malware or unauthorized access. Manufacturers must also perform vulnerability assessments and document mitigation strategies. As software increasingly interacts with cloud-based systems, mobile apps, and remote diagnostics, regulators expect detailed analysis of potential security threats and evidence that sufficient controls are in place.
Labeling and User Information
The labeling section of the technical file must contain all materials intended for the end user, including the Instructions for Use (IFU), user manuals, online help documentation, and training materials. These documents must provide adequate instructions on installation, usage, maintenance, and troubleshooting. For SaMD, usability and human factors engineering documentation is critical to ensure the software is intuitive and safe for its intended users. This section also includes Unique Device Identification (UDI) details and any symbols used, in compliance with Annex I of the MDR.
Conclusion
The technical documentation requirements for SaMD under EU MDR are significantly more rigorous and granular than under previous regulations. They are designed to ensure transparency, traceability, and safety throughout the software’s lifecycle—from design and development to deployment, maintenance, and decommissioning. For manufacturers, preparing a complete and compliant technical file requires multidisciplinary collaboration and careful planning, particularly in the areas of clinical validation, cybersecurity, risk management, and update control.
MDR Annex II and III prescribe:
- Software architecture/design documentation
- Algorithms, logic flow, source code management
- Version control and change impact analysis
- Risk analysis of incorrect outputs
- Human factors engineering validation
📌 Many startups and tech companies lack experience in generating these structured documents, requiring regulatory consultants or dedicated teams.
7. Economic & Strategic Impact on Industry
Increased Regulatory Compliance Costs
The transition from the MDD to the MDR has significantly increased compliance costs for software as a medical device (SaMD) manufacturers. Unlike the previous directive where many SaMDs could self-certify under Class I, the MDR’s Rule 11 has reclassified most SaMDs into higher risk categories (Class IIa, IIb, or III), necessitating Notified Body (NB) review and rigorous documentation. This shift demands extensive investment in clinical evaluations, cybersecurity planning, risk management files, and post-market surveillance systems. For smaller companies and startups, these costs often exceed their initial budget forecasts, leading to stalled product launches or withdrawal from the EU market altogether.
Delayed Time-to-Market
The stringent requirements under MDR and the limited capacity of Notified Bodies have resulted in prolonged approval timelines. For SaMD products, even minor software updates may require review or justification, creating operational delays. This slow regulatory turnaround can severely affect agile development cycles, particularly for companies working on AI-based or cloud-enabled solutions that rely on frequent iteration. The inability to update algorithms quickly can also render products obsolete faster in a competitive, fast-paced global healthcare technology market.
Innovation Bottlenecks in AI/ML
Artificial Intelligence and Machine Learning (AI/ML) algorithms pose a unique challenge under MDR. These systems often evolve with new data inputs, requiring continuous learning. However, MDR expects each new version of software—especially if it alters the clinical function or intended use—to be revalidated or reassessed. This clashes with the concept of continuous improvement integral to AI/ML development. As a result, some developers are choosing to scale back AI functionalities or avoid adaptive algorithms altogether when targeting the EU market, thereby curbing the pace of innovation in the region.
Strategic Shift Toward Other Regulatory Jurisdictions
Due to the financial and procedural burden imposed by MDR, many SaMD manufacturers, especially SMEs and startups, are prioritizing regulatory submissions in more predictable and cost-effective markets. The United States, through the FDA’s Digital Health initiatives, offers faster and more collaborative approval pathways. Similarly, markets in Asia-Pacific and the UK are seen as more accessible. Consequently, a noticeable trend is emerging where innovative SaMD products debut in non-EU regions first, delaying or altogether bypassing EU market entry. This shift undermines the EU’s position as a preferred launchpad for medtech innovations.
Market Consolidation and Product Withdrawal
Smaller players unable to cope with MDR’s demands are either being acquired by larger firms with established regulatory infrastructures or are exiting the market. At the same time, many companies are selectively withdrawing less profitable or low-volume SaMD products from the EU. This is particularly evident in niche clinical applications where the cost of MDR compliance outweighs expected revenue. While this consolidation may enhance regulatory quality in the short term, it risks reducing diversity in the device ecosystem and limiting access to specialized digital healthcare tools for patients and clinicians in Europe.
Operational Burden and Resource Allocation
MDR compliance has compelled organizations to realign their internal resources. Companies now require dedicated regulatory affairs teams, clinical experts, quality assurance personnel, and legal advisors focused solely on European compliance. This has led to higher operational costs and redirection of R&D budgets towards compliance activities rather than product development. For early-stage companies, this can delay innovation cycles and reduce investor interest due to extended timeframes for return on investment. Even for established players, sustaining compliance requires continual investment in staff training and documentation systems.
| Area | Impact |
|---|---|
| Time-to-Market | Increased due to classification upgrade and NB delays |
| Costs | Regulatory costs have surged (certification, audits, consultants) |
| Startups/SMEs | High barrier to entry; many are pivoting to non-EU markets |
| Innovation | Algorithm updates delayed due to re-validation demands |
| Market Access | Some SaMD developers exiting EU market to focus on FDA, UK, or APAC |
8. Comparison with Other Regulatory Bodies
EU MDR (European Union Medical Device Regulation)
Under the EU MDR (2017/745), SaMD is strictly regulated with clear definitions and rules. Rule 11 in Annex VIII is the central change, significantly reclassifying most SaMD from Class I (under MDD) to Class IIa or higher. This means that most SaMD products now require a conformity assessment by a Notified Body. The MDR imposes stringent requirements on clinical evaluation (Annex XIV), risk management (aligned with ISO 14971), software lifecycle management (IEC 62304), and ongoing post-market surveillance (PMS) and post-market clinical follow-up (PMCF). Each software update, especially for higher-risk products, must be evaluated for impact, often requiring reassessment by a Notified Body. While the MDR ensures high safety and transparency, it increases the regulatory burden and time-to-market, particularly for SMEs and AI-based adaptive software.
FDA (United States Food and Drug Administration)
The US FDA uses a risk-based approach under its Digital Health Policy Framework. SaMD is regulated under either the 510(k) premarket notification, De Novo classification, or Premarket Approval (PMA) processes, depending on risk level. The FDA recognizes and supports the IMDRF framework and has taken steps toward flexible regulation, especially for artificial intelligence and machine learning (AI/ML)-based software. Its proposed “Predetermined Change Control Plan” allows software updates within defined boundaries without requiring new submissions. The FDA also promotes the use of real-world evidence (RWE) and supports agile development through pilot programs like the Digital Health Software Precertification Program. Overall, the FDA is seen as more collaborative and innovation-friendly, with faster approval pathways compared to the EU.
UK MHRA (United Kingdom Medicines and Healthcare products Regulatory Agency)
The UK’s regulatory system currently mirrors many MDR elements, especially since Brexit, but it is evolving. The MHRA requires SaMD to carry the UKCA mark and comply with the UK Medical Devices Regulations 2002 (as amended). While these rules are still similar to the MDR, the UK is actively developing a new, independent regulatory framework for SaMD and AI medical software. In 2024, the MHRA proposed a new regulatory model that emphasizes a risk-based approach, supports innovation, and aims to introduce a “regulatory sandbox” for AI software. However, this new framework is still under consultation and implementation is expected gradually from 2025–2026 onward. Until then, many manufacturers still follow MDR-like procedures for SaMD in the UK, with some flexibility in enforcement.
TGA (Australian Therapeutic Goods Administration)
The TGA aligns closely with the IMDRF SaMD guidelines and has updated its software classification rules since 2021. Similar to the EU MDR, the TGA reclassified many SaMD products into higher risk classes, requiring more rigorous pre-market review and clinical evidence. However, it maintains some flexibility in handling updates and post-market obligations, particularly for lower-risk software. The TGA also emphasizes cybersecurity and real-world data usage but has taken a more proportionate approach compared to the EU. Manufacturers find the TGA’s processes to be more adaptive than MDR but more stringent than FDA in certain areas.
Health Canada
Health Canada regulates SaMD under the Medical Devices Regulations and categorizes software based on risk (Class I–IV). Like the EU MDR and TGA, it now mandates greater scrutiny for software with diagnostic or therapeutic influence. However, Health Canada has also launched the Agile Licensing Framework for digital health technologies and encourages iterative product improvement. Its approach to software changes is more flexible than the MDR, particularly for updates that don’t alter the intended use or risk profile. It also actively collaborates with international partners through the IMDRF and MDSAP programs, allowing greater harmonization and efficiency.
| Aspect | EU MDR (SaMD) | US FDA (SaMD) | UK MHRA (SaMD) |
|---|---|---|---|
| Classification | Rule 11-based | Risk-based (Level I-IV) | UKCA similar to MDR (for now) |
| Real-World Evidence | Required (PMCF) | Encouraged | Optional |
| AI/ML Updates | Each update reviewed | Pre-certified pathway in development | Not formalized yet |
| Software Lifecycle | Strict IEC 62304 and MDR Annex III | Based on QMS and 510(k)/De Novo | Under review (post-Brexit changes) |
✅ FDA is more flexible and collaborative in adaptive AI/ML, while EU MDR enforces stricter re-approval protocols for even minor changes.
9. Practical Recommendations for Compliance
Start Regulatory Planning Early in the Design Phase
Software developers should integrate regulatory strategy into the earliest stages of product development. Understanding the intended use, classification under Rule 11, and applicable conformity assessment pathways helps shape critical design decisions. Early engagement ensures that design controls, risk assessments, and performance validations are aligned with MDR expectations from the outset, preventing costly rework later.
Establish Cross-Functional Development Teams
Compliance with MDR for SaMD requires collaboration across multiple disciplines. Regulatory affairs professionals must work closely with software developers, clinical researchers, quality assurance specialists, and cybersecurity experts. This cross-functional approach ensures that clinical safety, software architecture, risk mitigation, and documentation are all addressed in parallel, reducing delays and miscommunication.
Leverage Harmonized and International Standards
Adopting harmonized standards such as IEC 62304 (software life cycle processes), ISO 14971 (risk management), IEC 82304-1 (health software), and ISO 13485 (QMS) can significantly streamline the compliance process. These standards provide structured guidance for software development, validation, and risk analysis. Compliance with these standards also makes technical documentation more acceptable to Notified Bodies and aligns with expectations during audits.
Create and Maintain Strong Traceability Throughout Development
Every clinical claim or software feature must be traceable through design inputs, risk analysis, architecture, code modules, test cases, and validation reports. Maintaining a detailed traceability matrix is essential, especially when dealing with high-risk Class IIb or III SaMD. Traceability is critical for proving safety and effectiveness during conformity assessments and post-market evaluations.
Implement Robust Clinical Evaluation and Post-Market Surveillance Systems
Manufacturers must ensure that their clinical evaluation (as per MDR Annex XIV) includes a robust plan for gathering and analyzing clinical data. This could include literature reviews, clinical trials, or post-market clinical follow-up (PMCF) using real-world data. Automating the collection and analysis of performance data through digital platforms or AI-based monitoring tools can improve efficiency and ensure compliance with PMS/PMCF obligations.
Develop a Structured and Compliant Update Process
Software updates must follow a validated, documented, and risk-assessed process. For Class IIa and above, any update that affects the intended use or performance may require re-certification by a Notified Body. Manufacturers should adopt version control systems, maintain update logs, perform impact analyses, and validate all changes prior to release. A clearly defined software change management procedure aligned with IEC 62304 is essential.
Prepare Comprehensive Technical Documentation from the Outset
MDR Annex II and III require detailed technical documentation, including software requirements, architecture, clinical evaluation reports, risk management files, and verification and validation data. Building these documents incrementally during development ensures accuracy and saves time. Manufacturers should also prepare summary reports and labeling content that reflect the device’s intended use, target population, and risk profile.
Establish Cybersecurity and Data Privacy Protocols
MDR expects medical software to address cybersecurity risks across its entire lifecycle. This includes secure data transmission, user authentication, encryption protocols, and protection from unauthorized access. Threat modeling and penetration testing should be part of the development process. Regular updates and vulnerability patching plans must be documented, with an emphasis on protecting patient safety and data integrity.
Use a Quality Management System (QMS) Suitable for Software Development
An ISO 13485-compliant QMS tailored for SaMD ensures all processes—from development and testing to release and post-market support—are controlled and documented. QMS should include procedures for risk management, design controls, validation, clinical evaluation, CAPA (Corrective and Preventive Actions), and customer feedback. Regular internal audits and management reviews help ensure ongoing compliance.
Engage Notified Bodies and Regulatory Experts Early
Due to the complexity of MDR requirements for SaMD, early engagement with a Notified Body can provide clarity on classification, clinical expectations, and documentation needs. Similarly, consulting regulatory affairs experts familiar with MDR and software lifecycle standards can help avoid delays, reduce compliance gaps, and streamline the certification process. For SMEs or startups, outsourcing regulatory strategy may be a cost-effective solution.
- Start Early: Build regulatory strategy during software design phase.
- Build Cross-Functional Teams: Developers + Clinical + Regulatory experts.
- Use IEC Standards: Especially IEC 62304, ISO 14971, ISO 13485.
- Maintain Traceability: From clinical claim → risk → architecture → test case.
- Automate PMS/PMCF: Leverage AI tools to collect real-world performance data.
- Document Every Update: Especially for Class IIb/III.
10. Conclusion: Strategic Implications
Increased Patient Safety and Trust
The MDR brings a strong emphasis on ensuring patient safety, clinical performance, and transparency—especially for software-based technologies that can impact critical medical decisions. By mandating rigorous clinical evaluation, risk management, cybersecurity protocols, and post-market surveillance, the regulation helps ensure that Software as a Medical Device (SaMD) is reliable, secure, and effective. This enhances public and professional trust in digital health tools, particularly in high-risk and life-supporting use cases.
Higher Regulatory Burden and Resource Demand
One of the most significant implications of MDR for SaMD developers is the increased complexity and resource demand. Unlike under the MDD, where many software products were classified as Class I and self-certified, the MDR’s Rule 11 places most SaMD into Class IIa or higher. This requires involvement of Notified Bodies, extensive documentation, and ongoing clinical evaluation. For organizations unfamiliar with traditional medical device regulation—especially start-ups and software-focused companies—this represents a steep and often costly learning curve.
Slower Innovation and Product Iteration
The MDR’s strict rules on software updates and lifecycle management create significant delays in iterative development, which is essential for AI/ML-based medical software. Every substantive change, including software version upgrades or algorithm refinements, may trigger re-certification or re-validation processes. This challenges the common agile and continuous development models used in software engineering, leading to slower innovation and reduced responsiveness to real-world performance feedback.
Barriers to Market Entry and Strategic Withdrawal
The heightened compliance burden under MDR has caused many smaller companies and digital health start-ups to reconsider entering or continuing in the EU market. The time, cost, and expertise needed to obtain certification often outweigh the commercial benefits, particularly for niche products or emerging markets. As a result, some manufacturers are pivoting their regulatory focus toward more agile frameworks, such as the US FDA’s Digital Health Software Precertification Program or markets in Asia-Pacific and the Middle East. This trend could limit European patients’ access to innovative software technologies.
Market Consolidation and Regulatory Specialization
The MDR is driving a wave of regulatory specialization and consolidation within the medical device software industry. Larger companies with established regulatory departments are better equipped to handle MDR demands, while smaller firms increasingly rely on external regulatory consultants or partnerships with certified entities. This dynamic is reshaping the competitive landscape, favoring organizations with long-term compliance infrastructure, diversified product portfolios, and the ability to absorb regulatory overhead as a strategic investment.
➕ Positive:
- MDR increases patient safety and data transparency.
- Encourages clinical rigor and traceable innovation.
➖ Negative:
- Raises entry barriers, especially for startups and iterative development models like AI.
- Slows down innovation lifecycle.
- Reduces availability of niche or legacy SaMD in EU.
Summary Table
| Impact Area | Change | Implication |
|---|---|---|
| Classification | Most SaMD reclassified to IIa/IIb | NB involvement required |
| Clinical Evaluation | Mandatory for all | Clinical trials or RWE needed |
| Technical File | Deep documentation needed | Time & expertise intensive |
| Cybersecurity | Explicit focus | Lifecycle and update plans required |
| Market Strategy | Costs & delays | Some companies exit EU market |