As noted in our previous articles on this topic, the upcoming EU Medical Device Regulation (2017/745) (EU MDR) presents a number of challenges for medical device manufacturers. For software-based medical devices, classification changes were a major concern. In particular, it appears that almost all software medical devices are likely to be Class IIa or even Class III (the highest risk category), whereas previously the majority were Class I. Under the current provisions of the Medical Devices Directive (MDD), the majority of this type of SaMD would have been Class I, the lowest risk category. This means that all software would then fall under classes IIa, IIb or III. Since the higher rule applies, this software should be assigned to Class III! One use case to consider is an alarm system that receives information from an ECG monitor. The standalone software that triggers the alarm is considered SaMD, while the ECG monitor software would be SiMD, an integrated device with embedded software. The source of this potentially spectacular assessment is Rule 11, Annex VIII of the EU MDR. The wording of Article 11 is very broad and (so far) there have been no formal guidelines on its interpretation. As a result, many manufacturers took a conservative approach to Rule 11 and assumed that the highest classification would apply. However, on 11 October 2019, the Medical Device Coordination Group (MDCG) published its guidance document on software qualification and classification. Below, we describe how the guidance appears to mitigate the effects of Rule 11 and provide more clarity regarding the classification of software medical devices.
While other people might say, “Oh my God, Class I MDR devices don`t exist, please reserve our consultation kit,” I think there are legitimate software medical devices that would fall under MDR I, and they would even add value to patients. Hopefully, government agencies and notified bodies follow this reasoning and provide at least some of the remaining innovation potential destroyed by the MDR transition. The approach followed in the guidelines is as follows. In characterizing Rule 11, the Guidelines state that “.. are intended to address the risks associated with the information provided by an active product, such as [software for medical devices]`. In this context, the Committee notes that Rule 11 was introduced in accordance with the IMDRF Guidelines. It is clear from the Guidelines that Rule 11″. describes and categorizes the importance of the information provided by the active device for the health decision (patient management) in combination with the health situation (patient condition)”. Although none of these terms are explicitly used in Rule 11. Here are some examples of well-known medical software: The MDCG also indirectly announces the (feared) end of all Class I software. He writes in reference to the sentence “Software intended to provide information used for decision-making for diagnostic or therapeutic purposes is classified as Class IIa”: To date, most SaMDs have been classified as Class I (low risk). The new software-specific classification rule, MDR Rule 11, pushes almost all SaMD into the higher risk classes of Class II and Class III.
There will be virtually no standalone software classified in Class I! Our fears seem to be coming true. The MDAG has prepared a project in which it presents its ideas for dealing with (and classifying) medical device software. In our view, the guidelines are good news for software medical device manufacturers. It introduces a way to potentially justify a lower classification for software that, for example, does not directly treat or diagnose a condition. We consider this to be a pragmatic approach to the classification of software medical devices. In particular, it recognizes that there is a different risk between software that acts directly on a patient and software that influences a clinician`s diagnosis or treatment decision. A strict interpretation of Article 11 alone does not permit such distinctions. As always, I`ve simplified everything a lot, and there are more subtleties. For example, if your software can cause death, then it is Class III. Note: MDAG does not limit the application of Rule 11 to stand-alone software. This means that the software of a physical device must be assigned its own class, at least if that software can do more than just control the device.
If this software is classified in a higher class than the “other” device, the manufacturer should rank the device higher. `All instruments, apparatus, software, etc., intended to be used by the manufacturer for any of the following purposes: i. the importance of the information provided by the software for health care decision-making, While there are many other medical software applications that now meet the definition of a “medical device”, it is important to note that these changes only apply to stand-alone software (software as a medical device, SaMD), and not to software that is part of an embedded system (software in a medical device, SiMD). Therefore, manufacturers of software medical devices under the EU MDR are faced with a situation where a device from the previous Class I could suddenly become Class III. In general, software is divided into higher classes. Here are some examples: (Almost) all software used for diagnosis, monitoring, prediction, prognosis or treatment purposes also provides information with which decisions are made for diagnostic or therapeutic purposes. It is precisely this type of software that is classified in Class IIa or higher under Rule 11. It is quite clear that the vast majority of software medical devices are designed to provide information used to make decisions for diagnostic or therapeutic purposes. For example, even software that works like a thermometer would be captured.
Therefore, the starting point is that a significant number of software medical devices are classified in Class IIa. Rule 11 of the MDR makes it very difficult for software to enter Class I. This is bad, because under the old legislation (the MDD), a Class I device allowed many start-ups to provide innovative software without having to go through an expensive and slow approval from a notified body. It was probably a good balance between innovation and patient safety. Why has the MDR made this so much more difficult? I don`t know, why are you asking? That wasn`t the question anyway. Um, back to the topic. EK-Med also recognises the risk of stricter classification: the organisation believes that this provision will generally lead to a stricter classification of software, in particular applications, which will lead, inter alia, to increased involvement of the notified body and the conduct of clinical trials. The document “EK-MED 1934/16”, in which other effects of the MDR are also discussed, can be downloaded here. However, classification in Class I remains possible. This will be the case for stand-alone MDSWs which, although intended for medical purposes, will remain below the threshold set out in Rule 11(a) and (b) and will therefore fall under Rule 11(c). Therefore, MDSW manufacturers should not assume by default that an MDSW must be at least Class IIa, but it is always useful to carefully check whether the characteristics of the software do not justify a Class I categorization instead.
The next (and last) example I can think of would be software to deal directly with diseases. While in the past, even highly critical software for calculating the dose of cytostatics fell into Class I, we can now observe the opposite: due to Rule 11, it could be that non-critical applications also fall into Class III.