Software as a Medical Device (SaMD) Under EU MDR: What Development Teams Need to Know

Qualification comes before classification

Start with the intended medical purpose, users and decisions supported by each module. A storage or communication feature is not automatically a medical device; an interpretive module may require a separate assessment. Classification follows qualification and the applicable rules, not the technology label “AI”. Consult MDCG 2019-11 rev.1.

For a design review, write down what an incorrect output could cause and how the user acts on it. Keep that assessment alongside the wider EU healthcare compliance map.

Introduction

If you are building healthcare software in Europe, there is a question your team needs to answer early: does your software qualify as a medical device under the EU Medical Device Regulation (MDR)?

Before placing qualifying software on the market or putting it into service, determine the applicable conformity route and any specific exemptions with the regulatory owner. Intended purpose, operating context and the consequences of an incorrect output all matter; a generic software label is not a conformity assessment.

As a developer who builds healthcare applications — including clinical decision support tools and AI-enhanced EHR integrations — I have navigated this regulatory landscape on multiple projects. This article covers what development teams actually need to know.

When Does Software Become a Medical Device?

The EU MDR (Regulation 2017/745) defines a medical device broadly. Software qualifies as a medical device if it is intended by the manufacturer for one or more of these medical purposes:

• Diagnosis — identifying a disease, condition, or risk factor
• Prevention — preventing a disease or injury
• Monitoring — tracking physiological or pathological processes
• Prediction — predicting disease progression or treatment outcomes
• Treatment — providing therapeutic recommendations or controlling treatment delivery

Examples That Need a Medical-Device Assessment

• Clinical decision support that recommends specific diagnoses or treatments
• AI/ML models that interpret medical images (radiology, pathology, dermatology)
• Software that calculates drug dosages based on patient parameters
• Mobile apps that monitor chronic conditions and trigger clinical alerts
• Software that controls or interfaces with physical medical devices
• Risk stratification tools that predict clinical events (sepsis, readmission, deterioration)

Functions Typically Outside Qualification When Limited to These Purposes

• Software for administrative purposes only (scheduling, billing, HR)
• EHR systems that store and display data without interpreting it
• Communication tools (telehealth video platforms without clinical decision features)
• Software for general wellness (fitness trackers, meditation apps)
• Clinical reference databases and educational tools

The key distinction is intended purpose. The same software feature can be either a medical device or not depending on how you market and describe it. If your product's marketing claims include words like "diagnose," "predict," "detect," or "recommend treatment," you are likely in medical device territory.

MDR Classification for Software

If your software is a medical device, the next step is classification. The MDR uses Rule 11 (Annex VIII) specifically for software:

Rule 11 Classification

Software intended to provide information used to take decisions with diagnosis or therapeutic purposes is classified as:

These branches paraphrase MDR Annex VIII, Rule 11. Other applicable rules must also be assessed. A product name or generic example is insufficient to assign a class.

The Development Lifecycle Under MDR

IEC 62304: Software Lifecycle Standard

IEC 62304 describes medical-device software lifecycle processes. Check the applicable edition and current harmonisation status for your conformity strategy. It defines three software safety classes:

• Class A — no injury or damage to health possible
• Class B — non-serious injury possible
• Class C — death or serious injury possible

The safety class determines the rigor of your development processes:

                    Class A        Class B        Class C
                    ────────       ────────       ────────
Development Plan    Required       Required       Required
Requirements        Required       Required       Required
Architecture        Optional       Required       Required
Detailed Design     Optional       Optional       Required
Unit Testing        Optional       Required       Required
Integration Testing Required       Required       Required
System Testing      Required       Required       Required
Traceability        Req → Test     Req → Arch     Full trace
                                   → Test         Req → Arch
                                                  → Design
                                                  → Code
                                                  → Test

What This Means for Your Development Process

Requirements Management

Every software requirement must be:

• Documented and uniquely identified
• Traceable to design elements, code, and tests
• Reviewed and approved before implementation
• Linked to risk analysis outputs

This does not mean waterfall. You can use agile methodologies, but you need to maintain traceability. Each sprint must produce traceable, documented requirements that link to test cases.

Architecture Documentation

For Class B and C software, you must document your software architecture:

• System architecture and component decomposition
• External interfaces (APIs, databases, third-party services)
• Functional and performance requirements allocated to components
• SOUP (Software of Unknown Provenance) — every third-party library and framework must be identified, risk-assessed, and monitored

This SOUP requirement is particularly impactful for modern JavaScript/TypeScript applications. Every npm package in your dependency tree is technically SOUP. You need to:

1. Maintain an inventory of all SOUP items (name, version, intended use)
2. Assess the risk of each SOUP item failing or behaving unexpectedly
3. Document the evaluation criteria (is it actively maintained? is it widely used? are there known vulnerabilities?)
4. Monitor for updates, security advisories, and end-of-life announcements

Risk Management (ISO 14971)

Risk management is the backbone of MDR compliance. ISO 14971 defines the process:

1. Risk analysis — identify hazards and estimate risk (severity × probability)
2. Risk evaluation — determine if risks are acceptable
3. Risk control — implement measures to reduce unacceptable risks
4. Residual risk evaluation — verify that risk controls are effective and do not introduce new risks
5. Risk-benefit analysis — for residual risks, confirm that clinical benefits outweigh the remaining risks

For AI/ML-based systems, risk analysis must also address:

• Model performance degradation over time (data drift)
• Bias in training data that could lead to misdiagnosis in specific populations
• Edge cases where the model's confidence is unjustifiably high or low
• Adversarial inputs that could manipulate model outputs

Quality Management System (ISO 13485)

MDR requires manufacturers to operate under a Quality Management System (QMS) compliant with ISO 13485. This covers:

• Document control — procedures for creating, reviewing, and approving documentation
• Design and development — structured processes from planning through validation
• Purchasing — controls on SOUP and third-party components
• Production and service — deployment, monitoring, and maintenance processes
• Corrective and preventive action (CAPA) — systematic approach to addressing problems
• Internal audits — regular assessment of QMS effectiveness

For small development teams, implementing a full QMS can feel overwhelming. My advice: start with the essentials (document control, design control, CAPA) and build out incrementally. There are lightweight QMS tools designed for software companies that make this manageable without enterprise-grade overhead.

Clinical Evaluation

MDR requires a clinical evaluation to demonstrate that your software achieves its intended clinical benefits. For software, this typically involves:

• Literature review — evidence from published studies supporting the software's clinical approach
• Clinical investigation data — if available, data from your own clinical studies or pilot deployments
• Equivalence claims — comparison with similar devices already on the market (the MDR has stricter equivalence requirements than the previous MDD)
• Post-market clinical follow-up (PMCF) — ongoing data collection after market placement

For AI/ML systems, clinical evaluation must include performance data on representative European patient populations — not just the dataset the model was trained on.

CE Marking Process

To legally place your medical device software on the EU market, you need CE marking:

1. Classification (Rule 11)
       │
       ▼
2. Quality Management System (ISO 13485)
       │
       ▼
3. Technical Documentation
   ├── Device description and specifications
   ├── Design and manufacturing information
   ├── Risk management file (ISO 14971)
   ├── Clinical evaluation report
   ├── IEC 62304 lifecycle documentation
   └── Labeling and instructions for use
       │
       ▼
4. Conformity Assessment
   ├── Class I → Self-assessment (no Notified Body)
   └── Class IIa/IIb/III → Notified Body audit
       │
       ▼
5. EU Declaration of Conformity
       │
       ▼
6. CE Marking → Market Placement
       │
       ▼
7. Post-Market Surveillance (ongoing)

The Notified Body Bottleneck

One of the biggest practical challenges in 2025-2026 is the limited number of Notified Bodies designated under MDR. Waiting times for conformity assessments can be 6-12 months or longer. Plan accordingly — CE marking is not something you can rush at the end of development.

Practical Advice for Development Teams

1. Determine your classification early — engage with a regulatory consultant before you write significant code. Discovering you need MDR compliance late in development is expensive.

2. Integrate IEC 62304 into your agile process — it is possible to be agile and compliant. Use tools that support traceability (requirements → code → tests) and automate documentation where possible.

3. Manage your SOUP rigorously — create and maintain a SOUP inventory from day one. Use npm audit and Dependabot, but also maintain a regulatory-grade inventory with risk assessments.

4. Design for post-market surveillance — your deployed system needs to feed performance data back for ongoing clinical evaluation. Build monitoring and analytics from the start.

5. Start the Notified Body process early — do not wait until your software is "ready." Engage with a Notified Body during development to avoid surprises during the conformity assessment.

Conclusion

Developing medical device software under EU MDR is a significant undertaking, but it is achievable — especially if you plan for it from the start rather than retrofitting compliance onto an existing product. The key is treating regulatory requirements as integral to your development process, not as a separate compliance workstream.

If you are building healthcare software and need help determining your MDR classification or structuring your development process for compliance, I am happy to discuss your situation.