MDR Rule 11 makes most medical device software class IIa or higher

EU guidance documents only mention one example of a class I medical device software. A conception support software (MDCG 2019-11). Are there more? In short: Yes, but…

Roughly summarised the MDR defines medical devices as devices that are intended for diagnosis or treatment of diseases or injuries. At the same time the MDR classification rule 11 states that all software that provides information that is used to take decisions for diagnosis or therapeutic purposes are classified as class IIa or higher. Does that make all medical device software class IIa, or higher?

We took a logical approach to analyse the MDR medical device definition and the classification rule 11 and found some software indications that could classify as class I (and qualify as medical device at the same time):

1. Of course there is the conception support (planning) software from the EU guideline. Not a typical medical device in common sense, however the MDR medical device definition specifically adds “devices for the control, or support of conception” to the scope (however conception prevention software would be class IIb due to other rules!).

2. And the EU has added further non-typical medical devices to the scope:

Products specifically intended for the cleaning, disinfection, or sterilisation of medical devices. For example, software of products specifically intended for the cleaning of medical devices could be classified as class I (but not for disinfecting or sterilization, other rules make them class IIa+).

OK, those are two exceptions in the MDR medical device definition, which are commonly not expected to be a medical device at all. What else could be a class I device?

3. Some Accessory software may qualify as class I. For example, a software accessory that only indicates the service status of a medical device (though a non-medical device qualification would also be thinkable in such cases)

OK, now we have untypical medical devices and accessories. But is there some “real” medical device software that still qualifies as class I?

Here it gets tricky: Yes, it would be thinkable. But such software would probably come with big limitations in otherwise possible functionality!

The medical device definition of the MDR also mentions the terms “Prevention, monitoring, prediction, or prognosis.”

In this regard it would be thinkable that that software for lay persons analyses data with the purpose of prevention, monitoring, or prognosis. The software may give very general feedback to the layperson e.g. to seek a specialist. However, the drawback: The software should not provide detailed results or data to the specialist because the software may not provide information for diagnostic or therapeutic decisions. The specialist would have to carry out an unbiased investigation to identify the condition. This limitation is problematic. If the software can predict a condition (that may be overlooked by a subsequent specialist investigation) it would be negligent not to tell the specialist in detail what has been found. And it causes ambiguity for the user and is a source of complaints if a person is asked to seek a specialist but no condition is found by the specialist.

Conclusion: For „untypical“ software a class I classification can be concluded easily. To some extent also to simple software accessories. For „typical“ medical device software a class I classification would bring big limitations in the usefulness of the software. Because it may provide information that will be used for therapeutic or diagnostic purposes. The MDR rule 11 classifies such software as class IIa, or higher, without considering the severity of the condition or the impact of such a decision.

Seems that the regulators don’t thrust low impact software medical device manufacturers to develop safe products under a class I self-declaration, as it is allowed for manufacturers of scalpels or lots of other non-active equipment commonly found in a surgery room.

If you continue to read our article below you can find the details of the logical analysis and discussions of specific software e.g. software that does not provide any information at all.

Detailed Discussion

The medical device classification is crucial for medical device manufacturers. While class I medical devices can be placed on the market under a “self-declaration”; class IIa, IIb, III devices require a notified body. This involves high costs (30+k EUR) and long lead times to certification (commonly 2 years). Especially for start-ups that could be a kill requirement.

The MDR introduced a classification rule (rule 11) specifically for software, which pushes most software into the class IIa. Therefore, manufacturers currently have different choices to avoid the class IIa plus classification:

to restrict their software functionality and purpose to not qualify as a medical device. Basically, such software may not perform any action beyond storage, archival, communication, simple search, lossless compression or have no medical purpose to qualify not as a medical device. (MDCG 2019-11)

Some try to apply rule 11 and adapt the software indications and functions to classify as class I.

The flowchart below logically reviews what kind of devices may be classified as class I devices according to the rule 11 and at the same time remain medical devices (or accessory) that are covered by the MDR.

The main conflict between the rule 11 class I classification and the MDR medical device definition (article 2(1)) is that the rule 11 classifies all software “that provides information to take decision with diagnose or therapeutic purposes” as class IIa, or higher.

However most medical devices are qualified (defined) as medical devices because they are for diagnostic or therapeutic purposes according to MDR article 2(1)).

We choose rule 11 as a starting point, rather than the medical device definition (MDR article 2(1)), to demonstrate that there are only very few pathways that lead to a class I under rule 11.

MDR Rule 11 logical analysis for software medical devices

Figure: Flow Chart logically illustrating the MDR Rule 11 and MDR medical device definition. Most endpoints result in „class IIa, IIb, III“, or „Not a Medical Device“

Applying the Flowchart – Cases when software could be classified as class I.

The first question in the flowchart is if the software provides information at all. Software that does not provide any information would remain class I after the Rule 11. However, it should be reviewed if such software is actually a medical device according to the MDR definition, and if other rules do not apply.

Software that does not provide information => unlikely to be class I

Software that does not provide information has the chance to be classified as class I (when no other rules apply).

It’s hard to imagine a software that does not provide any information. That may be a control software without any interface. However, a software used to control (drive a device or influences the use of) a device shall be classified the same as the device. We could not come up with a meaningful software that would control a class I device (Syringe, bandage, …)

=> Likely such software is not a medical device, or classified as class IIa, or higher if they control a device.

Further if a software is not a medical device itself it could be an accessory.

Accessory => possible class I

Accessories (according to MDR Article 2(2)), that do not control (drive a device or influences the use of a device) a device and that do not provided information that is also used (e.g. subsequently) to take decisions with diagnosis or therapeutic purposes may be classified as class I (if no other rules apply).

Possible Software Accessory under class I:

a mobile App software that indicates the Service Status or intervals of a medical device => can be considered as class I (but non-medical device qualification may also be thinkable)
a mobile software APP that does indicate the device status/state that is anyhow already shown on screen of the device itself (and where displaying the device status/state on the app does not influence the use of the device).

Further we had a look into the other terms of the medical device definition of the MDR article 2(1) indications of prevention, monitoring

Prevention, monitoring, prediction, or prognosis => possible class I, but not very useful

Possible Software under Class I:

(direct) Prevention/Prediction/Prognosis

To remain in the class I the data from prevention, monitoring, prediction, or prognosis may not be used for (e.g. subsequently) to take decisions with diagnosis or therapeutic purposes). That could be Software for layperson use that collects personal habits, activities, food/drink intake, questionnaires that predict or prognose a potential disease or injury. However, this information may not be taken into account for decisions with diagnosis or therapeutic purposes.

Such applications could e.g. provide statements such as: “you may develop the following condition; you better consult a professional”; but when consulting the professional the results of the application should not be taken into account by the professional (information provided also used (e.g. subsequently) to take decisions with diagnosis or therapeutic purposes).

Examples would be:

Pain recorder after a surgery. The user can record pain levels and receive information about trends. The trends of the pain level should then however not be taken into account by a professional for decisions with diagnosis or therapeutic purposes. And the pain level monitoring should not be a crucial part in the patient therapy.
Screening software to screen a wide population to predict a condition. However, this should only flag the patients for further investigation while not providing the screening results to a professional to take decisions with diagnosis or therapeutic purposes. The professional would have to take other means, or ways to investigate the patient..

=> This limitation is problematic. If the software can predict a condition that may be overlooked by a subsequent specialist investigation it would be negligent not to tell the specialist in detail what has been found. And it causes ambiguity for the user and is a source of complaints if a person is asked to see a specialist but no condition is found by the specialist.

Indirect Prevention

Those are typical Lifestyle or Fitness Apps that prevent conditions because of an improved health

=> Such software is usually not seen as a medical device.

Investigation, replacement, or modification => theoretically thinkable class I

investigation, replacement, or modification of the anatomy or of a physiological or pathological process. Most likely software in this category would be part of an implant or prothesis (e.g. implants or invasive devices usually classify as IIa, or higher).

An example would be a software (accessory) to a passive prothesis e.g. to record the lifetime of the prothesis or to illustrate loads to the prothesis (while the loads may not be critical for the use of the prothesis. Or to control a reading light which is built in an hand prothesis

Remark: A software that records loads, or angulation of a prothesis that is later to take decisions for diagnosis or therapeutic purposes (adjustment of the angular limitation of the prothesis, adjustment of physiotherapeutic exercises), or is curial for the use of the prothesis would be classified as class IIa or higher..

=> Theoretically thinkable class I but not questionable if such devices make sense…

Providing information by means of in vitro examination – Unlikely to be class I

We did not find a reasonable case where in vitro examination information is used in a medical purpose without a diagnosis or therapeutic purpose.

=> Either not a medical device or a Class IIa+

Support of conception => possible class I –

Support of conception (e.g. conception planning software)

Remark: Control (prevention of) conception would classify as class IIb (MDR Rule 15)!

=> This is the only class I software that is mentioned in EU guidelines (MDCG 2019-11).

Intended for cleaning => possible class I

This definition only applies for equipment (or solutions) that is inedited to be used for specific medical devices. General purpose equipment may not be covered by this medical device definition (and should be validated in a process validation as a process equipment for the environment and devices used).

Equipment intended to be used to clean a specific medical device may fall under this definition. Control software for such equipment could be covered by the rule 11 and result in a class I classification.

Examples:

Software of specific instrument washing machines (without disinfection or sterilization)
Software of (e.g. dental) specific prothesis washing equipment

Remark: Washer-disinfector or sterilization machines are class IIa devices (all devices intended specifically to be used for disinfecting or sterilising medical devices are classified as class IIa). To remain class I in this case software could only be optional accessories and would not be allowed to drive or influence the use of the device (e.g. simple status indication that is anyhow given by the device, or indication of service intervals)

Disclaimer: Classification of medical devices is a case by case decision depending on the software/device indications, claims, use environment and functionality. Manufacturers are responsible to carry out the classification by themself applying the MDR classification scheme. Manufacturers, notified bodies, or competent authorities may interpret the classification rules differently to us and result in different classifications for devices listed in the examples above.

Title picture credit: AI image, Microsoft Bing Copilot, Powered by DALL·E 3

Does class I medical device software still exist under the MDR?