Computer-implemented method for separating identification data from health data having reference to a person

Abstract

The invention relates to a computer-implemented method for separating identification data from health data having reference to a person, the method comprising the steps of: - receiving health data having reference to a person from a system which records health data, wherein the health data having reference to a person consist of identification data and further data, the method furthermore comprising the steps of: - separating the identification data from the health data having reference to a person, as a result of which the health data are split into the identification data and the further data, - adding a pseudonym to the further data in order to generate pseudonymised data, - storing the identification data in a first data space, - storing the pseudonymised data in a second data space, wherein the first and second data space are different data systems which can be controlled or checked or managed independently of one another, and the method having the following step: - providing the identification data and the pseudonymised via the same interface for a user.

Description

[0001] COMPUTER-IMPLEMENTED METHOD FOR SEPARATED IDENTIFICATION DATA FROM PERSONAL HEALTH DATA

[0002] FIELD OF THE INVENTION

[0003] The present invention relates to a computer-implemented method for separating identification data from personal health data, a method for bidirectional communication between a data room in which patient data is stored and a consent application of a patient's mobile terminal, a corresponding computer program, and a corresponding data processing device or network.

[0004] TECHNICAL BACKGROUND

[0005] The digitalization of healthcare is massively expanding the existing data volume, thus creating new innovation potential. The data volume is growing in scope (more data is being digitally captured, replacing paper-based processes), and more specific data (such as genomic data) that were previously rarely collected are being stored regularly.

[0006] The collected data is referred to as personal health data because the dataset contains both identification data (e.g., name, date of birth, electronic health card) and data points relating to the health status (e.g., diagnoses) of a data subject. In the majority of healthcare processes (e.g., patient admission, diagnostic examinations, surgeries), other people are involved in addition to the patient (e.g., doctors, nursing staff). These are also stored as part of the documentation and are referred to as personal data.

[0007] In particular, the processing and storage of particularly sensitive data, such as health data, requires special protection. This protection is ensured by technical and organizational measures (TOMs), although technical measures should be preferred (human misconduct can be largely ruled out).

[0008] The quality of the data (e.g. completeness, correctness) is crucial for the use of the data.

[0009] For secondary use, project-specific data spaces (e.g., files, databases) are usually created through a loading process. This usually occurs once, and subsequent changes in primary use (e.g., new data, data corrections) are no longer taken into account.

[0010] One problem the inventors have identified is the security concerns associated with the use of cloud systems (Infrastructure-as-a-Service). The inventors also noted that the primary data is stored in a data room, and even with sensitive data (e.g., health data), the identification data remains directly with the data record. Since it is presumably possible to identify the data subject, for example, based on their name, this can lead to negative consequences for the data subject.

[0011] In particular, the use of cloud services is critically considered because (1) unauthorized access to the data by employees of the service provider is feared and (2) the risk of cybersecurity attacks is considered higher for cloud systems than for self-managed infrastructure (on-premises).

[0012] Problem: Privacy by Design vs. Organizational Measures as Special Protection: Data at rest and data in motion are encrypted today to achieve a basic level of protection. Access control builds on this level of protection to grant only authorized users access to the decrypted data. However, effective protection is only possible if all systems used follow the same rules, which is rarely the case in reality. GENERAL DESCRIPTION OF THE INVENTION

[0013] In this section, the general features of the present invention are described by way of example with reference to possible embodiments of the invention.

[0014] This is achieved by the subject matter of the independent claims, with further embodiments being contained in the dependent claims and the following description.

[0015] The described embodiments similarly relate to the method for separating identification data from personal health data, the method for bidirectional communication between a data space in which patient data is stored and a consent application of a patient's mobile terminal, a corresponding computer program, and a corresponding data processing or network. Synergy effects can arise from various combinations of the embodiments, even if they are not described in detail below. Furthermore, it should be noted that all embodiments of the present invention relating to a method can be carried out in the order of steps expressly described here. Nevertheless, this need not be the only and essential order of the steps of the method.The methods presented here can also be carried out with a different order of the disclosed steps without deviating from the respective embodiment of the method, unless expressly stated otherwise below.

[0016] Technical terms are used in their general sense. Where certain terms have a specific meaning, definitions are provided below in the context in which they are used.

[0017] In the context of the present invention, the terms data space and data memory are used synonymously. A register / registry is a particular embodiment of a data space or data memory. Unless otherwise stated, any embodiment described in the context of the invention can be implemented with a register as the data space.

[0018] According to a first aspect of the invention, a computer-implemented method for separating identification data from personal health data is provided. The method comprises the steps:

[0019] - Receiving personal health data from a system that collects health data, the personal health data consisting of identification data and other data, the method further comprising the steps of:

[0020] - Separating the identification data from the personal health data, whereby the health data is divided into the identification data and the other data,

[0021] - Adding a pseudonym to the other data to generate pseudonymized data,

[0022] - Storing the identification data in a first data room,

[0023] - storing the pseudonymized data in a second data space, wherein the first and second data spaces are different data systems that are independently controllable or manageable, and the method comprising the step

[0024] - Providing the identification data and the pseudonymized data to a user via the same interface.

[0025] In one particular embodiment, this provides a PHI (protected health information) vault / a secure storage for sensitive, personal data.

[0026] This first aspect of the invention describes a solution to the aforementioned problem with personal data. The inventive solution creates two independently manageable data spaces by separating the identification data from the data stream. This can be achieved by splitting the data streams into identification data and the remaining data, which can be managed in independent systems. Access to identification data can be reserved only for authorized users. Other users then only have access to pseudonymized data, which significantly reduces the effects of unlawful use. Advantageously, existing systems do not need to be adapted for use with the described solution, since access continues to be achieved using a standard interface. This is explained in the context of detailed embodiments below.

[0027] According to one embodiment, the method further comprises the steps:

[0028] - Receiving a user request for retrieving at least part of the identification data and / or at least part of the pseudonymized data, wherein upon receiving the user request, information on a role of the requesting user with regard to a use of the requested data is also received, the method further comprising the steps:

[0029] Determining the data in the first and / or second data space that may be transmitted to the user based on the received information on the role of the requesting user with regard to the use of the requested data, and

[0030] Transmission of information about the requested data to the user and / or transmission of at least part of the previously determined data to the user.

[0031] According to one embodiment, the user request is received through the interface and / or the specific data is transmitted through the interface.

[0032] According to one embodiment, when determining the data that may be transmitted to the user based on the received information on the role of the requesting user with regard to the use of the requested data, a further attribute is additionally taken into account, in particular a stored consent of the person from whom the health data originates.

[0033] According to one embodiment, the first and second data spaces are designed as separate storage media or are provided using separate storage media,

[0034] - located at different geographical locations, and / or

[0035] - executed as different areas of a cloud storage.

[0036] According to one embodiment, a single interface is used.

[0037] According to one embodiment, a FHIR interface and / or a DICOM web interface is used.

[0038] According to one embodiment, the first and second data spaces each have only one data input and one data output.

[0039] According to one embodiment, the system that collects health data is a hospital, a laboratory, a PACS, and / or a HIS.

[0040] Further details and implementations of the process for separating identification data from personal health data are provided below. In particular, the technical innovation that enables the specially secured data space with standard interfaces is described below.

[0041] Figure 1: Example: Identification data is separated without adapting the standard interfaces (solution sketch)

[0042] Standard interface (API)

[0043] The system according to the invention can be connected to systems outside the system context via standard interfaces. In this case, a distinction is made in the solution sketch between data-collecting systems and data-using systems. However, this is not necessary, as they are connected via the same interface (the interface is shown twice in the solution sketch only for ease of illustration). Common standard interfaces, such as FHIR, DICOM DIMSE, DICOM web, GA4GH, can be used. The standard interfaces can be implemented in such a way that uniform access control based on a user token can be carried out, transparently for the data-using systems. In particular, it can be taken into account whether (1) the requirements for data access are met and whether (2) the user is authorized to access the identification data (otherwise, access to the data is only possible with a pseudonym).

[0044] In this non-limiting example, the user tokens are generated by a system (outside the system context) during user authentication. These tokens can be provided with a digital signature by the generating system so that the validity of the user token can be verified.

[0045] Table 1 Access control based on user token and other criteria

[0046] Regarding the separation or splitting of the primary data stream, the following should be noted: The primary data (e.g., personal health data) is separated by software into data with identification data and data without identification data (enriched with a person-specific pseudonym). The respective data streams are stored in separate data rooms. The pseudonym can be assigned and managed by the hospital's internal confidentiality office.

[0047] The following should be noted regarding the health data repository: The health data repository can be software that stores data without identification data. Various technical systems can be used to secure the data in order to enable technical and economic scaling. In particular, cloud systems can also be used. The following should be noted regarding the hospital-internal trust center: The hospital-internal trust center can be software that (1) creates pseudonyms based on identification data and (2) stores the pseudonyms together with the identification data in a protected data room. Access to the data can be reserved only for users with the appropriate authorization. The hospital-internal trust center can be managed organizationally and technically separately from the health data repository.

[0048] Implementation details using FHIR as an example Figure 2: Separation of identifying data from FHIR data

[0049] glossary

[0050] According to a second aspect of the invention, a method for bidirectional communication between a data room in which patient data is stored and a consent application of a patient's mobile terminal is provided. The method comprises the step

[0051] - Providing a bidirectional communication channel between the data room in which the patient's patient data is stored and the consent application of the patient's mobile device, whereby the bidirectional communication between the device and the data room takes place without revealing the patient's identity.

[0052] Any embodiment described in the context of the invention may, unless stated otherwise, be implemented with a register as the data space.

[0053] In other words, it provides privacy-preserving communication between the data room or registry and a patient.

[0054] The proposed method enables the creation of a secure, privacy-preserving communication channel between a data space / data repository, e.g., a medical registry, and a patient. Privacy-preserving means that the registry is unable to obtain personally identifiable information (PH) about the patient that would allow the registry to match the contributed patient's data to a real identity, while still enabling authenticated and secure communication between the data space / registry and the patient.

[0055] Possible applications / areas of use in specific examples are:

[0056] 1 . Management of patient consent

[0057] 2. Answering questions for clinical trials or outcome measurement

[0058] 3. Uploading HealthKit / Google Fit or other health and / or fitness data collected on mobile devices

[0059] 4. Delivery of push notifications to patients from the registry or data store to request further information about a patient. 5. Other uses

[0060] According to one embodiment, the communication connections used in this method are secured and / or encrypted. For example, TLS security / encryption can be used.

[0061] In order for this method to work effectively, the following tips can be taken into account.

[0062] According to one embodiment, a relationship of trust exists between the identity providers (usually hospitals) and the healthcare providers (usually also hospitals).

[0063] According to one embodiment, a universal national patient identifier exists, such as the electronic health card (eKG) or "teudat zehut" in Israel.

[0064] According to one embodiment, a trust center is used that is able to provide patients in registries with permanent pseudonyms.

[0065] According to one embodiment, there is a trusted party capable of forwarding network requests at the TLS level between the patient's mobile device and the registry to avoid disclosing the patient's device IP to the registry

[0066] According to one embodiment, there is a possibility to authenticate the patient either in physical presence or in another digital way.

[0067] According to one embodiment, the identity provider is trusted.

[0068] According to one embodiment, the first handshake takes place between an identity provider (usually a hospital) and a patient app (e.g., the consent application of the patient's mobile device), in which the patient app receives a digital signature, which may, for example, contain the identity card or the medical record number.

[0069] According to one embodiment, mobile devices generate a pseudonym per registry. The pseudonym can be, for example, a random number or a random string of characters. It is used to communicate with registries—one pseudonym for each registry—and healthcare providers, preventing the registries from tracking patients across registries.

[0070] Optionally, you can register the app for push notifications or the app can register itself for push notifications.

[0071] According to one embodiment, the method comprises the step of continuously informing the patient about the use of his patient data stored in the data room by means of the consent application.

[0072] According to one embodiment, the patient can use the consent application to continuously adjust his consent to the use of his patient data stored in the data room.

[0073] According to one embodiment, the method generates a dynamic consensus / consent of the patient regarding the use of his data stored in the data room.

[0074] According to one embodiment, the method comprises the step of providing a separate, bidirectional communication between the consent application of the patient's mobile device and a hospital.

[0075] According to one embodiment, the patient data in the data room are pseudonymized.

[0076] According to one embodiment, the method further comprises the step of sending a request from a user of the data room to the patient via the bidirectional communication channel to store further patient data via the bidirectional communication channel.

[0077] According to one embodiment, the method further comprises the step of using the consent application to identify a trust authority.

[0078] According to one embodiment, the method further comprises the step of generating own, new pseudonyms by the consent application.

[0079] According to one embodiment, the method further comprises the step of generating a key pair (KR P nv, KR PU b; private / public key) by the consent application and storing the key pair, in particular on the mobile device.

[0080] In particular, the key pairs generated in this way are used for communication with the registers, whereby one key pair can be used per register. This will be explained in the context of detailed embodiments below.

[0081] According to one embodiment, the method is executed by the consent application of the patient's mobile device, by an identity provider, by an application server, by a hospital, by a registry, and by a trust authority. Non-limiting specific embodiments thereof are shown, for example, in the figures.

[0082] According to one embodiment, the method further comprises the step of confirming the identity of the patient by an identity provider.

[0083] According to one embodiment, confirming the patient's identity comprises the following steps: Requesting a cryptographically signed identity confirmation from an identity provider through the consent application of the patient's mobile device. According to one embodiment, confirming the patient's identity comprises the following steps: Issuing and sending the cryptographically signed identity confirmation by the identity provider to the consent application of the patient's mobile device.

[0084] According to one embodiment, the identity provider confirms the patient's identity personally or digitally.

[0085] According to one embodiment, the method further comprises the steps:

[0086] - Enabling the patient to select one or more hospitals from a list using the consent application on the mobile device, and / or

[0087] - Enabling the patient to select one or more registers from a list using the consent application on the mobile device.

[0088] According to one embodiment, the method further comprises the steps:

[0089] Creating a specific app patient pseudonym lÜHi per hospital for each selected hospital using the consent application of the mobile device, and

[0090] Generate a specific app patient pseudonym IDFU per registry for each selected registry using the consent application of the mobile device.

[0091] According to one embodiment, the method further comprises the step of: performing a registration of the app patient pseudonyms for push notifications.

[0092] According to one embodiment, the registration of the app patient pseudonyms for push notifications is carried out by sending the push notification ID (i.e., in the case of e.g. Apple device token or device token of the mobile device) of the mobile device together with the app patient pseudonyms to the application server.

[0093] According to one embodiment, the method further comprises the step of: generating at least one key pair (KR P nv, KR PU b; private / public key) by the consent application for each selected register, and optionally storing at least one key pair on the mobile device.

[0094] According to one embodiment, the method further comprises the steps of encrypting patient data of the patient by the mobile terminal and transmitting the encrypted data via a / the hospital to a registry.

[0095] According to one embodiment, the encryption is performed by the consent application using a public key of the register.

[0096] According to one embodiment, the method further comprises the steps

[0097] - Encryption of a specific app patient pseudonym IDRI for a specific registry by the consent application using the public key KRpub of the key pair generated for this registry (KR P nv, KR PU b; private / public key), and

[0098] - Sending to a receiving hospital the thus encrypted app patient pseudonym IDRi for the specific register together with the verified eGK number, with the app patient pseudonym of the receiving hospital and with the public key KR PU b of the key pair generated for this register (KR P nv, KR PU b; Private-ZPublic-Key).

[0099] According to one embodiment, the method further comprises the step of requesting a temporary transfer number from the trust center and transmitting the temporary transfer number from the trust center to the receiving hospital.

[0100] According to one embodiment, the method further comprises the step of transmitting the encrypted app patient pseudonym of the receiving hospital and the public key KR PU b of the key pair generated for this register (KR P nv, KR PUb; private / public key) and data from the receiving hospital to the registry. According to one embodiment, the method further comprises the step of transmitting data from the mobile terminal to the registry with the help of the trust center.

[0101] According to one embodiment, the method further comprises the step

[0102] Receiving a temporary transfer number by the consent application from the trust authority, and

[0103] Sending data from the consent application to a receiving registry together with the temporary transfer number and the app patient pseudonym lÜRi of the receiving registry and together with the public key KRpub of the key pair generated for this registry (KR P nv, KR PU b; private / public key).

[0104] According to one embodiment, the method further comprises the step of contacting the trust center by the registry to retrieve the registry-specific trust center patient pseudonym for the temporary transfer number,

[0105] According to one embodiment, the method further comprises the step of storing the app patient pseudonym and the public key KRpub of the key pair generated for this register (KR P nv, KR PU b; private / public key) under the patient’s trusted pseudonym in the register.

[0106] According to one embodiment, the method further comprises the steps

[0107] Transferring data encrypted with the private key KR P nv of the key pair generated for this register (KR P nv, KR PU b; private / public key) are signed using a proxy server, and optionally

[0108] Validation of the signature by the registry using the public key KRpub of the key pair generated for this registry (KR P nv, KR PU b; Private-ZPublic-Key).

[0109] According to one embodiment, the method further comprises the step of notifying the patient and confirming the received data. A particular, non-limiting embodiment is shown in Figure 3, in which two variants (labeled "alternative" and "variant") are shown.

[0110] Steps 1 to 14 shown in Figure 3 are a particular, non-limiting embodiment of the method for bidirectional communication between a data space, i.e., here one or more registers in which patient data is stored, and a consent application, i.e., here an "app" or "application" of a patient's mobile device, i.e., here a "patient." This method of Figure 3 enables a bidirectional communication channel between the data space / register in which the patient's patient data is or will be stored, and the consent application of the patient's mobile device, without communication between the device and the data space, without revealing the patient's identity. The embodiment of Figure 3 makes use of various previously explained embodiments of the method according to the invention.The individual steps 1 to 14 are labeled in Figure 3 according to the respective process step.

[0111] In step 1, the application, i.e. the consent application, can be downloaded and set up on the user's mobile device, for example a mobile phone. In step 2, a cryptographically signed identity confirmation can be requested from an identity provider using the consent application on the patient's mobile device. The cryptographically signed identity confirmation is then issued by the identity provider. Step 2 therefore represents an identity verification. After a successful identity verification, one or more cryptographically signed tokens (token is a standard term in cryptography, such as in a JWT) can be made available on the patient's mobile device / mobile phone. Alternatively, data and results of the identity verification, such asIdentity features such as the eGK number or the patient ID are stored under a unique internal identifier in a database of the identity provider.

[0112] In step 3 of the method of Figure 3, a specific app patient pseudonym ID Hi per hospital for each selected hospital using the consent application of the mobile device and a specific app patient pseudonym ID Ri For each selected register, a pseudonym is generated using the mobile device's consent application. Preferably, each pseudonym is sufficiently long so that an attacker cannot determine the pseudonym without much computational effort.

[0113] In step 4 of Figure 3, the app patient pseudonyms are registered for push notifications. In a preferred embodiment, the app patient pseudonyms are registered for push notifications by sending the push notification ID (e.g., in the case of Apple device tokens or the device token of the mobile device) of the mobile device together with the app patient pseudonyms to the application server.

[0114] After step 4, two different preferred embodiments are shown, labeled "alternative" and "variant." The first alternative / embodiment contains steps 5 to 8, and the second alternative contains steps 9 and 10. Using the first alternative (steps 5 to 8), the patient's patient data is encrypted by the mobile device and the encrypted data is transmitted via a hospital to a registry. Using the second alternative (steps 9 and 10), data is transmitted from the mobile device to the registry with the help of the trust center.

[0115] In steps 5 to 8 of Figure 3, the following procedural steps are implemented. In step 5, the public key for the registry is searched for and transmitted. Encryption can then be performed by the consent application using a public key from the registry. In step 6, the verified eGK number and the specific app patient pseudonym ID are transmitted. Hi for the hospital, the encrypted specific app patient pseudonym ID Ri for a specific register and the public key KR PU b of the key pair generated for this register (KR pr iv, KR PU b; Private-ZPublic-Key) to the hospital.

[0116] The verified eGK number is a special embodiment of the identity confirmation mentioned above and below. In other words, in this embodiment, the identity confirmation is a signed token that establishes the connection between the eGK number (or another "primary" identity feature such as a social security number or similar) and the patient's identity in the consent application / mobile app (and thus the patient themselves). This connection is confirmed by a trusted party via a signature.

[0117] Furthermore, in the embodiment of Figure 3, a temporary transfer number is requested and transmitted in step 7. In step 8, the encrypted app patient pseudonym of the registry and the public key KR PU bof the key pair generated for this register (KR pr iv, KR PUb; private / public key) and data are transferred from the receiving hospital to the registry.

[0118] The second alternative / embodiment contains steps 9 and 10. Here, the transmission of data from the mobile device to the registry takes place with the help of the trust center. In step 9, a temporary transfer number is requested and transmitted. In step 10, data is sent from the consent application to a receiving registry along with the temporary transfer number and the app patient pseudonym ID. Ri of the receiving register and together with the public key KR PU b of the key pair generated for this register (KR P riv, KR PU b; private / public key).

[0119] This is followed in Figure 4 by steps 11 to 14, which again apply to both previously described alternatives / embodiments. In step 11, the registry-specific trust center patient pseudonym is retrieved for the temporary transfer number. To do this, the registry contacts the trust center. Furthermore, in step 12, it is possible to retrieve the app patient pseudonym and the public key KR. PU b of the key pair generated for this register (KR P riv, KR P ub; private / public key) under the patient's pseudonym in the registry. In step 13, data is transferred using a proxy server, for example, whereby the data is encrypted with the private key KR P riv of the key pair generated for this register (KR P riv, KR PU b; Private / Public Key). Optionally, the registry can validate the signature using the public key KR PUb of the key pair generated for this register (KR P riv, KR PU b; private / public key). In step 14, the patient is notified and, if necessary, the received data is confirmed. Figure 4 shows a particular embodiment of step 14 of Figure 3. According to one embodiment, the communication connections used in Figure 3 are secured and / or encrypted. For example, TLS security / encryption can be used.

[0120] Figure 4 shows a specific embodiment of step 14 of Figure 3. The method of Figure 4 is used to notify the patient. The registry sends a message to the patient / the consent application "app" without knowing the patient's identity. The previously provided bidirectional communication channel between the terminal device and the registry (i.e., the data room) is used without revealing the patient's identity.

[0121] A particular, non-limiting embodiment is shown in Figure 5, in which two variants (marked by “Opt”) are shown.

[0122] According to a third aspect of the invention, a data processing device is provided which is configured to carry out an aforementioned method.

[0123] According to a fourth aspect of the invention, there is provided a computer program which, when running on a computer or loaded onto a computer, causes the computer to carry out the method steps of an aforementioned method; and / or a program storage medium on which the program is stored; and / or a computer comprising at least one processor and a memory and / or the program storage medium, wherein the program runs on the computer or is loaded into the memory of the computer; and / or a data stream representative of the program.

[0124] DEFINITIONS

[0125] This section provides definitions of certain terms used in this disclosure that also form part of this disclosure.

[0126] Computer-implemented method The method according to the invention is, for example, a computer-implemented method. For example, all steps or only some of the steps (ie, fewer than the total number of steps) of the method according to the invention can be carried out by a computer (eg, at least one computer). One embodiment of the computer-implemented method is a use of the computer to carry out a data processing method. One embodiment of the computer-implemented method is a method that relates to the operation of the computer such that the computer is operated to carry out one, several, or all steps of the method.

[0127] The computer comprises, for example, at least one processor and, for example, at least one memory to (technically) process the data, for example electronically and / or optically. The processor consists, for example, of a substance or composition that is a semiconductor, for example at least partially n- and / or p-doped semiconductor, for example at least one II-, III-, IV-, V-, VI- semiconductor material, for example (doped) silicon and / or gallium arsenide. The described calculation or determination steps are, for example, carried out by a computer. Determination steps or calculation steps are, for example, steps for determining data within the framework of the technical process, for example within the framework of a program. A computer is, for example, any type of data processing device, e.g., an electronic data processing device. A computer can be a device that is generally regarded as such, e.g.,Desktop PCs, notebooks, netbooks, etc., but can also be any programmable device, such as a mobile phone or an embedded processor. A computer can, for example, comprise a system (network) of "sub-computers," where each sub-computer represents a standalone computer. The term "computer" also includes a cloud computer, e.g., a cloud server. The term "cloud computer" encompasses a cloud computer system, which, for example, comprises a system of at least one cloud computer and, for example, a plurality of operatively interconnected cloud computers, such as a server farm. Such a cloud computer is preferably connected to a wide area network, such as the World Wide Web (WWW), and is located in a so-called cloud of computers, all of which are connected to the World Wide Web.Such infrastructure is used for "cloud computing," which describes computation, software, data access, and storage services where the end user does not need to know the physical location and / or configuration of the computer providing a specific service. The term "cloud" is used in this context, for example, as a metaphor for the Internet (World Wide Web). The cloud, for example, provides computing infrastructure as a service (IaaS). The cloud computer can act as a virtual host for an operating system and / or a data processing application used to execute the inventive method. The cloud computer is, for example, an Elastic Compute Cloud (EC2) such as that provided by Amazon Web Services™. A computer includes, for example, interfaces to receive or output data and / or perform analog-to-digital conversion.The data is, for example, data that represents physical properties and / or is generated from technical signals. The technical signals are generated, for example, by means of (technical) detection devices (such as devices for detecting marker devices) and / or (technical) analysis devices (such as devices for carrying out (medical) imaging procedures), wherein the technical signals are, for example, electrical or optical signals. The technical signals represent, for example, the data received or output by the computer. The computer is preferably operatively coupled to a display device that enables the information output by the computer to be displayed, for example to a user.An example of a display device is a virtual reality device or an augmented reality device (also referred to as virtual reality glasses or augmented reality goggles), which can be used as "glasses" for navigation. A specific example of such augmented reality glasses is Google Glass (a trademark of Google, Inc.). An augmented reality device or a virtual reality device can be used both to input information into the computer through user interaction and to display information output by the computer. Another example of a display device would be a standard computer monitor, for example, including a liquid crystal display operatively coupled to the computer to receive display control data from the computer and generate signals used to display image information content on the display device.A specific embodiment of such a computer monitor is a digital lightbox. An example of such a digital lightbox is Buzz®, a product of Brainlab AG. The monitor can also be the monitor of a portable, e.g., handheld device such as a smartphone, a personal digital assistant, or a digital media player.

[0128] The invention also relates to a program which, when run on a computer, causes the computer to carry out one or more or all of the method steps described herein, and / or to a program storage medium on which the program is stored (in particular in non-transitory form), and / or to a computer comprising the program storage medium, and / or to a (physical, e.g. electrical, e.g. technically generated) signal wave, e.g. a digital signal wave, carrying information representing the program, e.g. the aforementioned program, which e.g. comprises code means arranged to carry out one or all of the method steps described herein.

[0129] Within the scope of the invention, computer program elements may be embodied by hardware and / or software (this includes firmware, resident software, microcode, etc.). Within the scope of the invention, computer program elements may take the form of a computer program product, which may be embodied by a computer-usable, e.g., computer-readable, data storage medium comprising computer-usable, e.g., computer-readable program instructions, "code," or a "computer program," embodied in the data storage medium for use on or in connection with the instruction-executing system.Such a system may be a computer; a computer may be a data processing device comprising means for executing the computer program elements and / or the program according to the invention, for example, a data processing device comprising a digital processor (central processing unit or CPU) executing the computer program elements and optionally a volatile memory (for example, random access memory or RAM) for storing data used to execute and / or generated by the computer program elements. Within the scope of the present invention, a computer-usable, for example, computer-readable, data storage medium may be any data storage medium capable of containing, storing, communicating, distributing, or transporting the program for use on or in connection with the instruction-executing system, device, or apparatus.The computer-usable, e.g., computer-readable, data storage medium may be, for example, but is not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, device, or apparatus, or a distribution medium such as the Internet. The computer-usable or computer-readable data carrier could even be, for example, paper or other suitable medium on which the program is printed, since the program could be electronically captured, e.g., by optically scanning the paper or other suitable medium, and then compiled, interpreted, or otherwise processed in a suitable manner. The data storage medium is preferably a non-transitory data storage medium. The computer program product and the software and / or hardware described herein constitute the various means for carrying out the functions of the invention in the embodiments.The computer and / or data processing device can, for example, be a.

[0130] Include guidance information device which has means for outputting guidance information. The guidance information can, for example, be output to a user visually by means of a visual display means (e.g. a monitor and / or a lamp) and / or acoustically by means of an acoustic display means (e.g. a loudspeaker and / or a digital voice output device) and / or tactilely by means of a tactile display means (e.g. a vibrating element or a vibrating element built into an instrument). For the purposes of this document, a computer is a technical computer which, for example, comprises technical, e.g. material, e.g. mechanical and / or electronic components. Any device referred to as such in this document is a technical, e.g. material device.

[0131] Collecting data

[0132] The term "acquiring data" encompasses, for example (in the context of a computer-implemented method), the scenario in which the data is determined by the computer-implemented method or program. Determining data encompasses, for example, measuring physical quantities and converting the measured values ​​into data, for example, digital data, and / or calculating (and, for example, outputting) the data using a computer, and for example, within the context of the method according to the invention. The term "acquiring data" also encompasses, for example, the scenario in which the data is received or retrieved by the computer-implemented method or program (e.g., input to the program), for example, from another program, a previous method step, or a data storage medium, for example, for further processing by the computer-implemented method or program.The generation of the data to be acquired can, but does not have to, be part of the method according to the invention. The term "acquiring data" can therefore also mean, for example, waiting for the receipt of data and / or receiving the data. The received data can, for example, be fed in via an interface. The term "acquiring data" can thus also mean that the computer-implemented method or program performs steps to (actively) receive or retrieve the data from a data source, for example a data storage medium (such as a ROM, RAM, a database, a hard disk, etc.), or via the interface (for example from another computer or a network). The data obtained with the disclosed method or programData acquired by the disclosed device may be acquired from a database located in a data storage device connected to a computer for transferring data between the database and the computer, e.g., from the database to the computer. The computer acquires the data to use as input for steps of determining data. The determined data may be output again to the same or another database for storage for later use. The database or database used to perform the disclosed method may be located on a network device or network server (e.g., a cloud data storage device or cloud server) or a local data storage device (e.g., a mass storage device operatively connected to at least one computer performing the disclosed method).The data can be made "ready for use" by performing an additional step before the acquisition step. According to this additional step, the data is generated for acquisition. The data is, for example, detected or recorded (e.g., by an analysis device). Alternatively or additionally, the data is input according to the additional step, for example, via interfaces. The generated data can, for example, be input (e.g., into the computer). According to the additional step preceding the acquisition step, the data can also be made available by storing the data on a data carrier (such as a ROM, RAM, CD, and / or hard disk) in such a way that it can be used within the framework of the method or program according to the invention.The step of "acquiring data" can therefore also consist of instructing a device to acquire and / or provide the data to be acquired. In particular, the step of acquiring is not an invasive step that represents a significant physical intervention in the body, the implementation of which requires medical expertise and, even if properly performed, poses a significant health risk. In particular, the step of acquiring data, e.g., determining data, does not involve a surgical step and, in particular, does not involve a step of surgical or therapeutic treatment of a human or animal body. To distinguish the various data used in the present method, the data are referred to as "XY data" and the like (i.e.,called) and defined in relation to the information they describe, which is then preferably referred to as "XY information" and the like.

[0133] In the following, further specific embodiments and details of the aforementioned aspects of the invention are given, which are explicitly not to be understood as a limitation of the aforementioned objects defined in the claims.

[0134] 1. Introduction

[0135] Every day, the amount of health data in patient care and clinical research grows exponentially. Patients are also generating more data every day through health and wellness apps, which are incorporated into their medical care. This data has great potential: through its integration and analysis, medical care and products can be improved and lives can be saved. Digital health applications, telemedicine, wearables, and innovative technologies such as AI and IoT can only reach their full potential with comprehensive and structured health data. The goal must therefore be to utilize these large amounts of data in secondary use for the benefit of future patients and thus tailor individualized healthcare even better to the individual patient. This is necessary to overcome the challenges of demographic developments and the shortage of skilled workers, while at the same time increasing demands on the level of care.The universities also conduct cutting-edge research in the fields of biomedicine and artificial intelligence, whose global competitiveness depends on unbureaucratic, secure access to health data and an IT infrastructure capable of supporting the high complexity of this research. Successfully establishing a shared data ecosystem comprising patients, healthcare providers, academic researchers, and industrial researchers would unleash disruptive innovation potential. While the details of legally mandated health data spaces are still being debated at the national and European levels, there is currently an opportunity to demonstrate how a health data space can become a reality in the short term by cleverly linking existing projects, technologies, and a well-thought-out organizational and regulatory framework: the Framework for Data-Based Health Research.

[0136] It is crucial that citizens are at the center of the framework. Individual data protection is the decisive factor. The ethical principles for data use enshrined in Europe serve as the foundation for the implementation of a secure and useful data space. These include values ​​such as privacy, security, informational self-determination, and protection against discrimination, which are already enshrined in the General Data Protection Regulation (GDPR).

[0137] This outline first examines the legal, technical, and organizational background. Assumptions are made regarding the requirements of the stakeholders involved and international best practices are presented. From this analysis, objectives are then derived that are to be achieved through the framework. It then shows how this target vision can be achieved through the interaction of state-of-the-art technical infrastructure and an organizational and regulatory framework. Finally, it outlines how this target vision can be achieved in an iterative process, building on existing projects and initiatives, so that initial results are available after just 6 and 12 months.

[0138] This disclosure and document are also intended to provide a starting point for concrete discussions and create a common understanding of a potential target image.

[0139] 2. Objectives of the concept

[0140] The following objectives can be derived from the previous chapter:

[0141] • Establishment of a scalable health data space for primary and secondary use with exemplary character in Germany and Europe

[0142] • Place patients at the center of the data space through fine-grained consent and full transparency regarding the use of their health data

[0143] • Leveraging a unique data treasure of healthcare data, research data and patient-generated data

[0144] • Equal opportunities for academic and industrial research and development in the sense of seamless technology transfer

[0145] • Unhindered data exchange between service providers

[0146] • Building the data room on existing partial data rooms, e.g. NUM infrastructure, and efficient use of scarce human resources in the healthcare sector

[0147] • End-to-end digital, operationally efficient and scalable administrative processes

[0148] • Demand-oriented and scalable provision of current cloud technology, especially for research projects with large data volumes such as biomedical research or AI development

[0149] • Promoting Open Science through structured archiving and reuse of research data

[0150] • Connecting researchers with each other and with available data to accelerate scientific progress • Simplified and transparent legal frameworks and contractual relationships for multicenter research

[0151] • Combination of decentralized and centralized components for maximum integration and flexibility

[0152] • Connectivity to planned German and European projects (e.g. GDNG, EHDS)

[0153] • Cultural change towards a data-driven healthcare system

[0154] • Increasing the attractiveness of the location for internationally competitive health research and industry

[0155] 3. Summary target image of data flows and processes

[0156] Figure 6: Architectural sketch of the framework for data-based health research consisting of decentralized components in the hospital, a central data room, an independent trust center and governance structures.

[0157] The service providers generate and collect health data during the medical treatment of patients, with the data being stored in various IT systems. The data stream is separated in the hospital data platform: The data is stored pseudonymously in the health data repository, and the identification data is stored separately in the hospital trust office. The communication server enables the connection of most existing IT systems via standard interfaces. The service providers and researchers collecting the data manage the data available in the hospital data platform in the data portal. Efficient use of the data is enabled by access to the distributed data via the hospital data platform, which acts as a central system within the service-providing facility.After approval of a data usage request and only with patient consent, data from multiple hospital data platforms can be consolidated into a central data room. Two-stage pseudonymization takes place during transmission with the help of the central trust center. The key here is that data from the same patient can be consolidated into a single dataset, creating valuable longitudinal and interdisciplinary data sets. Data can either be collected in continuous registers—for example, medical registers of professional societies—or made available on demand in project-specific data rooms for specific research projects.If a project-specific data room was initiated by an approved research project, data users can access the data in the project-specific Trusted Research Environment, using commercially available analysis software or conducting customized, complex analyses with the provided data. A comprehensive audit log continuously records processing in the Trusted Research Environment to verify whether research activities comply with all required guidelines and patient consent status. The data used for research, as well as any research results, can be stored in the archive for subsequent use.

[0158] Researchers can request data use by completing a fully digitalized and easy-to-follow application process with a short processing time in an application portal. Depending on the risks associated with the project, the required approvals may vary. The central research proposal committee reviews and approves eligible data use applications. In most cases, a separate review by an independent ethics committee is required. The central, automated data repository contains metadata on all data available in the hospital data platforms and continuous registers, along with their access modalities. Potential data users can use the repository and the forum to obtain information on data availability and access modalities.

[0159] An interdisciplinary data committee is responsible for the governance of the framework. As a regulatory body, the data committee must be independent of the research proposal committee and ethics committee.

[0160] 4. Decentralized Components in Hospitals: The integration of available data at the level of each service-providing facility, along with the central cloud infrastructure of the central data room, represents a crucial component. This is relevant not only in the context of secondary use, but also in the context of the changing IT landscape in healthcare. With the increasing modularization of the IT landscape, as has long been the case in other industries, the integration of legacy systems and modular systems with each other is becoming a crucial task. The architecture of the decentralized (internal hospital) component should therefore be suitable not only for secondary use, but also, in the long term, for primary care.

[0161] A fully centralized infrastructure has been deliberately avoided. On the one hand, this complies with established security concepts, and on the other, the decentralized component is intended to promote trust among service providers in the framework. Decentralized components facilitate connection to local systems and prevent system disruptions, thus increasing user-friendliness and acceptance. At the same time, centralized components allow for advantages such as cross-hospital pseudonymization. It is also important that data storage always takes place within the European Union.

[0162] Even smaller hospitals should be able to participate in data spaces with the help of preconfigured and easily integrated solutions and a strong focus on automation. The goal is to enable non-university hospitals (and potentially also private practice providers) not only to collect data but also to have the opportunity to research their own questions, for example, regarding process optimization or quality assurance. This is of great importance for the success of the framework, as 90% of all inpatient stays in Germany take place in non-university hospitals, and thus a large portion of the data is generated there. 1 .

[0163] Therefore, every hospital IT system should be equipped with a uniform technical basis – the hospital data platform – which (1) automatically transfers data into a secure database. If a facility already has a hospital data integration center, this can be connected as a data source.

[0164] 'German University Hospitals. (nd). The Contribution of German University Hospitals to the Healthcare System. Retrieved on September 24, 2023, from https: / / www.uniklinika.de / die-deutschenumversitaetsklinika / zahlen-und-fakten / . Furthermore, (2) research-based service providers can conduct research directly with the pseudonymized data of the service-providing institution in an internal hospital research environment. The hospital data platform (3) handles the pseudonymization and forwarding of the data to the central data rooms with the assistance of the central trust office, and (4) data-collecting service providers have the option of managing access rights to the data they collect via the data portal.

[0165] Essentially, clinical data from all hospital IT systems is integrated in FHIR format. The hospital data platform can be installed on local IT infrastructure. For internally pseudonymized data, an encrypted cloud solution can also be used in appropriate cases (e.g., for scalability reasons). On the hospital data platform, the identification data is separated from the other data in the first processing step and stored in encrypted form in the hospital's trust center. Further internal use of the data is then generally only permitted with the assigned pseudonym, and the identification data can only be accessed with appropriate authorization if necessary.

[0166] A core strength of the hospital data platform is that, with the help of suitable software, the collected data can be used directly within the service-providing facility for research projects or for internal hospital process optimization and quality assurance.

[0167] In addition, data-collecting service providers and researchers at the service-providing institution can manage the data sets they have collected via the data portal, for example, managing access rights or answering queries from the application portal. From the hospital data platform, health data can be transmitted to continuous registers and project-specific data rooms using a pseudonym assigned by the central trust office. Hospital-specific configurations may be necessary.

[0168] Essentially, the hospital data platform can consist of or include parts of the following components: Communication servers ensure integration with a hospital's IT systems, including legacy systems that do not support the hospital data platform's standard interfaces. These servers should be capable of handling large volumes of data and support various data formats and transmission protocols. Furthermore, real-time data transmission is required, and it must be ensured that data transmission always complies with strict security standards.

[0169] The hospital data platform pseudonymizes the data in collaboration with the hospital trust office before it is stored. While the identification data remains on-site at the hospital trust office, the pseudonymized data can also be stored in a cloud – in compliance with legal requirements. Access to the identification data for de-pseudonymization is restricted to authorized users.

[0170] The identification data remains in the highly secure hospital trust center. Strict access controls and authentication methods are implemented for authorized users. Furthermore, data activity is logged, and both at-rest and in-transit data is encrypted.

[0171] The healthcare data repository primarily supports the healthcare data formats FHIR and DICOM web and features cloud connectivity to handle growing data volumes. Secure data access and transfer protocols are also crucial here.

[0172] The data portal provides data-collecting service providers and researchers with a clear overview of all processed data and enables the management of access rights. An audit log for all data activities is also integrated. Furthermore, the transfer of metadata to a central data directory is enabled, supporting both automated metadata creation and manual metadata modification. An interface for offering data in the data directory and forum of the application portal is essential, as is an intuitive user interface.

[0173] The hospital's internal research environment provides tools for performing processes such as data aggregation, data normalization to a unified digital patient model, the application of algorithmic systems, quality control processes, and linking data with other datasets. The hospital data platform supports the SMART on FHIR standard, which enables the secure integration of custom software and thus the analysis of more specific questions. SMART on FHIR applications can be easily developed both internally and externally within the hospital. Corresponding commercially available applications are also available.

[0174] During transfer pseudonymization and data extraction, the data are filtered based on the data use certificates issued by the research proposal committee and the patient consent status. The data records of the resulting data stream are pseudonymized with the assistance of the central trust center and transmitted to the ongoing registries and project-specific data rooms. End-to-end encryption ensures the security and protection of the data during this process. Furthermore, the status and progress of the transfer pseudonymization and transfer process are displayed in real time on the data portal.

[0175] 5. Central component for data room

[0176] Based on state-of-the-art big data technology capable of organizing and separating data according to project approvals, a cloud-based data storage and processing component will be implemented. This will ensure that data users only have access to data approved by the research proposal committee. This will avoid unnecessary and costly data replication and adhere to the principle of data minimization. Data retention will also be deliberately avoided.

[0177] In general, a distinction can be made between continuous registers and project-specific data spaces, which are created as needed for specific research projects. Data can be accessed in a project-specific Trusted Research Environment (TRE), which can be used with commercial analysis software or with complex analyses, for example, using AI methods.

[0178] In certain cases, the release of data sets may be necessary for research projects. This may be essential, for example, for the approval of AI-based medical devices, whose verification and validation require data release. Here, too, regulatory and technical measures should be combined into a trustworthy process. For example, data users should be required to provide certification from a notified body during the application process.

[0179] The architecture comprises various central data rooms, which can be set up as both ongoing registries and project-specific data rooms. Pseudonymized health data are consolidated in these data rooms for the duration of the research project. To ensure the timeliness and relevance of this data, connectors are used that monitor patient consent in real time and integrate the central trust point for pseudonymization. The access control component ensures that data access complies with the submitted data usage certificate and the requirements defined by the data committee. Data access is enabled through data room interfaces. Project-based data organization in virtual data rooms avoids unnecessary and costly data replication.

[0180] In the Trusted Research Environment, users can access a variety of analysis tools, with special security measures implemented. Strict access management ensures that only authorized users can access the data, in accordance with the respective data usage certificate.

[0181] The audit log records all activities that occur in the data room. Audit logs are archived for a specified period of time. If certain activities or anomalies considered critical are detected, the system automatically sends notifications to the relevant departments.

[0182] The provision of storage and computing capacity should be independent of each other, flexible and on-demand, and billable on a usage-based basis. The infrastructure must meet high security requirements, including encryption and strict access management. Data sovereignty must also be ensured, for example, within a sovereign cloud. It must integrate seamlessly into both the data-providing IT infrastructure of the service-providing institutions and that of potential data users. The same or a different provider should also be selected following the same selection process to provide storage capacity for the long-term storage of research data.

[0183] Figure 7: Process diagram of query functions in the data room.

[0184] 6. Central trust point for pseudonymization

[0185] Before transmission to the data rooms, a two-stage pseudonymization process is performed with the help of the central trust center. This offers the advantage of merging patient data from multiple healthcare providers longitudinally using consistent pseudonyms, thus avoiding duplication.

[0186] The two-stage pseudonymization process is based on the concept envisioned in the Implant Register Establishment Act: Identification data is sent to the central trust office, which provides the data-providing clinic with a work number for the respective dataset. Using this work number, the data is transmitted to the central data room, where it is assigned the final pseudonym requested from the central trust office. This ensures that the final pseudonym is not known to the data-providing clinic. This process is already followed by the knee and hip register "Endoprosthesis Register Germany" of the German Society for Orthopaedics and Orthopaedic Surgery, which has been collecting data from approximately 1.6 million patients for around 10 years in coordination with all state data protection officers. 2 .

[0187] In all cases where patient data are aggregated longitudinally, the consent form must also allow for migration to a new trust body. In the future, it can be assumed that a multinational European body, such as the EMA, will take over pseudonymization in order to be able to aggregate data from patients treated across borders.

[0188] Figure 8: Process diagram for pseudonymization via a central trust point.

[0189] 2 Endoprosthesis Register Germany. (2021). Annual Report 2021: More Quality. Retrieved on September 24, 2023, from https: / / www.eprd.de / fileadmin / user_upload / Dateien / Publikationen / Berichte / Jahresbericht2021_2021- 10-25_F.pdf. 7. Uniform end-to-end digital application process

[0190] Figure 9: Data usage request process diagram.

[0191] The application process is designed to ensure that data is used only for scientifically sound, socially relevant, technically feasible, ethically, and legally permissible projects. Bureaucratic hurdles and inefficiencies are to be reduced by conducting the entire planning and application process for a research project involving health data on a single platform in a seamless digital process. Redundancies, such as those resulting from different templates for study protocols at the participating review bodies, are to be eliminated. Data availability, approval criteria, and any applicable processing fees are to be presented transparently from the outset. Those involved in the application process should be able to review applications quickly and asynchronously. Necessary changes should also be possible at short notice. Since an increasing number of applications is expected, the platform is intended to automate individual review steps wherever possible.

[0192] The application portal serves as a central online platform for researchers and reviewers, with the goal of digitizing the entire application process from submission to approval. This contributes to making the process efficient, reliable, and secure. Particular attention is paid to creating interfaces to existing software tools, such as the "ethics pool" tool used by ethics committees, while avoiding non-digital disruptions. The application portal also includes a data directory and a forum. These allow researchers to present their projects and search for collaboration partners.

[0193] A central feature of the application portal is a user management system. It allows the creation, management, and deletion of user accounts. To ensure data security and integrity, role-based access controls are implemented. This ensures that users only have access to information and functions relevant to them. Researchers benefit from a user-friendly interface that facilitates the submission and tracking of applications. Automatic notifications can also be sent here when application status changes.

[0194] The integration of a data repository helps researchers define their projects precisely. Search and filter functions allow them to identify specific data sets. Semi-automated reviews are planned to further optimize the review process. The application portal also offers communication and collaboration tools that enable direct exchange between researchers and reviewers.

[0195] A high level of security is achieved through end-to-end encryption, multi-factor authentication, strict password policies, and regular security audits. The application portal is designed to remain performant even with an increasing number of applications, supported by a cloud-based architecture. For approved research projects, a digital data usage certificate is created. This certificate contains all important details about the research project, including its identification, data description, and data protection requirements, in a machine-readable format and is digitally signed. Security, integrity, and clear notification protocols are emphasized during transmission. The data usage certificate is transmitted to the hospital data platforms, the data room operator, and the patient data cockpit.

[0196] Researchers can describe their projects in detail in the application portal's forum. An integrated messaging function promotes communication between researchers and interested parties. A rating system ensures transparency and quality. Projects may only be published after a certain embargo period. Automatic categorization of the research project based on the project information ensures error-free assignment, analogous to the patient consent categories.

[0197] 8. Central consent management for fine-grained patient consents. Patients' right to informational self-determination can be realized through fine-grained digital patient consent based on a further development of MH's Broad Consent. Patients should be able to manage their data sharing in a simple mobile application and, at the same time, view information about data sharing in general, as well as data usage. The patient's consent status for each data element is communicated to the hospital data platform to ensure that only the information corresponding to the consent is shared. The validity of the consent should extend across all service-providing facilities, thus avoiding redundant decision-making. The consent application must be transparent and easy to use for all members of society.Patients also have the option to provide their consent at a level of granularity of their choosing, including or excluding specific user segments, data types, and purposes of use. This also makes it possible to exclude particularly sensitive data, such as data related to mental health, from consent and to differentiate between the release of anonymized individual data sets or the aggregation of their data sets with other patient data sets.

[0198] A mobile consent app for patients enables discussion and decision-making regarding data sharing, independent of treatment. This digital application must meet high security requirements, permit real-time data exchange, and support digital signatures. This not only creates transparency but also encourages ongoing engagement with data usage. In the future, this could even lead to dynamic consent.

[0199] Appropriate consultations from trained staff, public relations campaigns, and recommendations from professional associations are intended to complement the digital implementation at the patient's fingertips to ensure informed and certain information. The goal is to ensure that consent status can be changed at any time, with the certainty that every hospital data platform will reflect these changes in real time.

[0200] While there is a debate going on at national and European level about whether, out of convenience, we should simply ignore the will of citizens and release health data for research without consent, it can be shown here that citizens, on the one hand, understand consent and, on the other hand, also give it and, with their data, lay the foundation for better treatment of our children and grandchildren.

[0201] 9. Repository for archiving, provision and reuse

[0202] Data used for research should be secured for at least 10 years according to the DFG guidelines, whereby archiving can take place in the institution itself or in a suitable repository 3The aim is, on the one hand, to document data relevant to the creation of a research result. On the other hand, the data should be made available for subsequent use, for example, replications or meta-studies. To enable subsequent use, the research data must be archived together with their contextual information (e.g., survey instruments and analysis tools), and processed data must be available in a structured form - only then can the data be managed in a way that is easy to find. If there are no applicable data models defined by the data committee for the data used for the research, the data committee should examine the standardization of the data model used, and the metadata catalog should be continuously expanded. In addition, a link to the raw data on which the analysis was based must be established.For this reason, the data room operator should establish a repository. Access to the data for subsequent use should be via the application portal. Subsequently, protected access should be possible via the register and the Trusted Research Environment. Prior to archiving, further archive-specific pseudonymization can be performed via the central trust office. The storage costs should be requested in research projects. For this purpose, particularly cost-effective yet secure storage capacity should be rented from the data room operator. The usage rights are transferred to the data room operator via a standard contract. The publication date can be agreed upon upon transfer of the usage rights.

[0203] 3 German Research Foundation (DFG) (2019). Guidelines for Ensuring Good Scientific Practice.

[0204] German Research Foundation. Retrieved on September 24, 2023, from https: / / www.dfg.de / download / pdf / foerderung / rechtliche_rahmenbedingungen / gute_wissenschaftliche_praxis / ko dex_gwp.pdf. However, this should not be more than 12 months in the future. In justified cases, the data may be restricted from use, for example, if specific research questions are still being addressed or if a publication or other use is pending. However, researchers should also be given the opportunity to object to archiving for specific reasons.

[0205] In the future, hospital data platforms should also be able to carry out structured archiving of raw data. In this case, the data protection periods for personal data must be observed. After the death of the data subject, a protection period of 10 years applies, or if the year of death is unknown, 100 years after the data subject's birth. If neither the year of death nor the year of birth can be determined with reasonable effort, the protection period ends after 60 years. 4 .

[0206] The public repository presented in this section would add another decisive unique selling point to the framework and corresponds to the Open Science approach 5 The repository should be based on the already published standards of the National Research Data Infrastructure (e.g. Base4NFDI) and thus be compatible with the emerging infrastructure 6 .

[0207] 10. Expansion stage 1

[0208] Figure 10: Graphical representation of the functionality at the end of Phase 1.

[0209] The technical partner has implemented an initial version of the digital data cockpit for patients. This was established by the data room operator in a pilot clinic. The first pilot clinic was equipped with the hospital data platform, which features a communications server, a health data repository, a data portal, and general infrastructure such as SMART on FHIR, IAM, and audit trail, as well as connections to PACS, LIS, HIS, and interfaces for data retrieval. The test of the clinic's internal

[0210] 4 Schaar, K. (2017). Informed consent as a prerequisite for the (re-)use of research data. German Council for Social and Economic Data. Retrieved on September 24, 2023, from https: / / www.konsortswd.de / wp-content / uploads / RatSWDWP264.pdf.

[0211] 5UNESCO. (nd). Open science: Making science more accessible, inclusive and equitable for the benefit of all. Retrieved September 24, 2023 from https: / / www.unesco.org / en / open-science?hub=686.

[0212] 6 NFDI. (nd). National Research Data Infrastructure. Retrieved on September 24, 2023, from https: / / www.nfdi.de / base4nfdi / . The research environment has been initiated. A cybersecurity review and test have also been completed.

[0213] Table 2: Work packages and milestones within the workstreams in Phase 1.

[0214] Work packages Milestones

[0215] WP 3.2: Implementation of a data cockpit Implementation of a digital data cockpit for patient consent management Digital consent management established at a pilot clinic

[0216] WP 3.3: Uniform technical equipment of the first pilot clinics with

[0217] Infrastructure for UKs and 6 non-hospital data platforms (communication servers, university pilot clinics health data storage, data portal, general infrastructure such as SMART on FHIR, IAM and Audit Trail, connection to PACS, LIS, HIS and

[0218] Interfaces for data retrieval)

[0219] Test of the in-house research environment started

[0220] WP 3.9: Cybersecurity Test Cybersecurity review of the system Cybersecurity test completed

[0221] 11. Expansion stage 2

[0222] Figure 11: Graphical representation of the functionality at the end of Phase 2.

[0223] A digital application process was implemented within the application portal. The data cockpit for patients was embedded in an information platform. All

[0224] Pilot hospitals were equipped with the hospital data platform. This hospital data platform was supplemented with an internal hospital trust center. A project-specific data room was also established for the first time. The trust center was equipped with basic functions for data transmission and can generate pseudonyms. Furthermore, the consent status can be transmitted to the hospital data platforms. Table 3: Work packages and milestones within the workstreams in Phase 2.

[0225] Work packages Milestones

[0226] WP 3.1 : Implementation of the application portal Implementation of the digital application process

[0227] WP 3.2: Implementation of a data cockpit Embedding the data cockpit in a patient information platform on secondary use and research projects

[0228] WP 3.3: Uniform technical equipment of all pilot clinics with

[0229] Infrastructure for UKs and 6 non-hospital data platform university pilot clinics (communication server,

[0230] Health data storage, data portal, general

[0231] Infrastructure such as SMART on FHIR, IAM and Audit

[0232] Trail, connection to PACS, LIS, HIS and

[0233] Interfaces for data retrieval, hospital-internal trust center)

[0234] WP 3.4: Implementation of the central creation of a project-related data room Data provision infrastructure and research environment

[0235] WP 3.5: Technical design of the implementation of basic functions (generating and managing pseudonymous trust centers)

[0236] Consent status can be sent to the

[0237] Hospital data platform

[0238] WP 3.6: Implementation of a leased long-term storage and resilient backup infrastructure

[0239] WP 3.9: Cybersecurity Test Cybersecurity Test completed

[0240] 12. Expansion Stage 3 The application process has been partially automated, so that, for example, formal reviews can run automatically. The data directory has been integrated into the application portal, allowing applicants to submit feasibility requests directly in the data directory. The data committee has published guidelines for archiving and reuse. Based on these guidelines, the application portal has been expanded to include a function for submitting reuse requests. An accessible version of the patient information and consent form has been developed, as well as a concept for using the consent processes for specific consents and dynamic consent. The latter has been implemented in the data cockpit. Furthermore, a concept for migrating the trust office has been developed. A storage facility has been rented for archiving research data and hospital data platform holdings. The archive has been connected to the data directory.Another cybersecurity test was successfully completed. The data room is fully developed and features an audit log, a trusted authority connection, and a trusted research environment.

[0241] Table 4: Work packages and milestones within the workstreams in phases 3 and 4.

[0242] Work packages Milestones

[0243] WP 3.1 : Implementation of the application portal Partial automation of the application process

[0244] Integration of the data directory

[0245] Submission of applications for subsequent use possible

[0246] WP 3.2: Implementation of a data cockpit. Accessible versions of patient information and patient consent developed.

[0247] Concept for specific consents or dynamic consents developed

[0248] Specific and dynamic consents implemented

[0249] WP 3.4: Implementation of the central expansion of the data room completed (audit log, data provision infrastructure and trust point connection) Research environment Expansion of the Trusted Research Environment completed

[0250] WP 3.5: Technical design of the active patient approach possible Trust office Concept for migration of the trust office developed

[0251] AP 3.6: Implementation of a leased storage long-term storage and resilient back-up connection to data directory completed up infrastructure

[0252] WP 3.7: Establishment and establishment of the data room operator concept for roll-out in all hospitals developed

[0253] WP 3.8: Technical design of the trust center can transmit data usage to the trust center data cockpit

[0254] WP 3.9: Cybersecurity Test Cybersecurity Review Completed

[0255] Cybersecurity test completed

Claims

CLAIMS 1. Computer-implemented method for separating identification data from personal health data, the method comprising the steps - Receiving personal health data from a system that collects health data, the personal health data consisting of identification data and other data, the method further comprising the steps of: - Separating the identification data from the personal health data, whereby the health data is divided into the identification data and the other data, - Adding a pseudonym to the other data to generate pseudonymized data, - Storing the identification data in a first data room, - storing the pseudonymized data in a second data space, wherein the first and second data spaces are different data systems that are independently controllable or manageable, and the method comprising the step - Providing the identification data and the pseudonymized data to a user via the same interface.

2. The method according to claim 1, the method further comprising the steps: - Receiving a user request for retrieving at least part of the identification data and / or at least part of the pseudonymized data, wherein upon receiving the user request, information on a role of the requesting user with regard to a use of the requested data is also received, the method further comprising the steps: - Determining the data in the first and / or second data space that may be transmitted to the user based on the received information on the role of the requesting user with regard to the use of the requested data, and - Transmission of information about the requested data to the user and / or transmission of at least part of the previously determined data to the user.

3. The method according to claim 2, wherein the receiving of the user request occurs through the interface, and / or wherein the transmission of the specific data occurs through the interface.

4. The method according to claim 2 or 3, wherein when determining the data that may be transmitted to the user based on the received information on the role of the requesting user with regard to the use of the requested data, a further attribute is additionally taken into account, in particular a stored consent of the person from whom the health data originate.

5. The method according to any one of the preceding claims, wherein the first and second data spaces - are designed as separate storage media or are provided using separate storage media, - are located at different geographical locations, and / or - are implemented as different areas of a cloud storage.

6. The method according to any one of the preceding claims, - using a single interface.

7. The method according to any one of the preceding claims, - where the interface is implemented as a FHIR interface and / or as a DICOM web interface.

8. The method according to any one of the preceding claims, - wherein the first and second data spaces each have only one data input and one data output.

9. The method according to any one of the preceding claims, wherein the system that collects health data is a hospital, a laboratory, a PACS, and / or a HIS.

10. A method for bidirectional communication between a data room in which patient data is stored and a consent application of a patient’s mobile terminal, the method comprising the step - Providing a bidirectional communication channel between the data room in which the patient's patient data is stored and the consent application of the patient's mobile device, whereby the bidirectional communication between the device and the data room takes place without revealing the patient's identity.

11. The method of claim 10, the method further comprising the step - Continuously inform the patient about the use of his or her patient data stored in the data room using the consent application.

12. Method according to claim 10 or 11, - whereby the patient can continuously adjust his consent to the use of his patient data stored in the data room using the consent application.

13. The method according to any one of claims 10 to 12, wherein the method generates a dynamic consensus / consent of the patient regarding the use of his / her data / patient data stored in the data room.

14. The method according to any one of claims 10 to 13, the method comprising the step - Providing separate, bidirectional communication between the patient's mobile device consent application and a hospital.

15. The method according to any one of claims 10 to 14, wherein the patient data are pseudonymized in the data space.

16. The method according to any one of claims 10 to 15, the method further comprising the step - Sending a request from a data room user to the patient via the bidirectional communication channel to store additional patient data via the bidirectional communication channel.

17. The method according to any one of claims 10 to 16, the method further comprising the step - Using the consent application to identify or select a trusted authority.

18. The method according to any one of claims 10 to 17, the method further comprising the step of Creation of your own, new pseudonyms through the consent application.

19. The method according to any one of claims 10 to 18, the method further comprising the step of - Generation of a key pair (KR P nv, KR PU b; private / public key) by the consent application and storing the key pair, in particular on the mobile device.

20. The method according to any one of claims 10 to 19, wherein the method is executed by the consent application of the patient's mobile terminal, by means of an identity provider, by means of an application server, by means of a hospital, by means of a registry, and by means of a trust center.

21. Method according to one of claims 10 to 20, the method comprising the step Confirming the patient's identity through an identity provider.

22. The method of claim 21, wherein confirming the patient’s identity comprises the following steps: Requesting a cryptographically signed identity confirmation from an identity provider through the consent application on the patient's mobile device.

23. The method according to claim 21 or 22, wherein confirming the patient's identity comprises the following steps: issuing and sending the cryptographically signed identity confirmation by the identity provider to the consent application of the patient's mobile device.

24. The method according to any one of claims 21 to 23, wherein the identity provider confirms the patient’s identity personally or digitally.

25. The method according to any one of claims 10 to 24, the method comprising the step Enabling the patient to select one or more hospitals from a list using the consent application on the mobile device, and / or Enabling the patient to select one or more registers from a list using the consent application on the mobile device.

26. The method according to claim 25, the method further comprising the steps of generating a specific app patient pseudonym ID H ipro Hospital for each selected hospital using the consent application on the mobile device, and Generating a specific app patient pseudonym ID R i per register for each selected register using the consent application of the mobile device.

27. The method of claim 26, the method further comprising the step of performing a registration of the app patient pseudonyms for push notifications.

28. The method according to claim 27, wherein the registration of the app patient pseudonyms for push notifications is carried out by sending the push notification ID of the mobile terminal together with the app patient pseudonyms to the application server.

29. The method according to any one of claims 25 to 28, the method comprising the step Generation of at least one key pair (KR P nv, KR PU b; Private-ZPublic-Key) by the consent application for each selected register, and optionally storing at least one key pair on the mobile device.

30. Method according to one of claims 10 to 29, the method comprising the step Encryption of patient data using the mobile device and transmission of the encrypted data via a hospital to a registry.

31. The method according to claim 30, wherein the encryption is performed by the consent application using a public key of the registry.

32. The method according to claim 30 or 31, the method further comprising the steps: Encrypting a specific app patient pseudonym ID Rifor a specific register by the consent application using a public key of the register; and Sending, to a receiving hospital, the thus encrypted app patient pseudonym IDRi for the specific register together with the verified eGK number, with the app patient pseudonym of the receiving hospital and with the public key KR PU b of the key pair generated for this register (KR pr iv, KR PU b; Private-ZPublic-Key).

33. A method according to any one of claims 30 to 32, the method further comprising the steps Request a temporary transfer number from the trust office and transfer the temporary transfer number from the trust office to the receiving hospital.

34. The method of claim 33, the method further comprising the steps Transmitting the encrypted app patient pseudonym of the receiving hospital and the public key KR PU b of the key pair generated for this register (KR P riv, KR PU b; private / public key) and data from the receiving hospital to the registry.

35. Method according to one of claims 10 to 29, the method comprising the step Transmission of data from the mobile device to the register with the help of the trust center.

36. The method of claim 35, the method comprising the steps of receiving a temporary transfer number by the consent application from the trust center, and Sending data from the consent application to a receiving registry along with the temporary transfer number and the app patient pseudonym ID Ri of the receiving register and together with the public key KR PUb of the key pair generated for this register (KR pr iv, KR PU b; private / public key).

37. The method according to any one of claims 10 to 36, the method further comprising the steps Contacting the trust office by the registry to retrieve the registry-specific trust office patient pseudonym for the temporary transfer number, 38. Method according to claim 37, the method further comprising the step of storing the app patient pseudonym and the public key KR P ub of the key pair generated for this register (KR P riv, KR PU b; private / public key) under the patient's pseudonym in the registry.

39. The method according to claim 38, the method further comprising the steps of transmitting data encrypted with the private key KR P riv of the key pair generated for this register (KR P riv, KR PUb; private / public key) are signed using a proxy server, and optionally Validation of the signature by the registry using the public key KR P ub of the key pair generated for this register (KR P riv, KR PU b; private / public key).

40. The method of claim 39, the method further comprising the step of notifying the patient and confirming the received data.

41. Data processing device configured to carry out the method according to one of the preceding claims.

42. A computer program which, when running on or loaded onto a computer, causes the computer to perform the method steps of the method according to any one of claims 1 to 40; and / or a program storage medium on which the program is stored; and / or a computer comprising at least a processor and a memory and / or the program storage medium, wherein the program runs on the computer or is loaded into the computer's memory; and / or a data stream representative of the program.

Images