App on Prescription – Digital Health Applications (DiGA)

What was unthinkable not too long ago is now becoming a reality: telemedicine and digital health applications in Germany. These DiGAs are apps that patients can install on their smartphones, and their costs are covered by standard care, i.e., by statutory health insurance funds.

Since these apps are low-risk medical devices (Class I or Class IIa), they undergo the usual approval procedures. As medical devices, they can support the detection, monitoring, treatment, or alleviation of diseases; or the detection, treatment, alleviation, or compensation of injuries or disabilities. However, these DiGAs offer an additional important aspect: they allow patients to manage their health more responsibly and independently. They offer patients the opportunity to take greater control of their health.

Digital health applications can conveniently have a positive impact on their users. Therapies can be monitored more easily, and patients can be reminded of and trained in necessary behavioral rules for their therapy. These are just a few of many possible application scenarios for these applications.

In recent months, the term “App on Prescription” has frequently been in the media. Doctors and psychotherapists can prescribe certain apps that are paid for by statutory health insurance funds. The prerequisite for this, however, is that the respective digital health application has been reviewed by the BfArM and is included in the DiGA directory according to § 139e SGB V. Only apps listed therein can be prescribed as an App on Prescription.

Requirements for an App on Prescription

Step 1: Approval as a Medical Device

All DiGAs are medical devices of Class I or IIa. Accordingly, the apps must also be approved as such. For Class I products, this does not require a notified body. Manufacturers generate the necessary evidence and independently issue a declaration of conformity. However, a notified body is involved for a Class IIa product. This body is then involved in the conformity assessment procedure and acts as the corresponding testing body in the approval process.

Step 2: Application to the BfArM: Fast-Track

After the app is approved as a medical device, the manufacturer submits an application to the BfArM. Via the fast-track, the app can be included in the DiGA directory. The processing time by the BfArM is 3 months.

The review specifically concerns the examination of the product properties declared by the manufacturer. Aspects of data protection, user-friendliness, and proof of positive care effects are naturally part of this.

Proof of positive care effects is often difficult to provide for a newly developed app. However, there is a solution: Provisional inclusion in the directory is possible if all other requirements are met. For this, the manufacturer must submit an application for provisional inclusion and then conduct a comparative study within a one-year trial phase. Exceptions are possible, in which the trial can extend over two years.

Step 3: Inclusion in the DiGA Directory

You can be included in the DiGA directory if

  • The BfArM has decided that positive care effects have been successfully demonstrated
  • The BfArM has approved your application for provisional inclusion

What are Positive Care Effects?

Medical benefit and patient-relevant structural and procedural improvements are valid endpoints regarding positive care effects. Depending on what your application is intended for, you must demonstrate the corresponding endpoints.

Medical benefit exists in the following cases:

  • improvement of health status,
  • shortening of illness duration,
  • prolongation of survival, or
  • an improvement in quality of life.

But what are patient-relevant structural and procedural improvements? This term refers to improvements related to the following points:

Focus on the detection, monitoring, treatment, or alleviation of diseases or the detection, treatment, alleviation, or compensation of injuries or disabilities AND

aimed at supporting the health actions of patients or integrating processes between patients and service providers AND

especially include the areas of

  1. coordination of treatment processes,
  2. alignment of treatment with guidelines and recognized standards,
  3. adherence,
  4. facilitation of access to care,
  5. patient safety,
  6. health literacy,
  7. patient sovereignty,
  8. coping with illness-related difficulties in everyday life, or
  9. reduction of therapy-related efforts and burdens for patients and their relatives.

Example: A digital health application that helps a patient fulfill their required therapy contributions increases adherence. Thus, the application supports the patient in their active role in therapy.

Proof of Positive Care Effects

The BfArM clearly describes which studies are permissible for generating data to sufficiently prove positive care effects. These include, among others, the following:

  • Observational analytical studies (e.g., case studies, control studies, cohort studies)
  • Experimental intervention studies (e.g., non-randomized or randomized controlled studies)
  • Meta-analyses evaluating own primary data

Combination with Hardware and Services

According to the BfArM, digital health applications can be native apps, desktop applications, or browser applications. There is even the possibility that the applications may also include hardware such as devices and sensors.

In projects, we have been asked multiple times whether additional services that are unrelated to the app itself may also be offered via the apps. The Federal Institute for Drugs and Medical Devices has published a paragraph on this in the DiGA Guideline, describing this as permissible. Accordingly, services such as coaching may be offered via the application. However, cost coverage by the health insurance fund is not possible for such services. It is recommended to clarify such offers with the BfArM.

For all additional functions that do not contribute to the positive care effect of the application, it must be noted that these additional functions must not influence the medical purpose.

Requirements for a Digital Health Application

Every DiGA must meet the following requirements and demonstrate this to the BfArM accordingly:

  • Safety and Functional Suitability
  • Data Protection and Information Security
  • Quality, especially Interoperability

Manufacturer’s Obligations after Inclusion in the DiGA Directory

  • Assessment of changes to the application regarding their influence on § 18 DiGAV. If applicable, notification of the change to the BfArM.
  • Ensuring the up-to-dateness and completeness of information within the directory (changes are made by application of the manufacturer to the BfArM).
  • Maintenance of information and distribution platforms linked in the directory (including link to instructions for use)
  • Maintenance and Improvement of Data Protection and Information Security
  • Management of Changes
  • Deletion and Blocking of Data No Longer Required
  • Maintenance of Directories of Used Third-Party Software
  • Detection of Security-Relevant Events and Proactive Prevention Thereof
  • If applicable, consideration of requirements from the General Data Protection Regulation

Costs

Consultations by the BfArM are divided into categories I to IV.

  • Consultation Category I: €250
  • Consultation Category II: €1,000
  • Consultation Category III: €2,000
  • Consultation Category IV: €5,000
  • Application for final inclusion in the DiGA directory:
    €3,000 – €9,900
  • Application for provisional inclusion in the DiGA directory:
    €3,000 – €9,900
  • Review of proof of positive care effects upon provisional inclusion:
    €1,500 – €6,600
  • Application for extension of the trial period:
    €1,500 – €4,900
  • Notification of significant changes:
    €1,500 – €4,900
  • Notification of the necessity of changes to the DiGA directory:
    €300 – €1,000
  • Deletion of a DiGA from the DiGA directory:
    €200