The complete regulatory path for a Software as a Medical Device startup under the MDR runs in nine sequential stages: (0) write the intended purpose, (1) qualify the software as a medical device using MDCG 2019-11 Rev.1 against Article 2(1), (2) classify under Annex VIII Rule 11, (3) run a Phase 1 feasibility outside the MDR, (4) build Phase 2 under EN 62304:2006+A1:2015 with EN ISO 14971:2019+A11:2021 risk management, EN 62366-1:2015+A1:2020 usability, and EN IEC 81001-5-1:2022 cybersecurity, (5) complete the clinical evaluation under Article 61, (6) assemble the technical documentation per Annex II and Annex III, (7) run conformity assessment. Which requires a Notified Body for Class IIa and above. And (8) affix the CE mark and operate post-market surveillance. Article 10 anchors the manufacturer's obligations across every stage. Article 51 is the classification anchor. The MDR is the North Star; the standards are the tools.

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

TL;DR

  • The SaMD regulatory path is not a framework. It is a sequence that follows directly from the MDR text, and every stage has an article or annex that governs it.
  • Stage 0 and Stage 1. Intended purpose and qualification. Are decided before a single line of production code is written. Get them wrong and everything downstream collapses.
  • Stage 2. Classification under Annex VIII Rule 11. Determines whether a Notified Body is mandatory. For most SaMD, the answer is yes, and the conformity assessment route is set at this point.
  • Stages 3 and 4. Phase 1 feasibility and Phase 2 compliant build. Are where the Subtract to Ship two-phase approach does its work. Subtract premature paperwork in Phase 1; keep engineering discipline that makes Phase 2 documentation possible.
  • Stages 5 through 8. Clinical evaluation, technical documentation, conformity assessment, CE mark and post-market surveillance. Are the visible certification project, but they rest on the decisions made in Stages 0 to 4.
  • MDCG 2019-11 Rev.1 (June 2025) is the current guidance. Using any older version is reading a superseded document.

The story that runs under this post

A Salzburg-based SaaS founder came to us with a clinical decision-support product that had six months of hospital-pilot data and no regulatory strategy. The engineering team had shipped fast, the product was useful, and the hospital partners were already asking about scaling to other sites. The founder had been told by two advisors that the product was probably Class I, maybe not even a medical device at all.

We ran the qualification and classification exercise in a single afternoon. The product was clearly a medical device under Article 2(1), and under Annex VIII Rule 11 it was Class IIa at minimum. The founder's reaction was the reaction we see most often: first frustration, then relief. Frustration because the "not a medical device" hope evaporated. Relief because for the first time the path was clear, and the path had a shape that could be planned, budgeted, and scheduled.

What we did next is the subject of this post. The product went through a deliberate Phase 1. Research use on hospital data, no diagnostic or therapeutic claims, funded by hospital pilots. Followed by a Phase 2 compliant build under EN 62304:2006+A1:2015. The Phase 1 gave the founder the signal that the product worked and the money to fund Phase 2. The Phase 2 produced a CE-marked SaMD that is now being sold across multiple EU hospitals. The total elapsed time from the afternoon of the qualification exercise to the CE mark was under two years. That is what a clean path looks like when every stage is taken in the right order.

Stage 0. Write the intended purpose

The intended purpose is the sentence that decides everything else. MDR Article 2(12) defines it as the use for which a device is intended according to the data supplied by the manufacturer on the label, in the instructions for use, in promotional or sales materials or statements, and as specified by the manufacturer in the clinical evaluation. Every stage that follows. Qualification, classification, lifecycle scope, clinical evaluation design, technical documentation, conformity assessment. Is driven by this sentence.

The intended purpose has to state what medical condition the software addresses, in which patient population, by which clinical users, in which clinical context, producing what kind of output, and for what downstream clinical action. A sentence that lacks any of these elements is a sentence that a Notified Body will not accept and that a founder cannot defend.

The intended purpose is the first artefact and the one that changes least. If it changes after Stage 1, every stage after it has to be re-run. That is why founders who end up with a clean regulatory path write the intended purpose first, have it reviewed by someone who has seen Notified Body assessments before, and only then open a file in their IDE.

Post 373 covers the intended-purpose decision in depth.

Stage 1. Qualify the software under MDCG 2019-11 Rev.1

Once the intended purpose is written, the qualification question is binary: is the software a medical device under MDR Article 2(1)?

MDCG 2019-11 Rev.1 (June 2025) provides the decision tree the European Commission and Notified Bodies use to answer this question. The tree walks through four tests: is the thing software, does it perform an action on data beyond storage and transmission, is the action for the benefit of individual patients, and is the intended purpose a medical purpose under Article 2(1). A software that passes all four tests is a medical device. A software that fails any one is not.

The qualification exercise produces a written document. The qualification rationale. That sits at the top of the technical documentation and is referenced by every Notified Body submission. The document must name MDCG 2019-11 Rev.1 explicitly, walk through the decision tree step by step, and reach a conclusion with reasoning. This is not a formality. A weak qualification rationale is one of the cleanest ways a technical file fails at Notified Body review.

Post 371 and post 374 cover the qualification exercise and the full reading of MDCG 2019-11 Rev.1. Post 411 walks through the qualification rationale template.

Stage 2. Classify the software under Annex VIII Rule 11

Classification under MDR Article 51 is the act of applying the rules in Annex VIII to the device and recording the result. For SaMD, the governing rule is almost always Annex VIII Rule 11.

Rule 11 reads, in substance: software intended to provide information used to take decisions with diagnostic or therapeutic purposes is Class IIa; it escalates to Class IIb if the decisions could cause serious deterioration of health or a surgical intervention; it escalates to Class III if the decisions could cause death or irreversible deterioration of a person's state of health. 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 practical consequence is that Class I is the exception. Most medical software that reaches a clinical user with an interpretation, a score, an alert, or a recommendation is Class IIa at minimum. MDCG 2019-11 Rev.1 contains worked classification examples that calibrate borderline cases, and those examples are the single best resource for testing a proposed classification before a Notified Body does.

The classification output is the single number that decides whether Stage 7 requires a Notified Body. For Class I SaMD, the manufacturer self-certifies. For Class IIa, IIb, and III, a Notified Body is mandatory. This is the moment in the path where the project's cost, timeline, and organisational shape are set.

Post 081 covers Rule 11 in full.

Stage 3. Run Phase 1 feasibility outside the MDR

Stage 3 is where the Subtract to Ship methodology does its specific work for SaMD. The goal of Stage 3 is to prove that the product works and that someone will pay for it, without yet carrying the weight of the MDR.

Phase 1 is the research-use, non-medical-claim configuration of the product. The software runs on hospital data in a non-clinical configuration. Internal analytics, research collaboration, retrospective analysis. And the claims across the website, the marketing materials, and the contracts match that configuration exactly. No diagnostic claim. No therapeutic claim. No clinical intended purpose. The engineering work is real, the data is real, the hospital partners are real, but the regulatory status is clearly non-medical because the intended purpose is clearly non-medical.

The trap to avoid is making medical claims in marketing while insisting the product is in research mode. A startup that does this is in Stage 4 whether it admits it or not, and the absence of MDR compliance becomes a regulatory problem. Phase 1 only works if the claims match the phase.

What Phase 1 must preserve, even though the MDR does not yet apply, is the engineering discipline that Stage 4 will require. Source control history, requirements traceability, design documentation, code review records, test artefacts, and risk-management thinking must be maintained at medical-grade quality from the first commit. Documentation that was not maintained during Phase 1 has to be reconstructed in Phase 4, and reconstructed documentation fails Notified Body audits.

Post 051 covers the two-phase approach and post 065 covers the Subtract to Ship framework applied to MDR.

Stage 4. Build Phase 2 under the harmonised standards

When Phase 1 has produced signal. Paying customers, clinical feedback, a proven product-market fit. Phase 2 begins. Phase 2 is the MDR-compliant build. The intended purpose now includes the medical claim, the QMS is stood up, and the lifecycle work begins under the harmonised standards.

Four standards govern the Phase 2 technical work for SaMD, and all four have to run in parallel.

EN 62304:2006+A1:2015. The software lifecycle. This is the harmonised standard for medical device software lifecycle processes. It covers planning, requirements analysis, architectural design, detailed design, implementation, integration, system testing, release, maintenance, risk management, configuration management, and problem resolution. It introduces its own software safety classification. Class A, B, C. Which is distinct from the MDR device class under Rule 11 and which drives the specific lifecycle activities required within the standard. Compliance with EN 62304:2006+A1:2015 gives presumption of conformity with the software-lifecycle aspects of MDR Annex I Section 17. Post 376 covers the lifecycle and post 377 covers the software safety classification.

EN ISO 14971:2019+A11:2021. Risk management. This is the harmonised standard for application of risk management to medical devices. It feeds the EN 62304:2006+A1:2015 software safety class determination and runs continuously across the product lifecycle. The risk-management file is not a document produced once at the end. It is a living artefact that tracks hazards, hazardous situations, foreseeable sequences of events, harms, risk estimates, risk controls, and residual risks, with updates every time the software changes. Post 379 covers the risk-management file.

EN 62366-1:2015+A1:2020. Usability engineering. This is the harmonised standard for application of usability engineering to medical devices. For SaMD, usability is often the dominant source of risk. A software that produces a correct output presented in a confusing way can drive a clinician to the wrong decision. The usability engineering file documents the use specification, the user interface characterisation, the known and foreseeable use errors, the usability validation, and the residual usability risks. Post 381 covers usability engineering for SaMD.

EN IEC 81001-5-1:2022. Cybersecurity. This is the harmonised standard for health software and health IT systems safety, effectiveness, and security. The cybersecurity activities in the product lifecycle. It covers secure development, threat modelling, vulnerability management, software bill of materials (SBOM), security risk management, and post-market security monitoring. Under MDR Annex I Section 17, information security is an explicit requirement, and EN IEC 81001-5-1:2022 is the state-of-the-art way to demonstrate it. Post 386 covers cybersecurity for SaMD.

All four standards run under an EN ISO 13485:2016+A11:2021 quality management system. The QMS is the container. The lifecycle, risk-management, usability, and cybersecurity files sit inside it.

Post 388 covers the Phase 2 build orchestration.

Stage 5. Clinical evaluation under Article 61

MDR Article 61 requires the manufacturer to plan, conduct, and document a clinical evaluation of the device. The clinical evaluation demonstrates that the device achieves its intended purpose, that the clinical benefits outweigh the residual risks, and that the state of the art has been taken into account.

For SaMD, the clinical evaluation has specific features. The clinical data can come from clinical investigations, from scientific literature, from clinical experience, or from post-market clinical follow-up, and the weighting of these sources depends on the novelty of the device and the class. A Class IIa clinical decision-support tool with a well-established clinical use may rely largely on literature and retrospective analytical performance; a Class IIb or Class III SaMD with a novel algorithm will almost always require prospective clinical investigation data.

The clinical evaluation plan is written at the start of Stage 5 and drives the clinical data strategy. The clinical evaluation report is the artefact that goes into the technical documentation. For software, the clinical performance, the analytical performance, and the scientific validity have to be distinguished and evidenced separately. A distinction that MDCG guidance on clinical evaluation of MDSW covers in detail.

Post 418 covers the clinical evaluation for SaMD in full.

Stage 6. Assemble the technical documentation per Annex II and Annex III

MDR Annex II specifies the structure of the technical documentation and Annex III specifies the post-market surveillance documentation. For SaMD, the technical documentation sits at the top of everything the engineering team and the regulatory team have produced in Stages 0 through 5.

The Annex II structure includes: device description and specification including variants and accessories; labelling and instructions for use; design and manufacturing information; general safety and performance requirements (a point-by-point demonstration of compliance with Annex I, including Section 17 for software); benefit-risk analysis and risk management (EN ISO 14971:2019+A11:2021 output); product verification and validation (including the EN 62304:2006+A1:2015 lifecycle output, the EN 62366-1:2015+A1:2020 usability engineering output, the EN IEC 81001-5-1:2022 cybersecurity output, and the clinical evaluation report from Stage 5).

Annex III specifies the post-market surveillance plan, the periodic safety update report (PSUR) for Class IIa and above, and the post-market clinical follow-up plan. These documents are not optional add-ons. They are part of the technical file, and a technical file without them is incomplete.

The technical documentation is the deliverable the Notified Body reviews. It has to be complete, traceable, consistent with the QMS records, and aligned with the intended purpose written in Stage 0. Any gap between the file and the underlying records is a finding.

Stage 7. Conformity assessment (with a Notified Body for Class IIa and above)

MDR Article 52 lays out the conformity assessment routes, and the route depends on the class from Stage 2. Class I SaMD (the rare case) is self-certified by the manufacturer. Class IIa, IIb, and III SaMD require Notified Body involvement under Annex IX, X, or XI.

The Notified Body conformity assessment has two main elements: an audit of the QMS under EN ISO 13485:2016+A11:2021 and a review of the technical documentation under Annex II and Annex III. For Class III and for implantable Class IIb, technical documentation review is mandatory for every device; for lower classes, it is typically sample-based. The Notified Body issues one or more certificates. QMS certificate and technical documentation certificate. That authorise CE marking.

Selecting a Notified Body is a project of its own. Capacity is tight across the EU, lead times for new clients are measured in months, and each Notified Body has its own scope of designation under the MDR. A Notified Body that is not designated for your product code cannot certify your device. Starting the Notified Body selection process in Stage 6 is often too late; Stage 4 is better.

Article 10 of the MDR is the anchor for the manufacturer's obligations across the conformity assessment and every stage before and after it. Reading Article 10 in full and tracing each sub-paragraph to a specific artefact in your QMS is one of the cleanest ways to pretest a technical file before it reaches the Notified Body.

Stage 8. Affix the CE mark and operate post-market surveillance

Once the certificates are issued, the manufacturer affixes the CE mark, issues the EU declaration of conformity, and places the device on the market. From the moment of placing on the market, the post-market obligations begin.

Post-market surveillance is continuous. The PMS plan (part of the technical documentation under Annex III) drives the ongoing collection of data about the device's performance and safety in real use. Post-market clinical follow-up (PMCF) specifically targets clinical data gaps identified during the clinical evaluation. Vigilance reporting covers serious incidents and field safety corrective actions. The periodic safety update report (PSUR) summarises PMS outputs at intervals defined by the class. Annually for Class IIb and III, every two years for Class IIa.

For SaMD, post-market surveillance has a specific feature: software changes. Every change to the software has to be assessed for significance. Significant changes require notification to the Notified Body and may require a new conformity assessment; non-significant changes are documented under change control in the QMS. The boundary between significant and non-significant is one of the recurring themes of MDCG 2019-11 Rev.1 and one of the most frequent questions founders bring us after CE marking.

The CE mark is not the end of the path. It is the transition from build mode to operate mode.

The Subtract to Ship angle. Why this sequence saves money

The nine stages above are not optional, and they are not negotiable. What is negotiable is how much work is done in each stage and when.

Subtract to Ship applied to SaMD looks like this. Do the intended purpose, the qualification, and the classification in full. Stages 0, 1, and 2. Before writing production code. The cost of doing these stages rigorously is measured in days. The cost of getting them wrong is measured in months or years of rework. This is work that must be added, not subtracted.

Subtract the premature MDR paperwork in Stage 3. The Phase 1 feasibility is outside the MDR by design. Do not stand up a full ISO 13485 QMS for a product that has not yet proved anyone will pay for it. Do not write a clinical evaluation plan for a product whose intended purpose may change. Do not select a Notified Body before you know if Phase 2 will happen.

Keep the engineering discipline even in Phase 1. Source control, requirements, design documentation, test artefacts, risk thinking. These cost little at the start and everything to reconstruct later. The Subtract to Ship instinct is to cut paperwork, not to cut discipline.

Add the full weight of Stages 4 through 8 only when Phase 1 has produced the signal that justifies it. This is where the math works: the Phase 1 reduces the probability of wasting Phase 2 spend on a product that would not have sold, and the Phase 2 produces a CE-marked product on the shortest defensible path.

The Salzburg SaaS story above is this math in practice. Phase 1 produced hospital pilots and paying customers. Phase 2 produced a CE-marked product. The total spend was a fraction of what the founder would have spent running Phase 2 from day one on a product that had not yet been validated.

Reality Check. Where are you on the SaMD path?

  1. Have you written your intended purpose as a single paragraph covering condition, population, users, context, output, and downstream action?
  2. Have you walked the MDCG 2019-11 Rev.1 decision tree for your software, in writing, and reached a documented qualification conclusion?
  3. Have you applied Annex VIII Rule 11 explicitly and recorded the classification output with reasoning?
  4. If you assumed Class I, have you tested that assumption against the worked examples in MDCG 2019-11 Rev.1?
  5. If your product is in a Phase 1 configuration, do every website claim, marketing asset, and customer contract match the non-medical positioning without exception?
  6. Is your engineering team already running a process that would map onto EN 62304:2006+A1:2015 activities. Source control, requirements, design, testing, problem resolution. Even if the standard is not yet formally in place?
  7. Is your risk-management thinking already following EN ISO 14971:2019+A11:2021 principles, with a hazard log that can become a risk-management file?
  8. Have you identified the Notified Body or Bodies whose scope of designation covers your product code, and do you know their current lead times?
  9. 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?
  10. Do you have a clinical evaluation strategy that reflects the novelty and class of your device, with a defensible plan for clinical performance, analytical performance, and scientific validity?
  11. Is your post-market surveillance plan written at the same time as the technical documentation, not afterwards?
  12. Do you know which changes to your software would trigger re-notification to the Notified Body once the device is CE-marked?

Any question you cannot answer with a clear yes is a gap. Close it before you take the next stage.

Frequently Asked Questions

How long does the full SaMD path take from Stage 0 to CE mark? For a Class IIa SaMD built cleanly on a two-phase approach, the range we see in practice is 18 to 30 months from the start of Stage 4 to CE mark, with Stages 0 to 3 often running for 12 to 24 months before that. For Class IIb and Class III, add six to twelve months. These numbers assume a Notified Body is selected early and has capacity.

Can we skip Phase 1 and go straight to Stage 4? You can. Whether you should depends on whether you already have strong evidence that the product will sell. If the clinical need is established, the paying customers are identified, and the funding is in place, skipping Phase 1 is reasonable. If any of those is missing, Phase 1 is how you find out whether Phase 2 spend is justified.

Do we need a Notified Body for Class I SaMD? No. Class I conformity assessment is carried out by the manufacturer under Annex VIII. But Class I SaMD is rare. Before assuming you are Class I, run the Rule 11 classification exercise with someone who has seen Notified Body assessments. A wrong Class I assumption is one of the most expensive mistakes in this category.

Which standard covers AI specifically in the Phase 4 build? The MDR itself does not treat AI as a distinct category. The qualification under Article 2(1), the classification under Rule 11, and the lifecycle under Annex I Section 17 apply to AI-based SaMD the same way they apply to rule-based SaMD. EN 62304:2006+A1:2015 is the lifecycle standard, EN ISO 14971:2019+A11:2021 is the risk standard, and EN IEC 81001-5-1:2022 is the cybersecurity standard. On top of the MDR, the EU AI Act adds a separate regulatory layer for AI systems that will interact with the MDR conformity assessment for AI-based medical devices. We cover the interaction in a dedicated post.

What happens if our intended purpose changes mid-project? Stages 1 through 6 have to be re-run to the extent that the change affects qualification, classification, lifecycle scope, risk analysis, or clinical evaluation. A change to the intended purpose that adds a new clinical condition or a new user group is not a minor change. The discipline that protects against expensive re-runs is to write the intended purpose carefully in Stage 0 and to revisit it only when the evidence demands it, not when the marketing team demands it.

Does the two-phase approach work for Class III SaMD? Yes, with a warning. Class III SaMD. The Rule 11 category where decisions could cause death or irreversible deterioration. Has the highest stakes and the longest path. Phase 1 in this category is possible but narrower, because some clinical work has to be done before any use with patients, even in a research configuration. The Phase 1 shape in Class III is usually retrospective analytical performance on historical data, not prospective hospital pilots. For Class III specifically, talk to someone who has done it before planning Phase 1.

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, Article 10, Article 51, Article 61, Annex II, Annex III, 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. Revision 1, June 2025.
  3. EN 62304:2006+A1:2015. Medical device software. Software life-cycle processes.
  4. EN 62366-1:2015+A1:2020. Medical devices. Application of usability engineering to medical devices.
  5. EN IEC 81001-5-1:2022. Health software and health IT systems safety, effectiveness and security. Part 5-1: Security. Activities in the product life cycle.
  6. EN ISO 14971:2019+A11:2021. Medical devices. Application of risk management to medical devices.
  7. EN ISO 13485:2016+A11:2021. Medical devices. Quality management systems. Requirements for regulatory purposes.

This post is the SaMD Roadmap hub in the Subtract to Ship: MDR blog. Authored by Felix Lenhard and Tibor Zechmeister. The MDR is the North Star for every claim here. The harmonised standards named in Stage 4 are the tools that provide presumption of conformity with MDR Annex I, not independent authorities. For startup-specific support on any stage of the SaMD path, Zechmeister Strategic Solutions is where this work is done in practice.