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.

Table 1: Important regulations on data security and data protection for digital health applications (more than 600 pages in total)

1.2 MDR/IVDR

In contrast to the EU directives, the EU regulations (the MDR and the IVDR) explicitly address information security. However, they are limited to general requirements only:

• 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.

1.3 DiGAV

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:

Data protection

• Conformity with GDPR, including consent, data minimization, confidentiality, accuracy
• Secrecy
• Obligation to provide information
• Data protection management
• Data protection impact assessment
• And more

Data security

• 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:

1. Application purpose
2. Architecture
3. Source codes
4. Third-party software
5. Use of cryptography
6. Authentication
7. Data storage and data protection
8. Paid resources
9. Platform-specific interactions
10. Network communication
11. Resilience

The guideline gives several test criteria for each testing aspect. Table 2 gives some examples.

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

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.

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:

• Documentation
• 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.

2. Process model for digital health application manufacturers

2.1 Advantages of a process model

A structured approach helps manufacturers to

1. Develop safe medical devices and operate them safely
2. Comply with the (above) data security and data protection requirements for digital health applications
3. Have their devices authorized as planned and included in the list of reimbursable digital health applications
4. 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)
• Processes
• 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
• Forms
• Checklists

There are numerous processes related to information security:

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 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”:

1. Copy the requirements in Annex I into an Excel list
2. Classify these requirements as “device requirements,” “process requirements,” and “documentation and information requirements.”
3. Transfer all the “device requirements” requirements to a “software requirements checklist.”
4. Add the process requirements to all processes

Further Information

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

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.”

BSI 200-2

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.