---
title: What Is Software as a Medical Device (SaMD)? The MDR Definition for Startups
description: Software is a medical device when its intended purpose meets MDR Article 2(1). Here is how SaMD qualification works and why Rule 11 pushes most software to Class IIa or higher.
authors: Tibor Zechmeister, Felix Lenhard
category: Software as a Medical Device
primary_keyword: software as a medical device MDR
canonical_url: https://zechmeister-solutions.com/en/blog/what-is-software-as-medical-device-samd-mdr
source: zechmeister-solutions.com
license: All rights reserved. Content may be cited with attribution and a link to the canonical URL.
---

# What Is Software as a Medical Device (SaMD)? The MDR Definition for Startups

*By Tibor Zechmeister (EU MDR Expert, Notified Body Lead Auditor) and Felix Lenhard.*

> **Software is Software as a Medical Device (SaMD) — the MDR uses the term Medical Device Software, or MDSW — when its intended purpose, as stated by the manufacturer, meets the definition of a medical device in Article 2(1) of Regulation (EU) 2017/745 and when it performs an action on data that goes beyond storage, archival, communication, or simple search. Once software qualifies, Annex VIII Rule 11 classifies it, and for software that provides information used for diagnostic or therapeutic decisions, the lowest defensible class is IIa — with IIb and III reserved for software whose decisions could lead to serious deterioration of health or death. Class I is the exception, not the rule.**

**By Tibor Zechmeister and Felix Lenhard. Last updated 10 April 2026.**

---

## TL;DR

- Software qualifies as a medical device under MDR Article 2(1) based on its intended purpose, not its technology stack, deployment model, or business model.
- The MDR text does not use the acronym "SaMD" — it is the IMDRF term. The MDR and MDCG 2019-11 Rev.1 (June 2025) use "Medical Device Software" (MDSW). In practice the terms overlap; we use SaMD and MDSW interchangeably in this post.
- SaMD runs independently of any physical medical device. Software in a Medical Device (SiMD) is embedded in or drives a physical device. The distinction matters because embedded software inherits the class of its parent device, while SaMD is classified on its own under Annex VIII Rule 11.
- Rule 11 pushes the vast majority of medical software to Class IIa, IIb, or III. Class I software under the MDR is rare and almost always the wrong assumption for a startup to make without expert review.
- MDCG 2019-11 Rev.1 (June 2025) is the definitive guidance on qualification and classification of software under MDR and IVDR. If you build medical software for the EU market and have not read it, start there.
- The software lifecycle is governed by MDR Annex I Section 17. EN 62304:2006+A1:2015 is the harmonised standard that provides presumption of conformity for software lifecycle processes — the tool for demonstrating compliance, not the authority.

---

## Why this matters for your startup

Most medical software startups we meet arrive with a variant of the same sentence. "We are building a platform that helps clinicians make better decisions, and we think we might be a Class I medical device, or maybe we are not a medical device at all." The sentence is almost always wrong in both directions. Either the product is clearly a medical device and the founders have not realised yet how much that changes their roadmap, or the founders have assumed they are a medical device and have already started building a QMS they do not need because a small change to the intended purpose would take them out of scope.

This is the category where the cost of getting the regulatory question wrong is the highest, because software can ship fast and break things much faster than hardware. A misclassified hardware device gets caught at conformity assessment. A misclassified SaMD can be live in hospitals for months before anyone asks the right question, and when they do, the fix is often a full re-development under a higher safety class. MDR Annex I Section 17 and EN 62304:2006+A1:2015 are not backwards-compatible with code written under consumer-software assumptions. If the software was not developed under a documented lifecycle from the first commit, the documentation has to be reconstructed — and reconstruction is always more expensive than starting clean.

The founders who survive this category do one thing differently. They answer the qualification question and the classification question with expert help, in writing, before the engineering team picks a framework. Everything downstream — architecture, data model, deployment, clinical evaluation, PMS — follows from those two answers. Get them wrong and every downstream decision has to be revisited. Get them right and the lifecycle becomes manageable.

## The MDR text — what the Regulation actually says about software

The MDR does not treat software as a special category. It treats software as a medical device, subject to the same definition, the same conformity assessment routes, and the same general safety and performance requirements as any other device — with software-specific obligations layered on top in Annex I Section 17 and software-specific classification in Annex VIII Rule 11.

The foundation is Article 2(1):

> *"'medical device' means any instrument, apparatus, appliance, software, implant, reagent, material or other article intended by the manufacturer to be used, alone or in combination, for human beings for one or more of the following specific medical purposes: diagnosis, prevention, monitoring, prediction, prognosis, treatment or alleviation of disease; diagnosis, monitoring, treatment, alleviation of, or compensation for, an injury or disability; investigation, replacement or modification of the anatomy or of a physiological or pathological process or state; providing information by means of in vitro examination of specimens derived from the human body..."* — Regulation (EU) 2017/745, Article 2, point 1.

Two things in that sentence are load-bearing for software. First, "software" is named explicitly — the MDR does not leave any doubt that software can be a medical device in its own right. Second, "intended by the manufacturer" — the qualification is driven by the stated intended purpose, not by what users do with the software in practice.

Article 2(12) defines intended purpose:

> *"'intended purpose' means the use for which a device is intended according to the data supplied by the manufacturer on the label, in the instructions for use or in promotional or sales materials or statements and as specified by the manufacturer in the clinical evaluation"* — Regulation (EU) 2017/745, Article 2, point 12.

That sentence is the pivot point for every SaMD discussion. The intended purpose is what the manufacturer says the software is for, across labelling, IFU, marketing, and the clinical evaluation. Claims on a website count. Claims in an app store listing count. Claims in investor decks do not bind the Regulation, but they bind reality once the software ships, and Notified Bodies notice.

Annex VIII Rule 11 is the software-specific classification rule. It states, in substance, that software intended to provide information used to make decisions with diagnostic or therapeutic purposes is at least Class IIa; it escalates to Class IIb if the decisions could cause serious deterioration of health or surgical intervention, and to Class III if the decisions could cause death. Software intended to monitor physiological processes is Class IIa, or IIb if it monitors vital physiological parameters where variations could result in immediate danger. All other software is Class I. The "all other software" bucket is narrower than founders hope — it is the exception, not the default.

MDR Annex I Section 17 sets out the general safety and performance requirements specific to software: the software must be developed and manufactured in accordance with the state of the art, taking into account the principles of development life cycle, risk management, information security, and verification and validation; and the minimum requirements concerning hardware, IT networks and IT security measures must be set out for devices that incorporate software or are themselves software.

EN 62304:2006+A1:2015 is the harmonised standard that operationalises those requirements. It is referenced in the context of MDR Annex I Section 17 as the state-of-the-art process standard for software lifecycle. Compliance with EN 62304:2006+A1:2015 gives presumption of conformity with the software-lifecycle aspects of Annex I. The MDR is the North Star. EN 62304:2006+A1:2015 is the tool.

## SaMD versus SiMD — the distinction that changes everything

Medical software splits cleanly into two categories, and the line between them changes how the regulation applies.

**Software as a Medical Device (SaMD)** is software that performs one or more medical functions on its own, without being part of a physical medical device. A diagnostic algorithm that ingests imaging data from any compatible scanner is SaMD. A clinical decision-support platform that takes EHR data and returns risk scores is SaMD. A mobile application that interprets ECG strips uploaded by a user is SaMD. The software runs on general-purpose hardware — a phone, a cloud server, a hospital workstation — and its medical function is the software itself.

**Software in a Medical Device (SiMD)**, which MDCG 2019-11 Rev.1 also calls software that drives or influences the use of a (hardware) medical device, is software that is an integral part of a physical device and cannot be separated from it. The firmware inside an infusion pump. The control software on a ventilator. The embedded image-processing software inside a CT scanner. This software is part of the physical device and is classified together with it.

The distinction matters for three reasons.

First, classification. SaMD is classified on its own terms under Annex VIII Rule 11. SiMD inherits the classification of the device it drives or influences — an infusion pump's firmware is classified as part of the infusion pump, not under Rule 11.

Second, the conformity assessment route. SaMD is conformity-assessed as a stand-alone device, which means the manufacturer is the software company. SiMD is conformity-assessed as part of the parent device, and the hardware manufacturer owns the regulatory file — unless the software is placed on the market separately, in which case it can become SaMD in its own right.

Third, the lifecycle obligations. Both categories are covered by MDR Annex I Section 17 and both commonly use EN 62304:2006+A1:2015. But the SaMD manufacturer carries the full weight of the QMS, PMS, clinical evaluation, and vigilance obligations on the software alone, while the SiMD developer is often operating under the parent device manufacturer's QMS.

Most of the startups we work with in this category are building SaMD, not SiMD. This post treats SaMD as the default. We cover the SiMD side separately — see post 372 for the full distinction.

## How software qualifies as a medical device under Article 2(1)

Qualification is the first question, and it is a binary: either the software is a medical device under Article 2(1) or it is not. MDCG 2019-11 Rev.1 provides the decision tree the European Commission and Notified Bodies use to answer this question consistently. The key tests, in the order that MDCG 2019-11 Rev.1 applies them, are these.

**Is it software?** Sounds trivial. It is not, because the MDR definition of software in MDCG 2019-11 Rev.1 includes things founders sometimes forget are software — algorithms embedded in hardware, cloud services, mobile applications, modules within larger systems. If the thing executes a set of instructions that process data, it is software for the purpose of this question.

**Does it perform an action on data beyond storage, archival, lossless compression, communication, or simple search?** This is the "more than a database" test. Pure storage is not SaMD. Pure transmission is not SaMD. Pure search — even over medical data — is not SaMD. The moment the software does something to the data that changes its meaning or produces new information — calculation, interpretation, pattern recognition, risk scoring, alerting on thresholds — the action test is crossed.

**Is the action performed for the benefit of individual patients?** General public-health statistics, aggregated research analytics, and population-level dashboards are typically not SaMD. The action has to be aimed at decisions about specific individuals.

**Is the intended purpose a medical purpose under Article 2(1)?** This is the final and often-decisive question. The medical purposes listed in Article 2(1) are specific: diagnosis, prevention, monitoring, prediction, prognosis, treatment, alleviation of disease; diagnosis, monitoring, treatment, alleviation of, or compensation for an injury or disability; investigation, replacement, or modification of the anatomy or a physiological or pathological process or state. If the manufacturer's stated intended purpose falls into one of these categories, the software is a medical device. If it does not, it is not.

What does not qualify, if the intended purpose is written correctly: lifestyle and wellness apps without medical claims; fitness trackers used purely for general fitness; simple appointment-booking software; hospital administration and billing software; educational or reference tools that do not provide patient-specific recommendations; and software that merely stores or transmits medical data without acting on it.

This is where the intended purpose becomes a strategic question. The qualification test is sensitive to how the manufacturer phrases the claims. A wellness positioning with no medical claims keeps the software outside the MDR. A medical positioning — even a small claim added to improve conversion — brings the software inside. The choice is legitimate either way as long as it is made deliberately, documented honestly, and held consistently across the website, the app store listing, the marketing materials, and the eventual clinical evaluation. We cover the intended-purpose decision in depth in post 006 and post 373.

## Classification under Annex VIII Rule 11 — the software reality check

Once software qualifies, Rule 11 applies. The language of Rule 11 is dense, but the practical consequence for startups is simple: most medical software is Class IIa at minimum.

Here is how Rule 11 breaks down.

**Class III** — Software intended to provide information which is used to take decisions with diagnostic or therapeutic purposes, where those decisions have an impact that may cause death or irreversible deterioration of a person's state of health.

**Class IIb** — Software intended to provide information which is used to take decisions with diagnostic or therapeutic purposes, where those decisions have an impact that may cause serious deterioration of a person's state of health or a surgical intervention; OR software intended to monitor physiological processes, where the nature of the variations of those parameters is such that it could result in immediate danger to the patient.

**Class IIa** — Software intended to provide information which is used to take decisions with diagnostic or therapeutic purposes (default for this category); OR software intended to monitor physiological processes.

**Class I** — All other software.

Read the hierarchy carefully. The word "information" covers outputs like risk scores, severity gradings, priority flags, classification outputs, and recommended actions — anything the software produces that feeds a clinical decision. The word "decisions" includes decisions made by clinicians using the software as one input, not only decisions the software makes autonomously. The phrasing was deliberate in the MDR to capture clinical decision support, not only autonomous diagnostic AI.

The practical consequence is that if your software provides any information that clinicians use to make diagnostic or therapeutic decisions about individual patients, the floor is Class IIa. Getting to Class I requires an intended purpose that genuinely does not provide decision-support information — for example, a purely administrative tool, or a pure communication tool, or an educational reference — which for most medical-software startups is not what they are building.

MDCG 2019-11 Rev.1 (June 2025) contains worked examples of Rule 11 classifications across imaging, cardiology, diabetes, oncology, dermatology, and other domains. Those examples are the single best resource for calibrating your own classification argument before it reaches a Notified Body. Post 081 and post 085 walk through Rule 11 at deeper levels for specific sub-cases.

The reality check for founders is this. If you assumed Class I, assume again. The most common classification mistake we see in early-stage medical software startups is a Class I assumption that does not survive the first serious reading of Rule 11 and MDCG 2019-11 Rev.1. Running that reading before building the QMS saves months.

## What MDCG 2019-11 Rev.1 actually says — and why you must read it

MDCG 2019-11 — Guidance on Qualification and Classification of Software in Regulation (EU) 2017/745 — MDR and Regulation (EU) 2017/746 — IVDR — was first published in October 2019. Revision 1 was published in June 2025 and is the current version at the time of writing. If you find a version online that is older than June 2025, you are reading a superseded document.

MDCG 2019-11 Rev.1 does four things that the MDR text alone does not do.

**It provides the qualification decision tree.** The MDR text gives you the definition and the intended purpose concept, but not a repeatable algorithm for walking a specific piece of software through the qualification question. MDCG 2019-11 Rev.1 gives you that algorithm in flowchart form. This is the flowchart that Notified Bodies and Competent Authorities themselves use. Using it yourself means you are reasoning the same way the people who will judge your file are reasoning.

**It provides worked classification examples.** The document walks through multiple real-world software examples and shows how Rule 11 applies to each. These examples are how you calibrate borderline cases — if your software resembles one of the worked examples, the classification is largely settled.

**It addresses modules and changes.** Modern medical software is rarely monolithic. MDCG 2019-11 Rev.1 covers how to handle software that contains both medical and non-medical modules, how to handle software that interfaces with other medical devices, and how to handle changes to software that is already placed on the market. This is the part of the document most founders skip — and it is the part that matters most once the software has shipped once and needs to evolve.

**It clarifies specific recurring borderline cases.** Decision support, CDS tools, pure imaging viewers, PACS, lab information systems, MDSW intended for non-medical purposes, apps that become medical devices by adding a claim — MDCG 2019-11 Rev.1 addresses each of these in ways that close off the most common misinterpretations.

Reading MDCG 2019-11 Rev.1 in full is a half-day exercise. We cover the document in detail in post 374. If you build medical software for the EU market and you have not read it, stop reading this post and go read that one.

## The software lifecycle — MDR Annex I Section 17 and EN 62304:2006+A1:2015

Once the software qualifies and is classified, the lifecycle obligations apply. The MDR text is explicit: software must be developed and manufactured in accordance with the state of the art, taking into account the principles of development life cycle, risk management including information security, verification, and validation. This is MDR Annex I Section 17. It is not optional, and it is not scalable in the sense of "we are small so we skip it." It is scalable only in the sense that the depth and formality of the work matches the software safety class.

EN 62304:2006+A1:2015 is the harmonised standard that provides presumption of conformity with the software-lifecycle aspects of Annex I. It defines the lifecycle activities — planning, requirements analysis, architectural design, detailed design, implementation, integration, system testing, release, maintenance, risk management, configuration management, problem resolution — and the documentation expectations at each stage.

EN 62304:2006+A1:2015 introduces its own software safety classification — Class A, Class B, Class C — which is distinct from the MDR device class under Rule 11. This is the point where founders get confused. The two classifications are related but not the same. The EN 62304:2006+A1:2015 software safety class reflects the severity of harm that could result from a software failure, before external risk controls, and it drives the specific lifecycle activities that are required within the standard. The MDR device class reflects the regulatory classification of the software as a medical device under Annex VIII Rule 11, and it drives the conformity assessment route with the Notified Body.

You need both classifications and they have to be consistent with the rest of the risk management file. Risk management runs under EN ISO 14971:2019+A11:2021, which is the harmonised standard referenced for risk management under MDR Annex I — and the risk-management output feeds into the EN 62304:2006+A1:2015 software safety class determination. Get the risk management wrong and the software safety class falls apart. Get the software safety class wrong and the EN 62304:2006+A1:2015 lifecycle activities do not match the actual risk, which either over-engineers the development or under-engineers it.

We walk through the software lifecycle expectations in post 376 and the EN 62304:2006+A1:2015 software safety classification in post 377.

The other foundational piece for medical software is EN ISO 13485:2016+A11:2021 — the QMS standard. A software company is still a medical device manufacturer, and a manufacturer needs a QMS. The QMS for a software-only company can be lean — we have seen effective ones run by three-person teams — but it has to be real. We cover the software QMS shape in the QMS category posts.

## Common startup misunderstandings

**"We are just an app. The MDR does not apply to apps."** The MDR does not distinguish between desktop software, web platforms, and mobile apps. The qualification is driven by intended purpose, not by the delivery channel. If your app claims to diagnose, monitor, predict, or treat a condition, you are in scope. The App Store review is not the regulatory assessment.

**"Our software is Class I because we just provide information."** Rule 11 does not work that way. Providing information used for diagnostic or therapeutic decisions is the default path to Class IIa, not to Class I. The "all other software" bucket at Class I is narrower than the name suggests.

**"We are not a medical device because a clinician is always in the loop."** Rule 11 explicitly covers decision-support software used by clinicians. The presence of a clinician in the loop does not remove the qualification, and it does not drop the classification below IIa unless the nature of the information genuinely does not inform diagnostic or therapeutic decisions.

**"We will figure out the lifecycle documentation later."** MDR Annex I Section 17 and EN 62304:2006+A1:2015 are not back-fillable without a lot of rework. Documentation that was not maintained as the code was written has to be reconstructed, and reconstructed documentation is one of the cleanest ways to fail a Notified Body audit. The lifecycle starts on day one of the code, not on day one of the certification project.

**"ISO 13485 is for hardware manufacturers, not software."** EN ISO 13485:2016+A11:2021 applies to any manufacturer of a medical device, hardware or software. The processes look different in a software-only company, but the obligations are the same.

**"Our engineers use Agile, so we cannot do EN 62304:2006+A1:2015."** EN 62304:2006+A1:2015 is process-neutral. Agile development is fully compatible with the standard. The required activities — planning, requirements, design, verification, problem resolution — happen in Agile teams too; they just happen in shorter cycles. The documentation has to reflect what actually happens, and with a well-set-up Agile pipeline this is mostly automatable.

## The two-phase approach for SaMD — the Subtract to Ship angle

SaMD is the category where the two-phase approach pays off most dramatically. We have worked with a Salzburg-based SaaS startup where Phase 1 was deliberately scoped outside the MDR. The software ran on hospital data in a non-clinical configuration — research use, internal analytics, no diagnostic or therapeutic claims. The goal of Phase 1 was to prove the product worked on real hospital data and solved a real problem that hospitals would pay for. Only after Phase 1 produced clear signal did the company move into Phase 2 — adding the medical intended purpose, starting the QMS, building the technical documentation, and moving toward CE marking.

The two-phase approach works in SaMD for reasons that do not apply to hardware. Software can be re-configured between a non-medical research use and a medical use without changing the code base — the delta is the intended purpose, the labelling, the claims, the clinical evaluation, and the lifecycle documentation. Hardware cannot do this; you cannot un-ship a catheter. Software can be built in a way that lets the medical claim come later, as long as the architecture, the data handling, the risk-management posture, and the documentation discipline are medical-grade from the start even if the claim is not yet medical.

This is the Subtract to Ship application to SaMD. Do not start the MDR work on day one for a product that has not yet proved anyone needs it. Do not skip medical-grade engineering discipline either, because the cost of back-filling is much higher than the cost of building it in. Subtract the premature regulatory paperwork; keep the lifecycle discipline that makes the later paperwork possible. Post 051 covers the two-phase approach in full; post 065 covers the Subtract to Ship framework as applied to MDR.

The trap to avoid is the opposite mistake — running in Phase 1 forever while making medical claims in marketing. A startup that says "it is not a medical device because we are in research mode" while their website claims diagnostic performance is in Phase 2 whether they admit it or not, and the absence of MDR compliance is a regulatory problem, not a framework. Phase 1 only works if the claims match the phase.

## Reality Check — Where do you stand on your SaMD qualification and classification?

1. Have you written down the intended purpose of your software in one paragraph, in the form the MDR Article 2(12) expects, covering labelling, IFU, and promotional materials?
2. Have you walked your software through the MDCG 2019-11 Rev.1 qualification decision tree, in writing, and reached a defensible answer?
3. If you believe you are not a medical device, does every public claim on your website, app store listing, and marketing materials match that position without exception?
4. If you believe you are a medical device, have you applied Rule 11 explicitly — not from memory, but from the text of Annex VIII — and reached a defensible class?
5. Have you cross-checked your Rule 11 classification against the worked examples in MDCG 2019-11 Rev.1?
6. Is your engineering team running a documented lifecycle process that would map onto EN 62304:2006+A1:2015 activities, even if the formal standard is not yet in place?
7. Does your risk management follow EN ISO 14971:2019+A11:2021, and does it feed the EN 62304:2006+A1:2015 software safety class consistently?
8. Do you know the difference between the MDR device class under Rule 11 and the EN 62304:2006+A1:2015 software safety class, and have you assigned both?
9. If you are in Phase 1 of a two-phase approach, do your public claims match the non-medical positioning of Phase 1?

Any question you cannot answer with a clear yes is a gap. Close it before the engineering team builds another sprint's worth of work on top of assumptions that may not hold.

## Frequently Asked Questions

**Is SaMD the same as MDSW under the MDR?**
In practice, yes. The MDR text and MDCG 2019-11 Rev.1 use the term "Medical Device Software" (MDSW). "Software as a Medical Device" (SaMD) is the IMDRF term, used in international regulatory discussions and widely adopted in industry. The two terms cover the same concept — software that is itself a medical device, as opposed to software embedded in a hardware device. When you file with a Notified Body in the EU, use the MDR and MDCG 2019-11 Rev.1 language (MDSW).

**Can a mobile app be a Class I medical device under the MDR?**
In theory yes, in practice rarely. Rule 11 pushes most medical software that processes patient-specific data for diagnostic or therapeutic decisions to Class IIa at minimum. A mobile app that is Class I under the MDR is usually one that does not provide decision-support information at all — for example, a pure patient diary without interpretation, or an appointment scheduler. If your app does any clinical interpretation, assume Class IIa until MDCG 2019-11 Rev.1 proves otherwise.

**Do I need EN 62304:2006+A1:2015 if I am not pursuing CE marking yet?**
The standard gives presumption of conformity with MDR Annex I Section 17. If you are not yet applying for CE marking, you are not yet legally required to comply. But if you are writing code now that will become a medical device later, running development under EN 62304:2006+A1:2015-compatible processes from the start is much cheaper than back-filling the documentation when the MDR project begins. This is the lifecycle-discipline-now, paperwork-later approach from the two-phase method.

**What happens if I launch my software without the MDR qualification question answered?**
If the software qualifies as a medical device and you placed it on the EU market without CE marking, you are non-compliant under MDR Article 5, which prohibits placing non-conforming devices on the market. The consequences range from enforcement action by Competent Authorities to market withdrawal and, in serious cases, penalties. For software, the specific risk is that a single marketing claim or a single clinical use pattern can retroactively make the product a medical device that should have been CE-marked. Answer the qualification question first, in writing, and keep it current.

**Is US FDA SaMD classification the same as MDR classification?**
No. The two systems use different criteria. The IMDRF SaMD framework influenced both, but FDA and MDR diverge in how they translate it into classification. A device that is Class II under FDA could be Class IIa, IIb, or even III under the MDR depending on Rule 11 — or the other way around. Never assume a US classification maps directly to an EU classification. We cover the comparison in the FDA category posts.

**My software uses AI. Does that change the classification?**
The MDR text and Rule 11 do not treat AI differently from other software for qualification and classification purposes. The qualification question is still driven by intended purpose, and Rule 11 still applies. What AI changes is the lifecycle discipline, the clinical evaluation expectations, the PMS obligations around model drift, and the transparency and documentation expectations of the Notified Body. The forthcoming AI Act adds a separate regulatory layer on top of the MDR for AI systems. We cover AI/ML medical devices in a separate category.

## Related reading

- [What Is the EU Medical Device Regulation?](/blog/what-is-eu-mdr) — the category-1 pillar covering the MDR as a whole, the anchor post for everything including SaMD.
- [What Is a Medical Device Under the MDR?](/blog/what-is-medical-device-under-mdr) — the general qualification question that precedes the software-specific qualification.
- [The Two-Phase Development Approach for MedTech Startups](/blog/two-phase-development-approach) — the time-axis strategy that works best for SaMD.
- [The Subtract to Ship Framework for MDR Compliance](/blog/subtract-to-ship-framework-mdr) — the methodology pillar for this entire blog, with direct application to SaMD scoping.
- [MDR Classification Rule 11 for Software — The Short Version](/blog/mdr-classification-rule-11-software) — the entry-level spoke on Rule 11.
- [MDR Classification Rule 11 for Software — The Deep Dive](/blog/mdr-classification-software-rule-11-deep-dive) — the advanced spoke on Rule 11, including borderline cases.
- [SaMD vs SiMD — Software as a Medical Device vs Software in a Medical Device](/blog/samd-vs-simd-distinction) — the detailed treatment of the distinction sketched in this post.
- [When Does Software Qualify as a Medical Device?](/blog/when-does-software-qualify-medical-device) — the qualification decision tree walkthrough.
- [MDCG 2019-11 Rev.1 — What the Software Guidance Actually Says](/blog/mdcg-2019-11-software-guidance) — the full reading of the definitive guidance document.
- [The MDR Software Lifecycle and EN 62304:2006+A1:2015](/blog/mdr-software-lifecycle-iec-62304) — the lifecycle obligations deep dive.
- [EN 62304:2006+A1:2015 Software Safety Classification A, B, C](/blog/software-safety-classification-iec-62304) — the software safety class, distinct from the MDR device class.

## Sources

1. Regulation (EU) 2017/745 of the European Parliament and of the Council of 5 April 2017 on medical devices, Article 2, points 1 and 12; Annex I, Section 17; Annex VIII, Rule 11. Official Journal L 117, 5.5.2017.
2. MDCG 2019-11 — Guidance on Qualification and Classification of Software in Regulation (EU) 2017/745 — MDR and Regulation (EU) 2017/746 — IVDR. First published October 2019; Revision 1, June 2025.
3. EN 62304:2006+A1:2015 — Medical device software — Software life-cycle processes (IEC 62304:2006 + IEC 62304:2006/A1:2015).
4. EN ISO 14971:2019+A11:2021 — Medical devices — Application of risk management to medical devices.
5. EN ISO 13485:2016+A11:2021 — Medical devices — Quality management systems — Requirements for regulatory purposes.

---

*This post is the pillar for the Software as a Medical Device Under MDR category in the Subtract to Ship: MDR blog. Authored by Felix Lenhard and Tibor Zechmeister. The MDR is the North Star for every claim in this post — EN 62304:2006+A1:2015 is the tool that provides presumption of conformity with the software-lifecycle requirements of MDR Annex I Section 17, not an independent authority. For startup-specific regulatory support on SaMD qualification, classification, and lifecycle, Zechmeister Strategic Solutions is where this work is done in practice.*

---

*This post is part of the [Software as a Medical Device](https://zechmeister-solutions.com/en/blog/category/samd) cluster in the [Subtract to Ship: MDR Blog](https://zechmeister-solutions.com/en/blog). For EU MDR certification consulting, see [zechmeister-solutions.com](https://zechmeister-solutions.com).*