Using the IMDRF Classification to Apply Rule 11

The MDCG Guidelines recommend the application of the International Medical Device Regulators Forum (IMDRF) risk categorization framework to help with risk classification of new or unknown software through an understanding and analysis of two critical aspects:

• How significant is the information provided?
• How critical is the situation or condition described?

However, there are a few uncertainties associated with the IMDRF risk categorization as described below:

•  Determining the correct category if the term “prediction” is used for the intended purpose is not clear.
• There is no clear distinction between “diagnosis” and “support of diagnosis”, “screening” and “triage”.
• The linkage between the criticality of the situation or condition and “fragile populations” is not clear.

Understanding the Intended Purpose

The intended purpose answers the question of whether the software under evaluation qualifies as a medical device, rendering it subject to any requirements from MDR such as the software classification. In order to qualify software as a medical device, it should “drive or influence the use”, “fulfilling a medical purpose in combination” and should thus be a part of the intended purpose.

In the case of software that in addition to driving or influencing another device is also achieving its own intended purpose, the risk class will not be lower than the risk class of the hardware medical device.

Even minute differences in the Intended Purpose may have a substantial impact.

To elucidate, let us consider a mole assessment app that allows users to take pictures of moles on their skin and thereafter store and analyze them. The app utilizes image processing algorithms to provide a detailed assessment of the scanned moles. In order to enable early diagnosis of skin cancer, the app also evaluates the probability that the scanned mole is a melanoma. Thus, in accordance with the MDCG guideline, there is no doubt that this app is an independent MDSW!

Assuming two versions of the app exist, such that the first is used by patients for a preliminary self-assessment and the second is used by healthcare professionals for medical diagnosis, the intended use of the MDSW will impact its risk classification.

In the case of Version 1, the app “informs of options for diagnosis” (significance of information), and even with the most serious disease type option, it would be classified as class IIa. Version 2 of the app is used for direct diagnosis, but rule 10 which refers to “direct diagnosis or monitoring of vital physiological processes” does not apply to it.

Although Version 2 of the app “aids in diagnosis”, the final diagnosis or decision is still the physician’s responsibility. Hence, even the most serious disease condition here would lead us to a class IIb classification. However, if the medical purpose of the app is the direct diagnosis it may even be assigned to class III.

Modules

The current rules allow for a modular approach to software qualification only if a true separation in functionality is possible. However, when software is broken into multiple applications, where each correlates to a module, some modules may have a medical purpose while others may not, raising the question of whether the whole product can be CE marked. The guidance indicates that modules that are software medical devices will be under the purview of the MDR.

Impact

1. Non-critical applications’ costs and expenses explode

Since there is hardly any software left that falls into class I according to the MDR, even for non-critical devices, a conformity assessment can no longer be performed without a notified body. Manufacturers must establish a certified quality management system, thereby leading to a significant rise in their costs and expenses. Smaller companies such as app developers, start-ups, and university spin-offs could be severely affected by this.

2. Classification does not always reflect the risk

Risks are combinations of degrees of severity and probabilities and the classification of the MDSW should indicate the risk. However, now, due to Rule 11, even some non-critical applications may fall within class III because classification either consider only severity (e.g. “might lead to death”) or duration (“irreversible”). For instance, software used to select drugs, calculate dosages of cytostatic drugs (previously class I), or schedule medical procedures will likely all fall within class III.

Our Thoughts

Although the Guidance was created partly with the intention of softening the impact of Rule 11 (by introducing the table of classification) and aims to align the EU position with the IMDRF guidance, its uniform interpretation cannot be assured, especially considering that it is not legally binding.

While the Guidance is a step in the right direction toward clarifying the MDR, patient safety and health must have first priority; Rule 11 has sparked a significant debate regarding suffocation of small innovative companies developing non-critical devices with burdensome bureaucratic compliances. Some industry experts believe that Rule 11 will slow the pace of innovation, impeding software development to an extent that makes it virtually impossible for small manufacturers to overcome regulatory obstacles.

A stricter classification of software, particularly of apps, among others, will result in increased involvement of notified bodies and execution of clinical trials. Thus, companies that are presently developing software to be used in conjunction with medical devices, or as a standalone medical device, must be mindful of these changes and introduce all necessary measures to ensure compliance with the new system.