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.
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 | Only general data protection and data security requirements. | Yes | 23 | |
DiGAV | 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)
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.
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:
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:
Data protection
Data security
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:
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.
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:
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.
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.
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:
Examples of test criteria for the manufacturer include the naming of a data protection officer and certification according to ISO 27001.
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:
The standard is also based on IEC 62443-1 and supplements the life cycle processes according to IEC 62304 with aspects such as:
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 (Schwerpunkt-Thema) 4 on page 15 in the field report from the independent, federal and state data protection supervisory authorities.
A structured approach helps manufacturers to
Firstly, manufacturers should define the intended purpose of their device, because a lot of decisions and classifications are derived from this intended purpose:
The protection requirement can only be derived from a risk analysis. This, in turn, requires the manufacturer to have determined and evaluated:
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.
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 operational structure describes the processes within the company. For this, manufacturers need to create specification documents, e.g.:
There are numerous processes related to information security:
Process | Examples of activities related to information security |
Development |
|
Production, data center operation |
|
Internal IT support |
|
Computerized systems validation |
|
Human resource management |
|
Post-market surveillance |
|
Purchasing |
|
Support, processing customer complaints |
|
CAPA and vigilance |
|
Management review |
|
Internal audit |
|
Document control |
|
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:
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.:
Until the DiGAV makes ISO 27001 or the BSI standard 200-2 mandatory (on January 01, 2021), manufacturers can start with a “light version”:
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
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.
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.
If the digital health application is registered as a medical device, manufacturers can request its inclusion in the German DIGA directory.
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.
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:
However, this consolidation and the classification of requirements into classes is not easy. This is because the regulatory requirements differ in their scope:
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.