How You Can Meet the Data Security and Protection Requirements for Digital Health Applications
The data security and data protection requirements for DIGA (digital health applications) go far beyond the set of questions contained in the DiGAV. Countless other regulations are making it increasingly difficult for manufacturers of (not just) digital health applications (DiGAs) to stay abreast of what’s going on in the regulatory jungle.
As far as possible, manufacturers should not overlook any requirements. Otherwise, they will run into difficulties when it comes to getting their devices authorized.
A process model provides clarity and, in addition to helping manufacturers avoid problems, it also helps consolidate the requirements established in hundreds of pages of regulations. This process model can be used by all medical device manufacturers, including SaMD (Software as Medical Device) manufacturers.
1. Regulatory data security and data protection requirements for digital health applications
1.1 Overview of regulations and requirements
The number of regulations with data security and data protection requirements for digital health applications is huge. Table 1 shows the most important ones. The following sections describe these requirements in more detail.
Is it binding?
Medical Device Regulation 2017/745
The EU regulations form the legal framework for all medical devices. The IT security requirements are very general.
Only general data protection and data security requirements.
Requirements for devices and organization, especially in § 4 and Annex 1.
BSI-Standard 200-1, Information Security Management Systems
Corresponds most closely to ISO 27001.
Optional, but is a prerequisite for BSI 200-2
BSI-Standard 200-2, IT-Grundschutz Methodology
The DiGAV requires an information security management system (ISMS) according to BS 200-2 or ISO 27001. BSI 200-2 describes how to implement an ISMS.
Yes, from January 02, 2022, alternatively ISO 27001
Sicherheitsanforderungen an digitale Gesundheitsanwendungen
This regulation, which is still in the draft stage, also relates to mobile digital health applications as defined by § 33a SGB V.
Information technology — Security techniques — Information security management systems — Requirements
Requirements for a management system comparable to ISO 9001 and ISO 13485, but with a focus on IT security.
Yes, from January 02, 2022, alternatively: BSI 200-2
Health software — Part 1: General requirements for product safety
This standard will be harmonized under the MDR.
Health Software – Part 2: Health and wellness apps – Quality and reliability
This standard is still under development, but could become the state of the art. The aim is to create a traffic light system like the “energy certification” for electrical appliances.
Safety, security and effectiveness in the implementation and use of connected medical devices or connected health software – Part 5-1: Security – Activities in the product lifecycle
This standard is still under development, but harmonization under the MDR is already planned.
Table 1: Important regulations on data security and data protection for digital health applications (more than 600 pages in total)
But there are many more data protection and data security requirements. Read about them in the articles on data protection in healthcare and data security in healthcare.
- Information security must be guaranteed according to the state of the art
- Device requirements with regard to IT security must be established
- Instructions for use must specify user and operator requirements with regard to information security
Additional requirements affect mobile platforms, risk management and software development, among other things.
Annex 1 of the DiGAV specifies requirements in the form of checklists. These requirements also concern data security and data protection for digital health applications:
- Conformity with GDPR, including consent, data minimization, confidentiality, accuracy
- Obligation to provide information
- Data protection management
- Data protection impact assessment
- And more
- State of the art.
- Information management system according to ISO 27000 series or BSI standard 200-2
- Analysis of protection requirements
- Software that complies with the MDR
- Data leakage prevention, including encryption
- Device requirements, e.g., authentication and authorization, logging, hardening
- Installing, uninstalling, updating
- SOUP documentation and analysis
- Penetration testing
- Protection against DoS attacks
1.3 BSI TR-03161
Guideline BSI TR-03161 describes security requirements for digital health applications. First of all, it details various threats, such as an attacker guessing a password. The guideline then lists some general “security policies”.
The guideline mainly focuses on the following testing aspects:
- Application purpose
- Source codes
- Third-party software
- Use of cryptography
- Data storage and data protection
- Paid resources
- Platform-specific interactions
- Network communication
The guideline gives several test criteria for each testing aspect. Table 2 gives some examples.
“The manufacturer must disclose the primary purpose of the application and the use of personal data before installation.”
“Security MUST be an integral part of the software development and life cycle for the entire application.”
“User inputs MUST be checked before use to filter out potentially malicious values before processing.”
Table 2: Examples of test criteria contained in BSI TR-03161
These test criteria affect both the device and the design of the processes. The verification of user input is a requirement placed on the device. The requirement that security must be part of the software life cycle affects processes.
1.4 BSI 200-2
BSI Standard 200-2 describes how organizations should implement an information security management system (ISMS) in accordance with BS 200-1 (or ISO 27001). The standard contains the following chapters:
- Overview of the most important steps (chapter 2)
- Initiation of the information security process (chapter 3)
- Organizational structure (chapter 4)
- Required documentation (chapter 5)
- The “basic protection” approach and how to test it (chapter 6)
- The “core protection” (chapter 7) and “standard protection” (chapter 8) approaches
- Implementation of all security concepts (chapter 9)
- Maintenance and improvement of the ISMS (chapter 10)
- Certification according to ISO 27001
The BSI describes the three types of protection (basic, core and standard protection) on its website. It also uses the diagram shown in Fig. 1 on its website.
1.5 ISO 27001
At just 45 pages long, ISO 27001 is a very compact standard. The main part is only nine pages long and consists of five chapters:
- Information security management system
- General requirements
- Establishing and managing the ISMS
- Documentation requirements
- Management responsibilities
- Management obligations
- Management of resources
- Internal ISMS audits
- ISMS management review
- General information
- Inputs for the evaluation
- Results of the evaluation
- Improvement of the ISMS
- Continuous improvement
- Corrective actions
- Preventive actions
Companies that have already set up an ISO 9001 or ISO 13485-compliant QM system will recognize a lot of the requirements. Section 4.2 details the biggest difference compared to the QM standards (establishing and managing the ISMS). In this section, the standard demands a risk management process specifically for the organization’s IT security.
This process, in turn, must include the control objectives and controls listed in the normative(!) Annex A. At 19 pages long, this annex is twice as long as the standard itself.
ISO 27001 describes the ISMS requirements for an organization and not a device like a digital health application. Therefore, only a company can be ISO 27001 certified, a medi-cal device cannot.
1.6 ISO/IEC 82304-1
Although IEC 82304-1 does establish some requirements for information security, they barely go beyond the requirements found in other regulations.
One of the few exceptions is the requirement for support to ensure “timely patches and updates for information security.” The requirements for information regarding this in the accompanying documents are more granular than, for example, those in the MDR.
Read more on IEC 82304 here.
1.7 ISO/IEC 82304-2
ISO/IEC 82304-2 is aimed at manufacturers and users of “Health and Wellness Apps.” The standard wants to create a quality label, like the one used for electrical appliance energy efficiency. The aim is for this quality label to give a rating for:
- Medical safety
- Security of personal data
- Technical quality
Examples of test criteria for the manufacturer include the naming of a data protection officer and certification according to ISO 27001.
1.8 IEC 80001-5-1
The title of IEC 80001-5-1 is “Safety, security and effectiveness in the implementation and use of connected medical devices or connected health software – Part 5-1: Security – Activities in the product lifecycle.”
The standard describes a software life cycle process based on IEC 62304 but with a focus on IT security. Examples of specific requirements are:
- Static code analysis
- Attack surface analysis and reduction
- Fuzz testing
- Penetration testing
The standard is also based on IEC 62443-1 and supplements the life cycle processes according to IEC 62304 with aspects such as:
- Protection of the development infrastructure
- Timely provision of security updates
- Publication of IT-related problems
- Continuous improvement of the security life cycle process
1.9 Other regulations
There are several other relevant regulatory specifications, such as the IEC 62443 family and the GDPR.
The federal states’ data protection officers are considering not just requiring compliance with the GDPR by organizations that process personal data but also by the manufacturers who develop the systems required for this processing! For more information, see focus topic (Schwerpunkt-Thema) 4 on page 15 in the field report from the independent, federal and state data protection supervisory authorities.
2. Process model for digital health application manufacturers
2.1 Advantages of a process model
A structured approach helps manufacturers to
- Develop safe medical devices and operate them safely
- Comply with the (above) data security and data protection requirements for digital health applications
- Have their devices authorized as planned and included in the list of reimbursable digital health applications
- Minimize the time and effort required for training, for the design of processes and specifications, and for the creation of project plans
2.2. Step 1: clarify the framework conditions
Firstly, manufacturers should define the intended purpose of their device, because a lot of decisions and classifications are derived from this intended purpose:
- Medical device: yes or no?
- Class according to MDR/IVDR
- Software security class
- Protection requirements according to DiGAV or BSI 200-2
The protection requirement can only be derived from a risk analysis. This, in turn, requires the manufacturer to have determined and evaluated:
- Assets in need of protection (data, systems)
- Processing activities
- Technical infrastructure, IT systems, network plans
- Cloud and software architecture
- Division of activities between the company and suppliers/processors
An inventory of these elements is a key prerequisite for the next steps.
The manufacturer should also define the target markets and, therefore, the applicable regulatory requirements at this early stage.
2.3 Step 2: establish the integrated quality and information security management system
Both a QM system and an ISMS are management systems. Because there are a lot of parallels and redundancies in the requirements, we recommend establishing an integrated management system. This integrated management system would have to comply with the requirements of ISO 13485 as well as those of the BSI standards or ISO 27001.
As with any management system, the operational and organizational structure must be described.
For example, the organizational structure defines:
- The people responsible for information security (e.g., as part of a position within senior management, comparable to the quality management deputy)
- Organizational units, business areas, responsibilities
The operational structure describes the processes within the company. For this, manufacturers need to create specification documents, e.g.:
- Process descriptions, standard operating procedures (SOPs)
- Work instructions
There are numerous processes related to information security:
Examples of activities related to information security
Production, data center operation
Internal IT support
Computerized systems validation
Human resource management
Support, processing customer complaints
CAPA and vigilance
Auditgarant has a series of training videos that describe the secure development life cy-cle and contain templates for processes, forms, and checklists.
Manufacturers should use two approaches to design their processes:
- Check existing processes to see whether they contain activities that affect IT security and data protection
- Go through laws and standards and check whether activities that are not yet covered by any of the existing processes are required
A process is needed to ensure that this integration into existing processes takes place. The procedure described in BS 200-2 is useful for this.
The manufacturer must extend the scope of the integrated management system in its manual and reference all the processes. The protection requirement and the security/protection aims should also be described in the manual.
Standard activities for setting up an ISMS are:
- Establishing the information security officer and their role with tasks, rights, and responsibilities. In small companies, this role can be performed by the data protection officer. However, the role cannot be fulfilled by the IT manager or the internal auditor. The manufacturer may have to use external resources.
- Create an overview of information/data. Classify this information by criticality.
- Describe the information flows and processing activities (list of processing activities according to the GDPR).
- Amend/update the IT system inventory.
- Conduct the risk analysis. For the risk assessment, the people responsible should take into account the threats according to the BSI IT-Grundschutz catalog and the modules according to this catalog.
- Define actions. The Grundschutz catalog also details these actions by module, and separately for basic and standard requirements.
- Review the completeness of the actions on the basis of the Grundschutz catalogs.
- Implement measures, including establishing internal guidelines (see below).
The Grundschutz catalog proposes a sequence in which the actions/modules can be dealt with.
The standard guidelines are mostly specification documents such as process and work instructions, e.g.:
- Guidelines for the use of the Internet
- Specifications on how to handle security incidents (catastrophe plan, individual work instructions, internal information and escalation steps, reports to authorities)
- Installation instructions, configuration instructions
- Testing and release procedures (also for changes)
- Specifications for classification and access to documents and data
- Rules for backup and data protection
- Audit plans
- Training documents
- Software development process (see CON module)
Until the DiGAV makes ISO 27001 or the BSI standard 200-2 mandatory (on January 01, 2021), manufacturers can start with a “light version”:
- Copy the requirements in Annex I into an Excel list
- Classify these requirements as “device requirements,” “process requirements,” and “documentation and information requirements.”
- Transfer all the “device requirements” requirements to a “software requirements checklist.”
- Add the process requirements to all processes
Get in touch with us (e.g., via our contact form), if you would like an overview that as-signs the corresponding process that have to be added and/or the checklists for the life cycle phases to each requirement in the DiGAV concerning data security and data protec-tion
2.4 Step 3: develop the device according to this QMS/ISMS and establish operating infrastructure
If the integrated management system is in place, the requirements regarding data security and data protection for digital health applications can be systematically met.
Manufacturers who follow the instructions of their own QMS/ISMS will automatically generate the documentary evidence required by regulations such as the MDR and the DiGAV.
2.5 Step 4: “authorize” the device as a medical device
For class I digital health applications, manufacturers can declare conformity themselves without the involvement of a notified body. For class IIa digital health applications, they have to involve a notified body who will check that the QM system has been certified and review the technical documentation for the device.
The Digitale-Versorgung-Gesetz does not currently permit class IIb or III digital health applications.
Regardless of the class of the device, manufacturers must register their medical devices, currently with the Member States, in the future in EUDAMED.
2.6 Step 5: submit an application for inclusion in the DIGA directory
If the digital health application is registered as a medical device, manufacturers can request its inclusion in the German DIGA directory.
3. Conclusion, summary
3.1 (Too) many requirements
It’s enough to make you scream “Enough! Please no more regulations!“ Manufacturers are faced with a mountain of over 600 pages of regulations just on data protection and on data security. And that's not including a lot of standards, such as the ISO 20000 family of standards (IT service management) and IEC 62443.
In addition to the data security and data protection requirements for digital health applications, manufacturers also have to comply with other requirements and overcome the corresponding hurdles.
3.2 Consolidation is needed
Manufacturers do not need any more regulations because they do not provide any additional security. What's needed instead is a consolidation of these requirements. The Johner Institute recommends dividing these requirements into:
- Device requirements at the level of
- Intended purpose and stakeholder requirements
- Device/software requirements
- Architecture requirements and choice of technologies
- Process-related requirements, e.g., for software development and data center operation
- Requirements regarding the information that manufacturers have to provide to users, operators and third parties
However, this consolidation and the classification of requirements into classes is not easy. This is because the regulatory requirements differ in their scope:
- Healthcare specific vs. non-healthcare specific
- Applicable to digital health applications, medical devices, or “health and wellness applications”
- Device requirements vs. process/management system requirements
- Focus on IT security and data protection or also on safety
3.3 A fish rots from the head down
Even those brave enough to read through 600 pages of requirements will fail without the support of management. Data protection and IT security cost time and money. But ignoring data protection and IT security also costs money. You just don't know when or how much. The penalties and potential reputational damage are huge.
Therefore, management has no choice but to make these resources available.
But management should not be under the misapprehension that it can just outsource the issue to the data protection officer. It can’t do this because the data security and data protection requirements for digital health applications also apply to the whole organization and its suppliers.
Despite all the regulations, one thing should always be clear:
“The comprehensive information regarding IT-Grundschutz do not substitute common sense.”
The Johner Institute helps manufacturers of digital health applications to comply with the regulatory requirements and have their devices safely and compliantly authorized and entered in the DIGA directory, thus ensuring market success.