Is your app a DiGA? Definition & criteria of digital health applications

So-called DiGA (digital health applications) can be reimbursed by statutory health insurance companies. This became possible for the first time when the Digital Supply Act (DVG) came into force on December 19, 2019. However, not every health app or medical app meets the definition of a DiGA and is therefore eligible for reimbursement. In this article, we explain in detail which criteria your app must fulfill in order to be considered a DiGA.

Overview of DiGA definition

The official DiGA guidelines of the BfArM concisely summarize the definition and criteria of DiGA. For your product to be potentially eligible for reimbursement as a DiGA, it must…

1. …be a medical device of risk class I or class IIa.
2. …be based primarily on digital technologies.
3. …not only be used to control a device
4. …support the detection, monitoring, treatment, alleviation and compensation of illnesses and injuries.
5. …not only serve the purpose of (primary) prevention.
6. …be used by the patient.

We will discuss each of these criteria below.

Criterion #1: Low-risk class medical device

Of course, not every health app is a medical device. For example, an app whose purpose is purely to document medical data is not a medical device and therefore not a DiGA. If your app collects blood pressure values but does not evaluate them for the diagnosis or treatment of diseases, it is not a medical device. You can find more information in our article on “Is your app a medical device?”.

Is your app a medical device? Great! However, it is still unclear whether it is also a medical device in a low risk class (I or IIa).

Rule 11 of the MDR is particularly relevant for determining the risk class:

Software intended to provide information that is used to make decisions for diagnostic or therapeutic purposes is in class IIa, unless these decisions have an impact that may cause the following:

• the death or irreversible deterioration of a person’s state of health, in which case they are assigned to Class III, or
• a serious deterioration in a person’s state of health or a surgical intervention; in this case, it is assigned to class IIb.

Software intended for the control of physiological processes is in Class IIa, unless it is intended for the control of vital physiological parameters, in which case the nature of the change in these parameters could lead to immediate danger to the patient, in which case it is in Class IIb. All other software is assigned to Class I.

In addition to the legal text of the MDR, our practical guide and the MDCG Guidance Document will also help you to classify your software correctly.

If you need an assessment of whether your app/software is a medical device, and if so, which risk class, please contact us at any time for a free consultation.

Criterion #2: Digital technologies

By definition, your product must be based primarily on digital technologies. Your app/software probably fulfills this criterion naturally. It excludes the possibility that, for example, a blood pressure monitor itself is a DiGA. Hardware is not a DiGA. In other words, you could also say that it must be independent software (so-called standalone software). This is the case with apps and web applications.

Criterion #3: More than one device control

Your app must fulfill the medical purpose essentially through the main digital function. If your app only serves to control a medical device – and therefore does not provide the essential medical purpose itself – it is not a DiGA. Although a DiGA can communicate with medical devices and read out sensor data, for example, this must not be the main purpose.

If your app reads external sensor data from a medical device and makes a diagnosis or gives treatment recommendations on this basis, this criterion is met. The essential purpose in this case is diagnosis or therapy improvement, and the purpose is fulfilled by a digital algorithm in your app/software.

You can find more information on the intended purpose in our article “Formulating the intended purpose for (software) medical devices”

Criterion #4: Diagnosis or treatment of illness or injury

A DiGA is defined in the DVG legal text as an application that supports the “detection, monitoring, treatment or alleviation of diseases or the detection, treatment, alleviation or compensation of injuries or disabilities”. This means that, for example, contraceptive apps, cycle tracking apps or pure (primary) prevention apps (criterion #5) are not DiGA. An application that supports patients with diagnosed visual impairment with digital visual exercises during therapy, for example, fulfills this criterion and could therefore also be a DiGA.

Criterion #5: No pure (primary) prevention

The DiGA guidelines formulate it as follows:

The prerequisite is that there is a risk factor in the sense of a disease that can be coded as a diagnosis.

An app that helps a healthy person to prevent illness is not a DiGA. (Primary) prevention apps are also potentially medical devices, but not yet DiGAs. This is because a DiGA is prescribed by a doctor in the case of a disease diagnosis, for example, and is therefore always aimed at people with a specific indication (ICD-10 code).

Criterion #6: The user is the patient

An app that primarily supports doctors in their daily work is not a DiGA. A DiGA must be intended for use by the patient. The app can certainly involve the doctor as long as the patient remains the main user.

The requirements for meeting the criteria

Of course, your app will not automatically be included in the DiGA directory and reimbursed if these criteria are met. If you basically meet each of these criteria, the next step is to look at the requirements for DiGA. These requirements are regulated by the Digital Health Applications Ordinance (DiGAV). These include the “requirements for safety, functionality, data protection and security as well as the quality of digital health applications”. In summary, this point includes the following requirements:

1. Safety and functionality requirements
2. Data protection and data security requirements
3. Quality and interoperability requirements
4. Robustness requirements
5. Consumer protection requirements
6. Requirements for user-friendliness
7. Requirements for the support of service providers
8. Requirements for the quality of medical content
9. Patient safety requirements

Your medical app must already meet many of these requirements as a medical device (according to MDR or MDD). You can also find more information in our guide to the DiGAV. You can find out how to develop an app/software as a medical device in our guide to developing medical apps. The DiGAV also contains a specific questionnaire that deals with all these requirements in detail. Within your application for inclusion in the DiGA directory, you must answer each point of this questionnaire. This can be found in Annex 1 and Annex 2 of the DiGAV. You must also demonstrate a positive supply effect with your DiGA. According to the DVG, a positive care effect is either a medical benefit or patient-relevant structural and procedural improvements in care. You must prove this positive supply effect in scientific studies. If you do not have such studies available at the time of application, you must at least submit a scientific evaluation concept with which you would like to demonstrate the effects of care at a later date. In future, data security and data protection certificates for DiGA will also be required.

Conclusion

Whether your app is potentially a DiGA is defined by the criteria mentioned. However, it is not always immediately clear whether your app is a medical device, for example, and if so, under which risk class it must be classified. If you need assistance with this evaluation, please contact us for a free consultation. As soon as the Digital Care and Nursing Modernization Act comes into force, a differentiation from the digital care application (DiPA) will also become interesting. We take a closer look at DiPA in this article. The most complex part of developing a DiGA, apart from the software development itself, is certainly meeting the additional quality management requirements within the regulatory framework of a medical device. This area is usually uncharted territory for start-ups in particular. First and foremost, you should draw up a reasonable sales and cost forecast for your DiGA project in advance. In this article, we will show you how you can calculate the potential turnover in your selected indication area (including an Excel template for the calculation).

To get an overview of exactly what you need to consider when developing apps as medical devices, read our article on “Medical app development”.