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.

Abbreviation

Title

Comments, mandatory?

Is it binding?

Pages

MDR

Medical Device Regulation 2017/745

The EU regulations form the legal framework for all medical devices. The IT security requirements are very general.

Yes

175

DVG

Digitale-Versorgung-Gesetz

Only general data protection and data security requirements.

Yes

23

DiGAV

Digitale-Gesundheitsanwendungen-Verordnung

Requirements for devices and organization, especially in § 4 and Annex 1.

Yes

31

BSI 200-1

BSI-Standard 200-1, Information Security Management Systems

Corresponds most closely to ISO 27001.

Optional, but is a prerequisite for BSI 200-2

48

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

180

BSI TR-03161

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.

Yes (future)

28

ISO 27001:2017

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

35

ISO/IEC 82304-1

Health software — Part 1: General requirements for product safety

This standard will be harmonized under the MDR.

Yes (future)

31

ISO/IEC 82304-2

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.

Recommended (future)

55

IEC 8001-5-1

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.

Yes (future)

39

 

 

Total

 

645

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

Further Information

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.

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.

Testing aspect

Example

Application purpose

“The manufacturer must disclose the primary purpose of the application and the use of personal data before installation.”

Architecture

“Security MUST be an integral part of the software development and life cycle for the entire application.”

Source code

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

data-protection
Fig. 1: Basic protection is used to quickly protect all relevant business processes. Core pro-tection focuses on an “ organization’s critical ‘crown jewels’.” The comprehensive standard protection is at the same level as the BSI’s IT-Grundschutz.

NB!

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.

Further Information

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
  • Usability
  • Security of personal data
  • Technical quality
iec-wellness-app-rating
Fig. 2: 82304-2 wants to give users a quick overview of the quality of “health and wellness apps” with this label. (Source)
The standard is essentially made up of checklists that are very similar to those in the DiG-AV. One concerns “Privacy and Security.” As with the DiGAV, most of the test criteria relate to the device and the accompanying information, only some relate to the manufacturer.

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.

NB!

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 (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

  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:

Process

Examples of activities related to information security

Development

 
  • Includes the secure development life cycle (see comment regarding Auditgarant)
  • Handling SOUP software
  • Control of IT security risks
  • Creation of accompanying materials (e.g., installation instructions and instructions for use)
 

Production, data center operation

 
  • Definition of protection requirements, modeling
  • Selection, maintenance and monitoring of the infrastructure
  • Installation and configuration instructions
  • Taking an asset inventory and monitoring assets
  • Definition of security zones and access controls – data security, recovery
 

Internal IT support

 
  • Taking an asset inventory and monitoring assets
  • Handling loss
  • User administration, assignment of permissions and their continuous monitoring
 

Computerized systems validation

 
  • Testing of the IT security of the systems
  • Checking the correct configuration and role assignment
 

Human resource management

 
  • Selection, guaranteeing of competence
  • Drafting of contracts
  • Onboarding, training, data protection instructions (e.g., Internet use, how to handle incidents)
  • Further training, checking of competence
  • Offboarding, removal of permissions, return of assets
 

Post-market surveillance

 
  • Monitoring of IT security databases
  • Monitoring of SOUP manufacturers
  • Monitoring of your own infrastructure
 

Purchasing

 
  • Requirements for suppliers
  • Requirements for purchased products
  • Incoming goods inspection
 

Support, processing customer complaints

 
  • Access according to GDPR
  • Processing requests (e.g., data change or deletion requests)
 

CAPA and vigilance

 
  • Handling security incidents
  • Notifications to data protection authorities
 

Management review

 
  • Review of the effectiveness of the management system
  • Assessment of new regulatory requirements
  • Assessment of new trends (technologies, security problems)
  • Decision on whether additional resources or other actions, such as the revision of the QM system, training or other technologies are necessary
 

Internal audit

 
  • Review of internal processes
  • Internal review
  • Security audits of suppliers, if necessary
 

Document control

 
  • Classification of the protection requirement, if necessary
  • Information of life cycle and destruction
  • Provisions for the protection of information
 

 

Tip

Auditgarant has a series of training videos that describe the secure development life cy-cle and contain templates for processes, forms, and checklists.

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

Tip

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

  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

Digital health application manufacturers
Fig. 3: Digital health application manufacturers have to comply with the organizational and process requirements as well as the requirements for the device itself, the DIGA.

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

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.