It is no secret that the German healthcare sector is heavily regulated in all possible aspects. The new Digital Health Applications Ordinance (DiGAV) of 21st April 2020 allows only approved digital health apps (DiGA) to be reimbursed by the patient’s health insurance.
We have previously covered the HIPAA security rule regarding audit trail logging requirements as well as the different aspects of GDPR. Below is a quick overview of the main data protection and security requirements of the new ordinance together with an outline of how you can cover them in the most secure way possible – by using SentinelDB, our secure database with field-level encryption for medical data and immutable audit trail of all operations.
DiGAV requires more than just simple encryption and collection of audit log – it defines strong privacy requirements as well as integrity guarantees and analytical capabilities. SentinelDB is designed in such a way that it fully conforms to the privacy and data protection requirements and let’s you focus on your core business.
Mapping Between the New DiGAV Requirements for Data Protection and Security and SentinelDB Secure Database
Data Protection
No | Topic | Requirements | Admissible reason for “not fulfilled” | SentinelDB Functionalities |
| 11. | Minimizing data and adequacy | Are health-related data stored separately from data required exclusively for the service accounting? | All health-related data can be stored securely in SentinelDB, while the rest of the data remains in a standard relational database. The link between the two, if needed, is implemented by storing an anonymous ID in the relational database. | |
| 12. | Minimizing data and adequacy | Does the manufacturer of the digital healthcare application ensure that persons entrusted with administrative tasks do not have access to health-related data? | The access control lists of SentinelDB can be created and managed through either the SentinelDB dashboard or the RESTful API. They allow straightforward review and easy management of all access control rules of the organization and segregation of access. | |
| 14. | Memory limitation | Are the personal data processed through the e-Health application stored in a form that allows identification of the persons concerned only for as long as necessary for the purposes for which they are processed? | SentinelDB allows data pseudonymisation for cases when the data is needed for analytical purposes. SentinelDB also supports anonymization of records (removing the link from the identifiable person). | |
| 15. | Integrity and confidentiality | Does the e-Health application provide for adequate technical and organisational measures to protect personal data against accidental or unlawful destruction, deletion, alteration, disclosure or unauthorised forms of processing? | SentinelDB encrypts every record with a separate key, using AES-256, thus ensuring that no data breach can occur even in case access is compromised. Moreover, we do not store any data unencrypted even in our search engine. This feature is out of the box and does not require anything additional. We also do regular re-encryption of data, following the best practices in the field. All these measures ensure that no health-related data stored in SentinelDB will be put on risk and any data breach incident is completely prevented. All actions performed on the health data result in an unmodifiable audit trail which is inspected for anomalous patterns and thus allows real-time prevention of possible ongoing attempts to destroy, alter or disclose parts of the data. | |
| 16. | Integrity and confidentiality | Is the exchange of data between the terminal device of the person concerned and external systems, controlled by the Digital Health Application, consistently encrypted according to the state of the art? | No personal data are exchanged between the terminal of the person concerned and external systems. | SentinelDB supports two modes: first, database mode and ,second, backend-as-a-service mode. In the latter case the device communicates directly with SentinelDB. In both cases the communication is over an encrypted channel (TLS) and requires valid authentication tokens. |
| 20 | Necessity | Is personal data stored even after the purposes according to § 5 paragraph 2 have been fulfilled? | The purposes of storage and the maximum storage period have to be justified separately by the manufacturer, stating the reasons why these purposes constitute a legitimation for the further storage of personal data. | SentinelDB allows setting up data deletion and data anonymization schedules for ensuring that the data kept is minimized. |
| 21 | Necessity | Does the e-Health vendor provide mechanisms through which the person concerned can exercise the right to data portability and also retrieve the data collected through the e-Health application in a format listed in the VESTA directory or transfer it to another e-Health application? | The processing of data on digital health applications is not based on the consent of the person concerned. | SentinelDB has data portability endpoints available out-of-the-box that export each user’s personal records in machine readable format. |
| 33 | Burden of proof | Has the manufacturer documented the data protection guidelines applicable to the company and trained its employees in their implementation? | SentinelDB also helps vendors by providing part of the relevant documentation regarding data protection. | |
| 34 | Burden of proof | Does the manufacturer of the digital health application take measures to ensure that it is possible to subsequently check and establish whether and by whom personal data have been entered, modified or removed? | The audit trail module’s dashboard allows straightforward review of all accesses and modifications of personal data. Furthermore, the SentinelDB API has built-in audit trail-related parameters that connect organization users with the actions performed. | |
| 35 | Burden of Proof | Can the manufacturer of the digital health application proof at any time that the necessary consent of the person concerned was given to the processing of personal data? | The processing of data via the digital health application is not based on the consent of the person concerned. | SentinelDB keeps a digital evidence of every single consent given by the person concerned |
Data Security
No | Topic | Requirements | Admissible reason for “not fulfilled” | SentinelDB Functionalities |
1 | Information security and service-management | Has the manufacturer of the digital health application implemented an information security management system (ISMS) according to ISO27000 series or BSI standard 200-2 and can present a corresponding recognized certificate upon request of the Federal Institute for Drugs and Medical Products? | The date of application is before 1 January 2022. | SentinelDB allows organizations to more easily prove compliance with ISO 27000 and similar standards. |
| 4 | Prevention of data leakage | Has the manufacturer of the Digital Health Application ensured that the communication of the Digital Health Application with other services is technically limited to such an extent that no unwanted data communication can occur from the Digital Health Application? | Access control lists of SentinelDB can be created and managed through either the SentinelDB dashboard or the RESTful API. All calls to SentinelDB are authenticated using standard HTTP authentication methods. Additionally, SentinelDB can warn and block suspicious or excessive communication. | |
| 4 | Prevention of data leakage | Is at least 1 transport encryption in accordance with the BSI’s minimum standard for the use of Transport Layer Security (TLS) under § 8 (1) S. 1 BSIG used for all data communication between different system components of the digital health application which takes place via open networks? | The digital health application does not trigger data communication through open networks. | SentinelDB uses transport encryption also known as “TLS” for all communication. |
| 5 | Prevention of data leakage | Whenever the digital health application accesses functionalities that can be called up via the Internet, does the digital health application check the authenticity of the called services before personal data are exchanged with these services? | If the readily available SentinelDB client libraries are used, checking the authenticity of the provided certificates is done automatically. | |
| 6 | Prevention of data leakage | Has the Digital Health Application manufacturer ensured that the Digital Health Application does not write unwanted log or help files? | No personal data is logged in the application logs of SentinelDB and this is under regular review. Moreover, the audit trail contains only anonymous identifiers. | |
8 | Authentication | Must all persons using the e-Health application authenticate themselves using a method appropriate to the protection needs of the data processed before the data that is available through the e-Health application can be accessed? | SentinelDB supports two-factor authentication and each stored user can be enrolled for it. Then each time username/password authentication is attempted, the user also has to provide the two-factor authentication code in order to obtain a token. | |
| 9 | Authentication | Do appropriate technical measures ensure that data used to authenticate a user is never exchanged over unsecured transport connections? | Yes, SentinelDB does not work over unencrypted connection. | |
| 12 | Authentication | If the authentication is made by using a password: – Does the digital health application force all users to use strong passwords according to a password policy that includes a minimum password length and limits on failed login attempts? – Is it ensured that passwords are never transmitted or stored in plain text? – Is the changing or resetting of passwords logged and is the person concerned – if suitable contact information is available – immediately informed about the resetting or changing of the password? | Authentication does not make use of a password | 1. Yes, password policies are available 2. SentinelDB does not communicate over plaintext 3. Notification emails are sent to users |
13 | Authentication | If the Digital Health Application stores authentication data on a terminal device or in a software component installed on it: Is the explicit consent of the person using the Digital Health Application requested (“opt-in”) and is this person informed of the risks of the function? | The Digital Health Application does not store any authentication data on a terminal device or in any software component installed on it. | Depending on the mode used, SentinelDB tokens can be stored on a terminal device. For those cases SentinelDB can also be used to securely store the consent given in the UI. |
14 | Authentication | If information about the identity or authenticity of the user or the authenticity of components of the e-Health application is shared between components of the e-Health application via dedicated sessions: Are all session data, both exchanged and stored, protected by technical measures appropriate to the protection needs of the e-Health application, and are any used session IDs being generated randomly, with sufficient entropy and through established procedures? Are all sessions created in an instance of a Digital Health Application invalidated when the Digital Health Application is stopped or terminated and can the user also force the explicit invalidation of a session? Do sessions have a maximum validity period and are inactive sessions automatically invalidated after a certain time? Does the invalidation of a session result in the deletion of all session data and is it ensured that a session that has become invalid once cannot be reactivated even if individual session data is known? | The digital health application does not use sessions. | All communication with SentinelDB is over an encrypted channel with up-to-day and secure cipher suites. All communication is stateless, so that no sessions are created. Tokens used can be invalidated at any point. |
15. | Access control | Does the e-Health application ensure that all access to protected data and functions is subject to a complete mediation process, which, in the case of access by staff of the e-Health vendor, uses a dedicated authorisation component that covers all protected data (‘reference monitor’ or ‘secure node/application’) and requires prior secure authentication of the accessing person? | Authentication is required for all operations, and 2-factor authentication can be enabled., too. All authentications are logged in an immutable audit log that serves as reference monitor. | |
| 16 | Access control | Are all permissions assigned restrictively initially and by default, and can permissions be extended only through controlled procedures which, in the event of changes to the permissions of operating personnel of the manufacturer of a digital health application, include effective audit and control mechanisms based on a multi-eye principle? | SentinelDB’s recommended pattern of use is for just a small number of administrators to have access to the admin dashboard. Limiting what users in the vendor system can do is outside the scope of the datastore. Another set of users can also have full access to the audit trail and alerting functionality. | |
| 17 | Access control | If the digital health application provides different user roles: Can each role only access functions of the Digital Health Application with the rights necessary to perform the functions associated with that role? | The digital health application provides no different user roles. | SentinelDB supports different roles, however this requirement is primarily focused on the vendor system. |
| 18 | Access control | Does the manufacturer of the digital health application ensure that access to functions and data by the manufacturer’s operating personnel is only possible via secure networks and access points? | SentinelDB supports IP whitelists for accessing the admin dashboard. | |
| 21 | Integration of data and functions | If the digital health application allows the user to upload files: Is this function restricted as much as possible (e.g. exclusion of active content), is a security check of the content made, and is it ensured that files can only be stored in the specified path? | The Digital Health Application does not allow uploading of files. | SentinelDB offers secure file storage; however, content limitation and inspection is a responsibility of the application vendor. |
| 22 | Logging | Does the digital health application perform a complete, traceable, tamper-proof logging of all security-related events – i.e. the secure identification, authentication and authorisation of persons and organisations? | Yes, our audit trail module is highly secure because it uses cryptographic protection. It can be used through the database API or separately, to log non-database related audit events. | |
23 | Logging | Are logging data automatically evaluated in order to detect or proactively prevent security-relevant events? | Fraud-detection rules can be defined based on the audit trail which, when triggered, will send alerts for anomalous behaviour. SentinelDB has a default, built-in set of rules that would automatically block suspicious activities. On top of that, SentinelDB has machine-learning anomaly detection that is trained to detect usage pattern anomalies and report them. All these measures put together allow detection and proactively prevent security-relevant events. | |
| 24 | Logging | Is access to logging data secured by appropriate authorization management and restricted to a few authorized persons and defined purposes? | Yes, the audit trail module is protected in terms of authorization, but more importantly – no audit event can be deleted or modified. | |
| 28 | Hardening | If the Digital Health Application processes data provided by the user or by sources not controlled by the Digital Health Application: -Are these data treated as potentially dangerous and validated and filtered appropriately? -Is this data checked on a trustworthy IT system? -If possible, are incorrect inputs not handled automatically or are corresponding functionalities implemented securely to prevent misuse? -Is this data encoded in a form that ensures that malicious code is not interpreted or executed? -Is this data separated from concrete requests to data-retaining systems (e.g. via stored procedures) and are data requests explicitly secured against attack vectors favoured by such data? | The Digital Health Application does not process data provided by the user or by sources not controlled by the Digital Health Application. | When data storage is concerned, SentinelDB does not interpret or execute and of the supplied data. SentinelDB can perform basic (JSON-schema-based) validation of the input. More sophisticated validation rules are a responsibility of the application vendor. |
| 30 | Hardening | Is the digital health application protected from automated access by appropriate protection mechanisms, if they realize unwanted uses of the digital health application? | At the storage layer, SentinelDB performs analysis on the inbound requests and blocks attempts at automated access. | |
31 | Hardening | Are configuration files relevant for the secure operation of the Digital Health Application protected against loss and corruption by appropriate technical measures? | The Digital Health Application does not use configuration files or they are not relevant to the secure operation of the Digital Health Application. | This requirement should be covered by organizational procedures within the vendor. However, the SentinelDB audit trail module can help ensure the protection of config files integrity, keeping historical records of their changes. |
| 34 | Use of third-party software | Does the manufacturer maintain a complete list of all libraries and other software products used in the e-Health application that have not been developed by the e-Health application manufacturer itself? | LogSentinel can provide a list of the SentinelDB dependencies. And all of them are regularly checked against vulnerability databases and upgraded accordingly. |
Additional requirements for digital health applications with very high protection needs
No | Topic | Requirements | Admissible reason for “not fulfilled” | SentinelDB Functionalities |
1 | Encryption of stored data | Is personal data processed on IT systems which are not at the personal disposal of the user stored on these systems only in encrypted form? | SentinelDB encrypts every record with a separate key, using AES-256. We do not store any data unencrypted even in our search engine. This feature is out of the box and does not require anything additional. We also do regular re-encryption of data, following best practices. The connection between SentinelDB and any application is always encrypted as well. | |
| 4 | Authentication | Is two-factor authentication enforced at least for the initial authentication of all persons using the digital health application? | SentinelDB supports two-factor authentication of users. | |
5 | Authentication | If the digital health application allows a fallback option to 1-factor authentication: – Is the person using the digital health application made aware of the risks involved and is such a fallback activated only after consent has been given through an active operation of the user? – Can the user deactivate this fallback option at any time from the Digital Health Application? | The digital health application does not allow a fallback option to 1-factor authentication. | SentinelDB doesn’t allow fallback to 1-factor authentication once 2-factor is configured, unless a vendor administrator resets that option. The reset leaves a trace in the audit trail. |
| 6 | Authentication | Can the digital health application enable SHI insurants to be authenticated as the persons using digital health applications via an electronic health card with contactless interface? | Authentication with physical means is outside the scope the data layer, however any identifier extracted from an electronic health card can be securely stored in the user profile in SentinelDB, allowing future authentication. | |
| 7 | Authentication | If the digital health application includes a user role for service providers: Can the digital health application support authentication of service providers as the persons using the digital health application via an electronic health professional card with contactless interface by 31 December 2020 at the latest? | Authentication with physical means is outside the scope the data layer, however any identifier extracted from an electronic health card can be securely stored in the user profile in SentinelDB, allowing future authentication. | |
| 8 | Measures against DoS and DDoS | Are messages (XML, JSON, etc.) and data sent to digital health application services that are accessible via open networks checked against defined schemas? | The digital health application does not exchange data with or between services accessible via open networks. | SentinelDB admins can specify a JSON schema against which all requests are validated. All API calls are also validated for conformity with the API specification. |
| 9 | Embedded Web Server | If components belonging to the Digital Health Application use web servers – e.g. for administration or configuration: -Is the web server configured as restrictive as possible? -Are only the required components and functions of the web server installed or activated? -Is the web server not operated under a privileged account as far as possible? -Are security relevant events logged? -Is access only possible after authentication? -Is all communication with the web server encrypted? | The Digital Health Application does not use a web server. | The requirement is applicable to the vendor web server. Since SentinelDB operates as a web application as well, we can confirm that all the requirements are met on our end. |
In case you would like to get DiGAV compliance out of the way, talk to us today and let us help you protect your digital records with no compromise.
Denitsa is a Digital Marketing Analyst at LogSentinel with strong interest in the field of Information Security. She has 5 years of valuable experience in the field of Digital Marketing and Public Relations. Denitsa holds a degree in Journalism from Birmingham City University and has passed various Digital Marketing masterclasses and courses.
