Part 1 of this blog series: The app on prescription – what is it and which idea is DiGA compliant?
Have you ever tried to reach a medical practice several times or been put on hold only to be told that the practice is no longer taking patients? There must be another way. After all, not every treatment needs to involve going to the doctor. And indeed, thanks to the digital offensive in the healthcare sector, the app is gaining ground as another form of healthcare. The Digital Care Act (Digitale-Versorgung-Gesetz) is a legal milestone in this development. It makes the app available on prescription. The Federal Institute for Drugs and Medical Devices (BfArM) will include reimbursable health apps in a directory for DiGA after a review process, e.g. in the so-called fast-track procedure. Doctors can prescribe so-called DiGA. However, health insurance companies can also approve a reimbursable health app for their insureds without a doctor’s prescription.
In this blog series, we will explain the privacy requirements that a health application must meet to be included in the directory of digital health applications. In the first part of the series, we will explain what a DiGA is and what it is not, and provide a brief overview of the privacy requirements, which we will cover in more detail in the second and third parts of the blog series.
Which health apps are DiGA-compatible?
You have an idea for a health application and wonder if your idea is suitable for a DiGA.
DiGAs are CE-marked, low-risk digital medical devices that can help patients detect, monitor, treat or alleviate diseases or compensate for disabilities. A scale that measures the patient’s weight and estimates the body fat percentage is not a DiGA. For example, DiGA is an app that helps migraine sufferers keep a symptom diary, integrates weather data, warns when there is a high probability of migraines, and provides guidance on preventive behavior and small acute treatment techniques. However, DiGA is not a scale for measuring body weight and estimating body fat percentage. The app documents the values, displays them graphically and provides additional information on nutrition and fitness for healthy people. The app is intended for healthy people and is therefore classified as primary prevention. The app is not intended for the “detection, monitoring, treatment, or mitigation of disease.
Previously, medical devices in risk classes I and II a were DiGA compliant. With the law for the acceleration of the digitalization of the health system (Digital Law – Digital-Gesetz (DiGi)) from February 2024, the risk class II b was added. While the so-called fast-track procedure at the BfArM for inclusion in the DiGA directory is provided for medical devices in risk classes I and II a, this option is denied to manufacturers of DiGA for risk class II b. The fast-track procedure allows provisional inclusion in the DiGA directory. Positive effects on health care can be demonstrated in the trial phase. The positive effect on health care must be proven to the BfArM at the time of application for DiGAs that are class II b medical devices.
The core function of DiGA is based on digital technologies. The medical purpose must essentially be achieved by the digital core function of the DiGA. Digital applications that only serve to read out or control a device, for example, are not a DiGA. An app that is a digital communication platform for coordinating and conducting video/phone/chat conversations with a psychotherapist for patients in psychologically stressful situations cannot be included in the DiGA directory. This is due to the fact that the main function of the application is the digitalization of the communication channel. Other, e.g. therapeutic services are missing for a DiGA. However, if the app offers patients with a mild depressive episode a digital care model that provides information about the illness, records and documents moods, records symptoms, supports the creation of personal content such as diaries, provides instructions for relaxation exercises, and enables contact with a chatbot, it is DiGA-compliant.
DiGA are “digital assistants” in the hands of patients. Applications that are used exclusively by healthcare professionals to treat patients (“practice equipment”) are also not DiGA. A DiGA must therefore be “used” by the patient alone or together with the doctor.
In principle, a DiGA can be a native application as well as a desktop or browser application. A DiGA is therefore also a web application that supports patients with functional low vision by offering treatment with digitally supported visual exercises in a virtual visual school.
In addition to software, a DiGA may include devices, sensors, or other hardware, such as wearables, as long as the primary function is predominantly digital, the hardware is necessary to achieve the purpose of the DiGA, and the hardware is not a privately financed everyday object, such as a gym mat or a smartphone for performing the exercises guided by the DiGA. For example, a DiGA is also an app that reminds patients to take their pain medication and suggests a dosage based on their current condition. It allows the patient to receive a reminder to take the necessary medication via a smartwatch as optional hardware and to confirm this directly. The use of optional hardware does not remove the functionality of DiGA. However, no DiGA is a platform application that allows the use of multiple DiGAs on a smartwatch. It is possible to enter data, read results and receive reminders. However, the digital services are primarily provided by the other DiGAs. As a pure platform function, the app alone is not a medical device.
Practical tip: The DiGA directory can be found at the following link: https://diga.bfarm.de/de/verzeichnis. It is certainly interesting to see which DiGAs have already been added to the directory.
Excursus: What is a Digital nursing application (DiPA)? Besides the DiGA there is also the DiPA. DiPA must also be included in a directory for digital nursing applications after a successful review by the BfArM, so that the DiPA manufacturer receives reimbursement for the use of his DiPA from the nursing care insurance. In contrast to the DiGA, the DiPA can be a medical device, but does not have to be. In contrast to the DiGA, the DiPA is used for care purposes and, like the DiGA, this is achieved by the digital application itself. The goal of DiPA is to reduce the impairment of the independence or abilities of the person in need of care or to prevent the need for care from worsening. Further information about DiPA can be found in the DiPA guidelines of the BfArM at https://www.bfarm.de/SharedDocs/Downloads/EN/MedicalDevices/DiGA_Guide.pdf?__blob=publicationFile. Spoilers: The privacy requirements for DiPA are almost identical to those for DiGA. So if you want to develop and market a DiPA, it is worth reading on.
What are the requirements for a DiGA?
If you have determined that your idea is suitable for a DiGA, your digital application must meet the requirements defined in §§ 3 to 6 of the Ordinance on Digital Health Applications (DiGAV) with regard to
- security and functionality
- data protection and data security, and
- quality, especially interoperability.
Proof of this must be submitted to the BfArM.
Practical tip: The BfArM’s DiGA guide contains many examples of what a DiGA is and what it is not. It also contains details of all requirements and explains the fast-track procedure. The guideline is available at the following link: https://www.bfarm.de/SharedDocs/Downloads/EN/MedicalDevices/DiGA_Guide.pdf?__blob=publicationFile.
What are the privacy criteria for a DiGA?
In the following, we would like to give you a first overview of the most important criteria that a DiGA must fulfill from a data protection perspective.
Practical tip: You can find a comprehensive overview in the data protection criteria of the BfArM (available at: https://www.bfarm.de/DE/Medizinprodukte/Aufgaben/DiGA-und-DiPA/Datenschutzkriterien/_node.html) (hereinafter also referred to as “BfArM data protection criteria”). The BfArM data protection criteria also apply to DiPA.
The BfArM data protection criteria essentially reflect the principles of the GDPR and are based on the standard data protection model. Article 5 of the GDPR sets out key principles for the processing of personal data: processing must be lawful, fair, transparent, purposeful, limited to what is necessary, based on accurate data, and respect integrity and confidentiality. In addition, personal data may only be kept for as long as necessary in a form that allows the identification of the data subjects. Adherence to the principles must be verifiable (“accountability”). The standard data protection model fulfills these legal requirements by translating the guarantee objectives into technical and organizational measures.
Practical tip: You want to learn more about the standard data protection model. You can find the current version at https://www.datenschutz-mv.de/datenschutz/datenschutzmodell/.
The DiGAV specifies the obligations arising from the GDPR and, in some cases, tightens them. The BfArM data protection criteria contain statements on the following principles and guarantee objectives:
- Lawfullness (Part 2 Section 2 of the BfArM data protection criteria)
- Processing in fairness and good faith (Part 2 Section 3 of the BfArM data protection criteria)
- Transparency (Part 2 Section 4 of the BfArM data protection criteria)
- Non-linkability (Part 2 Section 5 of the BfArM data protection criteria)
- Data minimization and storage limitation (Teil 2 Section 6 of the BfArM data protection criteria)
- Intervenability (Part 2 Section 7 of the BfArM data protection criteria)
- Integrity, accuracy and confidentiality (Part 2 Section 8 of the BfArM data protection criteria)
- Accountability (Part 2 Section 9 of the BfArM data protection criteria)
We will take a closer look at the BfArM’s data protection criteria in the second part of this blog series. This much can already be revealed: The privacy requirements for DiGA are high, in part because of the need to protect the health data stored in a DiGA. The Ordinance on Digital Health Applications (DiGAV) imposes additional requirements. These include, for example, that processing may only be carried out for a few purposes specified in the DiGAV and that most personal data may only be processed with the consent of the user. In the case of a DiGA, it must also be ensured that the DiGA user cannot be identified. Experience has shown that this is a challenge for DiGA manufacturers. In the second part of the blog series we will present some solutions.
Conclusion
If your idea is suitable for a DiGA and our first overview of the BfArM’s data protection criteria doesn’t deter you, you should definitely read parts 2 and 3 of our blog series and learn more about the data protection criteria a DiGA must fulfill. If you are deterred by the high requirements or your idea is not a DiGA, you have the option to develop a “normal” health app. This would have to meet the same privacy requirements as a DiGA, but without the additional requirements in particular of the DiGAV. In the case of a health app, personal data not related to health may also be processed, e.g. to fulfill the existing user contract with the user or for legitimate interests.
Do you have any questions? We are happy to support you in all IT and data protection questions regarding DiGA, to find out with you whether your app idea is DiGA-compatible and to help you with the inclusion in the DiGA directory.
Please contact us. We are looking forward to hearing from you!
