Is your app a DiGA? Definition & Criteria

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.

1. Overview of DiGA Criteria
2. Requirements for Fulfilling the Criteria
3. Selective Contracts – an Alternative to DiGA
4. Conclusion

1. 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.

1.1 Criterion #1: Medical Device with 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 guide to 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 contact us at any time for a free consultation.

1.2 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.

1.3 Criterion #3: More than just 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”

1.4 Criterion #4: Diagnosis or Treatment of Diseases or Injuries

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.

1.5 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 healthy people prevent disease 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).

1.6 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.

2. Requirements for Fulfilling 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.

3. Selective Contracts – an Alternative to DiGA

If your digital solution does not qualify as a DiGA, there is also the option in Germany of concluding selective contracts with individual health insurance companies. This provides you with a route to reimbursement that is tailored to your application.

In our guide to selective contracts, we provide an overview of this alternative form of cost reimbursement: To the guide – Selective contracts for digital solutions

Even beyond selective contracts and DiGA, there are other ways to obtain reimbursement for software products:

Overview of all paths to reimbursement: Read our white paper
Reimbursement for software in the GKV medical aids directory (HMV): See our guide
Digital care applications – DiPA procedure: To our guide
Central Prevention Review Board (ZPP): About our guidelines

In addition to the aforementioned reimbursement options, it is also worth looking into public funding opportunities that can bridge the gap. First and foremost, it is worth taking a look at the G-BA’s Innovation Fund, which provides financial support for digital healthcare solutions in their early stages.

You can find more information in our guide to the Innovation Fund: Go to guide

4. Conclusion

The criteria mentioned above determine whether your app is potentially a DiGA. However, it is not always immediately clear whether your app is, for example, a medical device 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. In addition to the software development itself, the most complex part of developing a DiGA is certainly meeting the additional quality management requirements within the regulatory framework for medical devices. This area is mostly uncharted territory, especially for start-ups.

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

Table of contents