MDR Rule 11: Classification
Rules for SaMD with their
benefits and challenges

Software development for medical devices has become significant with technology growth in recent years. However, improving patient care,diagnosis, and treatment through software asa Medical Device (SaMD) brings challenges, such as requiring specific regulations to ensure patient safety. Here enters MDR Rule 11, a crucial framework establishing Classification Rules for medical software. In this article, you will learn about the benefits and challenges associated with Rule 11, the criteria of MDR classification and the steps of deployment and regulation of SaMD applications.

TL;DR

Rule 11 is a significant part of MDR regulation for Software as a Medical Device (SaMD) in the European Union. It establishes classification rules for medical software, ensuring patient safety and effective healthcare. The rule describes four risk classes of medical software and requires manufacturers to comply with stricter requirements, including clinical evidence and cybersecurity management. While it presents challenges, such as increased costs and market entry requirements, MDR Rule 11 ultimately promotes quality, unifies regulations, and encourages innovation in medical software development.

What is MDR, and why is it important?

The Medical Devices Regulation (MDR) is a set of regulations that govern the safety, performance, and quality of medical devices in the European Union (EU).

It aims to ensure that medical devices placed on the market in the EU are safe, effective, and meet the same high standards of quality and safety, regardless of where they are manufactured or marketed within the EU.

The MDR was introduced in 2017 to replace the Medical Devices Directive (MDD) and includes stricter requirements for the design, development, testing, clinical evaluation and certification of medical devices, as well as improved transparency and traceability throughout the supply chain.

What is MDR Annex VIII?

Annex VIII of the MDR provides the rules for classifying medical devices based on the potential risks associated with the device and its intended use. The Annex contains 22 rules that outline the criteria for determining the class of a medical device, with Class I being the lowest risk and Class III being the highest risk. Rule 11 is a part of Annex VIII that specifically addresses the classification of medical software.

What is EU MDR Rule 11, and what it refers to?

MDR Rule 11 is a set of guidelines for medical software that guarantee that software used as a medical device (SaMD) is classified correctly according to its level of risk and interference in the patient’s health.

To facilitate the classification, MDR distinguished four classes of risk: Class I, Class IIa, Class IIb, and Class III.

You can read more about risk in the classification below in this article.

Why is it so important for medical device software manufacturers?

MDR requires the manufacturers to submit product technical documentation, including clinical evaluation, to ensure compliance with the regulation. This guarantees the safety and effectiveness of medical device software, unifying classification requirements and strengthening supervision within the EU.

Depending on the type of medical intended use of the software and the potential effects of its use on the user/patient, the software will belong to different risk classes. Consequently, the requirements for software in each class vary. A particularly large difference in requirements lies between Class I and Class IIa software.

There is also an entry differing MDR Rule 11 from previous MDD (Medical Device Directive) guidelines - medical software providing information used for diagnosis or treatment is classified as Class IIa or higher. The manufacturers must also provide sufficient clinical evidence, manage cybersecurity risks and comply with supply chain requirements.

The consequences of MDR Rule 11 of classification

When someone decides to create MDR Rule 11 software, there are some challenges to overcome on the path to certification.

Previously, most of the software was classified as low risk, which meant that the process of conformity assessment and introduction to the market was easier and cheaper to apply. Now, when the software risk class is higher, the manufacturers should be aware that potential risks concerning patients’ health may result in penalties for non-compliance.

What are the consequences of EU MDR Rule 11?

• Safety first: By regulating software according to the MDR, we can be more confident that applications marketed as medical devices will be safe and effective for their intended use.
  
  

• Quality of medical software: A qualitative approach from the initial conception to development, testing, implementation in clinical practice, and ongoing software maintenance is critical and guarantees the effectiveness of intended use.
  
  

• Unification of regulations: MDR Rule 11 unifies the regulation of SaMD across the European Union, which allows for consistent standards and requirements, making it easier for medical software manufacturers.
  
  

• Promoting the use of modern technologies in the medical industry: Rule 11 MDR encourages innovation in the field of SaMD by providing clear classification criteria.
  
  

• Increased production costs: With the shift away from Class I  classification, manufacturers might face additional expenses, including involving Notified Bodies in the conformity assessment procedure and enhancing Quality Management Systems (QMS).
  
  

• Obstacles for manufacturers: The complicated market entry requirements imposed by Rule 11 can create challenges for smaller manufacturers and slow down the launch of medical software products.
  
  

• Access to the European market: Compliance with MDR Rule 11 facilitates access to the European market. For the manufacturers who want to introduce their SiMD / SaMDapplications to a wider area, with MDR, it’s easier to do so.
  
  

• Opening to even more countries: Following MDSAP (Medical Device Single Audit Program) that guarantees the quality and safety of medical devices, the producers gain access to the American, Australian, Canadian, Brazilian and Japanese markets.

What are SaMD and SiMD in MDR Rule 11?

Medical software that is classified as an active medical device is called SaMD (Software as a Medical Device). Such a term refers to medical software intended for use, alone or in combination, for a specific medical purpose. This purpose refers to the definition of a "medical device" as outlined in the regulations for medical devices (MDR) or in vitro diagnostic medical devices (IVDR).

The MDR rules also apply to Software in Medical Devices (SiMD) - software that is embedded into a physical medical device.

Examples of SaMD and SiMD:

• Software that evaluates MRI images and makes diagnosis recommendations should be considered as SaMD, while software that controls an MRI machine is a SiMD.

• A mobile app that monitors a patient’s glucose levels and makes treatment recommendations to the patient and/or patient’s doctor is SaMD while software that allows a patient to control their insulin pump based on glucose readings is a SiMD.

• An application based on machine learning algorithms that reviews patient health data and makes treatment recommendations is another example of SaMD while software within a medical device that securely stores patient health and treatment history (e.g. Digital Health Records or Medical Information System) is a SiMD.

SaMD and SiMD are now classified as higher risk, mostly falling into Class II, as opposed to the former directive, where they were considered Class I with low risk. New medical devices manufactured after 2021 fall under MDR rules.

What is the risk classification mentioned in MDR Rule 11?

We already know that Rule 11 MDR classifies medical device software according to their level of risk, but what does the risk actually depend on?

Let’s have a look at the four categories of MDR Rule 11 software:

• CLASS I includes software considered to have the lowest level of risk that doesn’t require Notified Body certification.
  
  

• CLASS IIa covers software having a moderate level of risk. It’s generally intended to provide information to make “low-risk” decisions with diagnosis or therapeutic purposes or monitor physiological processes.
  Example: medicine dosage calculators, diagnostic software for mammography.
  
  

• CLASS IIb applies to software with a higher risk level than Class IIa. It’s intended to provide information for diagnostic or therapeutic decision-making that can have a significant impact, potentially leading to serious deterioration, surgical intervention, or monitoring vital physiological parameters with immediate patient danger potential.
  Example: magnetic resonance imaging (MRI) analysis software, applications used for treatment planning in radiotherapy.
  
  

• CLASS III includes software considered to have the highest level of risk. It’s intended to provide information which is used to make decisions with diagnosis or therapeutic purposes which have an impact that may cause death or an irreversible deterioration of the user.
  Example: applications monitor active implantable medical devices, insulin pump control software.

Note, however, that the above examples of devices are contractual and dependent on many factors, e.g. medicine dosage calculators, may also be a Class IIb device depending on the type of drug delivered or an insulin pump control software might be considered as Class IIb if there is no closed loop with glucose meter.

Therefore, the classification of software as a medical device should always be carried out individually for a given application, its intended purpose and the functionalities it provides to the user.

If you have any doubts about how to classify your medical software, we’re here to clear up any doubts.

Why is falling into Class I of MDR Rule 11 so difficult?

MDR Rule 11 has made it difficult for software medical devices to be Class I. It's an obstacle for many startups to ship innovative software without going through the expensive and slow approval of a notified body.

According to the MDR Rule 11, the types of software medical devices not classified as Class I medical devices are those which:

a) provide information used for diagnostic or therapeutic purposes, which makes them Class IIa or higher

b) monitor physiological processes, which also affect at least Class IIa.

It's worth noting that phrase a) describes the "mode of action shortly" characteristic for all MDSW; therefore, this sub-rule is generally applicable to all MDSW (excluding those with no medical purpose), which causes becoming a Class I medical device such difficult.

Additionally, under most circumstances, MDSW described with phrase b) is included in the description from phrase a). To avoid misunderstanding, according to MDCG 2019-11, it should be considered a specific sub-rule about software medical devices intended only for monitoring purposes of vital physiological processes but of any/all physiological processes.

Bearing in mind all of the above, giving a sample Class I MDSW is quite complicated, which can be clearly seen in a detailed example given in MDCG 2021-24 (fertility tracking app) that cleverly avoids doing any diagnosis or therapy. Applications preventing diseases might be Class I MDSW as long as there is no "contacting or alerting a physician" function which can cross the border of "diagnostic purpose of the device". The same border can not be crossed by an application with direct therapy of disease to stay as a Class I medical device.

A few side stories to MDR Rule 11

What is the intended use of medical devices?

The intended use of a medical device refers to its specific purpose and target population according to the manufacturer's instructions. It includes the medical purpose, target population, and any specific clinical conditions it’s indicated for.

For instance, software that collects exercise-related data, such as heart rate, number of steps, and distance walked and stores and/or transmits it for a qualified professional might not be considered a Class I medical device. Moreover, very often, it might not be considered a medical device at all, because collecting the data doesn’t make an app a medical device as long as it isn’t used for diagnosis or therapeutic purposes. However, if the same software takes information like heart rate or number of steps to make treatment recommendations directly to the patient or healthcare provider, it should be considered at least as Class IIa.

Let’s discuss another case - cognitive therapy software that includes diagnostic functions. The intention of the app is to determine follow-up therapy. Cognitive therapy MDSW (Medical Device Software) that includes a diagnostic function intended to give feedback to the software to determine follow-up therapy, e.g. software that adapts treatment of depression based on diagnostic feedback, should be in Class III. When a specialist determines the necessary cognitive therapy based on the outcome provided by the MDSW, the MDSW would be classified as Class IIa.

Clearly defining and documenting the intended use is crucial for regulatory submission and proper device or software classification. The intended use statement should be concise, accurate, and reflect the device's medical purpose and indications for use.

MDCG guide & EU Rule 11 MDR

If you still have a problem analysing rule 11 and are unsure what class to classify your software into, the MDCG 2019-11 guide can help you.

The Medical Device Coordination Group (MDCG) assists in implementing the MDR (Medical Device Regulation) in the EU. It provides guidance on classification, conformity assessment, post-market surveillance, vigilance, clinical investigations and many other topics related to MDR. The group ensures consistent implementation of the MDR rules and serves as a valuable resource for manufacturers, Notified Bodies, and industry stakeholders. You should look at MDCG 2019-11 Guidance on Qualification and Classification of Software in Regulation (EU) 2017/745 – MDR & Regulation (EU) 2017/746 – IVDR.

Please remember that the MDCG guide only includes guidelines, not laws, designed to facilitate understanding and implementation of the medical software classification.

How exactly does MDCG apply to MDR Rule 11?

The has created a document presenting ideas on classifying medical device software. The criteria specified in this document shall also apply to applications (commonly referred to as apps), whether operating on a mobile phone, in the cloud or on other platforms.

The MDCG's Guidance offers a more detail interpretation of Rule 11, addressing risks related to information provided by active devices, including medical device software. It provides examples and suggested classifications, allowing for proper classifications for software that informs diagnostic or treatment decisions rather than directly treating or diagnosing a condition.

Medical software certification in practice

The medical classification system marks medical devices with the CE Mark, which signifies proper classification and risk assessment. Notified Bodies assure compliance for classes IIa, IIb, and III medical software.

If you want your product to be CE marked, you need to go through the classification and compliance process.

What can you do to prepare for a certification?

• Considering their limited availability, plan an audit with a Notified Body in advance.

• Provide sufficient clinical evidence for MDR compliance.

• Address pre-market and post-market cybersecurity risks and requirements for other economic operators in the supply chain.

• Collect necessary documents and information for device classification, including descriptions, patient data, disease information, and treatment details.

• Offer evidence to support discussions with Notified Bodies and competent authorities,especially when seeking Class I classification for the devices balancing between two classes.

To classify your device according to Rule 11 MDR, start by gaining knowledge from governmental websites or specialised blog posts, where you can read interpretations and suggestions concerning Rule 11 and Annex VIII. Then, engage a software development company compliant with MDR rules. Find one with ISO 13485 certified QMS for medical software development to build the software and assist with technical documentation.

EU MDR Rule 11: final word and mistakes to avoid

Balancing safety and access to innovative digital health products takes time. Rule 11 MDR classifies software used for diagnostic or therapeutic decision-making as Class IIa, with exceptions for decisions that can cause severe harm or death (Class III) and those that may lead to surgical intervention (Class IIb). It helps manufacturers classify software based on provided information and patient condition severity. This may result in fewer devices entering the EU market, requiring manufacturers to adapt approval and monitoring methods for agile software development.

However, MDR Rule 11 classification also presents several advantages:

• Although Rule 11 MDR makes the path to the market more challenging for most SaMD, the rules increase the quality of manufactured software, and the authorities approve its safety.

• It’s based on risk assessment instead of considering only the potential harm. Paying attention to health conditions and potential interventions raises the safety of the devices.

• Thanks to the higher classification of software previously described as Class I, the level of risk in therapy and diagnosis of the patients will decrease.

Nevertheless, while considering the certification of your medical software, you should be aware of the most common mistakes the manufacturers make.

The major mistake is defining an inappropriate intended use of your medical device, which leads to:

• inappropriate classification of your medical device according to MDR 2017/745

• inappropriate classification of your medical device software according to ISO 62304.

These are common, but not only examples, of mistakes in defining medical software's intended use. We’re going to tell you more about it in future articles.

Summarising

MDR Rule 11 is crucial regulation for SaMD, establishing four classes of medical software that enhance quality, safety, and efficiency in the healthcare market.

Despite challenges like the need for clinical evidence and regulatory compliance, the benefits are undeniable. With clear classification criteria, MDR Rule 11 ensures precise SaMD regulation, prioritising safety, improving patient care, and facilitating European market access. Understanding its impact empowers medical software manufacturers to prepare for certification and drive innovative SaMD development.