With TÜVIT to health insurance
Your digital health application as an "app on prescription"
In order for your digital health application to be eligible for reimbursement, you must prove to the Federal Institute for Drugs and Medical Devices (BfArM) that your application fulfils certain IT security, data protection and data security requirements. We accompany you on your way to reimbursable DiGA.
The Digital Healthcare Act (DVG) created the basis for the entitlement of insured persons to the provision of digital health applications. Following on from this, the Digital Health Applications Ordinance (DiGAV) contains the requirements for the reimbursement of digital health applications (DiGA) by health insurance companies.
The requirements relate in particular to the aspects of safety, quality, data protection and data security.
The security of DiGA applications is crucial for their authorisation, the protection of sensitive health data and the trust of users. The following benefits show how targeted security measures not only fulfil regulatory requirements, but also protect your app in the long term.
What data protection and IT security requirements must digital health applications (DiGA) fulfil in order to become an "app on prescription"?
If a product version is applied for inclusion in the DiGA directory, a penetration test must have been carried out for all components - regardless of the protection requirements of the DiGA.
The pentest must be carried out by a BSI-certified test centre, include mandatory code reviews and whitebox tests and be based on the BSI's implementation concept for penetration tests and the OWASP Top 10 risks for web applications and mobile apps.
We carry out the corresponding tests to provide evidence and help you to identify and close potential security gaps.
The 1st DiGAV-ÄndV requires all DiGAs to have an ISMS in accordance with ISO 27001 or "ISO 27001 on the basis of IT-Grundschutz (BSI standard 200-2: IT-Grundschutz methodology)".
We offer audits and GAP analyses as part of which we check whether you fulfil the necessary certification requirements.
DiGAs must enable the regular, automated export of data collected by the DiGA to the ePA from 1 January 2024.
The corresponding requirements for semantic and syntactic interoperability are defined by the KBV.
The 1st DiGAV Amendment Ordinance introduces the need for a secure authentication option for insured persons via digital identity.
This must be implemented by 1 January 2024 at the latest.
From 1 August 2024, proof of compliance with data protection requirements must be provided. This takes the form of an issued certificate in accordance with Article 42 GDPR.
From 1 January 2025, DiGAs must also fulfil data security requirements in accordance with Section 139e (10) SGB V. This includes the Technical Guideline TR-03161 (Requirements for applications in the healthcare sector) of the BSI or a corresponding (TR) certificate. Our IT security experts will check your DiGA according to the requirements of BSI TR-03161 and accompany you on the way to successful certification.
Digital health applications (DiGA) are medical devices of low risk classes, i.e. risk classes I or IIa according to the Medical Device Regulation (MDR).
These are apps or web-based applications that are used to recognise, monitor, treat or alleviate illnesses. They can also be used in relation to injuries or disabilities.
This means that DiGAs are "digital assistants" in the hands of patients that have a health-related purpose and can be prescribed by doctors and reimbursed by health insurance companies.
The following evidence must be provided for inclusion in the DiGA directory or should be able to be presented on request:
* If a comparative study to prove a positive supply effect is not yet available, a provisional inclusion in the directory can be applied for.
You can find the guidelines for the fast-track procedure here.
If your company already has an ISMS certified according to the ISO 27000 series or BSI Standard 200-2, which includes the entire life cycle of your DiGA, adequate solutions for implementing most of the requirements in the data security checklist in Annex 1 to the DiGAV should already have been implemented for the DiGA and its operation. Nevertheless, verification by the manufacturer must be carried out here and documented in a binding manner by completing the checklist accordingly.
Security as a process: For every change to the DiGA and/or the framework conditions, it must be checked how this changes the analysed risks and threats and whether the protective measures are still sufficient. This must be done continuously, even without updates, e.g. if a security vulnerability is recognised in a library in use.
If the assessment of the risks to the security of the DiGA comes to the conclusion that there are new threats that can be better analysed or detected by a penetration test, then a new test should be carried out. If not, there is no need to carry out a new penetration test.
In general, however, it should be borne in mind that at a certain point, a new penetration test is typically required, as significant changes have occurred since the last penetration test. Proof that a penetration test has been carried out must be provided to the BfArM on request.
Good reasons that speak in our favour
