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." The product carries no CE marking and has had no conformity assessment, and the company has no certified quality management system. The company believes it operates outside medical device regulation because physicians make final diagnostic decisions. Whether that belief holds depends on what the company's own claims say the product is for.
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 Annex VIII MDR 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. The implementing rules of Annex VIII MDR may also override Rule 11's residual category entirely: software that drives or influences another device follows the classification of that device.
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 IVDR) does not include a software-specific classification rule equivalent to Rule 11 MDR; 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 is what the manufacturer says the product is for: on the label, in the instructions for use, in promotional or sales materials or statements, and in the clinical evaluation.
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 is the use the manufacturer gives the product in everything it supplies: the label, the instructions for use, promotional or sales materials or statements, and the clinical evaluation (Art. 2(12) MDR). If the application is promoted to physicians for their patients, if its interface displays clinically meaningful thresholds, or if its marketing cites clinical studies, regulators may conclude that its intended purpose is medical regardless of disclaimers.
Under MDCG 2019-11 Rev.1, software intended only for non-medical purposes, wellness and fitness apps among them, is not medical device software, but an app that gives a lay user a 10-year risk of cardiovascular disease from the data the user enters is.5MDCG 2019-11 Rev.1 (n 4), ss 3.1 and 6.1.
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 MDR regardless of whether a clinician reviews the output before acting.
The MDCG guidance treats a further factor as relevant to classification level: whether a healthcare professional can independently verify the software's output. 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 its 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 why the "wellness defense" and "physician override" arguments fail under MDR. Developers accustomed to the US CDS framework who enter the Swiss or EU market 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 MDR. 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 MDR 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 Annex VIII MDR classification rules by reference, including software-specific provisions corresponding to Rule 11 MDR.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.
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 map software to N12 categories (I–IV) internally before deriving MDR classification via Rule 11 MDR, and regulatory submissions may need to show that step.
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.
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. The EU AI Act (Regulation (EU) 2024/1689) also sets requirements for high-risk AI systems, a category that includes AI components of medical devices that require third-party conformity assessment.13Regulation (EU) 2024/1689 (AI Act) [2024] OJ L 2024/1689, Art. 6(1) and Annex I Section A(11). The same software may therefore need classification under Rule 11 MDR, conformity assessment under Chapter V MDR, and compliance with the AI Act's 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.
The preceding analysis leaves open when a software change calls for a new conformity assessment. MDCG 2020-3 Rev.1 addresses that question only for legacy devices, those still placed on the market under the transitional provision of Art. 120(3) MDR, by setting out when a change to their design or intended purpose, a software change included, counts as significant and so takes the device out of the transition (Art. 120(3c)(b) MDR).14MDCG 2020-3 Rev.1, Guidance on Significant Changes Regarding the Transitional Provision Under Article 120 of the MDR with Regard to Devices Covered by Certificates According to MDD or AIMDD (Medical Device Coordination Group, May 2023). It takes the directives the MDR replaced as the benchmark for such changes and does not deal with devices certified under the MDR, whose changes follow the MDR's own procedures: the notified body that certified a device must have the manufacturer submit planned changes to the device's approved design or intended use for prior approval (Annex VII, Section 4.9 MDR). For a legacy SaMD released through continuous deployment, the manufacturer is responsible for showing, case by case, that a change does not affect the design or intended purpose or is not significant, and the guidance expects the outcome of each assessment to be documented and made available to a competent authority on request. Its examples of non-significant software changes include bug fixes that restore the original specification and security updates, valid only where the device's risk/benefit ratio is not negatively affected. It does not say when a series of changes, each non-significant on its own, becomes significant, so a manufacturer that releases often is left to answer that question itself.
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 post-market surveillance 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. Running that system alongside frequent updates is an operational task that pre-market classification analysis rarely anticipates, yet it decides whether the product remains compliant on the market.
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-declaration of conformity and rapid market entry. If a competent authority later finds that determination incorrect, the manufacturer may face market withdrawal, a restarted conformity assessment with notified body involvement, and liability for the period the product was on the market without complying.
The product liability risk has also grown. Directive (EU) 2024/2853 on liability for defective products, the new Product Liability Directive (PLD), explicitly includes software within its definition of "product" and introduces rebuttable presumptions of both defectiveness (Art. 10(2) PLD) and causality (Art. 10(3) PLD).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 regulatory failure then counts in civil proceedings too: non-compliance with mandatory safety requirements triggers a presumption of defectiveness under Art. 10(2)(b) PLD, shifting the burden of proof to the manufacturer.
Classification also triggers further obligations, inside and outside the MDR. Annex I, Sections 17.2 and 17.4 MDR 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, July 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 matter most when the class proves higher than the manufacturer first 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.
Software classification resists standardization because it turns on intended purpose, which is whatever each manufacturer's own label, instructions for use, promotional or sales materials and clinical evaluation say its product is for. 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.