On April 21, 2020, the Regulation on the Requirements and Reimbursement Process for Digital Health Applications (Digitale Gesundheitsanwendungen-Verordnung or „DiGAV“, available here) entered into force in Germany.  Among other provisions, the DiGAV includes specific IT security and privacy requirements.  Shortly after the law took effect, Germany’s Federal Medicines and Medical Devices Agency (“BfArM”) also released an extensive explanatory Guidance (Leitfaden, available here) to the DiGAV.

Independently, on April 15, 2020, the German Federal Office for IT Security (“BSI”) published a draft version of its guidance on “Security Requirements for Digital Health Applications” (BSI TR-03161) (available here).  The BSI is now seeking feedback from industry on this draft guidance before releasing a final version.

While the scope of application of the DiGAV and the BSI draft guidance may be limited, the documents can serve to provide useful insights and benchmarks for health applications generally.

Scope of application

The DiGAV applies when the provider of a digital health application seeks reimbursement from German state health schemes.  While there are a variety of potential routes for seeking reimbursement, the DiGAV process is designed as a “fast track” procedure to attract companies less familiar with the German health system.  We summarize the DiGAV process in our Covington Digital Health blog here.

The DiGAV applies to health applications the main functionality of which is based on digital technologies, i.e., it is not limited to mobile apps. Moreover, a digital health application must be:

  • a certified low-risk medical device; and
  • used by patients, or jointly by a patient and a physician, dentist, or psychotherapist.

By contrast, the BSI draft guidance only pertains to mobile health apps falling within scope of the DiGAV, although the BSI indicates that it may also be relevant and instructive for any mobile app that processes sensitive data.


Key privacy requirements set out in the DiGAV and the BfArM guidance

According to the DiGAV and BfArM guidance, health application developers must:

  • implement appropriate data protection and security measures, taking into account the state of the art, the categories of personal data processed, and the sensitivity of the data;
  • carry out a Data Protection Impact Assessment;
  • obtain explicit consent from patients to process their health data (Art. 9(2) (a) GDPR), except to the extent that another applicable law permits or requires the processing;
  • not disclose personal data outside the European Economic Area to countries that do not provide an adequate level of protection, as determined by the European Commission pursuant to Art. 45 GDPR (i.e., transfers on the basis of consent, standard contract clauses or BCRs are not allowed; US providers must be Privacy Shield certified);
  • impose an obligation of confidentiality on all persons under their authority who have access to the personal data of users.

Patients’ data may be used by digital health application developers only for the following purposes:

  • to enable use of the digital health application and for reimbursement process;
  • to prove the benefit of the application (in the framework of specific provisions of Book V of the Social Security Code);
  • to ensure, on an ongoing basis, the technical functionality, user-friendliness and further development of the application, although patients must have the option to separately give or withhold their consent to the use of their data for these purposes.

Annex 1 to the DiGAV, which will form part of the application filed by a developer to request approval for reimbursability, includes a checklist in the form of a questionnaire that covers a variety of privacy-related topics.  In particular, it addresses data subject rights under the GDPR, the criteria for obtaining valid consent, data minimization requirements, additional requirements applicable to health data if it is not stored on the user device, as well as obligations pertaining to data integrity, confidentiality, data retention, and record-keeping.


Key interoperability and data portability requirements under the DiGAV and the BfArM Guidance

The digital health application must enable a patient to convert his or her data into a machine-readable, interoperable format for personal use and/or for use by a healthcare professional.  This compatible format must also enable the patient to print out extracts of the data in a “human readable” form.  If the application interacts with wearables, it must be able to communicate with the wearables using an interoperable interface.  The DiGAV and the BfArM Guidance set out in detail how to determine which standards to use to achieve interoperability.  Note developers have until January 1, 2021 to ensure their applications adhere to these interoperability requirements.

Furthermore, the BfArM estimates that it is not currently possible to ensure secure communications between digital health applications offered by different providers and that therefore, patients do not have the right to demand that their data be transferred directly from one digital health application to another.


Key data security requirements under the DiGAV and the BfArM Guidance

According to the DiGAV and BfArM guidance, health app developers must:

  • carry out an analysis of data protection requirements (Schutzbedarfsanalyse) in accordance with BSI standard 200-2;
  • implement an information security management system in accordance with ISO 27000 standards or BSI standard 200-2 (only if the application is filed after December 31, 2021);
  • implement release, change and configuration management processes taking into account the requirements of the Medical Devices Regulation (EU) 2017/745;
  • implement special security features for “very high-risk” applications; and
  • keep a record of third-party libraries and software used in the digital health application.


The BSI draft guidance on “Security Requirements for Digital Health Applications” (BSI TR-03161)

The BSI notes that its draft guidance is not exhaustive, although it covers a broad range of topics that include purpose limitation, architecture, source code, third-party software, cryptography, authentication, data storage and data privacy, chargeable features, network communication, platform specific interaction, and resilience.  Noteworthy points include:

  • A requirement that data transfers to third parties (e.g., social networks or third-party providers of built-in features such as maps) be restricted to the minimum required to fulfil the specific purpose of the health application.
  • If the health application uses a cloud service as backend system, the cloud service must have a security certification (C5 – Cloud Computing Compliance Criteria Catalogue [KCC-C5] or equivalent). (The BSI recently published a new version of the “Cloud Computing Compliance Criteria Catalogue”, which is available in English here.)
  • Special security measures applicable to third-party frameworks, libraries and software; third-party software that is no longer maintained by the third-party provider must not be used in a digital health app.
  • Factory settings must be those with “the maximum” of data security and privacy.
  • All sensitive data (as defined by the BSI) must be encrypted at all times.
  • The app must not record sensitive data in log files, nor send other messages or push notifications that are not explicitly enabled by the user.
  • If the app offers in-app payment features, the manufacturer must implement measures that prevent third parties from tracing the payment flows relating to these features.
  • All network communications of the app must be encrypted with TLS.