Computer-implemented method for splitting identification data from personal health data

Abstract

Computer-implemented method for extracting identification data from personally identifiable health data, the method comprising the steps - Receiving personally identifiable health data from a system that collects health data, where the health data relating to individuals consists of identification data and other data, the procedure further showing the steps: - Extracting the identification data from the personally identifiable health data, thereby splitting the health data into the identification data and the other data, - Adding a pseudonym to the additional data to generate pseudonymized data, - Storing the identification data in an initial data space, - 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.

Description

FIELD OF THE INVENTION

[0001] 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. TECHNICAL BACKGROUND

[0002] 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 captured digitally, replacing paper-based processes), and more specific data (such as genomic data) that were previously rarely collected are being stored regularly.

[0003] 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.

[0004] 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).

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

[0006] 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.

[0007] 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.

[0008] 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).

[0009] Problem: Privacy by Design vs. Organizational Measures as Special Protection: Data at rest and data in motion are now encrypted 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 in use follow the same rules, which is rarely the case in reality. GENERAL DESCRIPTION OF THE INVENTION

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

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

[0012] 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.

[0013] 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.

[0014] 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.

[0015] 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: - Receiving personal health data from a system that collects health data, wherein the personal health data consists of identification data and other data, the method further comprising the steps: - 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 pseudonymised data in a second data room, wherein the first and second data spaces are different data systems that can be controlled or managed independently of each other, and the method comprising the step - Providing the identification data and the pseudonymized data to a user via the same interface.

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

[0017] 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 then 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.

[0018] According to one embodiment, the method further comprises 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.

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

[0020] 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 is correct.

[0021] According to one embodiment, the first and second data spaces - are designed as separate storage media or are provided using separate storage media, - located at different geographical locations, and / or - executed as different areas of a cloud storage.

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

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

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

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

[0026] 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.

[0027] Fig.1: Example: Identification data is separated without adapting the standard interfaces (solution sketch)Standard interface (API)

[0028] The system according to the invention can be connected to systems outside the system context via standard interfaces. In this case, the solution outline distinguishes between data-collecting systems and data-consuming systems. However, this is not necessary, as these are connected via the same interface (the interface is shown twice in the solution outline only for simplicity). Common standard interfaces, such as FHIR, DICOM DIMSE, DICOM web, and GA4GH, can be used.

[0029] The standard interfaces can be implemented in such a way that uniform access control based on a user token can be implemented, transparently for the data-using systems. In particular, it can be considered 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).

[0030] 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. Table 1 Access control based on user token and other criteria Requirements for data access met User token authorizes access to identification data Result for the data stream Yes Yes Full data access (equivalent to primary data) Yes No Pseudonymized data (without identification data) No Yes No access No No No access

[0031] 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, generated 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.

[0032] Regarding the health data storage, the following should be noted: The health data storage can be software that stores data without identifying data. Various technical systems can be used to secure the data to enable technical and economic scaling. In particular, cloud systems can also be used.

[0033] The following should be noted regarding the hospital's internal trust center: The hospital's 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 secure data room. Access to the data can be restricted to users with the appropriate authorization. The hospital's internal trust center can be managed organizationally and technically separately from the health data repository. Implementation details using FHIR as an example

[0034] Fig. 2: Separation of identifying data from FHIR data glossary Personal health data May include data relating to the health status of a data subject, revealing information about the past, present, and future physical or mental health status of the data subject. In the context of this document, this also includes genetic data and other data collected in patient care or medical research. Identification data Data that can be used to identify a person, such as name, date of birth or EGK. Data Data is a collection of facts. Facts are referred to as data points. (Syntax) Personal data Data relating to an identified or identifiable natural person. information Information is created through the interpretation, organization, processing, or structuring of data in a specific context. (Semantics) Primary data Data that has been collected or generated to solve a specific problem. For example, in the healthcare sector, data for documenting a Patient treatment primary data as it is necessary for the implementation of the treatment process. Secondary data Using existing data to generate additional data based on the existing data. For example, in the healthcare sector, care data can be evaluated for statistical analyses and medical research. Data-at-rest Data that is permanently stored on a medium. See Data-in-motion. Data in motion Data that is transported over a medium (e.g., a computer network). The data is only temporarily available on the medium used. TOMs Technical and organizational measures. Data protection by design The specific requirements of data protection are taken into account at an early stage. This term is used particularly when expressing the legitimate nature of the data processing that actually takes place. In the context of this report, it is used synonymously with "privacy by design." Privacy by design See Data protection by design, where privacy by design primarily refers to the protection of privacy. In the context of this report, it is used synonymously with data protection by design.

[0035] 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 - 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, where bidirectional communication takes place between the terminal device and the data room without revealing the patient's identity.

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

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

[0038] 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 (PII) 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.

[0039] Possible applications / areas of use in specific examples are: 1. Managing patient consent 2. Answering questions for clinical trials or outcome measurement 3. Uploading HealthKit / Google Fit or other health and / or fitness data collected on mobile devices 4. Delivery of push notifications to patients from the registry or data store to request further information about a patient. 5. Other uses

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

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

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

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

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

[0045] 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

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

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

[0048] 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.

[0049] 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.

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

[0051] 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.

[0052] 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.

[0053] 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.

[0054] 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.

[0055] According to one embodiment, the patient data in the data room is pseudonymized.

[0056] 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.

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

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

[0059] According to one embodiment, the method further comprises the step of generating a key pair (K Rpriv , K Rpub; private / public key) by the consent application and storing the key pair, in particular on the mobile device.

[0060] 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.

[0061] 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.

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

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

[0064] 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.

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

[0066] According to one embodiment, the method further comprises the steps: - 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.

[0067] According to one embodiment, the method further comprises the steps: Generating a specific app patient pseudonym ID Hi per hospital for each selected hospital using the consent application of the mobile device, and Generating a specific app patient pseudonym ID Ri per register for each selected register using the consent application of the mobile device.

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

[0069] According to one embodiment, the registration of the app patient pseudonyms for push notifications is carried out by sending the push notification ID (ie, 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.

[0070] According to one embodiment, the method further comprises the step: Generate at least one key pair (K Rpriv , K Rpub ; private / public key) by the consent application for each selected register, and optionally storing at least one key pair on the mobile device.

[0071] 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.

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

[0073] According to one embodiment, the method further comprises the steps - Encrypting a specific app patient pseudonym ID Ri for a specific register by the consent application using the public key K Rpub of the key pair generated for this register (K Rpriv , K Rpub ; private / public key), and - Sending the encrypted app patient pseudonym ID to a receiving hospital Rifor the specific register together with the verified eGK number, with the app patient pseudonym of the receiving hospital and with the public key K Rpub of the key pair generated for this register (K Rpriv , K Rpub ; private / public key).

[0074] 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.

[0075] 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 K Rpub of the key pair generated for this register (K Rpriv , K Rpub ; private / public key) and data from the receiving hospital to the registry.

[0076] According to one embodiment, the method further comprises the step of transmitting data from the mobile terminal to the register with the aid of the trust center.

[0077] According to one embodiment, the method further comprises the step Receiving a temporary transfer number by the consent application from the trust authority, 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 K Rpub of the key pair generated for this register (K Rpriv , K Rpub ; private / public key).

[0078] 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,

[0079] According to one embodiment, the method further comprises the step of storing the app patient pseudonym and the public key K Rpub of the key pair generated for this register (K Rpriv , K Rpub ; private / public key) under the patient's trusted pseudonym in the register.

[0080] According to one embodiment, the method further comprises the steps Transferring data encrypted with the private key K Rpriv of the key pair generated for this register (K Rpriv , K Rpub ; private / public key) are signed using a proxy server, and optionally Validation of the signature by the registry using the public key K Rpub of the key pair generated for this register (K Rpriv , K Rpub ; private / public key).

[0081] According to one embodiment, the method further comprises the step of notifying the patient and confirming the received data.

[0082] A special, non-limiting embodiment is shown in the Fig. 3, where two variants (marked by “alternative” and “variant”) are shown.

[0083] The Fig.Steps 1 to 14 shown in Figure 3 are a particular, non-limiting embodiment of the method for bidirectional communication between a data room, ie, here one or more registers in which patient data is stored, and a consent application, ie, here "app" or "application" of a mobile device of a patient, ie, here "patient". With this method of Fig. 3, a bidirectional communication channel is enabled between the data room / register in which patient data of the patient is or will be stored, and the consent application of the patient's mobile device, without any communication between the device and the data room, without revealing the identity of the patient. In this case, the embodiment of the Fig. 3 Use of various previously explained embodiments of the method according to the invention. The individual steps 1 to 14 are shown in the Fig.3 labeled according to the respective process step.

[0084] 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.

[0085] In step 3 of the procedure of Fig. 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.

[0086] In step 4 of the Fig.3, a registration of the app patient pseudonyms for push notifications is performed. In a preferred embodiment, the registration of the app patient pseudonyms for push notifications is performed by sending the push notification ID (e.g., in the case of Apple device tokens or device tokens of the mobile device) of the mobile device together with the app patient pseudonyms to the application server.

[0087] 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.

[0088] In steps 5 to 8 of the Fig.3, the following procedural steps are implemented. In step 5, the public key for the registry is searched for and transferred. 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 transferred. Hi for the hospital, the encrypted specific app patient pseudonym ID Ri for a specific register and the public key K Rpub of the key pair generated for this register (K Rpriv , K Rpub ; private / public key) to the hospital.

[0089] 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.

[0090] Furthermore, in the exemplary embodiment the Fig. 3, a temporary transfer number is requested and transferred in step 7. In step 8, the encrypted app patient pseudonym of the registry and the public key K Rpub of the key pair generated for this register (K Rpriv , K Rpub; private / public key) and data are transferred from the receiving hospital to the registry.

[0091] 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 K Rpub of the key pair generated for this register (K Rpriv , K Rpub ; private / public key).

[0092] Then following in Fig.4, steps 11 to 14, which again apply to both previously described alternatives / embodiments. In step 11, the registry-specific trust center patient pseudonym for the temporary transfer number is retrieved. 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 K Rpub of the key pair generated for this register (K Rpriv , K Rpub ; 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 K Rpriv of the key pair generated for this register (K Rpriv , K Rpub ; private / public key). Optionally, the registry can validate the signature using the public key K Rpub of the key pair generated for this register (K Rpriv , KRpub ; private / public key).

[0093] In step 14, the patient is notified and, if necessary, the received data is confirmed. Fig. 4 shows a particular embodiment of step 14 of the Fig. 3. According to one embodiment, the Fig. 3 communication connections used are secured and / or encrypted. For example, TLS security / encryption can be used.

[0094] In Fig. 4 shows a particular embodiment of step 14 of the Fig. 3. Using the method of Fig.4, the patient is notified. The registry sends a message to the patient / the consent application (app) without knowing the patient's identity. This uses the previously provided bidirectional communication channel between the device and the registry (i.e., the data room) without revealing the patient's identity.

[0095] A special, non-limiting embodiment is shown in the Fig. 5, where two variants (marked by “Opt”) are shown.

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

[0097] 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. DEFINITIONS

[0098] This section provides definitions of certain terms used in this disclosure that also form part of this disclosure. Computer-implemented procedure

[0099] 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 (e.g., 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.

[0100] 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 carry out 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 to 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 performing (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 called 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 that the computer outputs. Another example of a display device would be a standard computer monitor, which may include 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.

[0101] 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.

[0102] 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, comprise a guidance information device having means for outputting guidance information. The guidance information can, for example, be output to a user visually via a visual display means (e.g., a monitor and / or a lamp) and / or acoustically via an acoustic display means (e.g., a loudspeaker and / or a digital voice output device) and / or tactilely via 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 that comprises, for example, 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. Collecting data

[0103] 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 by means of a computer and, for example, in 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 expression “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 expression “acquiring data” can thus also mean that the computer-implemented method or program carries out 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 program can be retrieved via the interface.Data 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 the 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. In accordance with this additional step, the data is generated in order to be acquired. The data is, for example, detected or recorded (e.g., by an analysis device). Alternatively or additionally, the data is entered in accordance with the additional step, for example, via interfaces. The generated data can, for example, be entered (e.g., into the computer). In accordance with the additional step preceding the acquisition step, the data can also be made available by storing the data in 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 carried out correctly, entails 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.

[0104] Further specific embodiments and details of the aforementioned aspects of the invention are given below. 1. Introduction

[0105] 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 that inform their medical care. This data has enormous potential: its integration and analysis can improve medical care and products and save lives. 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 harness these large amounts of data for secondary use for the benefit of future patients and thus tailor individualized healthcare even better to each patient.This is necessary to meet the challenges of demographic change and the shortage of skilled workers, while simultaneously increasing demands for the level of care provided. 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 of 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 discussed at the national and European level, 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.

[0106] 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 safe 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).

[0107] 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, the objectives to be achieved through the framework are then derived. 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.

[0108] This document is intended to provide a starting point for concrete discussions and create a common understanding of a potential target image. 2. Objectives of the concept

[0109] The following objectives can be derived from the previous chapter: • Establishment of a scalable health data space for primary and secondary use with exemplary character in Germany and Europe • Place patients at the center of the data space through fine-grained consent and full transparency regarding the use of their health data • Leveraging a unique data treasure of healthcare data, research data and patient-generated data • Equal opportunities for academic and industrial research and development in the sense of seamless technology transfer • Unhindered data exchange between service providers • Building the data room on existing partial data rooms, e.g. NUM infrastructure, and efficient use of scarce human resources in the healthcare sector • End-to-end digital, operationally efficient and scalable administrative processes • Demand-oriented and scalable provision of current cloud technology, especially for research projects with large data volumes such as biomedical research or AI development • Promoting Open Science through structured archiving and reuse of research data • Connecting researchers with each other and with available data to accelerate scientific progress • Simplified and transparent legal framework and contractual relationships for multi-center research • Combination of decentralized and centralized components for maximum integration and flexibility • Connectivity to planned German and European projects (e.g. GDNG, EHDS) • Cultural change towards a data-driven healthcare system • Increasing the attractiveness of the location for internationally competitive health research and industry 3. Summary target image of data flows and processes

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

[0111] The service providers generate and collect health data during the medical treatment of patients, with the data being stored in various IT systems. The hospital data platform separates the data stream: 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 accessing 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 is performed during transmission with the help of the central trust center. The key here is that data from the same patient can be combined into a single dataset, creating valuable longitudinal and cross-disciplinary 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 has been 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.

[0112] 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 and their access modalities. Potential data users can use the repository and the forum to obtain information on data availability and access modalities.

[0113] 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. 4. Decentralized component in hospitals

[0114] The integration of available data at the level of each service-providing facility represents a crucial component, alongside the central cloud infrastructure of the central data room. 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 the primary care sector.

[0115] 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 foster 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 enable advantages such as cross-hospital pseudonymization to be utilized. It is also important that data storage should always take place within the European Union. Even smaller hospitals should be able to participate in data rooms with the help of preconfigured and easily integrated solutions and a strong focus on automation.The objective is to enable non-university hospitals (and potentially also private practice providers) not only to collect data but also to research their own issues, for example, on process optimization or quality assurance. This is crucial 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. (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-deutschenuniversitaetsklinika / zahlen-undfakten / ).

[0116] 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 MII data integration center, this can be connected as a data source. Furthermore, (2) research providers can conduct research directly with the pseudonymized data of the service provider in an internal hospital research environment. The hospital data platform (3) handles the pseudonymization and forwarding of data to the central data rooms with the assistance of the central trust center, and (4) data-collecting service providers have the option of managing access rights to the data they collect via the data portal. 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 at the hospital's trust center. Further internal use of the data is then generally only permitted under the assigned pseudonym, and the identification data can only be accessed with appropriate authorization if necessary.

[0117] 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 hospital-internal process optimization and quality assurance.

[0118] 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. Health data can be transmitted from the hospital data platform to continuous registers and project-specific data spaces using a pseudonym assigned by the central trust office.

[0119] Hospital-specific configurations may be necessary.

[0120] The hospital data platform essentially consists of the following components: Communication servers ensure integration with a hospital's IT systems, including legacy systems that don't support the hospital data platform's standard interfaces. They must be capable of handling large data volumes 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.

[0121] 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. The identification data remains in the highly secure

[0122] 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.

[0123] 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.

[0124] 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 repository is enabled, supporting both automated metadata creation and manual metadata modification. An interface for offering data in the data repository and the application portal's forum is essential, as is an intuitive user interface.

[0125] 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.

[0126] 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.

[0127] In addition, the data portal displays the status and progress of the transfer pseudonymization and the transfer process in real time. 5. Central component for data room

[0128] 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.

[0129] 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 used in a project-specific Trusted Research Environment (TRE), which can be used both with commercial analysis software and with complex analyses, for example, using AI methods.

[0130] In certain cases, the release of datasets 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.

[0131] 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.

[0132] In the Trusted Research Environment, users can access a wide range 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.

[0133] 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.

[0134] 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.

[0135] Fig. 7: Process diagram of query functions in the data room. 6. Central trust point for pseudonymization

[0136] 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.

[0137] The two-stage pseudonymization process is based on the concept envisaged in the Implant Register Establishment Act: The identification data is sent to the central trust office, which provides the data-providing clinic with a work number for the respective data set. 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 means 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 on around 1.6 million patients for around 10 years in coordination with all state data protection officers (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.).

[0138] 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.

[0139] Fig. 8: Process diagram for pseudonymization via a central trust point. 7. Uniform end-to-end digital application process

[0140] Fig. 9: Data usage request process diagram.

[0141] 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.

[0142] 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.

[0143] 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.

[0144] 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.

[0145] End-to-end encryption, multi-factor authentication, strict password policies, and regular security audits ensure a high level of security. The application portal is designed to remain performant even with increasing application volumes, 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.

[0146] 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. 8. Central consent management for fine-grained patient consents

[0147] Patients' right to informational self-determination can be realized through fine-grained digital patient consent based on a further development of the MII's Broad Consent. Patients should be able to manage their data sharing in a simple mobile application and simultaneously 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 consent should be valid 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.

[0148] 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 use. In the future, this could also lead to dynamic consent.

[0149] 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.

[0150] While there is a debate going on at national and European level about whether, out of convenience, we should simply override 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 grant it, and with their data lay the foundation for better treatment of our children and grandchildren. 9. Repository for archiving, provision and reuse

[0151] According to the DFG guidelines, data used for research should be stored for at least 10 years. Archiving can take place within the researcher's own institution or in a suitable repository (German Research Foundation (DFG) (2019). Guidelines for Ensuring Good Scientific Practice. 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.). The goal is, on the one hand, to document data relevant to the development 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 reuse, the research data must be archived together with their contextual information (e.g., survey and analysis instruments), and processed data must be available in a structured format – only then can the data be managed in a retrievable manner. If there are no applicable data models defined by the data committee for the data used in the research, the data committee should examine the standardization of the data model used and continuously expand the metadata catalog. Furthermore, a reference to the raw data on which the analysis was based must be established. For this reason, the data room operator should set up a repository. Data access for reuse should be via the application portal. Protected access should then 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 costs for storage should be requested within research projects. For this purpose, particularly cost-effective yet secure storage capacity should be rented from the data room operator. Usage rights are transferred to the data room operator via a standard contract. The publication date can be agreed upon upon transfer of usage rights, but should not be more than 12 months in the future. In justified cases, the data can be restricted from use, for example, if specific research questions are still being addressed or a publication or other exploitation is pending. Researchers should also be given the opportunity to object to archiving for specific reasons.In the future, hospital data platforms should also be able to carry out structured archiving of raw data. 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. ( 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 / RatSWD_WP_264.pdf.). The public repository presented in this section would complement the framework with another decisive unique selling point and is in line with the Open Science approach. (UNESCO. (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. 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. (NFDI. (nd). National Research Data Infrastructure. Retrieved September 24, 2023, from https: / / www.nfdi.de / base4nfdi / . ). 10. Expansion stage 1

[0152] Fig. 10: Graphical representation of the functionality at the end of Phase 1.

[0153] 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. Testing of the clinic's internal research environment has begun. A cybersecurity review and test have also been completed. Table 2: Work packages and milestones within the workstreams in Phase 1. Work packages Milestones WP 3.2: Implementation of a data cockpit for patients Implementation of a digital data cockpit for patient consent management Digital consent management established at a pilot clinic WP 3.3: Uniform technical infrastructure for UKs and 6 non-university pilot clinics Equipping the first pilot clinics with a hospital data platform (communication server, health data storage, data portal, etc. Infrastructure such as SMART on FHIR, IAM and Audit Trail, connection to PACS, LIS, HIS and interfaces for data retrieval) Test of the hospital's internal research environment started WP 3.9: Cybersecurity Test Cybersecurity review of the system Cybersecurity test completed 11. Expansion stage 3

[0154] Fig. 11: Graphical representation of the functionality at the end of Phase 2.

[0155] A digital application process was implemented within the application portal. The patient data cockpit was embedded in an information platform. All pilot hospitals were equipped with the hospital data platform. This hospital data platform was supplemented by 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. Work packages Milestones WP 3.1: Implementation of the application portal Implementation of the digital application process WP 3.2: Implementation of a data cockpit for patients Embedding the data cockpit in an information platform on secondary use and research projects WP 3.3: Uniform technical infrastructure for UKs and 6 non-university pilot clinics Equipping all pilot clinics with a hospital data platform (communication server, health data storage, data portal, etc.) Infrastructure such as SMART on FHIR, IAM and Audit Trail, connection to PACS, LIS, HIS and Interfaces for data retrieval, hospital-internal trust center) WP 3.4: Implementation of the central data provision infrastructure and research environment Creation of a project-related data room WP 3.5: Technical design of the trust office Implementation of basic functions (generating and managing pseudonyms) Consent status can be transmitted to the hospital data platform WP 3.6: Implementation of a long-term storage and resilient backup infrastructure Storage rented WP 3.9: Cybersecurity Test Cybersecurity test completed 12. Expansion stage 3

[0156] The application process has been partially automated, allowing formal reviews, for example, to 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 supplemented with a function for submitting reuse requests. An accessible version of the patient information and consent form has been developed, as has 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. Table 4: Work packages and milestones within the workstreams in phases 3 and 4. Work packages Milestones WP 3.1: Implementation of the application portal Partial automation of the application process Integration of the data directory Submission of subsequent use applications possible WP 3.2: Implementation of a data cockpit for patients Accessible versions of patient information and consent developed Concept for specific consents or dynamic consents developed Specific and dynamic consents implemented WP 3.4: Implementation of the central data provision infrastructure and research environment Expansion of the data room completed (audit log, trust center connection) Expansion of the Trusted Research Environment completed WP 3.5: Technical design of the trust office Active patient contact possible Concept for migration of the trust office developed WP 3.6: Implementation of a long-term storage and resilient backup infrastructure Storage rented Connection to data directory completed WP 3.7: Establishment and establishment of the data room operator Concept for rollout in all hospitals developed WP 3.8: Technical design of the trust office Trust center can transmit data usage to data cockpit WP 3.9: Cybersecurity Test Cybersecurity review completed Cybersecurity test completed QUOTES CONTAINED IN THE DESCRIPTION

[0000] This list of documents submitted by the applicant was generated automatically and is included solely for the convenience of the reader. This list is not part of the German patent or utility model application. The DPMA assumes no liability for any errors or omissions. Cited non-patent literature

[0000] 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-deutschenuniversitaetsklinika / zahlen-undfakten /

[0115] 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.

[0137] German Research Foundation (DFG) (2019). Guidelines for Ensuring Good Scientific Practice. 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.

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

[0151] https: / / www.unesco.org / en / open-science?hub=686

[0151] NFDI. (nd). National Research Data Infrastructure. Retrieved on September 24, 2023, from https: / / www.nfdi.de / base4nfdi / .

[0151]

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, where the personal health data consists of identification data and other data, the method further comprising the steps: - 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 pseudonymised 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 of claim 1, the method further comprising the steps of: - Receiving a user request to retrieve at least part of the identification data and / or at least part of the pseudonymised data, When receiving the user request, information about the role of the requesting user with regard to the 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 user request is received through the interface, and / or whereby the transmission of the specific data takes place via 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 is correct. [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 collecting health data is a hospital, a laboratory, a PACS, and / or a HIS. [10] 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] Method according to 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] Method according to 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] Method according to one of claims 10 to 14, wherein the patient data in the data space are pseudonymized. [16] Method according to 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] Method according to one of claims 10 to 16, the method further comprising the step - Using the consent application to identify or select a trusted authority. [18] A method according to any one of claims 10 to 17, the method further comprising the step of - Generation of your own, new pseudonyms through the consent application. [19] A method according to any one of claims 10 to 18, the method further comprising the step of - Generation of a key pair (K Rpriv , K Rpub ; private / public key) by the consent application and storing the key pair, in particular on the mobile device. [20] Method according to one of claims 10 to 19, wherein the method is carried out 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] A method according to any one of claims 10 to 20, the method comprising the step of confirming the identity of the patient by an identity provider. [22] The method of claim 21, wherein confirming the patient’s identity comprises the steps of: Requesting a cryptographically signed identity confirmation from an identity provider through the consent application on the patient's mobile device. [23] Method according to one of claims 21 or 22, wherein confirming the identity of the patient 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 terminal. [24] A method according to any one of claims 21 to 23, wherein the identity provider confirms the patient’s identity personally or digitally. [25] Method according to 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 of claim 25, the method further comprising the steps of Generating a specific app patient pseudonym ID Hi per hospital for each selected hospital using the consent application of the mobile device, and Generating a specific app patient pseudonym ID Ri 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] Method according to one of claims 25 to 28, the method comprising the step of generating at least one key pair (K Rpriv , K Rpub ; private / public 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 of encrypting data of the patient by the mobile terminal and transmitting the encrypted data via a / the hospital to a registry. [31] The method of claim 30, wherein the encryption is performed by the consent application using a public key of the registry. [32] A method according to claim 30 or 31, the method further comprising the steps of: Encrypting a specific app patient pseudonym ID Rifor a specific register by the consent application using a public key of the register; and Sending the encrypted app patient pseudonym ID to a receiving hospital Ri for the specific register together with the verified eGK number, with the app patient pseudonym of the receiving hospital and with the public key K Rpub of the key pair generated for this register (K Rpriv , K Rpub ; private / public key). [33] A method according to any one of claims 30 to 32, the method further comprising the steps of requesting a temporary transfer number from the trust center and transmitting the temporary transfer number from the trust center to the receiving hospital. [34] The method according to claim 33, the method further comprising the steps of transmitting the encrypted app patient pseudonym of the receiving hospital and the public key K Rpub of the key pair generated for this register (K Rpriv , K Rpub ; 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 of transmitting data from the mobile terminal to the register with the aid of the trust center. [36] Method according to claim 35, the method comprising the steps Receiving a temporary transfer number by the consent application from the trust authority, and Sending data from the consent application to a receiving registry along with the temporary transfer number and the app patient pseudonym ID Riof the receiving register and together with the public key K Rpub of the key pair generated for this register (K Rpriv , K Rpub ; private / public key). [37] A method according to any one of claims 10 to 36, the method further comprising the steps of contacting the trust center through the registry to retrieve the registry-specific trust center 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 K Rpub of the key pair generated for this register (K Rpriv , K Rpub ; private / public key) under the patient's trusted pseudonym in the register. [39] The method of claim 38, the method further comprising the steps Transferring data encrypted with the private key K Rprivof the key pair generated for this register (K Rpriv , K Rpub ; private / public key) are signed using a proxy server, and optionally Validation of the signature by the registry using the public key K Rpub of the key pair generated for this register (K Rpriv , K Rpub ; 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 arranged 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 carry out 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 memory of the computer; and / or a data stream representative of the program.

Images