Is your app a DiGA? Definition of digital heath 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 criteria

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…

We will discuss each of these criteria below.

Criterion #1: Medical device in a lower or higher risk class

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 or higher risk class (I, IIa or IIb). 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. A detailed guideline for determining the risk class can be found here: Classification of software medical devices: MDR guideline. If you need an assessment of whether your app/software is a medical device and, if so, which risk class, please feel free to contact us at any time for a free consultation.

Criterion #2: Digital technologies

Your product must, by definition, 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 “Formulation of 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 guideline puts it this way:

A prerequisite is that a risk factor is present in the sense of an illness 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:

Safety and functionality requirements
Data protection and data security requirements
Quality and interoperability requirements
Robustness requirements
Consumer protection requirements
User-friendliness requirements
Requirements for the support of service providers
Requirements for the quality of medical content
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. The Digital Care and Nursing Modernization Act also provides an interesting distinction from the digital care application (DiPA). 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 to calculate the potential sales in your chosen therapeutic 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”.

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