What are Medical Device Regulations?

Software in the Medical Device Regulations World


A lot has already been said regarding the new classification of software under the Medical Device Regulations.

Scaremongering and rumours are already running wild, as if any Step Counter app would now be on the same level as the firmware of an implantable pacemaker.

Medical Device Regulations

Let’s try to put some order and perspective to this change:

1. Per the current MEDDEV 2.4/1 (par 3.1.4), standalone software is ALREADY considered an Active Device.

2. Accordingly, this software can currently be positioned from Class I up to IIb.

3. The concept that “Software, which drives a device or influences the use of a device, shall fall within the same class as the device.” remains unchanged.

4. The MDRs modify the classification of high risk software, in Rule 11 of Annex VIII. This is the part where significant changes can impact your device.

Classification of Software as a Medical Device based on MDR

The MDR is not dissimilar to the MDD, where the high risk software falls under Rule 10 today, for diagnostic software and software used to monitor physiological processes.

The new class of application, where the software can cause “death or an irreversible deterioration of a person’s state of health”, brings software to Class III scenarios. This clause, together with the specification that this is not just to be considered as a result of the control of a device, but “to provide information which is used to take decisions”, can shoot some Class I software to the Class III world.


A mobile medical app that helps doctors make diagnosis or set treatment parameters, based on manually entered data, such as physiological parameters.

As the app does not directly interface with any other device and is not used for any of the purposes of active devices, it can currently be classified as Class I. Depending on the exact application and intended use, it can even be a self-affixed CE mark case.

With the new MDR, as the app is “intended to provide information which is used to take decisions with diagnosis or therapeutic purposes” it is a minimum of Class IIa, up to Class III in the appropriate cases.

If you also add the fact that there is no more “grandfathering”, i.e. all devices currently on the market must be re-assessed to the new rules, create an explosive mix.

To summarize:

If you develop software that works in conjunction with a device, complementing or supporting its function, the classification would most likely not change, as it typically follows the device classification.

If your software is currently Class I (possibly due to the fact that it does not directly interact with a specific device, but only provides some sort of information, guidance, algorithm to interpret data, diagnosis, therapy definition or decisional support) and its malfunction can reasonably lead to “death or an irreversible deterioration of a person’s state of health”, then by 2020 you are expected to comply with the new classification of the MDR.