The BfArm Fast-Track Guide for the DiGA registration in Germany defines several specific requirements for the successful certification of a medical device and its inclusion in the DiGA directory. These requirements relate primarily to safety and functionality, data protection and information security, as well as quality and interoperability.
The manufacturer can employ checklists from Annexes 1 and 2 of the DiGAV for this purpose. The items in Annex 1 deal with requirements for data protection and data security. Appendix 2, however, focuses on requirements for interoperability, robustness, consumer protection, user-friendliness, support for service providers, quality of medical content, and patient safety.
All relevant access data for the DiGA must be made freely available to the BfArM as part of the application process. It is important that this data is always in accordance with the current legal and technical requirements. The BfArM checks the accuracy of this information and can request additional evidence for individual quality characteristics if necessary.
Furthermore, the BfArM can request additional evidence for individual quality characteristics. If the information proves to be untrue or not (any longer) up to date, the BfArM can impose sanctions according to § 139e SGB V in the form of removal from the DiGA list or a penalty payment. In addition, the manufacturer must inform the BfArM of any significant changes to the DiGA, particularly in the case of changes affecting data protection and information security.
Safety and functional performance
A DiGA must be able to demonstrate a certain level of safety and functional performance to meet the requirements for CE marking. To this end, the manufacturer must provide the SGB V with proof of product safety and functional capability as part of the application procedure. Generally, the certificate of conformity/EC attestation of the notified body or the manufacturer’s declaration of conformity provides this proof. The BfArM only performs the control of the formal legality of the CE marking.
Data protection and information security
Data protection as well as information security are also among the fundamental requirements for a DiGA and must be taken into account as early as the application stage. The BfArM, in agreement with the Federal Commissioner for Data Protection and Freedom of Information (BfDI) and the Federal Office for Information Security (BSI), annually defines the test criteria for the data protection requirements to be demonstrated by the DiGA in accordance with Section 139e (2) sentence 2 no. 2 SGB V.
Since 1st April 2023, proof of compliance with the data protection requirements must be provided by the manufacturer by submitting a certificate in accordance with Article 42 DSGVO (cf. Section 139e (11) SGB V).
Data protection requirements for a DiGA pursuant to Article 4 (2) sentences 1 and 2 DiGA
Requirements concerning information security refer to the protection of confidentiality, integrity and availability of all data processed via a DiGA. The information security criteria are summarised in Annex 1 to the DiGAV under two headings “Basic requirements, for all DiGA” and “Additional requirements for DiGA with very high protection needs”.
All information security requirements of the “Basic Requirements” must be met with no exception, or they are omitted, as they are not applicable to certain types of DiGA. Additional requirements must be addressed only if the DiGA has been identified as requiring a very high level of protection for the care
Information security requirements for a DiGA
DiGA must meet various quality requirements, with interoperability being a central point. These are listed in Section 5 (2) to (9) of the DiGAV and must be specified in the application for inclusion in the DiGA directory to be completed by the manufacturer.
DiGA must ensure use free of interference, data loss, transmission errors, and difficulty connecting to equipment to avoid corruption of the database. The manufacturer shall take technical measures to protect DiGA against or handle a cause of interference such that no loss or corruption of data occurs.
DiGA user’s particular life and/or medical condition shall not be exploited by the manufacturer to take advantage of the user. Therefore, the manufacturer must provide transparency to the service provider and the user about the intended use and performance characteristics of the DiGA. In addition, the manufacturer must provide a current compatibility commitment for each hardware and software, on the website maintained for the DiGA. This application webpage is also part of the documentation to be submitted for inclusion in the DiGA Directory.
In-app purchases of medical devices that exceed the scope of the reimbursement-reduced DiGA are permitted to the manufacturer. However, the additional cost must be covered by the insured. Should the manufacturer offer in-app purchases, the following requirements from Appendix 2 DiGAV must be considered:
- In-app purchases cannot be advertised in the DIGA.
- The sales platform/app website must clearly indicate which additional functions can be purchased and their price.
- In-app purchases cannot include automatically renewing subscriptions or time-limited special offers.
- The possibility of an unintentional in-app purchase must be ruled out.
§ 5 Absatz 4 DiGAV: Digitale Gesundheitsanwendungen müssen frei von Werbung sein.
[English: Article 5(4) of the DiGAV: Digital health applications must be free of advertising.]
A DiGA may not be used for advertising purposes. Self-advertising by the manufacturer for its own products as well as third-party advertising for third-party offers are prohibited.
Using a DiGA must be intuitive and easy to learn for the respective target group. When implementing alternative solutions, a particularly high level of usability must be ensured. The platform specific guidelines of the usability style guide will apply to provide a familiar platform for the users. Furthermore, user who are not experienced in using digital media must be taken into special consideration during focus group tests. In addition, the DiGA must either include user aids for people with disabilities or support the user aids offered by the platform.
DiGA may be used by physicians and other healthcare providers as an additional measure for patient use (See Chapter: Additional Requirements in special Cases). In this case, the manufacturer must provide additional information explaining the role of healthcare providers in the overall context of the application. Furthermore, the manufacturer must list the benefits the DiGA is intended to provide, how these benefits are to be achieved, as well as all respective legal requirements.
Quality of the medical content
The implementation of the DiGA and the content presented must be based on verified medical knowledge and comply with recognised professional standards. The medical and professional foundation of the DiGA must be derived from reliable and disclosed sources.
The health information provided to patients must be kept up to date and appropriate presented to the target group. Information should be carefully evaluated and structured to meet the needs of patients in their current health situation without influencing them in any way.
Safety of the patients
The DiGA manufacturer must ensure that the risks associated with the use of the application are minimised by taking appropriate administrative and technical precautions. This includes anticipating potential hazards at an early stage as well as raising user awareness. Users must be equipped to recognise when they need to consult a physician or discontinue use of a DiGA.
Interoperability describes the ability of technical systems to work together on a technical-syntactical, semantic, and organisational level. This major feature of the quality of a DiGA falls under the requirements of Section 139e (2) of the German Social Code, Book V (SGB V) and is further specified in §§ 5 and 6 DiGAV and in Annex 2 to the DiGAV (heading “Interoperability”).
Additional requirements in special cases
DiGA can have a wide range of applications in practice. Accordingly, based on these diverse use cases, there are additional requirements for a DiGA. The following table illustrates the specific requirements for a DiGA, depending on whether it is intended for use with hardware, services, optional features, or for preventive purpos