That a pacemaker should be a regulated medical device is obvious. However, with software, especially apps, the ambiguity is greater. Software must also be classified as a regulated medical device under the Medical Device Regulation (MDR) if it is used for specific purposes such as the diagnosis or treatment of diseases. If you want your product to be reimbursed as a DiGA (digital health application), classification as a medical device is actually one of the requirements.
In this article, we provide detailed guidance to help you make an informed decision as to whether your app or software qualifies as an MDR medical device.
Below you will find a guide to determining the correct risk class for your software: Classification of software medical devices: MDR guide.
Update June 2025: The official guidance document “MDCG 2019-11: Guidance on Qualification and Classification of Software […]” has been revised and published in Revision 1. This article reflects all updates. A detailed list can be found in the following chapter: Go to chapter on Revision 1
Table of contents
- Terminology: MDR, Medical Device & CE
- Motivation: Software as a medical device
- Focus of the article: MDR
- When is my app/software officially a medical device?
- The purpose decides
- What does this mean specifically?
- Types of apps/software as medical devices
- Frequent uncertainties
- Who makes the final decision?
- Medical device approval without regulation?
- June 2025: Update of the official MDCG guidance
- Conclusion
Terminology: MDR, Medical Device & CE
For the purposes of this article, the term “medical device” is defined according to the definition in the Medical Device Regulation (MDR). In short, a medical device is a product intended for medical use. In order for medical devices to be placed on the European market or put into service, they must bear a CE mark.
Software that is classified as a medical device is also officially referred to as medical device software (MDSW). Determining whether software falls under the definition of a medical device is known as qualification.
We highlight the entire path to medical device approval (and thus CE marking) in this article: Approval & Certification of Software Medical Devices (MDR).
Motivation: Software as a medical device
It usually starts with the idea of developing an app or software for use in the healthcare/medical sector. The second step is to determine whether your planned product is a medical device or not. As a software service provider specializing in the development of medical software, we are very familiar with the issues involved. This evaluation has a major impact on the future of your product. Depending on whether you launch your app as a medical device, many circumstances will change.
On the downside: an app as a medical device…
- is more complex and therefore more cost-intensive
- requires expertise in the area of quality management, which you either have to develop internally or buy in externally
On the pro side: an app as a medical device….
- can be reimbursed (more easily) by the health insurers, if necessary. Classification as a medical device is, for example, a basic requirement for inclusion in the DiGA directory.
- sets your application apart from the competition, which may not have been approved as a medical device. The CE mark builds confidence among patients, physicians, health insurers and other healthcare professionals.
However, the decision as to whether your app is a medical device is only indirectly up to you. A given product with a specified purpose and functionality either falls under the definition of a medical device or it does not. That depends on the wording of the MDR law. So you have to stick to that. Otherwise, you are not acting legally (more on this below).
However, to avoid classification as a medical device, you can of course change the intended purpose, functionality, and marketing of the product accordingly. For example, if you initially planned to develop an app to support the therapy of rehabilitation patients, you can instead develop a fitness app (which does not specifically target patients and is not intended for use in therapy). Read more in our article on formulating the intended purpose.
Focus of the article: MDR
In this context, we are focusing on the European market and looking specifically at the Medical Device Regulation (MDR). Since certification as a medical device in accordance with the Medical Device Directive (MDD) is no longer possible as of May 26, 2021, we will not discuss this further here. Incidentally, there are extensive overlaps between the MDR and MDD when it comes to defining a medical device.
In addition, this article specifically considers standalone software as a medical device. This includes mobile apps in particular. We will not discuss hardware (such as pacemakers) further.
When is my app/software officially a medical device?
Before we look at specific examples, it is important to understand what “officially” determines whether your app is a medical device. Surprisingly, this depends on only one definition in the MDR. Your app is a medical device if it falls under the MDR’s definition (“definition”) of a medical device:
“Medical device” means an instrument, apparatus, device, software, implant, reagent, material, or other article that, according to the manufacturer, is intended for human use and is intended, alone or in combination, to fulfill one or more of the following specific medical purposes:
- Diagnosis, prevention, monitoring, prediction, prognosis, treatment or alleviation of disease,
- Diagnose, monitor, treat, mitigate, or compensate for injury or disability,
- Examination, replacement, or alteration of anatomy or of a physiological or pathological process or condition,
- Obtaining information through in vitro examination of samples taken from the human body, including organ, blood, and tissue donations
and whose main intended effect in or on the human body is not achieved by pharmacological or immunological means or by metabolism, but whose mode of action may be assisted by such means.The following products are also considered medical devices:
- Products used to prevent or promote conception,
- Products specifically intended for the cleaning, disinfection or sterilization of the products referred to in Article 1(4) and the products referred to in paragraph 1 of this indent.
The purpose decides
Specifically, this paragraph means, among other things, that the intended purpose of your product is decisive for its classification (the decision as to whether your product is a medical device). The list of functions of your app/software is not relevant or only has an indirect influence on the intended purpose. If the intended purpose of your app is, for example, the treatment, diagnosis, or prevention of diseases, it must be classified as a medical device according to MDR and is therefore considered medical device software (MDSW). The term “intended purpose” is defined by the MDR as follows:
“Intended purpose” refers to the use for which a product is intended according to the manufacturer’s information on the label, in the instructions for use, or in the advertising or sales material or advertising or sales information and its information in the clinical evaluation.
This also makes it clear that the defined intended purpose of your product must also be communicated on all marketing/sales channels, for example. You cannot market your medical device for any purpose other than that specified in the declaration of conformity.
If you need help formulating the intended purpose, you can find more information in this article: Formulating the intended purpose for (software) medical devices
Let’s take the example of a diabetes app. If your software is intended for the purpose of “documenting glucose values,” it is not a medical device. It is not used for the treatment, prevention, diagnosis, etc. of diseases. It is purely a documentation tool with no direct medical purpose. However, if your application evaluates the documented values and provides advice on this basis (“You should eat something”), this constitutes “therapy recommendations.” The app therefore has the purpose of “treating diabetes,” for example. It is a medical device.
The fact that the intended purpose is paramount is also made clear in the foreword (19) to the MDR:
It is necessary to clearly establish that software as such, if specifically intended by the manufacturer for one or more of the medical purposes listed in the definition of medical devices, is a medical device, while software for general purposes, even if used in healthcare facilities, and software used for lifestyle and wellness purposes is not a medical device. […]
Software/apps for general purposes, and therefore not for specific use in the medical field, are not medical devices. For example, Microsoft Excel is not a medical device because it is intended for all kinds of applications. Of course, Excel can also be used to calculate certain key figures that could be used, for example, to diagnose a disease. However, this is not the intended purpose of Excel. An app/software that is specifically designed to calculate key figures for the diagnosis of a specific disease, on the other hand, is a medical device.
Note: It is possible that your software/app does not fall under the MDR, but under the IVDR (In-vitro Diagnostics Regulation). If your app is intended for obtaining information through the in vitro examination of samples derived from the human body, it falls under the IVDR. The qualification criteria are similar. However, this article does not explicitly cover this type of software.
What does this mean specifically?
As can be seen above, a single article of the MDR determines which software or devices are medical devices. So you don’t have to pore over the entire MDR to make this decision. At first glance, this seems to be an advantage. Unfortunately, however, this is more of a disadvantage: the definition is very brief and therefore very vague. In order to make decisions in specific cases, a little more background knowledge and guidance is needed.
Therefore, there are documents that attempt to explain the facts better with concrete examples. Probably the most important guidance document within the framework of the MDR comes from the MDCG (Medical Device Coordination Group) and is entitled “MDCG 2019-11 Qualification and classification of software […]”. Within this article, we refer to this document as “MDCG Guidance” (although there are a variety of different MDCG guidance documents).
The MDCG Guidance is not legally binding, but helps interpret the MDR paragraph. What we refer to in this article as software as a medical device, the MDCG Guidance refers to as Medical Device Software (MDSW). To help you decide whether your application is an MDSW (and therefore a medical device), the MDCG Guidance includes, among other things, a decision tree:
MDCG Guidance decision tree: click to enlarge
Types of apps/software as medical devices
Within the MDR and MDCG Guidance, a distinction can be made between three different types of software/apps as a medical device (or MDSW):
1. Accessories for a medical device
If your software/app controls or influences another medical device (usually hardware), it may be considered an accessory for a medical device. The MDR defines this as follows:
“Accessory of a medical device” means an item that is not itself a medical device but is intended by the manufacturer to be used together with one or more specific medical devices and specifically enables their use in accordance with their intended purpose(s) […]
The control software is therefore itself also a medical device.
2. Standalone medical device
If your software/app has its own independent medical purpose, it is considered a standalone medical device. An app that provides therapy recommendations based on specific input values is, for example, a standalone medical device. The majority of DiGA will fall into this category, for example.
3. Part of a medical device
Certain software is an integral part of the medical device. The software therefore does not need to be reclassified separately. This primarily includes embedded software, such as the software/firmware of a blood pressure monitor. An app is unlikely to fall into this category because it runs on a smartphone, which is not itself a medical device.
Depending on the type, slightly different regulations apply under the MDR, which we will not go into in detail here.
Frequent uncertainties
When evaluating whether a medical device is present, there are some typical ambiguities. We resolve some of them here:
Communication & data storage:
A chat or video call solution is not usually a medical device. The purpose is purely communication. This also applies, for example, to pure data storage/documentation. The MDCG guideline clearly states that “storage, archiving, communication & simple search is not a medical device”.
Influence of the operating system, runtime environment, and “location” of the software:
Whether your software runs on a remote server, on a smartphone, or on Android or Windows has no influence on the decision as to whether it is a medical device. As described above: the intended purpose counts.
Potential patient risk:
The risk of your app/software causing harm to a patient is irrelevant. The probability and severity of potential medical harm have no bearing on whether your app is a medical device. The following argument is not valid: “Our app can only cause very minor harm. Therefore, it should not be considered a medical device.” If the purpose is still to treat a disease, for example, we continue to refer to it as a medical device.
Indirect vs. direct damage:
It is often assumed that certain apps are not medical devices because they “only provide decision support” for doctors or patients. Ultimately, it is still the doctor or patient who decides how to proceed. So it shouldn’t be a medical device? This argument is also not effective. If your app provides therapy recommendations, the medical purpose is “treatment of a disease” and therefore a medical device. And that’s how it should be: an overworked doctor or tired patient tends to rely more and more on their software tool. Certain recommendations may no longer be questioned, which could lead to potentially wrong decisions with serious consequences. To the extent that they are intended for the treatment of diabetes, the following products are therefore also medical devices: a physical insulin pump, an app for controlling an insulin pump, or even just an app that provides specific dosage recommendations for injecting insulin.
Users of the software: patient, physician, or a “layperson”:
Just because your app is not used by a physician or patient does not mean that it is not a medical device. For example, a mother could help her child with limited mobility during treatment for an illness. The mother may use software for this purpose. However, she has no medical training and is not a patient herself. Nevertheless, the purpose is therapy. There is therefore a risk that the therapy will be carried out incorrectly, and for this reason, its use is also morally justified as a medical device.
Comparison with other apps on the market
People often try to argue by comparing our app with others on the market: “App XY is available in the App Store, has the same functionality as our app, and is not a medical device. So why do we have to be a medical device?”
Comparing our app with others does not help here either. There are many apps on the market that should actually be classified as medical devices, but are not. However, no conclusions can be drawn from this for your own app. Often, the makers of these apps have just been doing it without really knowing any better. However, in the event of a lawsuit/warning letter, these are contestable. If you want to build a stable business with your app, you should comply with the law.
Who makes the final decision?
You must decide for yourself whether your software is a medical device. To do so, you can consult the BfArM, advisors, lawyers, or even notified bodies. Ultimately, however, the decision remains yours. In the event of a lawsuit, your decision will be reviewed by the court.
If, for example, you have mistakenly failed to market your software as a medical device, you will bear the consequences. A review by a judge may be triggered, for example, by a claim for damages. A patient or competitor could sue you or send you a warning letter.
So if you are unsure, it is worth obtaining an assessment or expert opinion from a third party. The following options are available for this purpose:
- inquire at the BfArM (however, the long response times here are usually not sufficient)
- have an expert opinion issued by a lawyer specializing in this field
- Obtain an assessment or opinion from a regulatory consultant
It is important to emphasize again that even these assessments and opinions do not automatically protect you legally. In the event of a lawsuit, a lawyer would still have to defend you in court on the basis of this expert opinion. However, there is a good chance that you will win the case if your attorney has done a diligent job.
Medical device approval without regulation?
Is there a way to completely avoid regulatory obligations for medical device manufacturers?
Yes, there is: outsourcing the role of legal manufacturer to an external company. This is an efficient and risk-minimizing solution that conserves your resources while ensuring regulatory compliance. You don’t need to set up a quality management system and can completely hand over the regulatory approval process.
This allows you to focus on product design and marketing, while QuickBird Medical, as the legal manufacturer, takes care of all regulatory requirements and is responsible for compliance.
You can find more information here: To the technical article
June 2025: Update of the official MDCG guidance
In June 2025, a long-awaited update to the official MDCG guidance document on risk classification and qualification was implemented in the digital health scene.
All changes have already been taken into account in this article. Overall, nothing fundamental has changed with regard to the qualification of medical device software (MDSW).
The most important changes were as follows:
- The wording of the purpose clause for MDSW is discussed in greater detail.
- Specification that the calculation and interpretation of medical information could lead to a medical purpose and classification as a medical device.
- Clarification that fitness and wellness apps are not medical devices.
- New information regarding the applicability of the European Health Data Space Regulation (EHDS)
- A wide range of illustrative examples that qualify as medical devices or non-medical devices.
The new version of the MDCG Guidance can be found here.
Conclusion
It is not always easy to decide whether your app/software is a medical device. The MDR definition provides only very vague guidelines. The MDCG Guidance attempts to provide a better understanding with illustrative examples. However, when in doubt, it is always advisable to seek a third opinion. If you would also like to know whether your app qualifies as a medical device and, if so, which risk class it falls into, take a look at our article “Classification of software medical devices: MDR guidance.”
We develop medical apps and medical software on a contract basis for our customers. Therefore, we are regularly confronted with the question addressed. For a free initial assessment of whether your app/software is a medical device, please feel free to contact us at any time.
