Methods for securely storing and retrieving medical data

Abstract

This disclosure relates to a method for securely storing and retrieving medical data. The method includes: - obtaining medical data in a secure environment, the medical data including patient attribute data and patient identifier data, wherein the patient identifier data indicates at least one patient corresponding to the patient attribute data; - generating de-identified medical data in the secure environment by replacing the patient identifier data in the medical data with non-patient identifier coded identifiers; - generating a re-identification database in the secure environment indicating the correspondence between the non-patient identifier coded identifiers and the de-identified medical data; - generating an encrypted re-identification database by applying at least one symmetric and / or asymmetric encryption method to the re-identification database in the secure environment; - storing the encrypted re-identification database and the de-identified medical data on cloud storage outside the secure environment.

Description

Technical Field

[0001] This disclosure relates to a method for securely storing data, as well as a corresponding system, computer program, data storage medium, and data stream. An important application is backing up sensitive data.

[0002] Although applicable to any type of data, this disclosure and the corresponding potential issues will be explained in more detail by incorporating medical data. Background Technology

[0003] The ever-increasing volume of digital data in the healthcare industry has opened up new possibilities, but it has also brought new challenges, particularly regarding data privacy and security. Currently, key legal provisions in this area include, for example, the U.S. Health Insurance Portability and Accountability Act (HIPAA) and the European General Data Protection Regulation (GDPR).

[0004] On the other hand, there is an expectation that tenants in the healthcare field (such as hospitals or research institutions) can provide data push / pull systems or services, especially for cloud applications. These considerations often result in healthcare data being pseudonymous or encrypted even when accessed within the hospital network. This hinders workflow management because patient data cannot be re-identified, and therefore datasets cannot be (re)associated with specific patients.

[0005] Another challenge is that medical data must be stored securely for regular backups. In principle, cloud storage solutions are well-suited for backup applications because they are typically hosted far from the tenant's premises and therefore less susceptible to the same events that could lead to data deletion or corruption at the tenant's premises. At the same time, data privacy must be maintained for backups. Local backups (i.e., in the tenant's (potentially secure) environment) are possible, but they are not only vulnerable to anything that could affect the original data (e.g., natural disasters like floods or fires), but also represent a significant cost factor in terms of hardware and maintenance. Summary of the Invention

[0006] In summary, the purpose of this disclosure is to provide a method for securely storing medical data, as well as a corresponding system, computer program, data storage medium, and data stream.

[0007] This objective is achieved at least by means of the features of the independent claims according to this disclosure. Additional advantageous features and embodiments are described in the dependent claims and the specification.

[0008] According to a first aspect of this disclosure, a computer-implemented method for securely storing medical data (MD) is provided, the method comprising at least the following steps:

[0009] - Obtain medical data in a secure environment, the medical data including patient attribute data (PPD) and patient identifier data (PID), wherein the patient identifier data (PID) indicates at least one patient corresponding to the patient attribute data (PPD);

[0010] - De-identified medical data DIMD is generated in the secure environment by replacing the patient identifier data PID in the medical data MD with a non-patient identifier encoded identifier NPICI;

[0011] - Generate a reidentification database RIDB in the secure environment that indicates the correspondence (preferably a one-to-one correspondence) between the non-patient identifier coded identifier NPICI and the patient identifier data PID;

[0012] - An encrypted re-identification database eRIDB is generated by applying at least one symmetric and / or asymmetric encryption method to the re-identification database RIDB in the secure environment;

[0013] - Store the encrypted re-identification database eRIDB and the de-identified medical data DMID on cloud storage CS outside the secure environment SE.

[0014] A secure environment (SE) can, in particular, be an intranet associated with a specific tenant, such as a hospital's internal network. A secure environment (SE) can also be defined such that for data queries within the secure environment (SE), patient attribute data (PPD) is allowed (or even by default) to be displayed together with patient identifier data (PID). A secure environment (SE) can also be represented as a trusted environment (TE), because in this context, by definition, the environment is secure. This disclosure does not relate to methods for making a trusted environment secure. Instead, it is assumed that all necessary precautions have been taken.

[0015] In this context, Patient Identifier (PID) data is data that allows identification of a specific patient, such as the patient's explicit name, date of birth or age, gender, social security number, healthcare provider ID, passport number, etc.

[0016] In contrast, Patient Attribute Data (PPD) should be understood in this context as data relating to specific attributes of a patient, particularly medical details, but without indicating (or allowing inference of) the patient's identity. Therefore, Patient Attribute Data (PPD) may include items such as blood test results for one or more patients, previous diagnoses, medical history, currently known medical symptoms and / or conditions, health insurance data, and patient-related medical images (e.g., X-ray images, computed tomography images, or magnetic resonance images). Patient Attribute Data (PPD) can also be represented as Patient Medical Records (PMR).

[0017] The medical data preferably includes patient attribute data (PPD) for multiple patients, wherein the patient to which the corresponding patient attribute data (PPD) belongs is identified by patient identifier data (PID) of the medical data.

[0018] Therefore, replacing the patient information data (PID) with the non-patient identification code identifier (NPICI) means that the de-identified medical data (DIMD) can be advantageously used for research, diagnostic purposes, training artificial intelligence entities, statistics, etc., without any information about who owns the individual patient attribute data (PPD). In other words, the patient's identity is protected, and their data can be safely used for research, etc., or processed outside the secure environment (SE).

[0019] On the other hand, re-identifying the existence of the database RIDB and the one-to-one correspondence between the corresponding patient identifier data PID and the non-patient identifier coding identifier NPICI ensures that people with appropriate permissions (such as physicians, hospital administrators, etc.) can easily re-identify the deidentified medical data DIMD. That is, the patient attribute data PPD can be re-associated with each corresponding patient identifier data PID, or in other words, re-associated with each patient.

[0020] In this way, it is advantageous to provide a complete backup of the medical data MD through the presence of the de-identified medical data DIMD and the encrypted re-identification database eRIDB in the cloud storage CS, because the entire medical data MD can be restored by putting these two parts together (granting permission to decrypt the encrypted re-identification database eRIDB).

[0021] De-identified medical data (DIMD) can be stored as is on cloud storage (CS), or it can be stored in an encrypted state as encrypted de-identified medical data (eDIMD). In the latter case, the same encryption type and / or one or more encryption keys as the encrypted re-identification database (eRIDB) can be used, or a different encryption type and / or one or more encryption keys can be used.

[0022] On the other hand, due to de-identification, de-identified medical data (DIMD) may be stored in cloud storage (CS) in an unencrypted state (plaintext, denoted as pDIMD), making it available to third parties for further processing, such as training artificial intelligence entities (e.g., machine learning, artificial neural networks), or for characteristic statistics of specific patient groups. Of course, access to the cloud storage itself is usually restricted by passwords, ensuring that only authorized users can receive the de-identified medical data (DIMD), for example, after payment or in conjunction with smart contracts.

[0023] However, the reidentified database RIDB will only be stored on cloud storage CS in its encrypted state (eRIDB). This is because no entity outside the secure environment SE should simultaneously possess both the deidentified medical data DIMD and the reidentified database RIDB, as this would be equivalent to possessing or accessing the complete medical data MD.

[0024] Advantageously, since the reidentification database RIDB is available within the secure environment SE, this method allows authorized personnel, authorized applications / software, etc., to access medical data MD, including patient identifier data PID. This greatly facilitates patient diagnosis, treatment, monitoring, etc., in hospital settings (corresponding to the secure environment SE).

[0025] In some advantageous embodiments, improvements, or variations of the examples, at least one asymmetric encryption method is applied when generating the encrypted re-identification database eRIDB. This asymmetric encryption method is based on a private key PRK and a public key PUK, wherein the public key PUK is used for the asymmetric encryption, and the private key PRK used for corresponding decryption is stored in the secure environment SE. Applying different types of encryption increases the difficulty for unauthorized entities to attempt decryption. Preferably, at least one symmetric and at least one asymmetric encryption method are applied simultaneously when generating the encrypted re-identification database eRIDB.

[0026] In some advantageous embodiments, improvements, or variations of the implementation, the public key PUK and / or the private key PRK are stored in their respective encrypted states ePUK / ePRK within the domain of the secure environment SE. Storage within the domain of the secure environment SE can be understood as storage within the secure environment SE itself, such as in a hospital setting where the secure environment SE is implemented.

[0027] Storage within the Secure Environment (SE) domain can also be understood as referring to individuals with authority within the SE, such as hospital administrators or physicians who hold the encrypted public key and / or encrypted private key ePUK / ePRK (e.g., through storage media storing the encrypted public key and / or encrypted private key ePUK / ePRK). The corresponding encrypted state ePUK / ePRK can be advantageously generated by encrypting the public key PUK or private key PRK respectively using a security environment-specific token SEST. In this way, the key is also protected from unauthorized use within the SE, and thus also prevents attempts to gain access to the key by obtaining physical access to the location corresponding to or implementing the secure environment.

[0028] In some advantageous embodiments, improvements, or variations of the examples, the security environment-specific token SEST is based on at least one of the following:

[0029] - Identifier tokens (e.g., serial numbers) for the security environment (SE);

[0030] - An identifier token for at least one device (e.g., a gateway, a medical data source, such as a medical imaging scanner) in a secure environment (SE);

[0031] - An identifier token for at least one software application (such as an analysis program) used in a secure environment (SE);

[0032] - The RFID code of the dongle owned by the administrator;

[0033] -and / or

[0034] - The version number of the data to be encrypted using the public key PUK.

[0035] In some advantageous embodiments, improvements, or variations of the examples, the encrypted re-identified database eRIDB (and / or other data to be backed up, such as de-identified medical data DIMD) is additionally stored in a device within the secure environment SE, such as in a gateway, PACS, medical imaging device, etc. This provides additional redundancy and reduces latency. Furthermore, instead of occupying additional non-transitory storage on cloud storage, currently unused non-transitory storage within the secure environment can be used. Retrieval of files backed up within the device in the secure environment SE can be performed similarly to that described with respect to retrieval from cloud storage CS.

[0036] Storage in a device within a secure SE environment can be performed in DICOM format, i.e., by encapsulating the data to be stored into one or more DICOM files. Whenever DICOM is mentioned herein, it should be understood to refer to the "Medical Digital Imaging and Communications" (DICOM) standard, such as according to the current DICOM PS3.1 2020c standard (or any higher or lower version of the stated standard).

[0037] In some advantageous embodiments, improvements, or variations of the examples, the encrypted reidentification database eRIDB is generated or processed to consist of multiple blocks (i.e., individual data containers or fragments) stored on a cloud storage CS. Storing (or: uploading) individual blocks to (or to) the cloud storage CS is less error-prone than uploading a relatively large single-file database. Furthermore, as will be described below, the presence of a large number of blocks on the cloud storage CS provides additional security against unauthorized access attempts. In this context, each block can be understood as one of multiple parts of the encrypted reidentification database eRIDB, or it can be one of multiple parts of the plaintext reidentification database pRIDB, wherein said parts (i.e., blocks) are then individually encrypted to form the encrypted reidentification database eRIDB together.

[0038] Specifically, in some advantageous embodiments, improvements, or variations of the examples, blocks belonging to at least two different versions of the reidentified database RIDB can be stored in an encrypted state on the cloud storage (CS). Therefore, the historical record of the reidentified database RIDB can also be backed up.

[0039] Preferably, blocks do not contain any plaintext information about the version to which they belong. However, they may be tagged with coded identifiers, such as hash values ​​used to uniquely identify each block. For example, the hash value could be a hash of each block (and optionally its version number) generated using a secure hashing algorithm (such as SHA-1, SHA-2, SHA-3, etc.). For example, when blocks are stored on cloud storage CS, the coded identifier can be used as the name of the block.

[0040] The method in this variant advantageously includes the step of generating a version correspondence list (VCL), which (at least) indicates which blocks belong to which version. For this purpose, the version correspondence list (VCL) can indicate a correspondence (preferably a one-to-one correspondence) between, on the one hand, the encoded identifier of each block and on the other hand, the version number of the block (and optional additional details). Therefore, for efficient decryption, the version correspondence list becomes increasingly important as the number of versions of the same object (e.g., an encrypted re-identification database, eRIDB) on the cloud storage CS increases. This, in turn, means an increased challenge for unauthorized attackers.

[0041] In some advantageous embodiments, improvements, or variations of the example, the method includes the further step of encrypting the version mapping list (VCL) to obtain an encrypted version mapping list (eVCL). Since decrypting the encrypted re-identification database (eRIDB), which is implemented as multiple blocks, is very difficult without the version mapping list (VCL), efficient backup of the re-identification database (RIDB) implies that the version mapping list (VCL) should also be encrypted and, preferably, backed up similarly.

[0042] For example, the encrypted version mapping list (eVCL) can also be stored on cloud storage (CS). The encryption used for the version mapping list (VCL) can use the same encryption protocol and / or encryption key as the encryption of the reidentification database (RIDB), or it can use a different protocol and / or key.

[0043] In some advantageous embodiments, improvements, or variations of the example, the method includes the step of generating encrypted de-identified medical data eDIMD. The step of storing the de-identified medical data DIMD on a cloud storage CS may include or consist of storing the encrypted de-identified medical data eDIMD on the cloud storage CS. Alternatively, the step of storing the de-identified medical data DIMD on the cloud storage CS may include or consist of storing plaintext de-identified medical data pDIMD on the cloud storage CS.

[0044] Because plaintext de-identified medical data (pDIMD) does not contain any patient identifier data (PID), the system can allow it to be stored in an unencrypted (i.e., plaintext) state on cloud storage (CS) in accordance with many data protection rules. This has the added advantage of granting access to the plaintext de-identified medical data (pDIMD) to third parties or entities outside the secure environment, and allowing for further processing of this data. For example, plaintext de-identified medical data (pDIMD) can be used to train artificial intelligence entities (such as artificial neural networks) or for other machine learning applications.

[0045] In some advantageous embodiments, improvements, or variations of the examples, the method can be represented as a method for securely storing and securely retrieving medical data. The method may include the following steps:

[0046] - Retrieve (e.g., download) the de-identified medical data DIMD from the cloud storage CS;

[0047] - Retrieve (e.g., download) the encrypted reidentified database eRIDB from the cloud storage CS;

[0048] - Decrypt the encrypted reidentification database eRIDB in the secure environment SE to obtain the plaintext reidentification database pRIDB;

[0049] - The medical data MD is regenerated from the deidentified medical data DMID by replacing or associating the non-patient identifier encoded identifier (NPICI) in the deidentified medical data DIMD with the corresponding patient identifier data (PID) based on the reidentification database RIDB. These steps (and any other steps of the method) can advantageously be performed by a gateway in a secure environment.

[0050] In some advantageous embodiments, improvements, or variations of the examples, the method further includes the step of providing de-identified medical data (DIMD) from cloud storage (CS) to a processing entity outside a secure environment (SE) or making the de-identified medical data available to the processing entity. For example, the method may further include having the processing entity train an artificial intelligence entity based on the de-identified medical data (DIMD).

[0051] According to a second aspect, this disclosure also provides a gateway for use in a secure environment. Specifically, the gateway may include:

[0052] - Input module, the input module is configured to obtain medical data MD, the medical data including patient attribute data PPD and patient identifier data PID, wherein the patient identifier data PID indicates at least one patient corresponding to the patient attribute data PPD;

[0053] - De-identification module, which is configured to generate de-identified medical data DIMD by replacing the patient identifier data PID in the medical data MD with a non-patient identifier encoded identifier NPICI;

[0054] - Database generation module, configured to generate a reidentification database RIDB that indicates (preferably, one-to-one) the correspondence between the non-patient identifier coding identifier NPICI and the patient identifier data PID;

[0055] - An encryption module configured to generate an encrypted reidentification database eRIDB by applying at least one symmetric and / or asymmetric encryption method to the reidentification database RIDB;

[0056] - A communication module configured to transmit the encrypted re-identification database eRIDB and the de-identified medical data DMID to be stored on cloud storage CS outside (or separate from) the secure environment SE.

[0057] Whenever any module is mentioned herein, it should be understood that this can refer to a module implemented as hardware and / or software. Modules are mentioned and described for ease of understanding, and it will be apparent that all functions of all modules can be implemented by the same set of computer program instructions (or: computer code). Furthermore, without departing from this disclosure, the functions of any or all modules may overlap, and some modules may be integrated into other modules. Any or all modules may include or constitute at least one of the following: a microprocessor, a CPU (“Central Processing Unit”), a GPU (“Graphics Processing Unit”), a Field-Programmable Gate Array (“FPGA”), or an ASIC (“Application-Specific Integrated Circuit”).

[0058] According to embodiments of the second aspect of this disclosure, the gateway may be specifically configured to perform the methods according to any embodiment of the first aspect of this disclosure. Therefore, the gateway may be modified or adapted for any advantageous variations, improvements, or embodiments described herein with respect to the methods according to the first aspect.

[0059] According to a third aspect of this disclosure, a system is provided comprising a gateway according to an embodiment of a second aspect of this disclosure and a cloud storage service (CS), the gateway and the cloud storage being operatively linked to or connectable to each other, such that the gateway can store data on the cloud storage CS, preferably encrypted data (e.g., encrypted re-identification database eRIDB, encrypted version correspondence list eVCL, etc.), and optionally retrieve the stored data again from the cloud storage CS. Therefore, one function of the system is to provide cloud-based backup of medical data in or obtained by the gateway. The system can be specifically configured to perform the methods according to any embodiment of a first aspect of this disclosure.

[0060] According to the fourth aspect, this disclosure also provides a method for securely retrieving medical data. The method may include the following steps:

[0061] - Retrieve (e.g., download) de-identified medical data DIMD from cloud storage CS, wherein the de-identified medical data DIMD includes patient attribute data PPD and non-patient identifier coding identifier NPICI;

[0062] - Retrieve (e.g., download) the encrypted re-identified database eRIDB from the cloud storage CS;

[0063] - In a secure environment SE, the encrypted reidentification database eRIDB is decrypted to obtain a plaintext reidentification database pRIDB, which indicates the correspondence (preferably, a one-to-one correspondence) between non-patient identifier encoding identifier NPICI and patient identifier data PID, and the patient identifier data indicates at least one patient corresponding to patient attribute data PPD.

[0064] - The (plaintext) medical data MD is regenerated from the deidentified medical data DMID by replacing or associating the non-patient identifier encoded identifier NPICI in the deidentified medical data DIMD with the corresponding patient identifier data PID based on the (plaintext) reidentification database RIDB.

[0065] The method can be performed by another entity as a method according to an embodiment of the first aspect. For example, when a hospital opens a new branch and copies medical data stored in the original hospital to the new branch, the original hospital can securely upload (store) the medical data using the method according to an embodiment of the first aspect, and the new branch can securely download (retrieve) the medical data using the method according to an embodiment of the fourth aspect.

[0066] These steps (and any other steps of the method) can be advantageously performed by a gateway in a secure environment.

[0067] According to a fifth aspect, this disclosure also provides a method configured to perform any embodiment of a fourth aspect of this disclosure, specifically, a gateway used in a secure environment, the gateway comprising:

[0068] - A communication module, which is configured to:

[0069] - Retrieve (e.g., download) de-identified medical data DIMD from cloud storage CS, wherein the de-identified medical data DIMD includes patient attribute data PPD and non-patient identifier coding identifier NPICI;

[0070] - Retrieve (e.g., download) the encrypted re-identified database eRIDB from the cloud storage CS;

[0071] - A decryption module configured to decrypt at least the encrypted re-identification database eRIDB;

[0072] - A re-identification module configured to regenerate the (plaintext) medical data MD from the deidentified medical data DMID by replacing or associating the non-patient identifier encoded identifier (NPICI) in the deidentified medical data DIMD with the corresponding patient identifier data (PID) based on the (plaintext) re-identification database RIDB.

[0073] According to a sixth aspect of this disclosure, a system is provided comprising a gateway according to an embodiment of a fifth aspect of this disclosure and a cloud storage service (CS), the gateway and the cloud storage being operatively linked to or connectable to each other, such that the gateway can retrieve data from the cloud storage CS, preferably encrypted data, such as an encrypted reidentification database (eRIDB), an encrypted version correspondence list (eVCL), etc. Therefore, one function of the system is to employ cloud-based backup. The system can be specifically configured to perform the methods according to any embodiment of a fourth aspect of this disclosure.

[0074] According to a seventh aspect, this disclosure provides a computer program product including executable program instructions configured to, when executed, perform a method according to any embodiment of the first aspect and / or a method according to any embodiment of the fourth aspect.

[0075] According to an eighth aspect, this disclosure provides a non-transitory computer-readable data storage medium including executable program instructions configured to perform, when executed, a method according to any embodiment of the first aspect and / or a method according to any embodiment of the fourth aspect.

[0076] Non-transitory computer-readable data storage media can include or be constituted with any type of computer memory, particularly semiconductor memory such as solid-state memory. Data storage media can also include or be constituted with CDs, DVDs, Blu-ray discs, USB memory sticks, memory cards (e.g., SD cards), etc.

[0077] According to a ninth aspect, this disclosure provides a data stream that represents or is configured to generate executable program instructions, which are configured to perform, when executed, a method according to any embodiment of the first aspect and / or a method according to any embodiment of the fourth aspect.

[0078] Further advantageous variations, modifications, embodiments, and aspects of this disclosure will become more apparent from the following description with reference to the accompanying drawings. Attached Figure Description

[0079] This disclosure will be explained in more detail with reference to the exemplary embodiments depicted in the accompanying drawings.

[0080] These accompanying drawings are included to provide a further understanding of the present disclosure and are incorporated in and constitute a part of this specification. The drawings illustrate embodiments of the present disclosure and, together with the description, serve to illustrate the principles of the present disclosure. Other embodiments of the present disclosure and many anticipated advantages of the present disclosure will be readily understood as they become better understood by referring to the following detailed description. Similar reference numerals denote corresponding similar parts.

[0081] The numbering of method steps is intended to facilitate understanding and should not be construed as requiring the specified steps to be performed according to the numbering of the accompanying figure labels unless otherwise expressly stated or implied. In particular, multiple or even all method steps may be performed simultaneously, in an overlapping manner, or sequentially.

[0082] In the attached diagram:

[0083] Figure 1 A schematic flowchart illustrating the method according to the first aspect of this disclosure is shown;

[0084] Figure 2 A schematic block diagram illustrating a system according to a third aspect of this disclosure is shown, and further illustrations are provided based on... Figure 1 The method according to the fourth aspect of this disclosure, and the system according to the sixth aspect of this disclosure;

[0085] Figure 3 The illustration is shown. Figure 1 and Figure 2 Schematic block diagrams of options and variations of the method, and gateways according to embodiments of the second aspect of this disclosure and gateways according to embodiments of the fifth aspect of this disclosure;

[0086] Figure 4 A schematic block diagram illustrating a computer program product according to an embodiment of the seventh aspect is shown; and

[0087] Figure 5 A schematic block diagram illustrating a data storage medium according to an embodiment of the eighth aspect is shown.

[0088] Although specific embodiments have been illustrated and described herein, those skilled in the art will understand that various alternatives and / or equivalent implementations may be used instead of the specific embodiments shown and described without departing from the scope of this disclosure. In general, this application is intended to cover any modifications or variations of the specific embodiments discussed herein. Detailed Implementation

[0089] Figure 1 A schematic flowchart illustrating a method implemented by a computer for securely storing medical data (MD) according to a first aspect of this disclosure is shown. For a clearer understanding of the steps of the method, reference is also made to the following... Figure 2 and Figure 3 .

[0090] Figure 2 The illustrations show a system 1000 according to a third aspect of this disclosure, a gateway 100 according to a second aspect of this disclosure, and further illustrations according to... Figure 1 A schematic block diagram of the method. Further, Figure 2 This is used to illustrate a method according to an embodiment of the fourth aspect of this disclosure, a gateway 100 according to an embodiment of the fifth aspect of this disclosure, and a system 1000 according to an embodiment of the sixth aspect of this disclosure.

[0091] Figure 3 More detailed illustrations are shown for use according to Figure 1 A schematic block diagram illustrating the steps of a method for securely storing (and optionally retrieving from) backed-up medical data on cloud storage CS. Additionally, Figure 3 A schematic block diagram of a gateway 100 according to an embodiment of the second aspect of this disclosure is shown, which will be described later.

[0092] Furthermore, Figure 3 A schematic block diagram illustrating the steps of a method for retrieving backup medical data from cloud storage CS according to an embodiment of the fourth aspect of this disclosure, and a gateway 100 according to an embodiment of the fifth aspect of this disclosure.

[0093] Although some method steps are described along with the components or modules of gateway 100, it should be understood that these method steps can also be performed by other entities, systems, or devices. Similarly, gateway 100 will typically perform a variety of other functions besides those described herein.

[0094] In step S10, which is not a necessary part of this disclosure, medical data MD is acquired by medical data source 1. In this context, it is assumed that medical data source 1 resides within the hospital (tenant's) premises and is connected to a secure environment SE, i.e., connected to a secure network. However, medical data source 1 may also be located outside the premises and may access the secure environment SE in other ways. For example, patients may upload or bring their previous medical history to the hospital, physicians who previously treated patients may transfer medical data collected from said patients, and so on.

[0095] like Figure 2 As shown, this medical data source 1 may include medical imaging scanners (such as magnetic resonance imaging (MRI) scanners, computed tomography (CT) scanners, X-ray scanners, ultrasound equipment, etc.), fluoroscopy stations, physician assessments of patients (which are then digitized using a user interface), patient monitoring data such as those from heart rate monitors and respiratory monitors, camera images from surgically inserted cameras, data from implanted transmission devices, and so on.

[0096] In step S20, the acquired data can be stored within a secure environment SE. In the case of imaging data (as an example of medical data), the data can be stored, for example, in a picture archiving and communication system PACS 10 within the secure environment SE. The data can be stored by PACS 10 in the well-known DICOM format.

[0097] After the data is stored in PACS 10, the acquired data or the availability of the data at PACS 10 can be transferred to the subscriber list. Subscribers can be devices, monitoring stations, software modules, or any other post-processing or reporting systems used for analysis.

[0098] In this example, in step S30, data is also transmitted to gateway 100, which can also be referred to as a "Medical Data Gateway" (MDG). An example of such a medical data gateway is the Teamplay (registered trademark) receiver from Siemens Healthineers. This gateway will not only implement common gateway functions (such as providing interoperability between networks, protocol conversion, etc.), but will also implement various software modules, as will be discussed below. Figure 3 As described in the context of the above. Therefore, gateway 100 may be implemented as or include a computing device, which in particular includes a processing unit (CPU), working memory (RAM), data storage unit (persistent memory), and at least one input and at least one output interface, wherein the components of the computing device are operatively coupled to each other.

[0099] In step S30, other medical data (MD) not originating from PACS 10 may also be transmitted to gateway 100, particularly medical data (MD) unrelated to medical imaging. This data may include monitoring data (heart rate, respiratory rate, EEG data, etc.) and data entered into the user interface by a physician (e.g., on a personal computer PC). However, medical imaging data may also be transmitted to gateway 100 via means other than via PACS 10.

[0100] As a result of any combination of steps S10 to S30, medical data MD is acquired (or obtained) within a secure environment SE.

[0101] The medical data MD acquired or obtained includes patient identifier data (PID) and patient attribute data (PPD), or consists of patient identifier data (PID) and patient attribute data (PPD).

[0102] In step S40, specifically, de-identified medical data DIMD is generated within the secure environment SE via gateway 100. This is achieved by replacing the patient identifier data PID in the medical data MD with the corresponding non-patient identifier encoded identifier NPICI, as described above. Figure 3 As shown. For example, each non-patient identifier encoded identifier (NPICI) can be a hash key of the patient identifier data PID, a hash key of a portion of the patient identifier data PID, and / or can be based on at least a portion of the patient identifier data PID and other data.

[0103] Additionally, in step S50, a reidentification database RIDB is generated, specifically within the secure environment SE via gateway 100. The reidentification database RIDB indicates a (preferably one-to-one) correspondence between non-patient identifier encoded identifiers (NPICI) and patient identifier data (PID), for example, see [link to relevant documentation]. Figure 3 For example, the Reidentification Database (RIDB) may include or consist of tables having all data fields for each patient's Patient Identifier (PID) data, and additionally having a data field NPICI indicating a Non-Patient Identifier Coded Identifier corresponding to each patient. Within the security environment SE, specifically within gateway 100, the Reidentification Database (RIDB) may exist in plaintext, which may be represented as pRIDB.

[0104] Since the Reidentification Database RIDB not only has the function of providing (preferably, one-to-one) correspondences, but also has the function of providing the missing medical data MD portion from the deidentified medical data DIMD, the Reidentification Database RIDB preferably includes complete patient identifier data PID.

[0105] Advantageously, steps S50 and S40 are performed simultaneously or in parallel.

[0106] In step S60, an encrypted reidentification database eRIDB is generated by applying at least one symmetric and / or asymmetric encryption method (or: encryption protocol) to the reidentification database RIDB in a secure environment SE. The encryption protocol may be applied by a hardware security module HSM, which may be part of gateway 100.

[0107] In this example, both symmetric and asymmetric encryption protocols are applied, with the symmetric protocol applied first, followed by the asymmetric protocol. However, it should be understood that different protocols, different application orders, different numbers of encryption protocols, etc., can be applied. The inventors have found that the example described herein provides a good balance between security and feasibility, as more and more secure encryption protocols increase the time and computational power required to apply them.

[0108] Furthermore, in this example, the 256-bit Advanced Encryption Standard (AES256) is used as the symmetric encryption protocol, and RSA (e.g., 2048-bit RSA or 4096-bit RSA) is used as the asymmetric encryption protocol. It should be understood that any other suitable encryption method or standard can be applied equally or additionally. For example, AES256 can be replaced by Elliptic Curve Cryptography (ECC).

[0109] If the database RIDB is re-identified using the symbol M rd This means that encryption S60 can be performed in the following sub-steps:

[0110] In step S61, for M rd Perform AES256 encryption. enc，AES :

[0111] C rd =f enc，AES (M rd ,K),

[0112] Among them, C rd It is ciphertext, and K is a random key.

[0113] Then, in step S62, the public key PUK and private key PRK for the RSA protocol are generated in any known manner. For example, two large, not very close prime numbers p and q are chosen and multiplied, p * q = n. Carmichael's (or alternatively, Euler's) totient function Φ(n) is computed, and an integer e is chosen such that 1 < e < Φ(n) and e and Φ(n) are coprime, i.e., gcd(e, Φ(n)) = 1, where gcd denotes the greatest common divisor. Then, the integer d is determined as d = e. -1 mod(Φ(n)), that is, d is the modular inverse of e modulo Φ(n).

[0114] Therefore, the RSA public key PUK is given by {e, n}, and the RSA private key PRK is given by {d, n}.

[0115] In step S63, the public key PUK is used to further transmit the password C. rd Encrypted as C′ rd =f e (C rd ) = C rd e (modΦ(n)). Therefore, when Mrd is set to re-identify the database RIDB, C′ rd This corresponds to the encrypted re-identification database eRIDB.

[0116] To protect the public key PUK, which is also within the secure environment SE, the public key PUK can be stored in the secure environment SE in an encrypted state (ePUK), where the secure environment SE's secure environment-specific token SEST is used for this encryption.

[0117] For example, public key encryption can be applied to f PUK It is given by the following formula

[0118] f PUK (PUK) = PUK + SEST

[0119] Here, the addition can be modulo Φ(n).

[0120] A security environment-specific token (SEST) can be generated in any of a variety of ways using codes or numbers available at the security environment (SE). For example, a security environment-specific token (SEST) may include or be based on any or all of the following:

[0121] -Identifier token for the Secure Environment (SE);

[0122] - Identifier token of at least one device (e.g., gateway 100) in the security environment SE;

[0123] - The version number of the re-identified database RIDB to be encrypted;

[0124] - At least one medical data source 1 serial number;

[0125] - The RFID code of the dongle owned by the administrator;

[0126] -etc.

[0127] Similarly, the private key PRK can also be stored in a secure environment SE as an encrypted state (ePRK). For example, the private key encryption function f can be applied using the following formula. PRK

[0128] f PRK (PRK) = PRK + H MSK ,

[0129] Among them, H MSK This represents the master key, which may be owned by, for example, a hospital administrator. Master Key H MSK Therefore, the master key encryption function f can be used. MSK The generated encrypted state storage, for example:

[0130] f MSK (H MSK )=H MSK +SEST.

[0131] If RDBVDEK If the encryption key is used to re-identify the RIDB database, then it can be stored in an encrypted state.

[0132] f encr (RDBV DEK ) = RDBV DEK +PUK.

[0133] In step S70, the encrypted re-identification database eRIDB and the de-identified medical data DIMD are then stored on cloud storage CS outside the secure environment SE. Preferably, the data in transit is encrypted using TLS v1.2 (or later) and a strong cipher is enforced.

[0134] As an optional step, the de-identified medical data DIMD can be encrypted to provide encrypted de-identified medical data eDIMD, which can then be stored on cloud storage CS. Preferably, in this case, the plaintext de-identified medical data pDIMD is not stored on the cloud storage CS. The encryption protocol and / or key used can be the same as, but preferably different from, the encryption protocol and / or key used for the encrypted re-identification database eRIDB.

[0135] However, the advantage of storing plaintext de-identified medical data (pDIMD) on cloud storage is that this data can be provided to different processes via cloud storage CS (Service Center) without leaking any sensitive patient identifier data (PID). In this way, for example, plaintext de-identified medical data (pDIMD) can be used (i.e., transferred or allowed to be retrieved) to train artificial intelligence entities, such as artificial neural networks. Therefore, plaintext de-identified medical data (pDIMD) can be used as training data including underlying ground truth labels or as the basis for training data.

[0136] In some variations, the encrypted reidentified database eRIDB and / or deidentified medical data DIMD (eDIMD or pDIMD) can also be stored elsewhere besides cloud storage CS. For example, an additional backup copy of either or both can be stored in gateway 100, in any of the medical data sources 1, or in PACS 10, etc. For example, the encrypted reidentified database eRIDB and / or deidentified medical data DIMD can be encapsulated in DICOM format and stored in PACS 10.

[0137] Several variations of encryption step S60 are possible. For example, it is not necessary to apply the encryption protocol to the entire human-readable (plaintext) reidentification database pRIDB. Instead, in some variations, the reidentification database RIDB can be divided into several blocks, such as a fixed number of blocks or blocks of a fixed size.

[0138] One option is to allocate the bits of the reidentified database RIDB into a matrix structure, and then use steps S61-S63 described above to encrypt each cell of the matrix structure individually. For example, a 10×10 cell matrix structure could be used, where the first bit (or a larger portion) is placed in the first cell, the second bit (or a portion) in the second cell, and so on, until the 100th bit (or a portion) is placed in the 100th cell, then the 101st bit (or a portion) is placed back into the first cell, and so on. In other words, the bit (or portion) number x is placed in the cell number x mod 100. Other ways of splitting the reidentified database RIDB can also be easily envisioned.

[0139] In other words, in the above formula, the symbol M rd It may not refer to the entire reidentification database RIDB, but rather to each individual block of the reidentification database RIDB. This means that to decrypt the reidentification database RIDB, all (encrypted) blocks must be obtained, and then the decrypted blocks must be arranged in the correct order according to the matrix structure in order to reconstruct the original reidentification database RIDB.

[0140] In these variations, storing the S70-encrypted re-identified database eRIDB on cloud storage CS then includes storing each encrypted block on cloud storage CS.

[0141] Advantageously, the encrypted blocks themselves do not indicate which unit of the matrix structure they belong to. Instead, they may include coded unit identifiers (e.g., hash values) to uniquely identify the blocks.

[0142] Then, a block mapping list (CCL) can be generated, which indicates which encoded unit identifier corresponds to which unit in the matrix structure, so that the decrypted blocks can be rearranged in the matrix structure, thereby producing a readable reidentified database (RIDB).

[0143] Enhanced security is achieved when considering the general expectation of preparing and maintaining backups based on at least two versions. Clearly, if only one backup is initially stored on cloud storage client-side (CS), and the current backup is overwritten during the upload of the next backup, unexpected events or errors during the upload process could result in a situation where no valid backup exists at all. Therefore, it is desirable to always have at least two distinct versions of all files or data to be backed up on cloud storage client-side (CS).

[0144] If the reidentified database RIDB is now divided into blocks as a file to be backed up, these blocks are then encrypted and stored on cloud storage CS in step S70, then all the encrypted blocks represent the encrypted reidentified database eRIDB. For example, this could be one hundred blocks. If two versions of the reidentified database RIDB are backed up, for example, two versions from two different points in time, then this means that there will always be two hundred blocks on cloud storage CS representing two different encrypted reidentified databases eRIDB.

[0145] If an attacker were to gain access to cloud storage CS, they would find (in this simplified example) two hundred encrypted blocks identified solely by coded unit identifiers (e.g., hash values). Therefore, the attacker would not only be unaware of how many blocks represent an encrypted reidentified database eRIDB, but also of which blocks belong to which version. However, due to the way the reidentified database RIDB is split before encoding, the plaintext (i.e., the readable reidentified database RIDB) is only available if the decrypted blocks are arranged in the correct order.

[0146] Therefore, for each attempt by an attacker to decrypt multiple blocks, the attacker must also try a large number of different orders to arrange the blocks to determine whether the decryption was successful. For example, there are 100! ways to arrange one hundred blocks in a ten-by-ten matrix.

[0147] Security is further enhanced by using different encryption keys for each version of the re-identified database RIDB's asymmetric and / or symmetric encryption protocols.

[0148] It can generate a version correspondence list (VCL) indicating which encrypted blocks on the cloud storage CS belong to which version and which unit within it, enabling the administrator of the security environment (SE) to retrieve the reidentified database (RIDB) from the encrypted blocks representing the reidentified database (eRIDB).

[0149] The VCL can be encrypted in any suitable manner to form an encrypted version correspondence list eVCL, for example, again using the same key according to steps S61-S63, or preferably a different key. Therefore, an attacker must first know this arrangement, then first decrypt the version correspondence list VCL to know which blocks must be decrypted using the same decryption protocol before they can begin decrypting those blocks.

[0150] The method can also be extended to a secure data storage and retrieval method, as will be specifically discussed below. Figure 3 A brief description.

[0151] In step S80, the de-identified medical data DIMD (encrypted eDIMD or plaintext pDIMD) is retrieved from cloud storage CS to the secure environment SE, specifically via (and into) gateway 100. If the eDIMD is stored on the cloud storage CS, retrieval S80 includes downloading the eDIMD and applying a decryption step to the eDIMD to generate the pDIMD. If the pDIMD is stored on the cloud storage CS, the pDIMD is simply downloaded to perform retrieval S80.

[0152] In step S90, the encrypted reidentification database eRIDB is retrieved (specifically, downloaded) from cloud storage CS to the secure environment SE, particularly via (and into) gateway 100. Depending on the variant used, retrieving the encrypted reidentification database eRIDB may include downloading a single file or multiple encrypted blocks, optionally along with the version correspondence list VCL (preferably, the encoded version correspondence list eVCL).

[0153] In step S100, the encrypted reidentification database eRIDB is decrypted in the secure environment SE (again, depending on the encryption method used) to obtain the (plaintext) reidentification database RIDB (which may also be represented as pRIDB). In some variations described above, the decryption may be applied to each of the multiple blocks representing the encrypted reidentification database eRIDB, and then the plaintext reidentification database pRIDB may be regenerated by reversing the allocation of the blocks according to, for example, a matrix scheme.

[0154] In step S110, medical data MD is regenerated from DIMD by replacing the non-patient identifier encoded identifier NPICI with the corresponding patient identifier data PID based on the one-to-one correspondence indicated by the (decrypted, i.e., now plaintext) reidentification database RIDB. This step also... Figure 3 The diagram is shown in the image.

[0155] In other words, the pseudonymous non-patient identifier encoded identifier (NPICI) is remapped to the original patient identifier data (PID). To emphasize and clarify that medical data MDs exist in plaintext within gateway 100, they can also be represented as pMDs.

[0156] Return to reference Figure 2 The method may further include step S200, which involves providing de-identified medical data DIMD (particularly pDIMD) from cloud storage CS to a processing entity 3Pout outside the secure environment SE. For example, in step S210, the processing entity 3Pout may use the de-identified medical data DIMD to train an artificial intelligence entity, such as for machine learning, preferably an artificial neural network.

[0157] If a processing entity 3Pin within the secure environment SE requests medical data MD, it can provide de-identified medical data DIMD or even medical data MD (including patient identifier data PID), depending on the required security level, the permissions of processing entity 3Pin, etc. Processing entities 3Pout and 3Pin can access the de-identified medical data DIMD, for example, via a web browser.

[0158] Figure 3 Gateway 100 according to an embodiment of the second aspect of this disclosure and gateway 100 according to an embodiment of the fifth aspect of this disclosure are also illustrated. Gateway 100 may be specifically configured to at least perform Figure 1 and Figure 2 The method includes steps S30-S70, and preferably also steps S80-S110.

[0159] Specifically, gateway 100 may include:

[0160] - Input module 110, the input module is configured to obtain S30 medical data MD, the medical data including patient attribute data PPD and patient identifier data PID, wherein the patient identifier data PID indicates at least one patient corresponding to the patient attribute data PPD;

[0161] - De-identification module 120, the de-identification module is configured to generate S40 de-identified medical data DIMD by replacing the patient identifier data PID in medical data MD with the non-patient identifier encoded identifier NPICI;

[0162] - Database generation module 130, which is configured to generate a reidentified database RIDB (plaintext, i.e. pRIDB) that indicates a one-to-one correspondence between non-patient identifier coding identifier NPICI and patient identifier data PID.

[0163] - Encryption module 140, which is configured to generate an S60 encrypted reidentification database eRIDB by applying at least one symmetric and / or asymmetric encryption method to the (plaintext) reidentification database pRIDB;

[0164] - Communication module 150, which is configured to transmit encrypted re-identified database eRIDB and de-identified medical data DMID to be stored on cloud storage CS outside the secure environment SE in S70.

[0165] Input module 110 may be part of or implemented as an internal communication module (or: internal communication interface), configured for data transmission and reception within the secure environment SE. In this case, communication module 150 may be represented as external communication module 150 or as external communication interface.

[0166] It should be understood that the communication module 150 can be further configured to retrieve DIMD (pDIMD or eDIMD) and the encrypted re-identification database eRIDB from the cloud storage CS S80, S90.

[0167] Gateway 100 may further include a decryption module 160 for decrypting the encrypted re-identification database eRIDB (and optionally eDIMD) S100. Encryption module 140 and decryption module 160 may be integrated together, implemented separately, or may have overlapping components. For example, for some encryption / decryption protocols, decryption and encryption include or consist of the same operations. The same is true for any other module; in particular, encryption module 140 and / or decryption module 160 may be implemented in hardware and / or software. Therefore, for example, for operations that are identical for encryption and decryption, corresponding modules or submodules may be implemented in hardware.

[0168] Gateway 100 may further include a reidentification module 170, configured to regenerate S110 medical data MD from deidentified medical data DIMD by replacing (or associating) the non-patient identifier encoded identifier NPICI in the deidentified medical data DIMD with the corresponding patient identifier data PID based on the (plaintext) reidentification database pRIDB obtained from decryption module 160. Therefore, gateway 100 can be configured not only to execute any embodiment of the method for securely storing medical data MD, but also to securely retrieve stored medical data MD from cloud storage CS.

[0169] The entire functionality of gateway 100 can be controlled by gateway 100's controller module 180 (e.g., a microcontroller that executes a corresponding computer program with executable computer program instructions).

[0170] Figure 2 The illustration also depicts a system 1000 according to an embodiment of the third aspect of this disclosure and / or an embodiment of the sixth aspect of this disclosure. System 1000 may include a gateway 100 and a cloud storage CS operatively linked to each other, such that system 1000 is configured to perform or be permitted to perform the methods according to any embodiment of the first aspect of this disclosure. System 1000 may optionally include any number of medical data sources 1, PACS 10, etc., and may even include a secure environment SE.

[0171] Figure 4 A schematic block diagram illustrating a computer program product 200 according to an embodiment of the seventh aspect is shown. The computer program product 200 includes executable program instructions 250 configured to perform, when executed, a method according to any embodiment of the first aspect and / or a method according to any embodiment of the fourth aspect of this disclosure.

[0172] Figure 5 A schematic block diagram of a nontransitory computer-readable data storage medium 300 according to an embodiment of the eighth aspect is shown. The nontransitory computer-readable data storage medium includes executable program instructions 350 configured to perform, when executed, a method according to any embodiment of the first aspect and / or a method according to any embodiment of the fourth aspect of this disclosure.

[0173] In the foregoing detailed description, various features have been combined in one or more examples or illustrations to simplify this disclosure. It should be understood that the above description is intended to be illustrative and not restrictive. It is intended to cover all alternatives, modifications, and equivalents. Many other examples will be apparent to those skilled in the art after reading the foregoing specification. In particular, the embodiments and configurations described for systems and gateways can be applied accordingly to methods according to this disclosure, and vice versa.

[0174] These embodiments were chosen and described in order to best explain the principles of this disclosure and its practical application, thereby enabling others skilled in the art to best utilize this disclosure and various embodiments with various modifications suitable for the intended particular use. Throughout the appended claims and the specification, the terms “including” and “inwhich” are used as concise English equivalents to the corresponding terms “comprising” and “wherein”, respectively. Furthermore, “a” or “one” does not exclude a plural form in this application.

[0175] When referring to data, it should be understood that this may include plaintext or encrypted data, unless otherwise expressly or implicitly stated in the context.

Claims

1. A computer-implemented method for securely storing medical data (MD), the method comprising at least the following steps: - Obtain medical data (MD) in a secure environment (SE) (S10, S20, S30), the medical data including patient attribute data (PPD) and patient identifier data (PID), wherein the patient identifier data (PID) indicates at least one patient corresponding to the patient attribute data (PPD); - Deidentified medical data (DIMD) is generated in the secure environment (SE) by replacing the patient identifier data (PID) in the medical data (MD) with the corresponding non-patient identifier encoded identifier (NPICI), wherein each non-patient identifier encoded identifier is a hash key of the patient identifier data PID, a hash key of a portion of the patient identifier data PID, and / or based on at least a portion of the patient identifier data PID and other data. - Generate (S50) a reidentification database (RIDB) in the secure environment (SE) indicating the correspondence between the non-patient identifier encoded identifier (NPICI) and the patient identifier data (PID); - An encrypted re-identification database (eRIDB) is generated (S60) by applying at least one asymmetric encryption method to the re-identification database (RIDB) in the secure environment (SE); - The encrypted re-identified database (eRIDB) and the de-identified medical data (DIMD) are stored (S70) on cloud storage (CS) outside the secure environment (SE). The asymmetric encryption method is based on a private key PRK and a public key PUK, wherein the public key PUK of the asymmetric encryption method is used for the asymmetric encryption, and wherein the private key PRK used for corresponding decryption is retained in the secure environment (SE).

2. The method as described in claim 1, wherein, The public key PUK and / or the private key PRK are stored in the domain of the secure environment in their respective encrypted states ePUK / ePRK, wherein the corresponding encrypted states ePUK / ePRK are generated by encrypting the public key PUK or the private key PRK using the security environment-specific token SEST, respectively.

3. The method as described in claim 2, wherein, The security environment-specific token SEST is based on at least one of the following: - The identifier token of the security environment (SE); - Identifier tokens for at least one device (1, 10, 100) in the security environment (SE); - An identifier token for at least one software application used within the security environment (SE); and / or - The version number of the data to be encrypted using the public key PUK.

4. The method according to any one of claims 1-3, wherein, The encrypted reidentification database (eRIDB) is also stored in the device (1) within the secure environment (SE).

5. The method according to any one of claims 1-3, wherein, The encrypted re-identification database (eRIDB) is generated (S60) or processed into a plurality of blocks stored on the cloud storage (CS).

6. The method of claim 5, wherein, Blocks belonging to at least two different versions of the Reidentified Database (RIDB) are stored in an encrypted state on the cloud storage (CS); and wherein the method further includes the step of generating a Version Correspondence List (VCL) indicating which blocks belong to which version, wherein the blocks preferably do not contain any plaintext information about the version to which they belong.

7. The method of claim 6, further comprising the following steps: encrypting the version correspondence list VCL to obtain an encrypted version correspondence list eVCL; and storing the encrypted version correspondence list eVCL on the cloud storage (CS).

8. The method of any one of claims 1-3, further comprising the step of generating encrypted de-identified medical data (eDIMD), wherein, The storage of the de-identified medical data (DIMD) on the cloud storage (CS) (S70) includes or consists of storing the encrypted de-identified medical data (eDIMD) on the cloud storage (CS).

9. The method of any one of claims 1-3, further comprising the step of retrieving the medical data (MD) from the cloud storage (CS), the step comprising: - Retrieve (S80) the de-identified medical data (DIMD) from the cloud storage (CS); - Retrieve (S90) the encrypted re-identification database (eRIDB) from the cloud storage (CS); - Decrypt the encrypted re-identification database (eRIDB) in the secure environment (SE) (S100) to obtain the re-identification database (RIDB); - The medical data (MD) is regenerated from the deidentified medical data (DMID) by replacing or associating the non-patient identifier encoded identifier (NPICI) in the deidentified medical data (DIMD) with the corresponding patient identifier data (PID) based on the reidentification database (RIDB) (S110).

10. The method of any one of claims 1-3, comprising the step of providing the de-identified medical data (DIMD) from the cloud storage (CS) (S200) to a processing entity (3Pout) outside the secure environment (SE).

11. The method of claim 10, comprising training (S210) an artificial intelligence entity by the processing entity (3Pout) based on the de-identified medical data (DIMD).

12. A gateway (100) for use in a secure environment (SE), the gateway comprising: - Input module (110), the input module is configured to obtain (S30) medical data (MD), the medical data including patient attribute data (PPD) and patient identifier data (PID), wherein the patient identifier data (PID) indicates at least one patient corresponding to the patient attribute data (PPD); - De-identification module (120), the de-identification module is configured to generate (S40) de-identified medical data (DIMD) by replacing the patient identifier data (PID) in the medical data (MD) with corresponding non-patient identifier encoded identifiers (NPICI), wherein each non-patient identifier encoded identifier is a hash key of the patient identifier data PID, a hash key of a portion of the patient identifier data PID, and / or based on at least a portion of the patient identifier data PID and other data; - Database generation module (130), the database generation module is configured to generate (S50) a reidentification database (RIDB) indicating the correspondence between the non-patient identifier encoded identifier (NPICI) and the patient identifier data (PID); - An encryption module (140) is configured to generate (S60) an encrypted reidentification database (eRIDB) by applying at least one asymmetric encryption method to the reidentification database (RIDB); - A communication module (150) configured to transmit (S70) the encrypted re-identified database (eRIDB) and the de-identified medical data (DMID) to be stored on cloud storage (CS) outside the secure environment (SE), wherein the asymmetric encryption method is based on a private key PRK and a public key PUK, wherein the public key PUK of the asymmetric encryption method is used for the asymmetric encryption, and wherein the private key PRK used for corresponding decryption is retained in the secure environment (SE).

13. A computer program product (200) comprising executable program instructions (250) configured to perform the method according to any one of claims 1 to 11 when executed.

14. A non-transitory computer-readable data storage medium (300) comprising executable program instructions (350) configured to perform the method according to any one of claims 1 to 11 when executed.

Images