SaMD Under EU MDR: What Software Developers…

Understanding the Regulatory Landscape for Software as a Medical Device

Software plays an increasingly important role in modern healthcare technologies. In many cases, software itself is the medical device.

During the webinar "From R&D to market: IP and regulatory strategy across the product life cycle", Anne-Sophie Grell explained the regulatory framework governing Software as a Medical Device (SaMD) under the EU Medical Device Regulation (MDR 2017/745) and highlighted several challenges companies face when developing software-driven products.

For digital health companies, MedTech startups, and software developers entering the healthcare sector, understanding these regulatory requirements early is critical to ensuring both product compliance and successful market access.

1. Define the Intended Use First

The first regulatory question when developing healthcare software is whether the software qualifies as a medical device under MDR.

This determination depends entirely on the intended use of the software.

Software designed to:

diagnose disease
treat medical conditions
monitor patient health
prevent or predict disease

may qualify as a medical device. In contrast, general wellness or lifestyle applications typically fall outside the scope of MDR.

💡 Because intended use determines whether the product falls within the medical device regulatory framework, clear product definition is essential at the start of development. Early regulatory assessment helps prevent costly redesigns or regulatory surprises later in the product lifecycle.

2. Understand Rule 11 for Software Risk Classification

Under MDR, the risk classification of software is determined primarily through Rule 11.

Rule 11 evaluates the potential harm that could occur if the software provides incorrect information used for clinical decision-making. Depending on the level of risk associated with incorrect output, software may fall into different risk classes.

In practice, most software products qualifying as medical devices fall into Class IIa or higher, which means that conformity assessment requires the involvement of a Notified Body.

💡 Although regulatory discussions are ongoing regarding potential adjustments to the software classification framework, the current requirements remain fully applicable until formal regulatory changes are adopted.

3. Follow IEC 62304 for Software Lifecycle Management

For software used in medical devices, IEC 62304 defines the internationally recognised framework for software lifecycle processes.

This standard specifies how software development activities must be structured and documented, including:

Software design and architecture
Risk management integration
Verification and validation
Maintenance and change management

Compliance with IEC 62304 should be integrated directly into the Quality Management System (QMS) to ensure that software development processes align with MDR requirements.

💡 For many companies, the key lesson is that integrating IEC 62304 early in development is significantly easier than attempting to retrofit compliant processes once the software architecture has already been established.

4. Consider Additional Regulatory Frameworks

Developers of software-driven medical products must also consider several additional regulatory frameworks beyond MDR.

Depending on the nature of the product, relevant regulations may include:

GDPR, for the protection of patient data and personal health information
Cybersecurity requirements, increasingly scrutinised by regulators
The EU AI Act, particularly for software incorporating artificial intelligence or machine learning components

For companies developing AI-enabled medical software, it is therefore essential to understand how these frameworks interact with MDR requirements.

💡 Regulatory compliance for Software as a Medical Device increasingly requires a multi-regulatory perspective, where data protection, cybersecurity, and AI governance intersect with medical device regulation.

The Bigger Picture: SaMD Requires Structured Development

Developing Software as a Medical Device under MDR requires more than technical innovation. It requires structured development processes, clear product definition, and strong regulatory planning.

Companies that integrate regulatory thinking into their software development lifecycle from the beginning are far better positioned to navigate the regulatory landscape successfully.

Early regulatory alignment helps ensure that product architecture, documentation, and risk management practices meet MDR expectations, avoiding delays and costly remediation later in development.

Download the Whitepaper

📄 Standards and regulations for software used in medical devices

This whitepaper explores the regulatory standards and frameworks governing medical device software, including MDR, IEC 62304, cybersecurity expectations, and emerging AI regulations.

Watch the Full Webinar on Demand

This article is based on the webinar:

"From R&D to market: IP and regulatory strategy across the product life cycle" by QbD Group, Gevers & Biovia

In this session, experts discuss how regulatory strategy, intellectual property, and product development interact throughout the lifecycle of innovative healthcare technologies.

关于作者

Anne-Sophie Grell

PhD Physics, MSc Medical Physics · Manager Regulatory Affairs – Medical Devices

Anne-Sophie is a Regulatory Affairs leader with over two decades of experience in medical physics, diagnostic imaging, and medical device regulation. She supports clients navigating EU MDR, FDA, and international regulatory frameworks.

查看所有文章