13 October 2022

Medical Device Regulation (MDR) and its consequences for healthcare software development


Innovating in the healthcare industry means working on improving people’s lives through technology. But it also means having to adhere to regulations that ensure the solutions you create are safe for the patients – in many different ways. Medical Device Regulation (MDR) is probably the most important set of rules you need to follow when building a medical app. Let’s dive into why it exists, what it means for the healthtech sector, and why you should get familiar with it – especially if you’re planning to launch your medical app in Europe.

Accelerating the health technologies

Although embedded software, as well as desktop, web, and – more recently – mobile applications have been supporting medical professionals and patients for many years now, it has been the COVID pandemic that accelerated the medtech sector. Medical applications for mobile devices and computers support medical professionals and patients in the diagnosis, treatment, or monitoring of a disease or injury. 

These e-health apps range from calorie counters and pedometers (counting your steps) to blood glucose monitors and remote electrocardiogram (ECG) monitoring, which may also be connected to an electronic health record (EHR). Family planning apps (some use AI algorithms based on a woman’s menstrual cycle pattern, basal body temperature, and ovulation tracking with at-home ovulation tests) have gained popularity recently and there are several professional debates about whether they can be considered a form of contraception. Healthcare professionals often use apps with calculators, e.g. to estimate one’s risk of coronary artery disease or pre-eclampsia in pregnancy. There are several apps that support the diagnosis of skin diseases and help non-radiologists interpret imaging studies. And many, many more.

Mobile apps as medical devices

It’s possible you’re using several medical apps every day without even realizing that many of them are now considered medical devices. As a user, you don’t exactly need to be aware of the consequences of this, but as a company creating an app that may fall into this category, you definitely should.

So, how do you know if your medical app is a medical device and falls under the Medical Device Regulation?

First of all, you need to be able to differentiate between medical and well-being apps, as only the first one is covered by MDR legislation. However, the distinction between a well-being app and a medical app is not always straightforward, nor is it easy.

The labelled intended purpose remains the main criterion to determine the classification. For example, an app collecting and analyzing data on a person’s physical activity for the purpose of maintaining their general well-being, such as weight loss, is qualified as a general well-being app and falls out of the medical devices legislation. However, the same app collecting and analyzing identical data for a medical purpose, such as the control and management of eating disorders or diabetes, would be considered a medical app.

The most important thing is to analyze whether your mobile application meets the definitions of a medical device or accessory for a medical device contained in MDR. If so, this application is subject to MDR regulations. If not – an in-depth analysis of the application features is required, for example, if your mobile apps drive or influence the use of medical device, etc., in accordance with the applicable guidelines of the European Commission and MDCG.

Małgorzata Gonsior – Kustosz, Head of Regulatory Affairs at Revolve Healthcare

MDR and app classification

You should be aware though that the legal requirements for medical apps (considered in most cases as standalone software) have increased with the new MDR laws. The European Union (EU) Medical Device Regulation (2017/745) has replaced the EU Medical Devices Directive (MDD) and established a regulatory framework for medical devices that safeguards public health and safety while supporting the competitiveness of the market. The EU MDR came into force on May 26, 2021. The classification no longer depends solely on the labelled purpose of the device, but also on the inherent risks of the devices. This leads to significant implications for medical apps since many of them fall into higher classification rules.

The new MDR classifications reflect the potential risk of harm that a medical device poses. Class I devices are seen as the lowest risk whereas Class III are deemed high-risk devices. There is also a class of high-risk software that has been introduced with the MDR. Importantly, this includes stand-alone software (software that can work offline, or is a portable application). For example, an app that helps users to calculate drug doses would be a Class III medical device, because the potential errors involved pose high risks for the app’s users. You can find more examples and see what Class your software falls into on our website he


  Key changes in the new Medical Device Regulation (source).

Rule 11 and risk assessment

A separate classification rule has been dedicated to software that is a medical device. Rule 11 describes and categorizes the risk of software based on the combination of the significance of the information provided by the software to the healthcare decision and the healthcare situation or patient’s condition. According to rule 11, in general, software intended to provide information that is used to make decisions with diagnosis or therapeutic purposes is classified as class IIa. An example of such software would be one intended to rank therapeutic suggestions for a healthcare professional based on patient history, imaging test results, and patient characteristics.

Of course, there are exceptions where the use of medical software may or must entail a greater risk for the patient or user. In situations where the effects of the decisions made may result in death or an irreversible deterioration of a person’s state of health, the software should be classified as class III. If decisions have an impact that may cause serious deterioration of a person’s state of health or surgical intervention, the software should be classified as class IIb.

Software intended to monitor physiological processes is classified as class IIa – but not always. If the software is intended for monitoring vital physiological parameters, where the nature of variations of those parameters is such that it could result in immediate danger to the patient, the software is classified as class IIb.

All other software treated as a medical device is classified as class I.

If the software is independent of any other medical device, it shall be classified in its own right – it concerns most of medical apps. On the other hand, software, which drives a device or influences the use of a device, should fall within the same class as the device.

Moving forward

To sum up, for the proper software classification, it is needed to consider the intended purpose, intended population, context of the use of the software and of the information provided by the software as well as of the possible decisions to be taken.

In this article, we’ve covered the basics of what MDR is and why it’s relevant for you if you’re building health-related software. In later articles, we will follow with how MDR influences the software development process, how it relates to ISO 13485, and what you should pay special attention to if you want your app to be MDR compliant.