Introduction to Software as a Medical Device in MDR

The MDCG’s Guidance document defines the criteria for software qualification falling within the scope of the EU MDR and IVDR.

This doc even seeks to elucidate which software will be considered a medical device (qualification) and its subsequent risk classification (classification).

Although it is not legally binding, notified bodies and competent authorities are likely to follow it since medical devices must be correctly classified against new risk criteria.

Our previous article describes the new classification criteria. How new guidelines indicate subsequent up-classifications of a large proportion of medical device software; currently classified as Class I, to Class IIa or higher.

This article intends to provide a deeper analysis of the possible impacts of the guidance and useful clarifications on classification.

IVD Medical Devices: Main Principles

The IMDRF stresses the importance of establishing an appropriate balance between ensuring a high level of patients’ health protection and avoiding the unnecessary regulatory burden preventing the manufacturers from placing their devices on the market. In vitro, diagnostic medical devices should depend on the factors causing a certain risk to the user (patient). The proposed system should include four risk classes.

The correct class of the device should be determined depending on its features, causing a certain risk to the patient. According to the document, the risk associated with using the device mostly depends on The risks associated with it using the device. Thus, the requirements need to be determined.

IMDRF Proposed Principles of IVD Classification

IMDRF proposed new principles of classification of the in vitro diagnostic medical devices. The organization itself is focused on the development and improvement of the existing regulations. Frameworks to ensure the highest level of public health protection. It develops guidance documents that could be implemented by the national regulating authorities of the Member States of the member countries of the international community, which could implement the guidelines in the national. Member States will use these guidance documents to implement.

Using the IMDRF Classification to Apply Rule 11

The MDCG Guidelines recommend the application of the International Medical Device Regulators Forum (IMDRF); a 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 unclear.
  • 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.

Recommendations on Classification

The IMDRF proposes to utilize an alphabetical system consisting of four classes. The manufacturer shall take into consideration both a public health risk and individual health risk. The level of regulatory requirements increases with the class of the device. The device manufacturers must consider conformity assessment procedures to determine the correct class under the risk-based classification the device should be assigned to. Manufacturers must also consider public health risks associated with the device, such as those associated with its use. The manufacturer will have to make the device comply with requirements to ensure that it is eligible for free distribution in the foreign market. Manufacturers must also assess compliance with the required national rules and requirements that differ significantly from those of other countries.

Understanding the Intended Purpose

The intended purpose answers whether the software under evaluation qualifies as a medical device, rendering it subject to any requirements from MDR, such as the software classification.

 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, driving or influencing another device is also achieving its 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. Thereafter they store and analyze them.

The app utilizes image processing algorithms to provide a detailed assessment of the scanned moles. The app also evaluates the probability that the scanned mole is a melanoma to enable early diagnosis of skin cancer.

Thus, following the MDCG guideline, there is no doubt that this app is an independent MDSW!

Assuming two versions of the app exist. The first is for patients, for a preliminary self-assessment. The second is for 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 I.

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, the device is class III if the medical purpose of the app is the direct diagnosis.

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 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 of MDR

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’t perform without a notified body.

Manufacturers must establish a certified quality management system, 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.

The 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 considers 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 to soften Rule 11 (by introducing the table of classification) and aims to align the EU position with the IMDRF guidance, its uniform interpretation cannot assure, 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 priority; Rule 11 has sparked a significant debate regarding the 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 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 for use in medical devices or standalone medical devices must be mindful of these changes and introduce all necessary measures to ensure compliance with the new system.

Conclusion

ISO 13485:2016 and MDSAP program pushing for greater standardization and stronger post-market surveillance requirements. The MDR is a taste of how the regulatory environment for medical devices will be changing over the next decade.

Have your medical company in compliance with the EU MDR? If not then just take a look at our website you will find each and every piece of information regarding EU MDR.

Our Literature Review

Please provide your email and we will send you  our documentation on MDR Literature Reviews