[{"data":1,"prerenderedAt":4},["ShallowReactive",2],{"guide-mdr-rule-11":3},"\u003Ch2 class=\"unnumbered\" id=\"introduction\">Introduction\u003C/h2>\n\u003Cp>\n  Few parts of the MDR have sparked as much discussion as Rule 11. This is not surprising. Software\n  fundamentally defies traditional methods of categorizing medical devices into established groups.\n  Each software device is unique, impacting clinical decision-making in very specific ways. Indeed,\n  the diverse nature of software devices was one of the main reasons behind the EU Commission’s\n  decision to adopt the general safety and performance approach proposed by the IMDRF. This approach\n  recognizes that nowadays it has become impossible to individually regulate each medical device\n  group. Instead, common principles based on good scientific practices must be established that\n  apply to all devices.\n\u003C/p>\n\u003Cp>\n  Another issue is that, at the time of writing, Rule 11 effectively exists in two distinct forms.\n  The first is the text of the rule itself and the interpretation provided by the MDCG. The second\n  is how the rule is actually applied in the field. In principle, these two approaches should align.\n  In practice, they do not. The reason is straightforward: implementing Rule 11 as intended\n  represents a monumental shift for the medical technology field. Regulators are aware of this and\n  have been cautious about pushing in the practice a change that could potentially stifle an\n  expanding field. Achieving full application and a common understanding could take decades, similar\n  to the pharmaceutical industry’s shift to evidence-based medicine 50 years ago. This discrepancy\n  between theory and practice makes discussing Rule 11 challenging, as real-world applications often\n  diverge significantly from theoretical intentions.\n\u003C/p>\n\u003Cp>\n  For this reason, we have decided to divide this guidance into two parts. In Chapter 1, we explore\n  the “theory” of Rule 11. We show that applying rule 11 means assessing the transfer of\n  responsibility from healthcare professionals to standardized instructions—that is, the software.\n  The perspective provided in this first section is essentially where we anticipates the application\n  of the rule to evolve over the next years. In Chapter 2, we analyze the “reality” of the\n  application of Rule 11 on the market, providing practical tips and warnings with an eye to the\n  future. Given the rapid changes in the field following the release of the MDR, what is standard\n  practice today may soon be outdated.\n\u003C/p>\n\u003Ch2 id=\"the-theory\">1 The theory\u003C/h2>\n\u003Cp>\n  Rule 11 consists of three parts. The first part provides the general classification rules for\n  software with diagnostic and therapeutic purposes. The second part provides specific rules for the\n  classification of software for monitoring of physiological process and vital physiological\n  parameters. The third and final part stipulates that any devices not covered by the first two\n  sections are classified as Class I. We will analyze each part separately.\n\u003C/p>\n\u003Ch3 id=\"part-1\">1.1 Part 1\u003C/h3>\n\u003Cp>The first part of Rule 11 states\u003C/p>\n\u003Cblockquote>\n  \u003Cp>\n    Software intended to provide information which is used to take decisions with diagnosis or\n    therapeutic purposes is classified as class IIa, except if such decisions have an impact that\n    may cause:\n  \u003C/p>\n  \u003Cul>\n    \u003Cli>\n      \u003Cp>\n        death or an irreversible deterioration of a person’s state of health, in which case it is in\n        class III; or\n      \u003C/p>\n    \u003C/li>\n    \u003Cli>\n      \u003Cp>\n        a serious deterioration of a person’s state of health or a surgical intervention, in which\n        case it is classified as class IIb.\n      \u003C/p>\n    \u003C/li>\n  \u003C/ul>\n\u003C/blockquote>\n\u003Cp>\n  We break the analysis of this first part into three sections. First, we clarify what it means to\n  \u003Cem>provide information that is used to take decision\u003C/em>. We then anylze\n  \u003Cem>diagnostic and therapeutic purposes\u003C/em> covered by the MDR. Finaly, we analyze the two final\n  exceptions specified in the two bullet points.\n\u003C/p>\n\u003Ch4 id=\"information-that-is-used-to-take-decisions\">\n  1.1.1 Information that is used to take decisions\n\u003C/h4>\n\u003Cp>\n  The first part of MDR Annex VIII Rule 11 begins with the words “\u003Cem\n    >Software intended to provide information which is used to take decisions...\u003C/em\n  >”. These words highlights a crucial aspect of how medical device software works, namely by\n  providing information to the user. Here we intentionally speak of “user”. In theory a machine\n  could also make use of the output of medical software to take automated decision concerning\n  patient management. In this case, however, MDR speaks of “closed loop systems”, the classification\n  of which is covered in Rule 22.\n\u003C/p>\n\u003Cdiv class=\"warningbox\">\n  \u003Cdiv class=\"boxtitle\" id=\"box-1\">\u003Cp>Box 1: User vs. patient\u003C/p>\u003C/div>\n  \u003Cp>\n    “User” and “patient” are distinct roles, not necessarily distinct people. Both roles can be\n    covered by the same physical person.\n  \u003C/p>\n  \u003Cp>\n    Consider, for example, an app that provides a physiotherapy excercises plan to the patient. In\n    this case the patient is also a user.\n  \u003C/p>\n  \u003Cp>\n    However, the opposite is also possible. Consider, for example, FFP3 masks. They are used by the\n    healthcare professional, and protect the patient as well as the the healthcare professional from\n    infection risk.\n  \u003C/p>\n\u003C/div>\n\u003Cp>\n  What does it mean that a software “\u003Cem>provides information that is used to take decisions\u003C/em>”?\n  It means that the information provided by the software can influence patient management (see also\n  box below). Why does this matter?\n\u003C/p>\n\u003Cp>\n  In most countries, medical practice is strictly regulated. Only individuals who have undergone\n  years of training can intervene in clinical decision-making. These professionals—doctors, nurses,\n  physiotherapists, pharmacists, dentists, phychologists, radiologists, etc—are tasked with the\n  clinical management of patients. Software that impacts clinical decision-making takes on clinical\n  responsibility—fully or partially—by encoding some of these medical tasks into a\n  \u003Cem>set of instructions\u003C/em\n  >\u003Ca href=\"#fn1\" class=\"footnote-ref\" id=\"fnref1\" role=\"doc-noteref\">\u003Csup>1\u003C/sup>\u003C/a\n  >. Similarly to how governments require healthcare professionals to undergo necessary training to\n  manage medical responsibilities, they also require that software assuming medical responsibility\n  meets specific requirements.\n\u003C/p>\n\u003Cdiv class=\"warningbox\">\n  \u003Cdiv class=\"boxtitle\" id=\"box-2\">\u003Cp>Box 2: Patient management\u003C/p>\u003C/div>\n  \u003Cp>\n    It will be obvious to most, but it is worth emphasizing this point to avoid misunderstanding.\n    When the MDR refers to “patient management,” it does not refer to managing patient data for\n    administrative purposes. Instead, “patient management” means the comprehensive coordination and\n    oversight of a patient’s clinical care, which includes diagnosis, treatment, and follow-up.\n  \u003C/p>\n\u003C/div>\n\u003Cp>\n  Before analyzing how software influences clinical decision-making, let’s examine two examples of\n  software that do not affect clinical decision-making.\n\u003C/p>\n\u003Cp>\n  Consider a software application that enables patients to remotely discuss their symptoms with\n  their doctor to determine if they need to stay home from work for medical reasons. During the\n  call, the doctor performs a clinical evaluation (anamnesis), assesses the symptoms as consistent\n  with the flu, and decides that an in-person visit is unnecessary. The doctor then issues a digital\n  medical excuse for work absence and schedules a follow-up consultation. In this scenario, the\n  software solely facilitates communication and does not engage in any medical decision-making. All\n  critical decisions—from conducting the anamnesis to determining the necessity of follow-up\n  visits—are made by the licensed healthcare professional. This software provides a platform for a\n  conversation like the one that could otherwise take place in the doctor’s office.\n\u003C/p>\n\u003Cdiv class=\"warningbox\">\n  \u003Cdiv class=\"boxtitle\" id=\"box-3\">\u003Cp>Box 3: Telemedicine\u003C/p>\u003C/div>\n  \u003Cp>\n    As we will explore below, just because software is classified as “telemedicine” does not mean it\n    cannot influence clinical decisions. Consider the previous example, where the consultation\n    involves inspecting a patient’s skin using a camera image. An inaccurate image could lead the\n    practitioner to make an incorrect clinical decision. If the software allows this kind of\n    application, it becomes the manufacturer’s responsibility to ensure that the images collected by\n    the softare is suitable for diagnostic purposes.\n  \u003C/p>\n\u003C/div>\n\u003Cp>\n  Consider another example: A software that enables doctors to digitally collect and store clinical\n  data. The doctor conducts the anamnesis and stores this alphanumeric data in a database for later\n  retrieval in its original form. The software does not modify or process the data; it merely stores\n  them for later retrieval, effectively replacing traditional paper records. In this scenario, the\n  software does not assume any medical responsibility nor does it perform any medical\n  decision-making functions; it simply facilitates data storage. Every decision—what information to\n  collect, how to interpret it—is made by the licensed healthcare professional.\n\u003C/p>\n\u003Cdiv class=\"warningbox\">\n  \u003Cdiv class=\"boxtitle\" id=\"box-4\">\u003Cp>Box 4: Storage and retrieval\u003C/p>\u003C/div>\n  \u003Cp>\n    When MDCG 2019-11 specifies that storage and retrieval do not constitue medical purpose it\n    refers to the technical action of storing and retrieving the data. The MDCG is not referring to\n    the action of deciding \u003Cem>what\u003C/em> must stored or retrieved. See also the section on cinical\n    input below.\n  \u003C/p>\n\u003C/div>\n\u003Cp>\n  To analyze how software can influence clinical decision-making, we examine the workflow depicted\n  in Figure \u003Ca href=\"#fig-infoworkflow\">1.1\u003C/a>. In traditional clinical decision-making, healthcare\n  professionals start by collecting clinical information from patients (\u003Cem>input\u003C/em>). They then\n  analyze this data to discern key details and patterns (\u003Cem>processing\u003C/em>). To understand the\n  \u003Cem>output\u003C/em> phase, consider a healthcare professional who seeks additional insights from a\n  colleague’s expertise. This professional communicates their findings using values, words, texts,\n  and visuals. The final phase (\u003Cem>decision\u003C/em>) involves the actual decision-making process,\n  where the professional determines the diagnosis and treatment plan for the patient. In the\n  remainder of this section, we explore how software can impact each step in this chain.\n\u003C/p>\n\u003Cfigure>\n  \u003Cimg src=\"/guides/mdr-rule-11/figure-1.svg\" />\n  \u003Cdiv id=\"fig-infoworkflow\">\u003C/div>\n  \u003Cfigcaption>Figure 1.1: Decision-making in medical praxis\u003C/figcaption>\n\u003C/figure>\n\u003Ch5 id=\"clinical-input\">Clinical input\u003C/h5>\n\u003Cp>Software can impact the content, timing, or quality of the clinical input.\u003C/p>\n\u003Cul>\n  \u003Cli>\n    \u003Cp>\n      \u003Cstrong>Content.\u003C/strong> Software can influence the content of clinical data by determining\n      which information is gathered for patient management. Consider a dermatology software that\n      conducts patient anamnesis and sends this information to one of the dermatologists in its\n      database for diagnosis or therapy decisions. In this case, the software, not the doctor,\n      determines the anamnesis content. It does not matter whether the anamnesis consists of static\n      questionnaires or dynamically adapts to individual patients. The software might request too\n      little, too much, or simply incorrect information for a specific patient’s condition,\n      potentially leading the dermatologist to make an erroneous clinical decision.\n    \u003C/p>\n    \u003Cdiv class=\"warningbox\">\n      \u003Cdiv class=\"boxtitle\" id=\"box-5\">\u003Cp>Box 5: Paper questionnaires\u003C/p>\u003C/div>\n      \u003Cp>\n        It has been suggested that, based on the above analysis, all paper or electronic\n        questionnaires used in medical practices would qualify as medical devices. Clearly, this is\n        not the case. When you visit a doctor and are handed an anamnesis questionnaire to complete,\n        it is under the doctor’s responsibility. However, in the scenario described above, the\n        software determines the content of the electronic questionnaire \u003Cem>before\u003C/em> the contact\n        with the doctor. Thus, it is not the doctor who decides which questionnaire to administer,\n        but the software itself. It is this key difference that signifies the transfer of medical\n        responsibility from the healthcare professional to the software.\n      \u003C/p>\n    \u003C/div>\n  \u003C/li>\n  \u003Cli>\n    \u003Cp>\n      \u003Cstrong>Timing.\u003C/strong> Software influences input timing when it determines when to collect\n      the clinical input. For example, software may autonomously define when to perform the next\n      anamnesis or when to schedule the next visit. These are medical decisions traditionally taken\n      by healthcare professionals. Collecting information at the wrong time can have consequences\n      for diagnosis and therapy. Therefore, software that decides on the timing of this information\n      can influence patient management.\n    \u003C/p>\n    \u003Cdiv class=\"warningbox\">\n      \u003Cdiv class=\"boxtitle\" id=\"box-6\">\u003Cp>Box 6: Reminders\u003C/p>\u003C/div>\n      \u003Cp>\n        Software that reminds patients of scheduled doctor visits does not assume responsibility for\n        the timing of the input, as the decision on when to conduct the visit remains with the\n        healthcare professional.\n      \u003C/p>\n    \u003C/div>\n  \u003C/li>\n  \u003Cli>\n    \u003Cp>\n      \u003Cstrong>Quality.\u003C/strong> Software inflluences the quality of the input when it affects how\n      the data is collected. For example, a software could instruct a patient to take a picture of a\n      body location, providing feedback to the patient to improve the picture quality.\n      Alternatively, a software can instruct patients on whether the electrodes of an ECG system\n      have been properly applied to ensure the correct signal-to-noise ratio. In traditional medical\n      praxis, a healthcare professional would evaluate the picture or the ECG signal live and guide\n      the patient on any necessary adjustment. A software that takes over the role of guiding the\n      patient to the correct input also takes over the responsibility that comes with this role.\n    \u003C/p>\n  \u003C/li>\n\u003C/ul>\n\u003Ch5 id=\"processing\">Processing\u003C/h5>\n\u003Cp>\n  Processing is perhaps the most intuitive aspect of the information workflow where the impact of\n  software on clinical decision-making becomes evident. Medical software commonly processes input\n  data to reveal insights that are not obvious in the raw data. This processing can take several\n  forms:\n\u003C/p>\n\u003Cul>\n  \u003Cli>\n    \u003Cp>\n      \u003Cstrong>Calculation of medical scores:\u003C/strong> Medical software frequently involves the\n      computational generation of scores based on patient data, which are used to guide clinical\n      decisions. These scores, such as risk assessments for cardiovascular diseases or scoring\n      systems for the severity of chronic illnesses, are developed through extensive research and\n      validation involving large patient populations.\n    \u003C/p>\n    \u003Cdiv class=\"warningbox\">\n      \u003Cdiv class=\"boxtitle\" id=\"box-7\">\u003Cp>Box 7: Combining scores\u003C/p>\u003C/div>\n      \u003Cp>\n        In the medical literature, most scores are validated individually. The medical field\n        exercises caution when aggregating scores. The guiding principle is that the fact that each\n        scores works individually does not mean that several scores will also work in combination.\n      \u003C/p>\n    \u003C/div>\n  \u003C/li>\n  \u003Cli>\n    \u003Cp>\n      \u003Cstrong>Feature Extraction, Pattern Recognition, Data Segmentation, etc:\u003C/strong> This process\n      involves algorithms designed to identify specific patterns or features within complex\n      datasets. Here some examples. In cardiology, software analyzes ECG (electrocardiogram) traces\n      to detect abnormalities like atrial fibrillation by identifying irregularities in heart rhythm\n      patterns. In radiology, advanced algorithms analyze imaging data to detect and classify tumors\n      in MRI or CT scans. In dermatology, image analysis software evaluates skin lesions from\n      photographic images, using pattern recognition to suggest potential diagnoses, such as\n      distinguishing between benign moles and malignant melanomas. In ophthalmology, software tools\n      segment retinal scans to identify and classify regions of interest, such as blood vessels or\n      indicators of diabetic retinopathy, aiding in the early detection and management of eye\n      diseases.\n    \u003C/p>\n  \u003C/li>\n\u003C/ul>\n\u003Ch5 id=\"clinical-output\">Clinical output\u003C/h5>\n\u003Cp>Software can impact the content, timing, or quality of the clinical output.\u003C/p>\n\u003Cul>\n  \u003Cli>\n    \u003Cp>\n      \u003Cstrong>Content.\u003C/strong> Software can influence decision-making by determining which\n      information to show to the user. For example, a clinical decision support system might filter\n      and highlight critical patient data during emergency situations to assist clinicians in making\n      rapid decisions. By selecting which information to display the software can affect the\n      healthcare professional decision.\n    \u003C/p>\n    \u003Cdiv class=\"warningbox\">\n      \u003Cdiv class=\"boxtitle\" id=\"box-8\">\u003Cp>Box 8: Information overload\u003C/p>\u003C/div>\n      \u003Cp>\n        The principle “the more, the better” seldom applies in clinical decision-making, where an\n        overload of information can overwhelm the user, leading to poorer decisions compared to when\n        less information is provided.\n      \u003C/p>\n    \u003C/div>\n  \u003C/li>\n  \u003Cli>\n    \u003Cp>\n      \u003Cstrong>Timing.\u003C/strong> Software influences data output when it determines when to present\n      the clinical output to the user. For example, a patient monitoring system used in intensive\n      care units might decide the frequency at which updates on vital signs are displayed to\n      healthcare professionals, or it might determine when to issue alerts if a patient’s condition\n      changes suddenly. By setting these parameters, the software plays a crucial role in how and\n      when interventions are made, directly impacting patient care outcomes.\n    \u003C/p>\n  \u003C/li>\n  \u003Cli>\n    \u003Cp>\n      \u003Cstrong>Quality.\u003C/strong> Software can impact (intentionally or unintentionally) the quality\n      of the collected clinical data. For example, a software for telemedicine might render images\n      in a way that makes it impossible for healthcare professionals to recognize certain details.\n      Alternatively, a software might present the ECG signal in a format that does not allow a\n      doctor to identify anomalous patterns.\n    \u003C/p>\n  \u003C/li>\n\u003C/ul>\n\u003Ch5 id=\"decision\">Decision\u003C/h5>\n\u003Cp>\n  Software can impact the quality of collected clinical data, whether intentionally or\n  unintentionally. For instance, telemedicine software may process images in a manner that prevents\n  healthcare professionals from recognizing specific details. Similarly, software might display ECG\n  signals in a format that obstructs a doctor’s ability to detect anomalous patterns.\n\u003C/p>\n\u003Cdiv class=\"warningbox\">\n  \u003Cdiv class=\"boxtitle\" id=\"box-9\">\u003Cp>Box 9: The role of informational materiall\u003C/p>\u003C/div>\n  \u003Cp>\n    A point that is often forgotten is that software can influence clinical decision-making even\n    through its informational material The informational material provided with a medical device is\n    an integral part of the device. A manufacturer may thus influence clinical decisions not only\n    through the information provided \u003Cem>by\u003C/em> the software but also through the information\n    provided \u003Cem>with\u003C/em> the software. For example, if a manufacturer claims a specific clinical\n    benefit, this may lead a healthcare professional to prescribe that particular device. In such\n    cases, the software device is affecting clinical decision-making through the information\n    material.\n  \u003C/p>\n\u003C/div>\n\u003Cp>\n  In instances where software provides outputs or elements that are further processed by healthcare\n  professionals to make the final decision, the presence of these professionals does not\n  automatically absolve the software of responsibility. In some cases, once the software has\n  processed information, it may not be possible for the healthcare professional to correct any\n  errors introduced. For example, if software processes an image and loses critical details, this\n  missing information may go unnoticed by the healthcare professional, leaving them unable to\n  attempt recovery of the lost details.\n\u003C/p>\n\u003Cdiv class=\"warningbox\">\n  \u003Cdiv class=\"boxtitle\" id=\"box-10\">\u003Cp>Box 10: Software that “performs” the therapy\u003C/p>\u003C/div>\n  \u003Cp>\n    It has been suggested that software that “performs” the therapy does not “provide information\n    that is used” for therapeutic purposes. This reasoning is flawed for the simple reasons that\n    software cannot “perform” therapies. This is a striking difference with physical appliances that\n    provide therapy directly to the body, such as defibrillatory, radiation therapy systems,\n    insuling pumps, ect. As discussed earlier, the mode of action of software is through\n    information. The only thing software can do is present the therapeutic plan information to the\n    patients, who then implement it in their therapy.\n  \u003C/p>\n\u003C/div>\n\u003Ch5 id=\"purpose-matters\">Purpose matters!\u003C/h5>\n\u003Cp>\n  We conclude the analysis of how software can affect clinical decision-making with an important\n  remark. Merely having the potential to impact clinical decision-making does not qualify software\n  as doing so. The manufacturer must “communicate” the idea that the software is suitable for a\n  medical use, either directly—such as through its stated intended purpose, or claims—or\n  indirectly—via marketing materials or other forms of written or oral communication.\n\u003C/p>\n\u003Cp>\n  Consider the following scenario. A dermatologist utilizes a commercially available video calling\n  application, such as Zoom or WhatsApp, to assess a patient for a butterfly-shaped rash across the\n  cheeks and nose, which is indicative of lupus. These applications significantly process\n  images—they compress images to minimize bandwidth and often apply filters to enhance visual\n  appearance. As a result, there is no guarantee that the images displayed by these applications\n  maintain the necessary quality for a dermatologist to discern subtle differences in skin\n  conditions.\n\u003C/p>\n\u003Cp>\n  Nevertheless, applications like Zoom or WhatsApp are not designed for telemedicine or medical\n  diagnoses, nor are they sold for this purpose. Using them for such purposes is entirely at the\n  discretion and risk of the healthcare professional. This situation is similar to when a healthcare\n  professional decides to use a medical device off-label.\n\u003C/p>\n\u003Cp>\n  However, if a software manufacturer claims or implies that their software can be used for\n  dermatological assessments, they must then demonstrate that the software meets the necessary\n  performance and safety requirements for this specific purpose. Should a manufacturer choose to\n  integrate platforms like Zoom or WhatsApp as components of their telemedicine system, it becomes\n  their responsibility to ensure and prove that the image quality and processing capabilities of\n  these platforms are adequate for the intended medical use.\n\u003C/p>\n\u003Ch4 id=\"diagnostic-and-therapeutic-purposes\">1.1.2 Diagnostic and therapeutic purposes\u003C/h4>\n\u003Cdiv class=\"table-wrap\">\n  \u003Ctable>\n    \u003Ccaption>\n      Table 1.1: Medical purposes defined in MDR Article 2.1, definition of “medical device”\n      provided in (•= combination applicable,\n      \u003Cspan class=\"math inline\">∘\u003C/span>\n      = combination not applicable). The combinations in orange are provided in MDR Annex VIII.\n      Monitoring of physiological processes is not specified as a medical purpose in Article 2.1.\n      However, MDR Annex VIII extends the are of application of “monitoring” to phsyiological\n      conditions, state of health, illnesses or congenital deformities, physiological processes,\n      vital physiological processes and vital parameters. For this reason, in Table\n      \u003Ca href=\"#mdr-purposes\">1.1\u003C/a>\n      we have marked the combination of “monitoring” and “physiological process” or “pathological\n      process” as applicable. These additional monitoring combinations are specifically covered in\n      the second part of Rule 11, Section\n      \u003Ca href=\"#second-part\">1.2\u003C/a\n      >.\n    \u003C/caption>\n    \u003Ctbody>\n      \u003Ctr class=\"odd\">\n        \u003Ctd style=\"text-align: left\">\u003C/td>\n        \u003Ctd style=\"text-align: left\">Disease\u003C/td>\n        \u003Ctd style=\"text-align: left\">Injury\u003C/td>\n        \u003Ctd style=\"text-align: left\">Disability\u003C/td>\n        \u003Ctd style=\"text-align: left\">Anatomy\u003C/td>\n        \u003Ctd style=\"text-align: left\">Physiological process/state\u003C/td>\n        \u003Ctd style=\"text-align: left\">Pathological process/state\u003C/td>\n      \u003C/tr>\n      \u003Ctr class=\"even\">\n        \u003Ctd style=\"text-align: left\">\u003Cstrong>Diagnostic/treatment purposes\u003C/strong>\u003C/td>\n        \u003Ctd style=\"text-align: left\">\u003C/td>\n        \u003Ctd style=\"text-align: left\">\u003C/td>\n        \u003Ctd style=\"text-align: left\">\u003C/td>\n        \u003Ctd style=\"text-align: left\">\u003C/td>\n        \u003Ctd style=\"text-align: left\">\u003C/td>\n        \u003Ctd style=\"text-align: left\">\u003C/td>\n      \u003C/tr>\n      \u003Ctr class=\"odd\">\n        \u003Ctd style=\"text-align: left\">Prevention\u003C/td>\n        \u003Ctd style=\"text-align: left\" class=\"cell-lightgreen\">•\u003C/td>\n        \u003Ctd style=\"text-align: left\" class=\"cell-lightgray\">\u003Cspan class=\"math inline\">∘\u003C/span>\u003C/td>\n        \u003Ctd style=\"text-align: left\" class=\"cell-lightgray\">\u003Cspan class=\"math inline\">∘\u003C/span>\u003C/td>\n        \u003Ctd style=\"text-align: left\" class=\"cell-lightgray\">\u003Cspan class=\"math inline\">∘\u003C/span>\u003C/td>\n        \u003Ctd style=\"text-align: left\" class=\"cell-lightgray\">\u003Cspan class=\"math inline\">∘\u003C/span>\u003C/td>\n        \u003Ctd style=\"text-align: left\" class=\"cell-lightgray\">\u003Cspan class=\"math inline\">∘\u003C/span>\u003C/td>\n      \u003C/tr>\n      \u003Ctr class=\"even\">\n        \u003Ctd style=\"text-align: left\">Prediction\u003C/td>\n        \u003Ctd style=\"text-align: left\" class=\"cell-lightgreen\">•\u003C/td>\n        \u003Ctd style=\"text-align: left\" class=\"cell-lightgray\">\u003Cspan class=\"math inline\">∘\u003C/span>\u003C/td>\n        \u003Ctd style=\"text-align: left\" class=\"cell-lightgray\">\u003Cspan class=\"math inline\">∘\u003C/span>\u003C/td>\n        \u003Ctd style=\"text-align: left\" class=\"cell-lightgray\">\u003Cspan class=\"math inline\">∘\u003C/span>\u003C/td>\n        \u003Ctd style=\"text-align: left\" class=\"cell-lightgray\">\u003Cspan class=\"math inline\">∘\u003C/span>\u003C/td>\n        \u003Ctd style=\"text-align: left\" class=\"cell-lightgray\">\u003Cspan class=\"math inline\">∘\u003C/span>\u003C/td>\n      \u003C/tr>\n      \u003Ctr class=\"odd\">\n        \u003Ctd style=\"text-align: left\">Prognosis\u003C/td>\n        \u003Ctd style=\"text-align: left\" class=\"cell-lightgreen\">•\u003C/td>\n        \u003Ctd style=\"text-align: left\" class=\"cell-lightgray\">\u003Cspan class=\"math inline\">∘\u003C/span>\u003C/td>\n        \u003Ctd style=\"text-align: left\" class=\"cell-lightgray\">\u003Cspan class=\"math inline\">∘\u003C/span>\u003C/td>\n        \u003Ctd style=\"text-align: left\" class=\"cell-lightgray\">\u003Cspan class=\"math inline\">∘\u003C/span>\u003C/td>\n        \u003Ctd style=\"text-align: left\" class=\"cell-lightgray\">\u003Cspan class=\"math inline\">∘\u003C/span>\u003C/td>\n        \u003Ctd style=\"text-align: left\" class=\"cell-lightgray\">\u003Cspan class=\"math inline\">∘\u003C/span>\u003C/td>\n      \u003C/tr>\n      \u003Ctr class=\"even\">\n        \u003Ctd style=\"text-align: left\">Diagnosis\u003C/td>\n        \u003Ctd style=\"text-align: left\" class=\"cell-lightgreen\">•\u003C/td>\n        \u003Ctd style=\"text-align: left\" class=\"cell-lightgreen\">•\u003C/td>\n        \u003Ctd style=\"text-align: left\" class=\"cell-lightgreen\">•\u003C/td>\n        \u003Ctd style=\"text-align: left\" class=\"cell-lightgray\">\u003Cspan class=\"math inline\">∘\u003C/span>\u003C/td>\n        \u003Ctd style=\"text-align: left\" class=\"cell-lightgray\">\u003Cspan class=\"math inline\">∘\u003C/span>\u003C/td>\n        \u003Ctd style=\"text-align: left\" class=\"cell-lightgray\">\u003Cspan class=\"math inline\">∘\u003C/span>\u003C/td>\n      \u003C/tr>\n      \u003Ctr class=\"odd\">\n        \u003Ctd style=\"text-align: left\">Treatment\u003C/td>\n        \u003Ctd style=\"text-align: left\" class=\"cell-lightgreen\">•\u003C/td>\n        \u003Ctd style=\"text-align: left\" class=\"cell-lightgreen\">•\u003C/td>\n        \u003Ctd style=\"text-align: left\" class=\"cell-lightgreen\">•\u003C/td>\n        \u003Ctd style=\"text-align: left\" class=\"cell-lightgray\">\u003Cspan class=\"math inline\">∘\u003C/span>\u003C/td>\n        \u003Ctd style=\"text-align: left\" class=\"cell-lightgray\">\u003Cspan class=\"math inline\">∘\u003C/span>\u003C/td>\n        \u003Ctd style=\"text-align: left\" class=\"cell-lightgray\">\u003Cspan class=\"math inline\">∘\u003C/span>\u003C/td>\n      \u003C/tr>\n      \u003Ctr class=\"even\">\n        \u003Ctd style=\"text-align: left\">Alleviation\u003C/td>\n        \u003Ctd style=\"text-align: left\" class=\"cell-lightgreen\">•\u003C/td>\n        \u003Ctd style=\"text-align: left\" class=\"cell-lightgreen\">•\u003C/td>\n        \u003Ctd style=\"text-align: left\" class=\"cell-lightgreen\">•\u003C/td>\n        \u003Ctd style=\"text-align: left\" class=\"cell-lightgray\">\u003Cspan class=\"math inline\">∘\u003C/span>\u003C/td>\n        \u003Ctd style=\"text-align: left\" class=\"cell-lightgray\">\u003Cspan class=\"math inline\">∘\u003C/span>\u003C/td>\n        \u003Ctd style=\"text-align: left\" class=\"cell-lightgray\">\u003Cspan class=\"math inline\">∘\u003C/span>\u003C/td>\n      \u003C/tr>\n      \u003Ctr class=\"odd\">\n        \u003Ctd style=\"text-align: left\">Monitoring\u003C/td>\n        \u003Ctd style=\"text-align: left\" class=\"cell-lightgreen\">•\u003C/td>\n        \u003Ctd style=\"text-align: left\" class=\"cell-lightgreen\">•\u003C/td>\n        \u003Ctd style=\"text-align: left\" class=\"cell-lightgreen\">•\u003C/td>\n        \u003Ctd style=\"text-align: left\" class=\"cell-lightgray\">\u003Cspan class=\"math inline\">∘\u003C/span>\u003C/td>\n        \u003Ctd style=\"text-align: left\" class=\"cell-lightorange\">•\u003C/td>\n        \u003Ctd style=\"text-align: left\" class=\"cell-lightorange\">•\u003C/td>\n      \u003C/tr>\n      \u003Ctr class=\"even\">\n        \u003Ctd style=\"text-align: left\">Compensation\u003C/td>\n        \u003Ctd style=\"text-align: left\" class=\"cell-lightgray\">\u003Cspan class=\"math inline\">∘\u003C/span>\u003C/td>\n        \u003Ctd style=\"text-align: left\" class=\"cell-lightgreen\">•\u003C/td>\n        \u003Ctd style=\"text-align: left\" class=\"cell-lightgreen\">•\u003C/td>\n        \u003Ctd style=\"text-align: left\" class=\"cell-lightgray\">\u003Cspan class=\"math inline\">∘\u003C/span>\u003C/td>\n        \u003Ctd style=\"text-align: left\" class=\"cell-lightgray\">\u003Cspan class=\"math inline\">∘\u003C/span>\u003C/td>\n        \u003Ctd style=\"text-align: left\" class=\"cell-lightgray\">\u003Cspan class=\"math inline\">∘\u003C/span>\u003C/td>\n      \u003C/tr>\n      \u003Ctr class=\"odd\">\n        \u003Ctd style=\"text-align: left\">Investigation\u003C/td>\n        \u003Ctd style=\"text-align: left\" class=\"cell-lightgray\">\u003Cspan class=\"math inline\">∘\u003C/span>\u003C/td>\n        \u003Ctd style=\"text-align: left\" class=\"cell-lightgray\">\u003Cspan class=\"math inline\">∘\u003C/span>\u003C/td>\n        \u003Ctd style=\"text-align: left\" class=\"cell-lightgray\">\u003Cspan class=\"math inline\">∘\u003C/span>\u003C/td>\n        \u003Ctd style=\"text-align: left\" class=\"cell-lightgreen\">•\u003C/td>\n        \u003Ctd style=\"text-align: left\" class=\"cell-lightgreen\">•\u003C/td>\n        \u003Ctd style=\"text-align: left\" class=\"cell-lightgreen\">•\u003C/td>\n      \u003C/tr>\n      \u003Ctr class=\"even\">\n        \u003Ctd style=\"text-align: left\">Replacement\u003C/td>\n        \u003Ctd style=\"text-align: left\" class=\"cell-lightgray\">\u003Cspan class=\"math inline\">∘\u003C/span>\u003C/td>\n        \u003Ctd style=\"text-align: left\" class=\"cell-lightgray\">\u003Cspan class=\"math inline\">∘\u003C/span>\u003C/td>\n        \u003Ctd style=\"text-align: left\" class=\"cell-lightgray\">\u003Cspan class=\"math inline\">∘\u003C/span>\u003C/td>\n        \u003Ctd style=\"text-align: left\" class=\"cell-lightgreen\">•\u003C/td>\n        \u003Ctd style=\"text-align: left\" class=\"cell-lightgreen\">•\u003C/td>\n        \u003Ctd style=\"text-align: left\" class=\"cell-lightgreen\">•\u003C/td>\n      \u003C/tr>\n      \u003Ctr class=\"odd\">\n        \u003Ctd style=\"text-align: left\">Modification\u003C/td>\n        \u003Ctd style=\"text-align: left\" class=\"cell-lightgray\">\u003Cspan class=\"math inline\">∘\u003C/span>\u003C/td>\n        \u003Ctd style=\"text-align: left\" class=\"cell-lightgray\">\u003Cspan class=\"math inline\">∘\u003C/span>\u003C/td>\n        \u003Ctd style=\"text-align: left\" class=\"cell-lightgray\">\u003Cspan class=\"math inline\">∘\u003C/span>\u003C/td>\n        \u003Ctd style=\"text-align: left\" class=\"cell-lightgreen\">•\u003C/td>\n        \u003Ctd style=\"text-align: left\" class=\"cell-lightgreen\">•\u003C/td>\n        \u003Ctd style=\"text-align: left\" class=\"cell-lightgreen\">•\u003C/td>\n      \u003C/tr>\n      \u003Ctr class=\"even\">\n        \u003Ctd style=\"text-align: left\">\u003Cstrong>Other purposes\u003C/strong>\u003C/td>\n        \u003Ctd style=\"text-align: left\">\u003C/td>\n        \u003Ctd style=\"text-align: left\">\u003C/td>\n        \u003Ctd style=\"text-align: left\">\u003C/td>\n        \u003Ctd style=\"text-align: left\">\u003C/td>\n        \u003Ctd style=\"text-align: left\">\u003C/td>\n        \u003Ctd style=\"text-align: left\">\u003C/td>\n      \u003C/tr>\n      \u003Ctr class=\"odd\">\n        \u003Ctd style=\"text-align: left\">Control of conception\u003C/td>\n        \u003Ctd style=\"text-align: left\">\u003C/td>\n        \u003Ctd style=\"text-align: left\">\u003C/td>\n        \u003Ctd style=\"text-align: left\">\u003C/td>\n        \u003Ctd style=\"text-align: left\">\u003C/td>\n        \u003Ctd style=\"text-align: left\">\u003C/td>\n        \u003Ctd style=\"text-align: left\">\u003C/td>\n      \u003C/tr>\n      \u003Ctr class=\"even\">\n        \u003Ctd style=\"text-align: left\">Support of conception\u003C/td>\n        \u003Ctd style=\"text-align: left\">\u003C/td>\n        \u003Ctd style=\"text-align: left\">\u003C/td>\n        \u003Ctd style=\"text-align: left\">\u003C/td>\n        \u003Ctd style=\"text-align: left\">\u003C/td>\n        \u003Ctd style=\"text-align: left\">\u003C/td>\n        \u003Ctd style=\"text-align: left\">\u003C/td>\n      \u003C/tr>\n      \u003Ctr class=\"odd\">\n        \u003Ctd style=\"text-align: left\">Cleaning of devices\u003C/td>\n        \u003Ctd style=\"text-align: left\">\u003C/td>\n        \u003Ctd style=\"text-align: left\">\u003C/td>\n        \u003Ctd style=\"text-align: left\">\u003C/td>\n        \u003Ctd style=\"text-align: left\">\u003C/td>\n        \u003Ctd style=\"text-align: left\">\u003C/td>\n        \u003Ctd style=\"text-align: left\">\u003C/td>\n      \u003C/tr>\n      \u003Ctr class=\"even\">\n        \u003Ctd style=\"text-align: left\">Disinfection of devices\u003C/td>\n        \u003Ctd style=\"text-align: left\">\u003C/td>\n        \u003Ctd style=\"text-align: left\">\u003C/td>\n        \u003Ctd style=\"text-align: left\">\u003C/td>\n        \u003Ctd style=\"text-align: left\">\u003C/td>\n        \u003Ctd style=\"text-align: left\">\u003C/td>\n        \u003Ctd style=\"text-align: left\">\u003C/td>\n      \u003C/tr>\n      \u003Ctr class=\"odd\">\n        \u003Ctd style=\"text-align: left\">Sterilization of devices\u003C/td>\n        \u003Ctd style=\"text-align: left\">\u003C/td>\n        \u003Ctd style=\"text-align: left\">\u003C/td>\n        \u003Ctd style=\"text-align: left\">\u003C/td>\n        \u003Ctd style=\"text-align: left\">\u003C/td>\n        \u003Ctd style=\"text-align: left\">\u003C/td>\n        \u003Ctd style=\"text-align: left\">\u003C/td>\n      \u003C/tr>\n    \u003C/tbody>\n  \u003C/table>\n\u003C/div>\n\u003Cdiv id=\"mdr-purposes\">\u003C/div>\n\u003Cp>\n  The formulation of Rule 11 further specifies the nature of the decisions covered by the rule as\n  “\u003Cem>decisions with diagnostic or therapeutic purposes.\u003C/em>” This specification is important\n  since we can classify the medical purposes specified in the MDR Article 2 into\n  diagnostic/therapeutic and “other” purposes. We summarized this classification in Table\n  \u003Ca href=\"#mdr-purposes\">1.1\u003C/a>. Rule 11 applies only to the diagnostic and therapeutic purposes.\n  This interpretation aligns with MDCG 2019-11 and MDCG 2021-24.\n\u003C/p>\n\u003Cp>\n  It has been suggested that software devices providing information for prevention, prediction, and\n  prognosis do not actually serve diagnostic and therapeutic purposes. However, the scope of Rule 11\n  is not intended to be confined to diagnosis and therapy alone; rather, it includes a broader range\n  of “diagnostic” and “therapeutic” purposes. Indeed, prognosis, which involves forecasting the\n  development of a disease, plays a critical role in clinical decision-making. For instance, in\n  cancer treatment, determining the prognosis based on tumor stage, grade, and genetic markers is\n  essential for deciding on appropriate interventions such as chemotherapy, radiation, or surgery.\n  Similarly, in chronic conditions like heart failure, prognosis informed by factors such as\n  ejection fraction and comorbidities is crucial for customizing medical therapy and lifestyle\n  changes.\n\u003C/p>\n\u003Cp>\n  Moreover, the relevance of prevention and prediction should not be underestimated. For example, an\n  app that delivers personalized dietary advice and real-time alerts to mitigate Crohn’s disease\n  flare-ups also significantly affect clinical decision. Indeed, inadequate prevention of the\n  flare-ups can lead to severe Crohn’s disease progression, resulting in significant complications\n  like bowel cancer.\n\u003C/p>\n\u003Ch4 id=\"higher-risk-decisions\">1.1.3 Higher risk decisions\u003C/h4>\n\u003Cp>\n  The first part of Rule 11 concludes with two exceptions. The phrasing of these exceptions begins\n  with the words “\u003Cem>except if such decisions have an impact that may cause:...\u003C/em>”. This\n  formulation suggests that the crucial factor in determining whether the exceptions apply is the\n  diagnostic or therapeutic decision, regardless of the extent to which the software contributes to\n  the decision-making process. This approach in the software classification system of the MDR,\n  therefore, appears to diverge from that proposed in IMDRF/SaMD WG/N12, which considers both the\n  the clinical decision and the software’s contribution to that decision.\n\u003C/p>\n\u003Cp>\n  However, MDCG 2019-11 proposes interpreting this aspect of Rule 11 in a manner that aligns with\n  the IMDRF classification. Yet, the acceptance of the MDCG interpretation might vary depending on\n  the notified body. Indeed, a notified body might argue that if the European Commission had\n  intended to align this section of the regulation with the IMDRF methodology, they would have\n  explicitly done so, as they have in other sections of the regulation.\n\u003C/p>\n\u003Cp>\n  Consider for example the CHA2DS2-VASc calculation. This score provides information which is used\n  to take therapeutic decisions, specifically, whether to administer anticoagulants to a patient to\n  prevent stroke. A wrong decision may cause\n  \u003Cem>a serious deterioration of a person’s state of health or a surgical intervention\u003C/em>.\n  Strictly interpreting Rule 11, therefore, could lead to classifying a software that implements\n  this score as class IIb. However, the software only partially contributes to the decision,\n  therefore IMDRF classifes this tool as IIa because it “\u003Cem\n    >is not normally expected to be time critical in order to avoid death, long-term disability, or\n    other serious deterioration of health\u003C/em\n  >\u003Ca href=\"#fn2\" class=\"footnote-ref\" id=\"fnref2\" role=\"doc-noteref\">\u003Csup>2\u003C/sup>\u003C/a\n  >.”\n\u003C/p>\n\u003Cp>\n  Finally, MDCG 2019-11 provides elaborates on what constitutes a “serious deterioration in state of\n  health of a patient, user or other person, as including the following:\n\u003C/p>\n\u003Col>\n  \u003Cli>\u003Cp>a life-threatening illness or injury,\u003C/p>\u003C/li>\n  \u003Cli>\n    \u003Cp>\n      permanent or temporary impairment of a body structure or a body function (including\n      impairments leading to diagnosed psychological trauma),\n    \u003C/p>\n  \u003C/li>\n  \u003Cli>\n    \u003Cp>a condition necessitating hospitalisation or prolongation of existing hospitalisation,\u003C/p>\n  \u003C/li>\n  \u003Cli>\n    \u003Cp>medical or surgical intervention to prevent I or II, examples of this can be:\u003C/p>\n    \u003Cul>\n      \u003Cli>\u003Cp>professional medical care or additional unplanned medical treatment,\u003C/p>\u003C/li>\n      \u003Cli>\u003Cp>a clinically relevant increase in the duration of a surgical procedure\u003C/p>\u003C/li>\n    \u003C/ul>\n  \u003C/li>\n  \u003Cli>\u003Cp>a chronic disease,\u003C/p>\u003C/li>\n  \u003Cli>\n    \u003Cp>\n      foetal distress, foetal death or any congenital abnormality (including congenital physical or\n      mental impairment) or birth defects.\n    \u003C/p>\n  \u003C/li>\n\u003C/ol>\n\u003Ch3 id=\"part-2\">1.2 Part 2\u003C/h3>\n\u003Cdiv id=\"second-part\">\u003C/div>\n\u003Cp>\n  The second part of Rule 11 focuses on the classification of monitoring software. It states that:\n\u003C/p>\n\u003Cblockquote>\n  \u003Cp>\n    \u003Cem\n      >Software intended to monitor physiological processes is classified as class IIa, except if it\n      is intended for monitoring of vital physiological parameters, where the nature of variations\n      of those parameters is such that it could result in immediate danger to the patient, in which\n      case it is classified as class IIb.\u003C/em\n    >\n  \u003C/p>\n\u003C/blockquote>\n\u003Cp>\n  As noted in MDCG 2019-11, this rule “\u003Cem\n    >was introduced to ensure that medical device software which has the same intended purpose as\n    (hardware) devices which would fall under Rule 10, third indent, are in the same risk class.\u003C/em\n  >” However, unlike Rule 10 third indent, this par of Rule 11 applies to software intended to be\n  used for monitoring any/all physiological processes and not just vital physiological processes.\n  What is the difference?\n\u003C/p>\n\u003Cp>\n  \u003Cem>Physiological processes\u003C/em> refer to the functions and processes occurring within the body.\n  Examples include heart rate, blood pressure, body temperature, oxygen saturation, respiratory\n  rate, muscle strength, metabolic rate, and hormonal levels. Parameters that can be measured\n  concerning these processes are called physiological parameters.\n\u003C/p>\n\u003Cp>\n  \u003Cem>Monitoring a physiological process\u003C/em> or state means continuously or periodically measuring\n  and tracking these parameters to observe trends, detect abnormalities, and eventually alarm the\n  user of significant changes that may indicate a need for medical intervention. According to MDR,\n  the presence of alarms is compulsory in the case of situations which require intervention or that\n  could lead to death or severe deterioration of the patient’s state of health\u003Ca\n    href=\"#fn3\"\n    class=\"footnote-ref\"\n    id=\"fnref3\"\n    role=\"doc-noteref\"\n    >\u003Csup>3\u003C/sup>\u003C/a\n  >.\n\u003C/p>\n\u003Cp>\n  A vital parameter is a subclass of physiological parameters that involves processes essential for\n  sustaining life, such as heart rate, respiratory rate, blood pressure, body temperature, and blood\n  oxygen levels. Crucially, it is nearly \u003Cem>impossible\u003C/em> to provide an exhaustive list of vital\n  physiological parameters as their significance can vary widely depending on the clinical context.\n  This context includes the patient’s overall condition, existing comorbidities, and the specific\n  medical setting or scenario. For instance, for a patient with a heart condition taking\n  anticoagulants and experiencing a gastric ulcer leading to a digestive hemorrhage, monitoring the\n  International Normalized Ratio (INR) is vital. A high INR would lead doctors to treat for\n  anticoagulant overdose, whereas a normal INR would suggest that surgical intervention is needed.\n  In this context, INR monitoring becomes crucial as it directly influences the therapeutic\n  decision. However, when a patient is on anticoagulants due to chronic stable heart disease,\n  monitoring INR, while important, is not classified as “vital.” The immediate risk of\n  life-threatening complications is lower, and the focus is on maintaining therapeutic levels to\n  prevent thromboembolic events.\n\u003C/p>\n\u003Cp>\n  The same emphasis on context is necessary to asses whether variations of those parameters are such\n  that it could \u003Cem>result in immediate danger to the patient\u003C/em>.\n\u003C/p>\n\u003Cp>\n  Indeed, the class IIb classification is open to interpretation only if the medical context is not\n  considered. Devices monitoring vital parameters in contexts where timing is critical to medical\n  decisions should be in a higher risk class. For instance, in an emergency or resuscitation\n  setting, the accuracy of a blood pressure monitor is crucial because it directly influences\n  life-saving decisions. Hence, such devices are classified as Class IIb. On the other hand, a blood\n  pressure monitor used at home for routine monitoring doesn’t have the same immediate impact on\n  medical decisions, so it is classified as Class IIa. This distinction ensures that devices are\n  appropriately regulated based on their intended use and potential impact on patient safety.\n\u003C/p>\n\u003Ch3 id=\"part-3\">1.3 Part 3\u003C/h3>\n\u003Cp>\n  The final part of Rule 11 simply states that “\u003Cem>All other software is classified as class I.\u003C/em\n  >”, meaning that any software not covered by the first two sections is considered low risk.\n  According to our analysis and as noted by MDCG 2019-11 and MDCG 2021-24, an example of software\n  that does not fall under the first two parts is software intended to support conception (note that\n  software intended to prevent conception is covered under Rule 15).\n\u003C/p>\n\u003Ch3 id=\"conclusions\">1.4 Conclusions\u003C/h3>\n\u003Cp>\n  It has been suggested that Rule 11 is incomplete, inconsistent, and assigns classes to medical\n  device software that are excessively high compared to other devices. However, this criticism is\n  unfounded. Firstly, Rule 11 is not incomplete. Instead, as we have seen above, it allows\n  classifying devices across essentially all medical purposes covered by the MDR.\n\u003C/p>\n\u003Cp>\n  Secondly, the rule is not inconsistent. The critique that Rule 11 inappropriately mixes diagnostic\n  and therapeutic purposes stems from a misunderstanding. Rule 11 intentionally groups these\n  functions together because, in the realm of medicine, the line between diagnostic and therapeutic\n  purposes can often be blurred—software that assists in diagnosis frequently plays a critical role\n  in guiding therapy.\n\u003C/p>\n\u003Cp>\n  Thirdly, it is uncomprehensible how Rule 11 is supposed to penalize medical software with respect\n  to other medical devices. The time of cathode tube monitors is long gone. Today, almost any\n  medical device that supports clinical decision-making or that monitors parameters incorporates\n  some form of medical software. It is a common misconception that Rule 11 applies exclusively to\n  stand-alone software. In reality, Rule 11 covers any software with medical purposes, regardless of\n  its implementation—whether operating in the cloud, on a computer, on a mobile phone, or as\n  integrated functionality within a hardware medical device. This is a striking difference from the\n  IMDRF classifiction of SaMD, which only applies to software that is not part of a hardware medical\n  device.\n\u003C/p>\n\u003Ch2 id=\"the-reality\">2 The reality\u003C/h2>\n\u003Cp>\n  Addressing Rule 11 has proven challenging for the medical device industry. This not due to any\n  inherent flaw in the rule itself. As analyzed above, contrary to some suggestions, the rule is\n  neither incomplete nor inconsistent. The real challenge stems from a mismatch between expectations\n  and reality. The industry expected a rule based purely on clear-cut semantics—a straightforward\n  system to categorize devices by specific terms; for example, placing all “telemedicine” software\n  in the same category. The reality, however, is that medical software is intangible and comes in\n  countless forms and purposes. A thousand manufacturers might give a thousand different\n  interpretations of “telemedicine” or “clinical decision support systems”. That is why the\n  Commission implemented a classification rule based on context, that requires a detailed\n  understanding and analysis of the nuances of medical practice to correctly classify software that\n  might impact this practice. It is precisely this task—analyzing medical context—that has proven\n  most challenging for an industry previously accustomed to decades of lack of clinical scrutiny.\n\u003C/p>\n\u003Cp>\n  It is no surprise, therefore, that a large number of software devices brought onto the market is\n  misclassified. In particular, a large proportion of Class I software is “underclassified”, meaning\n  their classification would be IIa or higher if assessed accurately according to MDR rules. Indeed,\n  especially startups and smaller companies view Class I as a lifeline to certification that allows\n  them to access domains reserved to CE-marked devices, such as reimboursement or hospitals, without\n  incurring in notified bodies costs that are often beyond their financial capacity.\n\u003C/p>\n\u003Cp>\n  However, the manufacturers are not the only ones accountable for this situation. Generally, there\n  is a perception that authorities across Europe have been cautious about applying classification\n  rules stringently to avoid stifling the startup scene. For example, it is an open secret in the\n  German medtech that some regional authorities perform little or no checks on the classification\n  when Class I products are registered. The problem with this approach is that it places all the\n  risk on the manufacturers. And the manufacturers might not be aware of this.\n\u003C/p>\n\u003Cp>\n  Indeed, a German manufacturer might assume that if the regioanl authority does not object to the\n  device being classified as Class I, then the classification is correct and the manufacturer is\n  legally protected. However, this is not the case. It is the responsibility of the manufacturer to\n  ensure that a Class I device is correctly classified. In the event of a legal dispute with a\n  patient or competitor, citing the regioanl authority’s lack of objection will not serve as a\n  defense\u003Ca href=\"#fn4\" class=\"footnote-ref\" id=\"fnref4\" role=\"doc-noteref\">\u003Csup>4\u003C/sup>\u003C/a\n  >.\n\u003C/p>\n\u003Cp>\n  The long-term strategy appears to be one in which differences in classification will eventually\n  level out as competition increases. For example, manufacturers who have properly classified their\n  devices may request those with underclassified devices to follow suit. Indeed, this trend has\n  started to manifest in Germany, where a recent lawsuit has sent shockwaves through the industry\n  \u003Ca href=\"#fn5\" class=\"footnote-ref\" id=\"fnref5\" role=\"doc-noteref\">\u003Csup>5\u003C/sup>\u003C/a\n  >, after the higher regional court decided against the class I classification of a diagnostic\n  telemedicine solution, following a competitor lawsuit. The competition and lawsuits are only bound\n  to increase, especially as several European governments begin to establish lucrative reimbursement\n  schemes for digital therapeutics.\n\u003C/p>\n\u003Cp>\n  For these reasons, manufacturers should exercise caution when dealing with device classification.\n  First, it is critical that they understand the risks associated with potential classification\n  errors. Unfortunately, a growing consulting industry often promises easy solutions to complex\n  problems, tempting manufacturers with shortcuts. Therefore, we recommend ensuring that any\n  strategic consultation, especially regarding classification, includes a contract that requires\n  consultants to share in liability for damages. This approach would have two benefits. Firstly, it\n  would discourage reckless consulting practices. Secondly, it would help ensure that the\n  consequences of a lawsuit resulting from underclassification do not fall solely on the\n  manufacturer.\n\u003C/p>\n\u003Cp>\n  Additionally, manufacturers concerned about the accuracy of their device classification should\n  develop a contingency plan. Indeed, it appears that most underclassified Class I devices lack a\n  “Plan B,”. For example, collecting clinical data observationally—which offers significant\n  advantages over pre-market studies—under Class I certification to prepare for a higher\n  certification with a notified body.\n\u003C/p>\n\u003Cp>\n  The pharmaceutical industry took decades to transition to evidence-based medicine; the process\n  will not be swift for medtech either. However, compared to 50 years ago, information today flows\n  much faster, accelerating the pace in medtech. Indeed, the transition is advancing at a\n  breathtaking pace, and those who do not keep up risk falling behind. Therefore our recommendation\n  is: The time is limited, use it well.\n\u003C/p>\n\u003Csection id=\"footnotes\" class=\"footnotes footnotes-end-of-document\" role=\"doc-endnotes\">\n  \u003Chr />\n  \u003Col>\n    \u003Cli id=\"fn1\">\n      \u003Cp>\n        See the definition of “software” in MDCG 2019-11.\u003Ca\n          href=\"#fnref1\"\n          class=\"footnote-back\"\n          role=\"doc-backlink\"\n          >↩︎\u003C/a\n        >\n      \u003C/p>\n    \u003C/li>\n    \u003Cli id=\"fn2\">\n      \u003Cp>\n        See section 7.4 of IMDRF/SaMD WG/N12\u003Ca\n          href=\"#fnref2\"\n          class=\"footnote-back\"\n          role=\"doc-backlink\"\n          >↩︎\u003C/a\n        >\n      \u003C/p>\n    \u003C/li>\n    \u003Cli id=\"fn3\">\n      \u003Cp>\n        See MDR Annex I Section 18.4.\u003Ca href=\"#fnref3\" class=\"footnote-back\" role=\"doc-backlink\"\n          >↩︎\u003C/a\n        >\n      \u003C/p>\n    \u003C/li>\n    \u003Cli id=\"fn4\">\n      \u003Cp>\n        In Germany, the BfArM is the competent authority responsible for processing request for\n        evaluating the classification of medical devices. However, currently accessing these\n        services can involve significant waiting times.\u003Ca\n          href=\"#fnref4\"\n          class=\"footnote-back\"\n          role=\"doc-backlink\"\n          >↩︎\u003C/a\n        >\n      \u003C/p>\n    \u003C/li>\n    \u003Cli id=\"fn5\">\n      \u003Cp>\n        Hanseatisches Oberlandesgericht. (2024). [Case No. 3 U 3/24, 416 HKO 64/23 LG Hamburg].\u003Ca\n          href=\"#fnref5\"\n          class=\"footnote-back\"\n          role=\"doc-backlink\"\n          >↩︎\u003C/a\n        >\n      \u003C/p>\n    \u003C/li>\n  \u003C/ol>\n\u003C/section>\n",1792608381978]