A startup develops an application that analyzes smartphone camera images to assess skin lesions. The algorithm suggests whether a lesion warrants dermatological consultation. Marketing materials describe the product as a "wellness tool" that "empowers users to monitor their skin health." No CE marking. No conformity assessment. No quality management system certification. The company believes it operates outside medical device regulation because physicians make final diagnostic decisions. Whether that belief survives regulatory scrutiny depends on factors the development team may never have considered.
1. How Does MDR Classify Software?
The EU Medical Device Regulation establishes that software qualifies as a medical device when it meets the definition in Art. 2(1) MDR: any instrument, apparatus, implant, reagent, material or other article, including software, intended by the manufacturer to be used, alone or in combination, for human beings for specific medical purposes, among them diagnosis, prevention, monitoring, prediction, prognosis, treatment, or alleviation of disease.1Art. 2(1) Regulation (EU) 2017/745 of the European Parliament and of the Council of 5 April 2017 on medical devices [2017] OJ L117/1 (MDR). The definition turns on intended purpose (what the manufacturer claims the product does), not on how sophisticated the underlying technology is or whether a healthcare professional intervenes before clinical decisions are made.
Rule 11 of MDR Annex VIII assigns software to risk classes ranging from I to III based on the clinical impact of decisions the software informs.2MDR (n 1), Annex VIII, ch III, Rule 11. The rule's apparent precision (distinguishing diagnostic from monitoring functions and grading severity of potential harm) dissolves at the threshold question of what constitutes "information used to take decisions with diagnosis or therapeutic purposes," a formulation whose scope neither the regulation nor implementing guidance has settled definitively. Whether a given software function provides such information, merely displays data a clinician might consult, or falls somewhere between those poles depends on an analysis Rule 11 does not specify. And the interaction between Rule 11 and the Annex VIII implementing rules (under which software that drives or influences another device follows the classification of that device) introduces a further variable that may override the residual category entirely.
A threshold question precedes Rule 11 entirely: does the software fall under MDR or under the IVDR? Software that analyzes laboratory results, interprets genomic data, or functions as a companion diagnostic platform is classified under Regulation (EU) 2017/746 rather than MDR.3Art. 2(2) Regulation (EU) 2017/746 of the European Parliament and of the Council of 5 April 2017 on in vitro diagnostic medical devices [2017] OJ L117/176 (IVDR); Annex VIII, Rules 1–7. The IVDR classification framework (Annex VIII, Rules 1–7) does not include a software-specific classification rule equivalent to MDR Rule 11; IVD software is instead classified under the general rules applicable to the relevant device type. The IVDR transition timelines, with extended deadlines for legacy IVDs being reclassified, create distinct compliance urgency. A Swiss biotech developing software that analyzes blood biomarkers to predict treatment response must determine whether it faces MDR or IVDR classification before reaching Rule 11 at all. This article focuses on MDR software, but the MDR/IVDR boundary is itself a frequent source of misclassification.
Intended purpose derives from manufacturer claims, but regulators assess the totality of evidence, including foreseeable use and context, to determine what the intended purpose actually is.
The apparent simplicity of this framework dissolves upon application. What constitutes "information used to take decisions"? If software presents data that a clinician might use alongside other information, does the software provide information for decisions or merely display measurements? The MDCG has issued guidance addressing these questions, but the guidance creates its own interpretive challenges.4MDCG 2019-11 rev.1, Guidance on Qualification and Classification of Software in Regulation (EU) 2017/745 – MDR and Regulation (EU) 2017/746 – IVDR (Medical Device Coordination Group, June 2025).
2. Where Do Misclassifications Occur?
Misclassification typically follows predictable patterns. Each reflects a misunderstanding of how regulatory frameworks assign intended purpose and assess risk.
The "Wellness" Defense
Manufacturers frequently argue that software does not qualify as a medical device because it serves "wellness" rather than medical purposes. A blood pressure tracking application that claims to help users "understand cardiovascular trends" rather than "monitor hypertension" appears to fall outside regulatory scope. But intended purpose derives from the totality of claims and context, including marketing materials, user interface language, distribution channels, and foreseeable use. If physicians recommend the application to patients, if the interface displays clinically meaningful thresholds, if marketing references clinical studies, regulators may conclude that the actual intended purpose is medical regardless of disclaimers.
The MDCG has specifically addressed this pattern. Software that calculates cardiovascular risk scores, even when presented as informational, qualifies as a medical device if the output is intended, or reasonably foreseeable, to influence clinical decisions.5MDCG 2019-11 rev.1 (n 4), Annex II examples.
The "Clinical Decision Support" Distinction
Software that supports clinical decisions occupies contested regulatory territory. The MDR does not exclude clinical decision support software from device status, unlike certain other jurisdictions. Software that recommends a diagnosis, suggests a treatment protocol, or identifies patients at elevated risk provides "information used to take decisions" within Rule 11 regardless of whether a clinician reviews the output before acting.
Whether a healthcare professional can independently verify the software's output, a concept the MDCG guidance treats as relevant to classification level, introduces a further analytical layer whose application to specific clinical workflows resists the binary framing the guidance suggests. Independent verifiability affects classification level, not device qualification: whether software is a medical device at all depends on intended medical purpose, not on whether output can be verified. But the distinction between verifiable and non-verifiable output, applied to real clinical settings where (as documented in human factors research) time pressure, cognitive load, and algorithmic complexity interact, proves considerably less clear than the guidance framework implies.
The "Physician Override" Argument
A related misclassification pattern, illustrated in this article's opening scenario, relies on the claim that software is not a medical device because healthcare professionals make final decisions. The manufacturer argues that their diagnostic algorithm merely provides information, with the physician retaining ultimate clinical authority. This argument fundamentally misunderstands the MDR framework: intended purpose determines device status, and if software is intended to inform clinical decisions, it qualifies as a device regardless of whether a professional intervenes before action is taken. The physician's involvement may affect classification level through the independent verification analysis, but it does not determine whether the software is a device in the first instance. MDCG guidance assesses intended purpose on the totality of evidence rather than on the presence of a clinician in the loop, leaving the "physician override" framing without footing where software clearly aims to influence diagnostic or therapeutic decisions.
The contrast with US regulatory treatment sharpens this point. The 21st Century Cures Act (§ 3060) explicitly exempts certain clinical decision support software meeting four criteria, among them that the software is intended for display to a healthcare professional who can independently review the basis for the recommendations.621st Century Cures Act, Pub. L. 114-255, § 3060(a) (2016), codified at 21 U.S.C. § 360j(o)(1)(E). The statutory exemption applies to software meeting four cumulative criteria addressing the nature of the output, the intended audience, and the relationship between algorithmic recommendation and clinical judgment. The EU has no equivalent exemption, which is precisely why the "wellness defense" and "physician override" arguments fail under MDR. Developers accustomed to the US CDS framework who enter the EU market through Switzerland frequently discover that their regulatory assumptions do not translate.
The Module Theory
Software developers sometimes argue that their product does not qualify as a device because it functions as a module within a larger system. An algorithm that processes data feeds from authorized medical devices and returns results to the same devices appears to be a component rather than a standalone device. The MDR implementing rules address related scenarios: software that drives or influences the use of a device follows the classification of that device; software that is independent of any other device is classified in its own right.7MDR (n 1), Annex VIII, ch II, Implementing Rules, Rule 3.3: 'Software, which drives a device or influences the use of a device, shall fall within the same class as the device.' Independent software is classified under Rule 11. The practical question (when software constitutes an independent device versus one that drives or influences another device) lacks clear resolution in many configurations.
Underclassification Within Device Status
Even manufacturers who correctly identify their software as a medical device may misclassify within the device framework. Class I software requires only self-declaration of conformity. Class IIa and above require notified body involvement. The difference in regulatory burden is substantial, and creates incentives for aggressive classification arguments.
A manufacturer might argue that software providing diagnostic suggestions for a non-serious condition qualifies as Class IIa rather than Class IIb because the condition itself is not serious. But Rule 11 focuses on the impact of decisions, not the underlying condition. If erroneous software output could lead to delayed diagnosis of a serious condition (missing melanoma because the software incorrectly assessed a lesion as benign), the classification analysis may need to be revisited regardless of how the manufacturer characterizes typical use cases, though competent authorities may reach different conclusions on the precise classification level depending on the specific clinical context and risk mitigation measures.
3. How Does Swiss Law Apply?
Swiss medical device law has substantially aligned with EU MDR through the revised Medizinprodukteverordnung (MepV), which entered into force on 26 May 2021 and has been updated to maintain equivalence with EU requirements. Art. 15 MepV incorporates the MDR Annex VIII classification rules by reference, including software-specific provisions corresponding to Rule 11.8Art. 15 Medizinprodukteverordnung (MepV) vom 1. Juli 2020 (SR 812.213). Switzerland incorporated the MDR classification rules by reference as part of broader regulatory updates, though the medical devices chapter of the EU-Switzerland MRA has not been updated to reflect this alignment. A manufacturer classifying software for the Swiss market applies the same framework as for EU market access, with certain procedural differences.
Swissmedic maintains authority over Swiss market surveillance. A software product correctly classified for EU purposes may still face Swissmedic inquiry if Swiss market placement triggers surveillance activity. The substantive classification analysis should yield identical results, but the procedural posture differs: as an independent national authority, Swissmedic is not formally bound by positions that EU notified bodies or Member State authorities may have accepted, even where the underlying classification framework is substantively equivalent.9Bundesgesetz über Arzneimittel und Medizinprodukte (Heilmittelgesetz, HMG) vom 15. Dezember 2000 (SR 812.21), Art. 58–60.
For Swiss manufacturers seeking EU market access, the absence of updated mutual recognition creates additional complexity. A Swiss software manufacturer must designate an EU authorized representative, register devices in EUDAMED as its modules become mandatory, and work with EU-based notified bodies for conformity assessment. The obligation runs inbound as well, and that direction surprises foreign developers most: a manufacturer without a Swiss domicile, whether EU-based or US-based, may place a device on the Swiss market only after appointing a Swiss authorized representative (CH-REP), who is jointly liable for defective devices.10Art. 51 MepV (n 8) (Swiss authorised representative, CH-REP, jointly liable); Art. 11 MDR (n 1) (obligations of authorised representatives); Art. 29 MDR (n 1) (registration of devices in EUDAMED). The classification decision affects which notified bodies have competence; not all notified bodies are designated for all device classes and categories. A misclassification that underestimates device class may result in working with a notified body that lacks designation for the correct classification, invalidating the conformity assessment process.
Market reality compounds this challenge. As of 2025, not all notified bodies have the technical expertise or designation scope required for SaMD-specific conformity assessments, particularly for AI/ML-based software devices. The pool of notified bodies capable of assessing a Class IIb algorithm incorporating machine learning appears, based on industry experience, to be smaller than those handling conventional Class IIa medical devices. These capacity constraints may result in timeline risk: manufacturers whose classification analysis underestimates device class may face not only regulatory rework but also a queue for notified body availability that delays market access by months.
Swiss manufacturers thus face dual interpretive frameworks: MepV classification rules that substantively mirror MDR, and MDCG guidance that Swiss authorities reference even though Switzerland is not an EU Member State. The following section examines how MDCG guidance shapes classification analysis, guidance that Swissmedic considers relevant for interpretive purposes even though it lacks formal legal status in Switzerland.
4. How Is MDCG Guidance Evolving?
The Medical Device Coordination Group has issued multiple guidance documents addressing software qualification and classification. MDCG 2019-11 provides the primary framework, revised in 2025, reflecting accumulated experience and stakeholder feedback. The 2025 revision clarified points of application and refreshed the worked examples rather than restructuring the framework. The guidance does not carry binding legal force; manufacturers remain responsible for their own classification decisions, but competent authorities and notified bodies reference MDCG positions when assessing manufacturer determinations.
The MDCG guidance itself reflects broader international harmonization efforts. The IMDRF SaMD Framework (N12) provides a global risk-categorization structure that many jurisdictions (including EU regulators interpreting MDR and Swissmedic applying MepV) use as conceptual reference.11International Medical Device Regulators Forum (IMDRF), Software as a Medical Device (SaMD): Possible Framework for Risk Categorization and Corresponding Considerations (IMDRF/SaMD WG/N12FINAL:2014). Manufacturers often internally map software to N12 categories (I–IV) before deriving MDR classification via Rule 11, adding another analytical layer that regulatory submissions may need to demonstrate.
The guidance distinguishes between software that qualifies as a medical device and software that does not, then addresses classification within the device category. Software that merely stores, archives, communicates, or performs simple searches of medical data without modification generally does not qualify as a device, while software that performs calculations or processing that could influence clinical decisions generally does qualify. The "independent review" concept (whether a healthcare professional can independently verify software output) affects classification level but not device qualification itself.
MDCG 2021-24 addresses borderline and classification questions more broadly, with specific examples relevant to software.12MDCG 2021-24, Guidance on Classification of Medical Devices (Medical Device Coordination Group 2021). The document confirms that manufacturers bear classification responsibility but acknowledges that borderline cases may require competent authority consultation. Whether a manufacturer should seek such consultation, and the weight to accord an informal response, presents its own strategic considerations.
Artificial intelligence and machine learning present classification challenges for which existing guidance provides limited analytical framework. Software that learns from data and modifies its behavior raises questions about how intended purpose is established when functionality evolves. If the manufacturer defines intended purpose at market launch but the algorithm's behavior changes through learning, does the classification analysis require updating? The MDCG has acknowledged these questions without providing definitive answers; manufacturers must develop classification rationales that address foreseeable algorithm evolution. Compounding this complexity, the EU AI Act (Regulation (EU) 2024/1689) creates additional requirements for high-risk AI systems, a category that includes AI components of medical devices.13Regulation (EU) 2024/1689 (AI Act) [2024] OJ L 2024/1689, Art. 6(1) and Annex I Section A(11). The interaction between MDR classification and AI Act categorization adds a parallel regulatory dimension: software may simultaneously require classification under Rule 11, conformity assessment under MDR ch V, and compliance with AI Act obligations for high-risk AI systems, which apply from 2 August 2027. Neither framework fully accounts for the other's requirements in its classification methodology.
MDCG 2020-3 (rev. 1) addresses a question the preceding analysis leaves open: when does a software change require a new conformity assessment, and when can it be managed within the existing quality management system?14MDCG 2020-3 rev.1, Guidance on significant changes regarding the transitional provision under Art. 120 of MDR (Medical Device Coordination Group, May 2023). For SaMD developers accustomed to agile development and continuous deployment, this guidance fundamentally transforms the release process. Whether a particular software update constitutes a significant change requiring notified body reassessment depends on criteria that interact differently for each product's architecture and regulatory history. The practical question (when an accumulation of individually minor updates collectively crosses the significance threshold) lacks a bright-line answer but demands systematic change management that most software development workflows are not designed to accommodate.
The lifecycle dimension extends further. Art. 83–86 MDR establish post-market surveillance obligations that apply from the moment a device reaches the market.15Art. 83–86 MDR (n 1) (post-market surveillance obligations). For SaMD that pushes monthly updates, the manufacturer must maintain a PMS system that tracks clinical performance across versions, identifies emerging risks that may result from software modifications, and feeds field data back into the risk management process. The intersection of frequent updates with PMS obligations creates an operational challenge that pre-market classification analysis rarely anticipates, but that determines whether continued market presence remains compliant.
5. What Are the Consequences of Getting It Wrong?
Classification decisions made early in development constrain options throughout the product lifecycle. A determination that software qualifies as Class I permits self-certification and rapid market entry. That same determination, if later found incorrect by a competent authority, may require market withdrawal, conformity assessment restart with notified body involvement, and potential liability exposure for the period of non-compliant market presence.
The liability dimension has sharpened. Directive (EU) 2024/2853 on liability for defective products explicitly includes software within its definition of "product" and introduces rebuttable presumptions of both defectiveness (Art. 10(2)) and causality (Art. 10(3)).16Directive (EU) 2024/2853 of the European Parliament and of the Council of 23 October 2024 on liability for defective products [2024] OJ L 2024/2853, Art. 4(1) and 10(2)–(3). Member States must transpose the directive by 9 December 2026. For a SaMD manufacturer that has misclassified and placed a product on the market without appropriate conformity assessment, the new PLD creates exposure beyond regulatory consequences: non-compliance with mandatory safety requirements triggers a presumption of defectiveness under Art. 10(2)(b), shifting the burden of proof to the manufacturer. Misclassification thus compounds: regulatory non-compliance becomes evidence supporting the defectiveness presumption in civil proceedings.
Classification also triggers obligations that extend beyond the MDR framework. MDR Annex I, Sections 17.2 and 17.4 impose cybersecurity requirements for devices incorporating software, requirements that apply from the moment a product is classified as a medical device and that must be addressed during the conformity assessment.17MDR (n 1), Annex I, Sections 17.2 and 17.4; MDCG 2019-16 rev.1, Guidance on Cybersecurity for Medical Devices (Medical Device Coordination Group 2020). Many SaMD developers coming from software or ICT backgrounds encounter medical device cybersecurity obligations for the first time during classification analysis. Similarly, SaMD processing health data simultaneously constitutes a medical device under MDR and a data processing system under GDPR (or DSG in Switzerland).18Regulation (EU) 2016/679 (General Data Protection Regulation) [2016] OJ L119/1, Art. 9 (special categories including health data), Art. 35 (data protection impact assessment); Bundesgesetz über den Datenschutz (Datenschutzgesetz, DSG) vom 25. September 2020 (SR 235.1), Art. 5(c) (sensitive personal data including health data), Art. 22 (data protection impact assessment). The data protection legal basis analysis, DPIA requirements, and data subject rights obligations run in parallel with, and are not satisfied by, the MDR conformity assessment. These dual-track obligations multiply the compliance surface that flows from a single classification decision.
The strategic questions cascade from this threshold risk, and they interrelate in ways that isolated analysis obscures. A classification rationale built on marketing claims and UI design must also account for algorithm evolution if the software incorporates machine learning: a compliant launch does not remain compliant as the product learns, and the classification analysis that satisfied a notified body at market entry may not survive the next software update cycle. The same rationale depends on the "independent review" analysis reflecting realistic clinical workflows (where human factors literature documents time pressure, cognitive load, and potential over-reliance on algorithmic outputs) rather than idealized use cases that regulators will not accept at face value.
These factors compound when classification proves higher than initially assessed. The notified body that certified a Class IIa device may lack designation scope for Class IIb, transforming a classification correction into a complete conformity assessment restart with a different notified body and a different timeline. The practical distance between an aggressive classification position and a defensible one is measured not in regulatory theory but in the remediation cost when a competent authority disagrees.
Classification analysis for software resists standardization precisely because intended purpose, the determinative factor, derives from the totality of manufacturer claims, user interface design, distribution channels, and clinical context. Industry conventions and competitor precedents may themselves reflect unexamined assumptions that competent authorities have not tested. The consequences of assuming that convention equals compliance become apparent only when market surveillance activity targets the specific product.