That a pacemaker should be a regulated medical device is obvious. However, with software, especially apps, the ambiguity is greater. Mobile apps must also be classified as a regulated medical device if they are used for specific purposes such as the diagnosis or therapy of diseases. In fact, if you want to get your DiGA (digital health app) reimbursed under the DVG, classification as a medical device is one of the requirements. In this article, we will give you an overview of how to decide whether your app or software is a medical device. Subsequently, you can find the correct risk class for your app here: Classification of software medical devices: MDR Guide.
Terminology: MDR, Medical Device & CE
In the context of this article, the term “medical device” is defined by the definition in the Medical Device Regulation (MDR). In a nutshell: a medical device is a product with a medical purpose. In order for medical devices to be placed on the European market or put into operation, they must be provided with a CE marking. An app as a medical device is often also called a medical app or medical software. 
In this article, we examine the entire process of medical device approval (and thus CE marking): Approval certification of software medical devices (MDR)
Motivation: App as a medical device
Usually, it all starts with the idea of developing an app or software to be used in the health/medical sector. The second step is to determine whether or not your planned product is a medical device. As a software service provider, we specialize in the development of medical apps and are therefore very familiar with the issues involved. This evaluation has a significant impact on the future of your product. Depending on whether you bring your app to market as a medical device, many circumstances 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 a basic requirement for inclusion in the DiGA directory under the DVG and thus for reimbursement.
- sets its own application apart from the competition, most of which will not be classified 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 own app is a medical device is only indirectly yours. A given product with a defined purpose and functionality either falls under the definition of a medical device or not. That depends on the MDR legal text. So you have to comply with that. Otherwise, you are not acting legally (more on this below). 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 had originally intended to develop an app to support the therapy of rehabilitation patients, you could instead develop a fitness app (which does not specifically target patients and does not include therapy as an intended purpose). Read more in our article on phrasing the intended purpose. In the past, companies often tried to define their software/app as something that was not a medical device. The effort, costs and necessary know-how were simply too high an entry barrier. However, the situation has changed for many due to the Digital Care Act (DVG) and the DiGAV. In order to have a DiGA (digital health application) reimbursed by the statutory health insurance funds under the DVG, this app/software must be classified as a medical device (of a low or higher risk class). As a result, more and more companies are asking themselves: “How do I ensure that my DiGA can be approved as a medical device?” You can only legitimately classify your DiGA as a medical device in Europe if it falls within the definition of a medical device under the MDR (or MDD, prior to 05/26/2021).
Focus of the article: MDR
In this article, we will focus on the European market and take a closer look at the Medical Device Regulation (MDR). Since certification as a medical device according to the Medical Device Directive (MDD) is no longer possible after 05/26/2021, we will not discuss this further here. Incidentally, there is extensive overlap between the MDR and the MDD when it comes to the definition of a medical device. In this article, we also specifically consider stand-alone software as a medical device. In particular, this includes mobile apps. We will not discuss hardware (such as pacemakers) in more detail.
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 single 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 any instrument, apparatus, appliance, software, implant, reagent, material or other article intended by the manufacturer to be used for human purposes and which 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 by the in vitro examination of samples derived from the human body, including organ, blood and tissue donations, and whose principal intended action in or on the human body is not achieved by pharmacological or immunological means or metabolically, but whose mode of action may be supported 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 for qualification (deciding whether your product is a medical device), it is the intended purpose that counts. The functionality of your app/software is not relevant or has only indirect influence on the purpose. If the intended purpose of your app is, for example, the therapy, diagnosis or prevention of diseases, it must be classified as a medical device. The MDR defines the intended purpose as follows:
“Intended purpose” means the use for which a device is intended according to the data supplied by the manufacturer on the labeling, in the instructions for use or in promotional or sales material or advertising or sales information and its clinical evaluation data;
This also makes it clear that the defined purpose of your product must also be communicated in this way, for example, on all marketing/sales channels. You cannot market your medical device under a different intended purpose than you have stated in the declaration of conformity. If you need help formulating the intended purpose, you can find more information in this article: Phrasing the intended purpose for (software) medical devices. Let’s take the example of a diabetes app. If your app’s intended purpose is “to document glucose levels”, it is not a medical device. It is not used for the therapy, prevention, diagnosis, etc. of diseases. It is purely a documentation tool without a direct medical purpose. However, if your application evaluates the documented values and provides advice on this basis (“You should eat something”), “therapy recommendations” are given. The app thus has the purpose of “treating diabetes”, for example. It is a medical device. The fact that the intended purpose is the main focus is also made clear again in the preface (19) of 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 thus not for specific applications in the medical field, are not medical devices. For example, Microsoft Excel is not a medical device because it is intended for use in any number of applications. Of course, Excel can also be used to calculate certain key figures that could be used to diagnose an illness, for example. However, this is not the intended use of Excel. By contrast, an app/software that is specifically designed to calculate key figures for the diagnosis of a specific disease 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 from the above, a single article of the MDR decides 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, it is more of a disadvantage: the definition is very brief and therefore very vague. To decide on specific cases, a little more background knowledge and guidance is needed. Therefore, there are documents that try to explain the facts better with specific examples. Probably the most important guidance document in the context of the MDR comes from the MDCG (Medical Device Coordination Group) and is titled “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 guidance documents from the MDCG).
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
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 an accessory for a medical device. The MDR defines this as follows:
“Accessory to a medical device” means an article which, while not being in itself a medical device, is intended by the manufacturer to be used together with one or more specified medical devices and which specifically enables their intended purpose(s) […]
The controlling software is therefore itself also a medical device.
2. Standalone medical device
If your software/app independently has its own medical purpose, it is a standalone medical device. For example, an app that provides therapy recommendations based on certain input values is a standalone medical device. The majority of DiGA will fall into this category.
3. Part of a medical device
Certain software is an integral part of the medical device. Therefore, the software does not have to be reclassified on its own. This includes, in particular, 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 discuss in detail here.
Frequent uncertainties
When evaluating whether a medical device is present, there are some typical ambiguities. We will resolve some of these here:
Communication data storage
A chat or video call solution is generally not a medical device. The purpose is purely for communication. This also applies, for example, to pure data storage/documentation. The MDCG Guidance is very clear on this: “Storage, archival, communication simple search is not medical product”.
Influence of the operating system, runtime environment and “location” of the software
Whether your software runs on a remote server, on a smartphone, on Android or Windows, none of this has any influence on the decision as to whether it is a medical device. As described above: the intended purpose is what counts. Possible patient risk:
The risk of your app/software causing harm to a patient is not relevant. The probability and severity of possible medical harm have no influence on whether your app is a medical device. The following line of argument is not helpful: “Our app can only cause very minor harm. Therefore, it should not be a medical device.” However, if the purpose is to treat an illness, then we are still talking about 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 the doctor or patient. In the end, the doctor or patient still decides how to proceed. Therefore, it should not be a medical device? This argument is also not helpful. If your app gives therapy recommendations, the medical purpose is the “therapy of a disease” and thus a medical device. And that’s the right way to be: a doctor who is overworked or a patient who is tired tends to trust his software tool more and more. Certain recommendations may no longer be questioned, and potentially wrong decisions with serious consequences could be made. So, to the extent that they are intended for the treatment of diabetes, the following products are also medical devices: a physical insulin pump, an app for controlling an insulin pump, or even just an app that provides specific dose recommendations for injecting insulin.
Software user: patient, doctor or layperson
Just because your app is not used by a doctor or patient does not mean that it is not a medical device. For example, a mother could help her child with limited mobility to manage an illness. To do this, the mother might use software. However, she has no medical training and is not a patient herself. Nevertheless, the purpose is therapy. This means there is a risk that the therapy will be carried out incorrectly, and so the application is morally a medical device.
Comparison with other apps on the market
Another favorite argument is to compare with other apps on the market: “App XY is in the App Store, has the same functionality as our app and is not a medical device.” Why do we have to be a medical device then?” Comparing your app to other apps also doesn’t help here. There are many apps on the market that should actually be classified as medical devices, but aren’t. However, this doesn’t allow any conclusions to be drawn about your own app. Often, the manufacturers of such apps have acted out of pure ignorance. In the event of a lawsuit/cease and desist letter, however, they are vulnerable. 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 this, you can consult the BfArM, consultants, lawyers or even notified bodies. However, the final decision remains with you. In the event of a lawsuit, your decision will be reviewed by the court. If, for example, you have mistakenly not marketed your software as a medical device, you will bear the consequences. A review by a judge can be triggered, for example, by a case of damage. A patient or the competition could sue you or send a warning letter. So if you are unsure, it is worthwhile to obtain an assessment or an 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, for example, a lawyer would still have to defend you in court based on this expert opinion. However, there is a good chance that you will win the case if your attorney has done a diligent job.
Current market situation: reimbursement of DiGA
The number of apps that have made it onto the market as a medical device is still manageable. On the one hand, this is due to the effort involved in developing an app as a medical device. On the other hand, it has been difficult to build a functioning business model with the finished app/software. The DVG at least makes it easier to build a business model by allowing certain software or DiGA to be reimbursed by health insurance companies in a standardized way. The reimbursement of digital care applications (DiPA) has also been legally anchored in the meantime. In contrast to DiGA, DiPAs are not necessarily defined as medical devices. You can find out more about this in this article. Within the framework of the DVG, the Spitzenverband Digitale Gesundheitsversorgung has already published a list of members submitting digital health applications in advance. Based on the requirements of the DiGAV, these are therefore all medical devices. This gives a good impression of which applications will be available on the market with the CE mark in the future.
Conclusion
It is not always easy to decide whether your app/software is a medical device. The definition of the MDR is very vague. The MDCG Guidance tries to provide a better understanding with illustrative examples. However, if in doubt, it is always advisable to ask for a third opinion. If you also want to know whether your app qualifies not only as a medical device, but also in which risk class it falls, it is worth taking a look at our article “Classification of software medical devices: MDR guide”. Some apps may even qualify as DiGA. Find out more in our article “Is your app a DiGA?” We develop medical apps and medical software for our customers on a contract basis. Therefore, we are regularly confronted with the issues discussed. For a free initial assessment of whether your app/software is a medical device, please feel free to contact us at any time.
