Germany's Digital Medical Device Regulations: A Framework For The World To Follow, Part II

Germany’s Digital Healthcare Act came into effect on December 19, 2019, introducing the “app on prescription” as part of healthcare provided to patients through digital health applications (in German: “digitale Gesundheitsanwendungen,” hereinafter DiGA). The Bundesinstitut für Arzneimittel und Medizinprodukte (BfArM, or the Federal Institute for Drugs and Medical Devices) released a new guide in August 2020 detailing the requirements for DiGA manufacturers in order to make your DiGAs available to the more than 73 million participants in the German statutory health insurance. In Part 1 of this article series, I gave an overview of the situation and covered the many privacy requirements noted in the new guide. In this Part 2, I examine the data security requirements. Later, in Part 3, I’ll detail the interoperability, robustness, consumer protection, and patient safety requirements.

Information Security And Service Management

• You have implemented an information security management system (ISMS) in accordance with ISO 27000 series or a comparable system and can provide a corresponding recognized certificate or comparable evidence.
• You have a structured protection needs analysis considering damage and threat scenarios with your documented output being be a normal, high, or very high protection requirement for the DiGA in accordance with BSI standard 200-2, and you can submit the documentation of the protection requirement analysis at the request of BfArM.
• You have implemented and documented processes of DiGA/software release, change control, and configuration management, taking into account the EU MDR requirements. Ensure that extensions and adjustments to the DiGA, have been sufficiently tested and explicitly approved before they are put into production.

Data Leakage Prevention

• You have ensured that the communication between the DiGA and other services is technically limited to such an extent that no unwanted data communication can take place from the DiGA via which personal data can be sent.
• At least one transport encryption is used for every data communication between different system components of the DiGA via open networks.
• The DiGA checks the authenticity of the services accessed every time it accesses functionalities that can be accessed via the internet before personal data is exchanged with these services.
• You have ensured that the DiGA does not write any unwanted log or auxiliary files.
• You have ensured that the DiGA does not generate error messages that may reveal confidential information.

Authentication

• All users must authenticate themselves using a method appropriate to the protection requirements before data on the application can be accessed.
• You have ensured through suitable technical measures that the data used to authenticate a person using the DiGA is never exchanged via unsecured transport connections.
• The DiGA uses or contains a central authentication component implemented with established standard components that are only permitted for the initial authentication and whose trustworthiness can be verified by the DiGA’s services.
• The DiGA enforces that a user can only change the data used for their authentication if sufficient information is added to check the authenticity of this person.
• If authentication is carried out using a password:
  • The DiGA forces everyone using it to use secure passwords in accordance with a password guideline which, among other things, specifies a minimum length for passwords and defines limit values for failed login attempts.
  • You have ensured that passwords are never transmitted or saved in clear text.
  • The DiGA logs and informs the user of any changing or resetting of passwords.
• If the DiGA stores authentication data on a terminal device or in a software component located on it, the explicit consent of the user is requested ("opt-in") and advised of the risks of the function.
• If information on the identity or authenticity of the user or on the authenticity of the DiGA’s components is shared between components via dedicated sessions:
  • All session data is protected by appropriate technical measures, during both exchange and storage, with the protection requirements. The session IDs used, if applicable, are generated randomly, with sufficient entropy and using established procedures.
  • All sessions are set up in an instance of a DiGA invalidated when its use is aborted or ended, and the user can also force the explicit invalidation of a session.
  • Sessions have a maximum validity period and inactive sessions are automatically invalidated after a certain period of time.
  • The invalidation of a session results in the deletion of all session data and a session that has once become invalid cannot be reactivated even if individual session data is known.

Access Control

• The DiGA ensures that every access to protected data and functions goes through an authorization check (“complete mediation”), for which a dedicated authorization component, including all protected data, is used for access by operating personnel of the manufacturer (“reference monitor” or “secure node/application”), which requires prior secure authentication of the accessing person.
• All authorizations initially and restrictively are assigned by default and authorizations are only extended via controlled procedures that include effective checking and control mechanisms based on a multiple-eye principle when the authorizations for operating personnel of the manufacturer are changed.
• If the DiGA provides for different user roles, each role can only access functions with the rights required to execute the functionalities associated with the role.
• You have ensured that access to functions and data by your operating personnel is only possible via secure networks and access points.
• All errors and malfunctions of the access control result in a denial of access.

Integration Of Data And Functions

• Only the insured can move within the trust domain of the DiGA or a trustworthy external content checked by you.
• If the DiGA allows the user to upload files, such function is restricted as much as possible (e.g., excluding active content), a security check of the content takes place, and you have ensured that files can only be saved in the specified path.

Logging

• The DiGA can carry out complete, traceable, falsification-proof logging of all security-relevant events, i.e., the secure identification, authentication, and authorization of individuals and organizations.
• Logging data are automatically evaluated by you in order to recognize security-relevant events or to prevent them proactively.
• Access to logging data is secured by a suitable authorization management system and restricted to a few authorized individuals and defined purposes.

Regular And Secure Updates

• You inform the person concerned (e.g., via push mechanisms or before a user starts the DiGA) if a security-relevant update has been made available for installation or carried out.

Hardening

• If DiGA services can be called up via web protocols:
  • Methods of the protocols used that are not required are deactivated for all services that can be called via open networks.
  • You have restricted the permitted character encodings as much as possible.
  • You have limited values for access attempts set for all services that can be called via open networks.
  • You have ensured that no safety-related comments or product and version information are disclosed.
  • You regularly delete unnecessary files.
  • You have ensured that these services are not recorded by search engines.
  • There is no absolute local path information.
  • You have excluded the retrieval of source texts.
• If the DiGA processes data that is provided by the user or by sources not controlled by the DiGA:
  • You treat this data as potentially dangerous and validate and filter accordingly.
  • You check this data on a trustworthy IT system.
  • Incorrect entries, if possible, are not handled automatically or the relevant functionalities are reliably implemented so that misuse is excluded.
  • This data is encoded in a form that ensures that malicious code is not interpreted or executed.
  • This data is separated from specific queries to data-holding systems (e.g., via stored procedures) or data queries are explicitly secured against attack vectors benefiting from such data.
  • You have consistently ensured that errors in the DiGA are dealt with and lead to the abortion and possibly rolling back of the initiated functions.
  • The DiGA is protected against automated access by suitable protective mechanisms if these are not part of the intended use.
  • Configuration files relevant for secure operation are protected against loss and falsification by suitable technical measures.

Use Of Sensors And External Devices

• If the DiGA directly accesses the sensors of a mobile device and/or external hardware (e.g., sensors close to the body):
  • You have specified the framework conditions under which sensors or connected devices can be installed, activated, configured, and used and you have ensured the existence of these framework conditions as far as possible before carrying out the corresponding functionalities.
  • The DiGA ensures that sensors and connected devices are set to a basic setting during installation or initial activation, which corresponds to a documented safety guideline.
  • The user can reset sensors and devices directly controlled by the DiGA to a basic setting that corresponds to a documented safety guideline.
  • Data exchange between the DiGA and directly controlled sensors or devices is only possible when the installation and configuration of the sensors or devices has been completed.
• If the DiGA exchanges data with external hardware (e.g., body-hugging sensors):
  • The processes for installing, configuring, activating, and deactivating this hardware are described appropriately for the target group and, as far as possible, secured against incorrect operation.
  • There is a mutual authentication between the DiGA and external hardware.
  • Data between the DiGA and external hardware will only be encrypted after an initial connection.
  • You have ensured that if the DiGA is uninstalled or if its use is ended, all data stored on external hardware will be deleted.
• You have documented how connected hardware can be safely deactivated so that no data is lost and no sensitive data remains on the device.

Third-Party Software

• You must keep a complete list of all libraries and other software products used in the DiGA that were not developed by you as the manufacturer.
• You use suitable methods of market observation to ensure that previously unknown risks for data protection, data security, or patient safety emanating from these libraries or products are identified promptly.
• You have established procedures to take appropriate measures in the event of such identified risks to be able to immediately block the app and notify users.

Additional Requirements For DiGAs With Very High Protection Requirements

• Personal data processed on IT systems that are not at the personal disposal of the user are only stored in encrypted form on these systems.
• You have carried out a penetration test for the version of the DiGA to be included in the directory, considering common attack vectors such as clickjacking or cross-site request forgery, among others.
• You have documented the results of the penetration tests and the results of the processing of the measures or recommendations and, if necessary, transferred them to suitable management systems.
• You will enforce a two-factor authentication at least for the initial authentication of all users.
• If the DiGA allows a fallback option to one-factor authentication:
  • The user is made aware of the associated risks and such a relapse is only activated after the user has given their consent, which has been confirmed by an active action.
  • The user can deactivate this relapse option at any time from within the DiGA.
• The DiGA can support authentication of insured persons as the user via an electronic health card with a contactless interface by December 31, 2020, at the latest.
• Messages (XML, JSON, etc.) and data are sent to DiGA services accessible via open networks checked against defined schemes.
• If components are web servers, e.g., for administration or configuration:
  • The web server is configured as restrictively as possible.
  • Only the required components and functions of the web server are installed or activated.
  • The web server is not operated under a privileged account.
  • Security-related events are logged.
  • Access is only possible after authentication.
  • All communication with the web server is encrypted.

It is important to understand that the German Federal Office for Information Security (Bundesamt für Sicherheit in der Informationstechnik, or BSI) which helps organizations identify and implement measures to help secure IT systems has created a baseline set of standards for protecting information technology (in German, IT-Grundschutz). These BSI standards consist of:

• An ISMS based on ISO/IEC 27001 standards (BSI-Standard 100-1)
• The IT-Grundschutz methodology, which describes how to set up and operate an ISMS (BSI Standard 100-2)
• A risk analysis method (BSI Standard 100-3)
• The IT-Grundschutz Catalogues, a standard set of potential threats and safeguards against them for typical business environments.

Also, it is important to note that ISO/IEC 27001 is a security standard that formally specifies an ISMS that is intended to bring information security under explicit management control. As a formal specification, it mandates requirements that define how to implement, monitor, maintain, and continually improve the ISMS. It also prescribes a set of best practices that include documentation requirements, divisions of responsibility, availability, access control, security, auditing, and corrective and preventive measures. Certification to ISO/IEC 27001 helps organizations comply with numerous regulatory and legal requirements that relate to the security of information.

In Part 3 of this article series, I’ll detail the interoperability, robustness, consumer protection, and patient safety requirements.

About The Author:

John Giantsidis is the president of CyberActa, Inc, a boutique consultancy empowering medical device, digital health, and pharmaceutical companies in their cybersecurity, privacy, data integrity, risk, SaMD regulatory compliance, and commercialization endeavors. He is also a member of the Florida Bar’s Committee on Technology and a Cyber Aux with the U.S. Marine Corps. He holds a Bachelor of Science degree from Clark University, a Juris Doctor from the University of New Hampshire, and a Master of Engineering in Cybersecurity Policy and Compliance from The George Washington University. He can be reached at john.giantsidis@cyberacta.com.