With the publication of the draft bill for the Digital Health Applications Ordinance (DiGAV), the German Federal Ministry of Health gave the go-ahead for the so-called “apps on prescription” in April 2020.
1. Overview: Digital Health Applications
The Digital Health Applications were made possible by the Digital Health Care Act (DVG), which came into force on December 19, 2019. For the first time, insured persons in the statutory health insurance system are entitled to be provided with DiGA, which can be prescribed by doctors and psychotherapists and are reimbursed by the health insurance fund. The aim is to support a path to a self-determined, health-promoting lifestyle. In this context, the DiGAs support the detection, monitoring, treatment, or alleviation of diseases as well as the detection, treatment, alleviation or compensation of injuries or disabilities.
The basis for approval as a Digital Health Application is that medical purpose as the main function is based on digital technologies.
2. Demarcation – Digital Health Applications
2.1 When is an app a medical advice?
The app stores on our smartphones and tablets offer a wealth of applications in the sports, wellness and health sectors. Here, of course, the distinction from a medical device is not so simple. The decisive factor for classification is the purpose of the app, which is also conveyed via the instructions for use and advertising materials (e.g. website, app store information). Indications that point to a medical device are, for example, decision support for therapeutic measures, calculation of medication dosages or monitoring of a patient and data collection in connection with therapy instructions.
2.2 Demarcation to hardware
Digital Health Applications are also possible in combination with hardware. However, it should be noted here that the main function is based on the digital technology. And the app is not only used as a connecting point for the functions of the hardware. The examples from the BfArM’s guide to Digital Health Applications show this very clearly here:
2.3 Demarcation to services
In the case of services in connection with DiGA, these must be viewed in a differentiated manner. When combining services such as consulting, coaching or private medical services in connection with DiGA, the situation is similar to that with additional hardware. The focus must be on digital technology. Services provided by contract physicians, for example by the attending physician, will continue to be paid for by the statutory health insurance funds as part of the physician’s remuneration. However, these may have to be taken into account when proving the positive supply effect, as the supply effect must be clearly attributable to the DiGA. In general, only physicians in private practice or psychotherapists are eligible for services provided by SHI-accredited physicians.
Here, too, we have looked at an example from the BfArM’s guide to Digital Health Applications:
Finally, we can state that additional functions and services must not have any influence on the medical purpose of the DiGA and must not impair or change its positive effects on care. A clear demarcation is important, which should correspond to the guidelines of the BfArM. If you have any questions here, the BfArM guidelines are often a good point of reference or, of course, you are welcome to contact us without obligation.
3. Qualitative requirements for Digital Health Applications
3.1 Definition of a DiGA
The basis for the successful application procedure for the listing of a DiGA in the BfArM directory is the fulfillment of the requirements described in paragraphs 3 to 7 from the DiGAV with regard to safety, functional capability, data protection, information security as well as quality (in particular interoperability). For this purpose, the answering of the questionnaires Annex 1 and Annex 2 of the DIGAV is required. In the following, we would like to briefly describe the 4 most comprehensive points to give you an overview.
3.2 Security and functional capability
According to SGB V, distributors of DiGAs must prove the product safety and functional capability of their DiGA. For this purpose, the CE mark is used as the manufacturer’s declaration of conformity. Through this, the manufacturer confirms compliance with the quality and safety requirements via a “notified body” such as the “TÜV”.
Since the DiGA is a medical device, certification must take place here. In general, medical devices are divided into classes I, IIa, IIb and III according to the Medical Device Directive (MDD) and also according to the new Medical Device Regulation (MDR). Class I requires the CE mark as well as an EU declaration of conformity according to Article 19 MDR. In this you declare the conformity of your products. Since there are also liability risks here, you should go through the process conscientiously and consult external help if necessary.
As a manufacturer for DiGAs, you should keep an eye on the certification. According to MDR, a DiGA to be certified should at least fall into class IIa MDR, which requires the involvement of a notified body. Apps of higher risk classes (IIB MDR and higher) in turn cannot seek a DiGA listing.
3.3 Data protection of a DiGA
Data protection is naturally a very high priority for DiGAs. In the GDPR, patient data as sensitive data has a very high level of protection. As a developer and manufacturer of a DiGA, you should pay very close attention to the correct processing of the data right from the start.
Since the data protection requirements must already be met when the application is submitted, you should take a very close look at the questionnaire in Annex 1 DiGAV. The facts are queried there in detail, and the appendix thus serves you as a guideline and test catalog. Due to the cancellation of the Privacy Shield agreement, the storage of personal data and use of tools and providers in the USA is currently very controversial and may be a hurdle for you in the further application process.
The Fast Track Guide for Digital Health Applications also addresses this issue. You should therefore already take this into account at the beginning of the programming of your DiGA and keep it in mind on an ongoing basis.
3.4 Information security
To further protect health data, there are also continuing information security requirements. Here, the focus is on protecting the confidentiality, integrity and availability of all data processed via a DiGA. According to the DiGAV, there is a distinction here between the basic requirements for all Digital Health Applications and the additional requirements for Digital Health Applications with very high protection requirements. This is based on the processes for an information security management system described in BSI Standards 200-1, 200-2 and 200-3 for an information security management system.
An information security management system (ISMS) determines the tools and methods that management can use to plan and implement information security tasks and activities, and activities related to information security in a traceable manner. A complete ISMS is only required for DiGAs that apply for inclusion in the DiGA directory after Jan. 1, 2022. You can use the ISMS to map a required basis of the MDR certification and also design your medical device to be future proof now.
3.5 Interoperability
Interoperability is the ability of technical programs or systems to work with other systems without restrictions on access or implementation. This will become increasingly important for DiGAs in the future so that a national e-health infrastructure can be established. An illustrative example of this is the use of the Health Insurance Number (KVNR) instead of a specifically assigned patient ID. As a developer and manufacturer, you should definitely familiarize yourself with the standards of Vesta and MIOs, as well as check the more detailed explanations in the guide and the questions in Annex 2 DIGAV.
4. Demonstration of positive care effects of DiGAs
In general, the positive effects of DiGA can be divided into two areas. Either the DiGA provides a medical benefit (mN) or generates patient-relevant structural and procedural improvements (pSVV) in care. Because a manufacturer must demonstrate one or more of these care effects when submitting an application, this topic is of particular importance.
The positive supply effect must also be stated for a specific patient group. This is defined by the International Statistical Classification of Diseases and Related Health Problems (ICD-10), a three- or four-digit number. After application, the proof of benefit of the DiGA is only provided for this patient group and, after successful listing, is also only reimbursable for this group.
4.1 Evidence of positive care effects for Digital Healthcare Applications
The proof of positive care effects is divided into different steps. The first step is a preliminary study. In this, you show the BfArM which data justify the positive care effect for your DiGA. Whether these data are sufficient for the preliminary study can usually be clarified at short notice in a consultation with the BfArM. We will be happy to prepare this consultation with you, accompany you during the discussion and can support you in the preparation of the necessary consultation documents. In addition to this preliminary study, an evaluation concept must be prepared for the application. This consists of a study protocol (protocol) and a statistical analysis plan (SAP). In short, this describes the study that will be used to demonstrate the specified positive supply effect. If the application for inclusion in the DiGA directory is approved, the 12-month trial begins, during which the study planned in the evaluation concept is carried out. After successful testing, subsequent publication of the study results is mandatory.
The topic of proof of positive care effects incl. study design must always be examined individually.
5. Path to refund
The basis for successful inclusion in the DiGA directory for testing is the conscientious fulfillment of the extensive requirements in advance. You should seek advice from the BfArM. (“The bait must be tasty for the fish”). If the application is not successful, your DiGA will be blocked for one year before a new application for listing is made possible. Since this is very new legislation, many guidelines and notices are revised on a regular basis. You should accordingly pay attention to the update of the provided documents by the BfArM.
We have summarized the following graphic for you, which illustrates the path of a DiGA into reimbursement:
5.1 Application costs in connection with the preparation of a DiGA
Finally, we would like to give an overview of the possible costs for the application and fulfillment of the requirements. Of course, this is only a rough overview, which depends significantly on the respective DiGA and its supply effects.
You should include the following costs in your calculations:
- Provisional inclusion in the directory for Digital Health Applications for testing – according to DiGAV 3,000 – 9,000 euros
- Decision on permanent inclusion in the directory after completion of the trial – acc. to DiGAV 1,500 – 6,600 euros
- Consultations with the BfArM – between 250 and 5,000 euros (minor general oral, written, or electronic information is excluded from this)
Any questions?
The DiGA jungle is often not that easy to navigate. As a specialist in Healthcare Strategy & Market Access Consulting, we at SmartStep Consulting support you in meeting the qualitative requirements, determining and limiting the positive supply effects and your path to reimbursement by the statutory health insurers (SHI funds). Years of experience from various negotiations with health insurance companies, especially in the context of reimbursement negotiations for pharmaceuticals, which are understood by many as a blueprint for the regulations of DiGA reimbursement, can be valuable for you in your price and reimbursement negotiations.
Just contact us by email and we will be happy to advise you!