Classifying Software as Medical Device in EU MDR
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 article seeks to elucidate which software will be considered a medical device (qualification) and its subsequent risk classification (classification).
Although it is not legally binding and notified, bodies and competent authorities will likely follow it since medical devices must be correctly classified against new risk criteria.
Our previous article describes the new classification criteria and 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 provides a deeper analysis of the possible impacts of the guidance and valuable clarifications on classification.
IVD Medical Devices: Main Principles
The IMDRF stresses the importance of establishing an appropriate balance between ensuring a high level of patient safety and health protection and avoiding the unnecessary regulatory burden preventing manufacturers from placing their devices on the market. In vitro, diagnostic medical devices should depend on the factors causing a particular risk to the user (patient). Therefore, the proposed system should include four risk classes.
The correct class of the device should be determined depending on its features, causing a particular risk to patient safety. 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 in vitro diagnostic medical devices. The organization itself is focused on the development and improvement of the existing regulations.
Frameworks 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?
IMDRF risk categorization
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 unclear.
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 an 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 classification under the risk-based classification to which the device should be assigned. The manufacturers must also consider public health risks associated with the device, such as those associated with its use. In addition, 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.
IMDRF is a group that consists of voluntary medical device regulators from all over the world who have come together to harmonize medical device regulation. IMDRF develops internationally agreed-upon documents related to various topics affecting medical devices. In 2013, IMDRF formed the Software as a Medical Device Working Group (WG) to develop guidance supporting innovation and timely access to safe and effective Software as a Medical Device globally.
The FDA has developed various guidelines as part of its efforts to develop more uniform, consistent rules for software classified as medical devices.
Understanding the Intended Purpose
The intended purpose is to answer whether it qualifies the medical device as a SAMD (software as a medical device) under evaluation qualifies, rendering it subject to any requirements from MDR, such as the software classification.
To qualify medical device software as SAMD, 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. Therefore, 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. After that, 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 and medical 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). Therefore, even with the most severe 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 monitor 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 severe 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 of medical device software functions
The current rules allow for a modular approach to software qualification only if a proper 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 medical device software modules will be under the purview of the Medical Device Regulations (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, significantly increasing their costs and expenses. In addition, this could severely affect smaller companies such as app developers, start-ups, and university spin-offs.
The classification of medical device software 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, medical device 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 about medical device software
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 medical device software, particularly of apps, will result in increased involvement of notified bodies and execution of clinical trials.
Thus, companies presently developing medical device software or standalone software must be mindful of these changes and introduce all necessary measures to ensure compliance with the new system.
Conclusion
ISO 13485:2016 and MDSAP (Medical Device Single Audit Program) push for greater standardization and stronger post-market surveillance requirements. The MDR is a taste of how the medical device regulatory environment will change 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.
