Part 3 of this blog series: Further obligations of the DiGA manufacturer as the controller
In the first part of our blog series we looked at what a DiGA is and what it is not. In the second part, we gave you an overview of the most important criteria that a DiGA must fulfill from a data protection perspective. The data protection criteria of the Federal Institute for Drugs and Medical Devices (BfArM) (available at https://www.bfarm.de/DE/Medizinprodukte/Aufgaben/DiGA-und-DiPA/Datenschutzkriterien/_node.html, hereinafter also referred to as “BfArM data protection criteria”) reflect in particular the data protection principles of Art. 5 GDPR and are based on the guarantee objectives of the standard data protection model.
In the third and final part of this blog series, we would like to take a closer look at the obligations of the DiGA manufacturer as data controller. This is because the data protection principles must not only be anchored in the digital application, but also in the entire organization of the DiGA manufacturer. The last article in our series will therefore focus on how the data protection organization of the DiGA manufacturer must be structured, whether and how processors may be used, and to which other countries the data of a DiGA may be transferred. Like any data controller, the DiGA manufacturer also has documentation obligations.
Exercise of responsibility (Part 3 Section 10 of the BfArM data protection criteria)
The DiGA manufacturer must set up a data protection organization appropriate to the risk. This includes the appointment of a suitably qualified data protection officer (DPO). The DPO may not perform any tasks in connection with the development or operation of the digital application that could lead to a conflict of interest with the role of the data protection officer. The DPO must have access to all processing operations and related documentation. A corporate culture should be promoted in which the DPO is proactively involved. He or she must be able to suggest and demand improvements on his or her own initiative. Any rejection of the DPO’s proposals must be justified and documented.
All employees involved in the processing of personal data must be required to maintain data confidentiality.
The group of employees who have access to personal data must be limited to what is necessary according to the need-to-know principle. The DiGA manufacturer must have defined the roles of its employees in such a way that it is clear from the job description whether access to personal data processed via the digital application is required.
The development and operation process of the digital application must be designed in such a way that data protection risks are identified and monitored. This means, for example, that new features of the digital application are assigned to a specific release only after an assessment of the associated potential risks to the rights and freedoms of natural persons, and that the necessary technical and organizational measures are implemented at least simultaneously with the release. Short-term changes to the digital application must not weaken the effectiveness of the existing technical and organizational measures. The employees responsible for the analysis and design of the digital application must have up-to-date knowledge of the technical measures for data protection.
The DiGA manufacturer must have processes in place to ensure timely notification to the supervisory authorities in the event of a personal data breach. This obligation includes the creation of a process plan. This plan must include a clear definition of decision-making responsibilities. The controller must use the capabilities of the digital application to notify the data subject of a high risk personal data breach, even if only pseudonymous data is processed. This can be done, for example, through a pop-up in the digital application. Technical and organizational measures must be put in place to force a change of login information. These can include specifying a policy in the logon procedure that forces a change after the first logon or after a specified period (e.g. every three months), otherwise no logon is allowed. Microsoft Entra ID (formerly Active Directory) and similar services make it easy to specify such policies using predefined settings. For individual developments, this can be achieved using data fields that store a logon counter and the last password change.
Order processing and data transfer (Part 3 Section 11 of the BfArM data protection criteria)
In principle, the manufacturer of the DiGA can commission service providers with data processing. If the service provider processes personal data of the DiGA, an order processing contract must be concluded. An order processing contract must contain certain provisions according to Art. 28 GDPR (see Art. 28 para. 3 lit. a) – h), para. 4 GDPR). In its comments on the data protection criteria, the BfArM requires that the requirements of Art. 28 GDPR must be contractually secured and implemented in the relationship with the processor. The processor may only process personal data on behalf of the controller, i.e. the DiGA manufacturer. The order processing contract must contain a corresponding provision. In addition, the DiGA manufacturer must set up a procedure for documenting and monitoring the instructions given.
Practical tip: The EU Commission has published EU standard contractual clauses between data controllers and data processors (available at https://commission.europa.eu/publications/standard-contractual-clauses-controllers-and-processors-eueea_en). It is advisable to use these pre-formulated model clauses approved by the EU Commission as a data processing agreement. This is because they meet the requirements of Art. 28 GDPR. Please note: Only the annexes may be completed and the options proposed by the EU Commission may be selected. No other changes may be made to the clauses.
Before concluding a contract with a processor, the controller must ensure that the processor offers sufficient guarantees for the security of the processing, based on its expertise, reliability and the resources made available to it. To this end, the controller should request evidence of the processor’s certifications.
In the context of digitization, service providers from the USA are often unavoidable. The use of US tools in a DiGA was not possible until July 2023. This is because the DPA limits the place of data processing for the data processed by the DPA to the Federal Republic of Germany, the member states of the European Union, the signatory states to the Agreement on the European Economic Area (EEA) and Switzerland, as well as countries for which an adequacy decision exists pursuant to Art. 45 GDPR exists. With the adoption of the adequacy decision on the new data protection framework between the EU and the U.S. (the so-called Privacy Framework) by the European Commission, personal data can again be transferred from the European Union to the U.S. with legal certainty as of July 10, 2023. However, this requires that the US provider that the DiGA manufacturer wants to use is certified according to the Data Privacy Framework. The use of, for example, a European service provider with a U.S. parent company without appropriate certification remains difficult within the framework of DiGA and is only possible under strict conditions (see further information from the BfArM at the following link https://www.bfarm.de/SharedDocs/Downloads/DE/Medizinprodukte/Datenverarbeitung_ausserhalb_Deutschlands_FAQ.pdf?__blob=publicationFile).
Practical tip: To find out if a U.S. provider is already certified under the Privacy Framework, visit the U.S. Chamber of Commerce website at https://www.dataprivacyframework.gov/list.
Data protection impact assessment and record of processing activities (Part 3, Section 12 of the BfArM data protection criteria)
The DiGA manufacturer must create and maintain the necessary data protection documentation. This includes performing a Data Protection Impact Assessment (DPIA) and creating a record of processing activity.
Practical tip: Use a data protection software to create the required data protection documentation. We recommend PLANIT//PRIMA. More information about this software can be found at the following link: https://www.planitprima.com/en/
When conducting a DPIA, the BfArM follows the standard data protection model. According to this model, a DPIA should include the following steps
- Perform a threshold analysis
- Identify the risks and assess the impact on the rights and freedoms of individuals
- Determine technical and organizational measures to minimize the risks
- Assess the remaining risks and their residual impact
- If high risks remain, coordination with the Federal Data Protection Commissioner or the competent state data protection authority is required (Art. 36 GDPR).
As part of the threshold analysis, it is necessary to consider whether a DPIA is required for the digital application.
Practical tip: The German Data Protection Conference (DSK), an association of all German federal and state data protection authorities, has published a list showing when a DPIA must be carried out. This can be found at the following link: https://www.lda.bayern.de/media/dsfa_muss_liste_dsk_de.pdf.
Technical and organizational measures (Part 3 Section 13 of the BfArM data protection criteria)
The controller of the digital application and the service providers it uses as processors must take appropriate technical and organizational measures in accordance with the state of the art to ensure a level of protection for DiGA’s personal data that is appropriate to the risk. These measures can include
- Pseudonymization and encryption of personal data. Pseudonymization is used to make it more difficult to attribute data to individuals. Technically, pseudonymization can be achieved through tokenization, encryption, data masking, or data merging: Tokenization replaces sensitive data with unique identifiers (tokens). These tokens are not directly associated with the original data. Encryption converts data so that it cannot be read without the correct key. During data masking, records are assigned to specific pseudonyms using a table. Care must be taken to ensure that no direct reference can be made to the original data. Data shuffling changes the order of the data to make identification more difficult.
- Ensure the confidentiality, integrity, availability, and resiliency of systems and services. These are the basic protection goals of information security.
Confidentiality can be achieved through mechanisms such as
- Access control: Only authorized users can access information.
- Encryption: Information is converted into an unreadable code that can only be decrypted with a valid key.
- Security policies: Establish rules for storing, processing, and transmitting information within a system.
Integrity aims to protect information from unauthorized modification or destruction. Integrity mechanisms include
- Checksums: Verifying the integrity of data by calculating checksums.
- Digital signatures: Authenticate and protect data integrity.
- Change logging: Traceability of changes.
Availability ensures that authorized users have access to information and systems at all times. This can be achieved through
- Redundancy: Backup systems to prevent failures.
- Load balancing: Spreading the load across multiple systems.
- Careful maintenance: Regular maintenance and monitoring of systems.
Resilience is the ability of a system to function under stress or attack. This can be achieved by, among other things
- Robust architecture: Designing systems that can tolerate failures.
- Contingency plans: preparing for unexpected events.
- Regular testing: verifying the resilience of systems.
These cornerstones of IT security are typically part of standardized certifications such as ISO27001 or BSI baseline protection. They are also part of the NIS2 regulation.
- The ability to quickly restore availability and access to personal data in the event of a physical or technical incident. In addition to the cornerstones mentioned above, there are other exemplary options (e.g., data protection and a reliable backup concept; redundant systems and monitoring of system utilization).
The needs of the target group and typical usage patterns must also be taken into account. Users of the DiGA must not be tempted by uncontrollable measures to use the digital application in a way that undermines these measures or increases the likelihood of other risks.
The technical and organizational measures must be documented. This can be done, for example, in a TOMs concept and a security concept. The controller must specify which references (norms, standards, guidelines, etc.) he has used as a benchmark for the “state of the art”. As part of the documentation of the measures, the controller must justify the choice of measures. The controller shall explain what alternatives were considered and why they were rejected. The controller shall establish a procedure for periodic review of the technical and organizational measures.
If you are wondering what specific technical and organizational measures you need to take, and whether the measures you are planning are state of the art, we recommend using the German Federal Office for Information Security (BSI) IT Grundschutz as a guide.
Practical tip: The BSI has produced a guide to developing secure web applications. It contains helpful checklists starting on page 45. It is available at https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/Studien/Webanwendungen/Webanw_Auftragnehmer.pdf?__blob=publicationFile&v=1. And englisch website with information on IT Grundschutz can be found at: https://www.bsi.bund.de/EN/Themen/Unternehmen-und-Organisationen/Standards-und-Zertifizierung/IT-Grundschutz/it-grundschutz_node.html. In addition, the DSK has published a guideline entitled “Anforderungen an Anbieter von Online-Diensten zur Zugänglichkeit” (Requirements for Providers of Online Services for Access Security) (available at https://www.datenschutzkonferenzonline.de/media/oh/20190405_oh_anbieter_onlinedienste.pdf). This describes, among other things, state-of-the-art measures for securing access to applications.
In addition, we would like to briefly point out the following obligations of the controller (DiGA manufacturers):
If a version of the digital application is to be made available for mobile platforms, the controller must consider alternative distribution channels to the app stores. This review must be repeated on a regular basis.
If the digital application can be used via mobile devices, the controller must take measures to protect the personal data accessible or retrievable via the device, including in the event of loss or theft of the device. In particular, the mere possession of the device must not result in unauthorized persons gaining access to the data subject’s personal data. For example, the controller must have a procedure in place to block all data associated with a user account from external access. The controller must have implemented measures in the digital application or in the associated user management processes that allow access data to be securely reset or new access data to be issued to the data subject. It shall be possible to authenticate the individual as the legitimate owner of the account. This is usually achieved through multi-factor authentication, which adds another layer of identity assurance, such as an authentication app (Microsoft or Google Authenticator) or SMS.
In addition to security of processing, technical and organizational measures include privacy by design and privacy by default. The most privacy-friendly system settings must be preset in the digital application (privacy by default). Users must be warned in the digital application when a change to a system setting results in new or increased risks to their rights and freedoms. They should also be able to restore the most privacy-friendly system setting in a simple and intuitive way. The digital application must consistently apply the principle of “fail-safe defaults,” i.e., any access attempt that is not explicitly authorized must be rejected. They are an important aspect in the design of authentication systems. They aim to increase security by ensuring that users only receive access rights that have been explicitly assigned to them. This can be achieved through a clean authentication and authorization architecture with encryption and secure hashing of access data to protect against hacker attacks. The key is a rights management system that assigns authorization profiles to user roles in such a way that users can only access the functions for which they are authorized. In addition, every access attempt must be checked (“complete mediation”). This prevents unauthorized access and ensures the integrity of the system.
Conclusion
Not only DiGA, but also the company of the DiGA manufacturer has to fulfill data protection requirements. These do not differ significantly from the obligations of other companies as controllers of personal data. If you have set up your company to market the DiGA, these various obligations can present you with major challenges. You can therefore benefit from our many years of experience in setting up risk-adequate data protection organizations, including in the pharmaceutical environment for manufacturers of drugs and medical devices.
We are also happy to take on the role of data protection officer. Please contact us. We look forward to hearing from you!
