Digital health apps: German guideline on security requirements

On 15 April 2020, the Federal Office of Information Security (Bundesamt für Sicherheit in der Informationstechnik – BSI) published a technical guideline (Guideline) on the minimum requirements for the secure operation of digital health applications for mobile devices (Digital Health Apps) (Sicherheitsanforderungen an digitale Gesundheitsanwendungen – Technische Richtlinie BSI TR-03161).

Healthcare sector profits of increased digitalisation

The Guideline was published in the context of the increased digitalisation of all areas of life. The BSI highlights that already in 2018 the number of worldwide Internet users exceeded the four billion mark and that currently two thirds of the world's 7.6 billion people use a mobile phone. According to the BSI more than three billion people currently use social networks and do so in nine out of ten cases using their smartphone.

The BSI emphasises that this digitalisation trend affects the healthcare sector, pointing to the trend towards “self-tracking” and the increasing demand for the efficient use of medical data that has already been collected, meaning the use of such data irrespective of time and location.

Digital Health Apps

As far as the definition of Digital Health Apps is concerned, the BSI draws upon Section 33a of Book Five of the German Social Code (Sozialgesetzbuch (SGB) Fünftes Buch (V)). According to this provision the national health insurance grants the insured under certain conditions an entitlement to be provided with digital health applications. In this context, digital health applications shall have the purpose to support the detection, monitoring, treatment or relief of illness-es or the detection, treatment, relief or compensation of injuries or disabilities (Unterstützung bei der Erkennung, Überwachung, Behandlung oder Linderung von Krankheiten oder die Erkennung, Behandlung, Linderung oder Kompensierung von Verletzungen oder Behinder-ungen).

Comprised smartphones pose severe data protection risks

The BSI points out that it is convenient for many users to be able to access their medical data regardless of time and location. It has to be noted, however, that Digital Health Apps store sensitive personal data, such as the pulse rate, recordings of the sleep rhythm, medication plans as well as medical prescriptions and certificates. Digital Health Apps are able to connect the user with health services and act as communication nodes. The BSI, as such, emphasises that a compromised smartphone might pose severe data protection risk in relation to any Digital Health App stored on such device. Compliance with appropriate IT security standards can help to mitigate such risk.

Three goals of IT security

The BSI points out that IT security pursues three goals: confidentiality, integrity and availability.

The BSI highlights that compliance with IT security - requirements is particularly important for Digital Health Apps: in contrast to finance, where fraudulently transferred amounts of money can be reimbursed by credit institutions to customers, the confidentiality of health data that is involuntarily made public might be lost forever. The BSI emphasises that the unwanted disclosure of health data, in the social as well as in the professional environment, could have undesirable consequences with considerable effects: if an attacker were able to manipulate the health data of a user and thereby violates the user’s integrity, this could have a significant impact on therapy decisions and ultimately the health of the user.

Purpose of the Guideline

In the light of the above, the BSI has the intention that this Guideline supports developers of Digital Health Apps in the creation of secure mobile applications. Beyond this, the Guideline should also be utilized for any other mobile application that processes sensitive data.

The Guideline focuses on security measures for applications installed on a mobile device, such as a smartphone.

The document is published as a - non binding - “trial-use” version. The BSI aims to revise the Guideline in the future in order to include industry feedback and chapters on conducting respective reviews and certifications.

Relevant security risks

The Guideline identifies relevant security risks as well as recommended organisational security measures to counter such risks.

The risks include, amongst others, the possibility of identifying unprotected data structures by means of reverse engineering, unauthorised access to sensitive data by means of using third-party IDs as well as intercepting insufficiently encrypted data transfers.

As examples for adequate organisational security measures to counter such threats, the BSI highlights, amongst others, the following:

• access authorisation concepts;
• monitoring for exploitable security vulnerabilities and prompt security updates;
• implementation of high encryption validation of third-party data prior to usage; and
• issuing critical updates.

The Guideline highlights that it there are, of course, additional security risks relating to the backend services and any connections between Digital Health Apps and Internet -of-Things (IoT) devices, which need to be taken into account (but which are not subject of this Guideline).

Digital Health Apps’ minimum requirements

The Guideline lists Digital Health Apps’ minimum requirements from a security and data protection perspective. The developer shall document how these requirements are implemented:

Purpose of use & Consent

Any data shall only be processed if necessary for the primary purpose of the Digital Health App. In addition, the BSI clarifies that (amongst others) the following is relevant:

• The user has to be informed (amongst others) on the primary purpose of the Digital Health App as well as the processing of personal data before the app is installed (eg in the description of the app in the App Store) and at least once when the app is used for the first time.
• Any data processing shall require a user’s consent, which the user must be able to withdraw.
• Sharing sensitive data with a third-party requires a user’s informed consent and may only be conducted as far as this is necessary for the primary purpose of the Digital Health App.

Architecture

Already during the design stage of the Digital Health App data protection and security aspects need to be taken into account (privacy by design principle). Amongst others, it has to be ensured that:

• backend services have valid and established security certificates;
• security features are implemented throughout all components of the system (eg backend, Digital Health App, interfaces);
• the backend can push out security relevant updates to the Digital Health App; and
• source code.

The source code of the Digital Health App has to be protected from unlawful alterations. Amongst others:

• any user input has to be checked prior to its use in order to avoid that malware gets hold of the system;
• developer tools have to be deactivated in the final version; and
• errors notifications and other alerts may not include sensitive data (eg user identifier).

Third-party software

Any use of third-party software has to be scrutinized; this includes regular vulnerability checks and underlying security concepts. Amongst others, it has to be ensured that:

• security updates are continuously provided; where such provision is discontinued, the use of the respective software has to be stopped;
• security updates are implemented in a timely manner; and
• any data that the third-party software transmitted to the Digital Health App has to be validated.

Cryptographic implementation and random numbers

Necessary encryption tools - such as cryptographic generators for random numbers – have to be state of the art. Furthermore,

• cryptographic generators have to provide an high encryption standards;
• the generators encryption procedures may not be identifiable from outside the application; and
• cryptographic keys may only be used for exactly one purpose and must be protected against manipulation.

Authentication

Authentication (two-factor) and (role-based) authorisation measures have to be implemented. In addition, manufacturers have to comply with requirements for the use of biometric authentication measures and any other relevant authentication measures.

Data storage and data protection

Default settings have to provide the maximum level of data protection and security. Furthermore,

• sensitive data has to be encrypted and stored by means of providing protection against access and manipulation;
• data processing has to adhere to the principles of data minimisation and storage limitation and shall be conducted in the backend;
• as far as recording devices are utilized (such as camera or microphone), the recorded data must be stripped of any meta data; and
• as far as sensitive data is submitted by means of keyboard, the application shall prevent third parties from recognizing such data.

Extra Fees

Any services that are subject to additional fees have to be explicitly highlighted. Furthermore,

• a user’s consent must be obtained before carrying out such services. The App has to enable the user to withdraw such consent;
• third-parties must be prevented form tracing back the resulting cash flow to the use of particular services of the Digital Health App; and
• third-party payment methods must be secure and validated.

Network communication

Any data transfer / communication of the Digital Health App has to be encrypted by state of the art measures. Furthermore, the Digital Health App has to:

• only accept trustworthy certificates;
• check the server certificate of the backend and validate the integrity of any of the backends’ responses; and
• keep log files on the backend for all established connections.

Platform specific interactions

The device on which the Digital Health App is located may not process user’s data without his/her explicit instruction to do so. Furthermore,

• messages and notifications concerning sensitive data have to be expressly activated by the user;
• the Digital Health App must implement access restrictions on all data; and
• sensitive functionalities shall not be provided using inter-process communication of the device.

Resilience

The Digital Health App has to be able detect potential harm to the security of the processed data. It must:

• abort its launch, if it is started under unusual user rights (eg root or nobody);
• verify the integrity of the device before processing sensitive data; and
• implement access control mechanisms, taking into account different platforms and platform versions.

Please note that this is a summary of the Guideline. We have not listed all security measures suggested by the BSI, but only some of them.

If you have any questions in relation to the Guideline or any other questions relating to Digital Health, please do not hesitate to contact us at any time.

See our coronavirus (COVID-19) feature for more information generally on the possible legal implications of COVID-19.