Method and system for data processing via pseudonymization

Abstract

The present invention relates to a method for adding data to a database, wherein the method comprises retrieving a transport pseudonym based, at least in part, on a medical data code assigned to a user, and retrieving a medical data pseudonym based, at least in part, on the transport pseudonym. The present invention also relates to a corresponding system, to a use of the system, and to a computer program product for generating the medical data code.

Description

[0001] METHOD AND SYSTEM FOR DATA PROCESSING VIA PSEUDONYMIZATION

[0002] Field

[0003] The present invention relates to field of data processing. More particularly, it relates to a method and a system for creating and / or managing a database of medical data of patients, and for using the database to send information to the patients.

[0004] Background

[0005] Recent advances in the field of medicine have made it possible to develop treatments for diseases once thought incurable. A significant contribution to this progress has been made by developments in the understanding of human genetics. However, while significant progress has been made, there remains a substantial number of diseases the genetic origin of which is, at least substantially, confirmed, but for which there are no treatments. A relevant consideration in developing treatments for such diseases may be the difficulty in identifying patients with a specific genetic disease or mutations / symptoms associated with a specific genetic disease for conducting informational surveys or clinical trials on such patients.

[0006] Typically, such patients may be identified at a laboratory or a physician. Thus, it may be of advantage, to share information about upcoming surveys or clinical trials with the laboratory or the physician. However, the laboratory or the physician may not have appropriate permissions to share contact details of the patients with third parties. Even when the appropriate permissions are available, the identification of patients with specific genetic diseases or mutations relevant to a specific genetic disease may be cumbersome. Further, the process of sharing information about a new clinical trial or survey and obtaining the patient's consent may be time-consuming and inefficient. Or, sharing the information with a sufficient number of laboratories or physicians to allow robust survey or trial results may be difficult.

[0007] In light of the above considerations, it is an object of the present invention to provide a system and a method for identifying patients with a specific genetic disease or mutations / symptoms associated with a specific genetic disease and to send information about new clinic trials / surveys to the identified patients that may be simpler, and more efficient. Embodiments of the present invention may further allow patients to be contacted more easily and with enhanced data privacy and security.

[0008] Summary

[0009] In the following, storing an association between a pair of data elements may be understood to comprise storing a relationship between the two data elements. For example, the relationship may be stored by means of a look-up table, a symbol table, a tree, or any other suitable data structure. Further exemplarily, the association may be stored by means of a function such that the function may accept as input the two data elements and output true / false depending on whether there exists an association between the input data elements. Alternatively, or additionally, one of the data elements may be generated based, at least in part, on the other data element, and the association may be stored as the function used for the generation. Yet further exemplarily, an object may be created, comprising the two data elements as instance variables of the object. Generally, it may be understood, that suitable means for storing an association may be provided.

[0010] According to a first aspect, the present invention relates to a method for adding data to a database, wherein the method comprises: retrieving a transport pseudonym based, at least in part, on a medical data code assigned to a user, and retrieving a medical data pseudonym based, at least in part, on the transport pseudonym. The assignment to a user may be understood to comprise a physical assignment such that the user is in possession of the medical data code physically. This may be of advantage in ensuring that no other person may use the medical data code to add data to the database.

[0011] The method may further comprise retrieving medical data based, at least in part, on the medical data code.

[0012] The retrieved medical data may comprise encrypted medical data.

[0013] The method may comprise storing the retrieved medical data and storing an association between the medical data pseudonym and the retrieved medical data.

[0014] The method may comprise generating the medical data code.

[0015] Generating the medical data code may comprise obtaining the transport pseudonym and generating the medical data code based, at least in part, on the transport pseudonym.

[0016] Generating the medical data code may comprise obtaining unencrypted medical data.

[0017] The method may comprise determining if the unencrypted medical data comprises a defined format.

[0018] The method may comprise, in response to determining that the unencrypted medical data does not comprise the defined format, converting the unencrypted medical data to the defined format.

[0019] Generating the medical data code may comprise, in response to the unencrypted medical data comprising the defined format, compressing the unencrypted medical data comprising the defined format. Generating the medical data code may comprise obtaining a public key and encrypting the compressed unencrypted medical data using the public key.

[0020] The method may comprise generating the medical data code based, at least in part, on the encrypted medical data.

[0021] The method may comprise providing the generated medical data code to the user.

[0022] The medical data code may comprise a QR-code.

[0023] The user may comprise a patient with a genetically-confirmed medical disease.

[0024] According to a second aspect, the present invention relates to a computer program product comprising instructions, when executed on a device capable of executing the computer program product, to generate a medical data code, generating the medical data code comprising at least one of: obtaining a transport pseudonym, retrieving unencrypted medical data, converting the retrieved unencrypted medical data to a defined format, compressing the unencrypted medical data in the defined format, obtaining a public key and encrypting the unencrypted, compressed medical data in the defined format based, at least in part, on the public key.

[0025] The method, as described above, may further comprise providing, to the user, the computer program product as described above.

[0026] According to a third aspect, the present invention relates to a system for adding data to a database, wherein the system may comprise: a user data handling component configured to retrieve a transport pseudonym based, at least in part, on a medical data code assigned to a user, the user data handling component further configured to retrieve a medical data pseudonym based, at least in part, on the transport pseudonym.

[0027] The system may be further configured: to retrieve medical data based, at least in part, on the medical data code, to store the retrieved medical data and to store an association between the retrieved medical data and the medical data pseudonym, and to receive and to store contact data for the user.

[0028] According to a fourth aspect, the present invention relates to a use of a system as described above, the system further configured to accept search criteria, the use comprising identifying users with a defined genetic diagnosis based, at least in part, on the search criteria, and sending information to the identified users.

[0029] Exemplary features of the present invention are further detailed in the accompanying figures and the description of the figures below. Brief Figure Description

[0030] Figure 1 depicts an embodiment of a system for managing data in a database;

[0031] Figure 2 depicts an embodiment of a method for preparing data to be added to the database;

[0032] Figure 3 depicts an embodiment of a method for adding prepared data to the database; and

[0033] Figure 4 depicts an embodiment of a method for using the database to send information.

[0034] Detailed Figure Description

[0035] Figure 1 depicts an embodiment of a system 1 according to the present invention. The system 1 may be configured for creating and / or updating and / or using a database of user data. The system 1 may be configured to add and / or update data in the database or to use the database for sending notification. The system 1 may, in particular, be of advantage for storing and / or retrieving patient data of patients with a genetic disease. Preferably, the system 1 may be used to store and / or retrieve patient data for patients with a medically-confirmed genetic disease.

[0036] Patient data may be understood to comprise identification data, the identification data comprising contact data that may be used to contact a patient. For example, contact data may comprise any of a mailing address, a contact number, an electronic address such as an email address, or other such data related to the patient. In some embodiments, the identification data may further comprise personal data that may be used to identify a patient. For example, personal data may comprise any of a name, an age, a sex, a date of birth of the patient. In particular, the identification data may not comprise data that may be related, at least in part, to a health of the patient.

[0037] Patient data may further comprise medical data related to a patient. Medical data may comprise, generally, any data related or relevant to a health of the patient. Preferably, medical data may comprise information related, at least in part, to any of (an) affected gene(s), a mutation associated with the genetic disease in the affected gene(s), (an) existing symptom(s) that may be associated with the mutation, an age, or a gender of the patient. Note that data comprised in medical data and in identification data may not be disjoint. In particular, as described above, an age or a sex of the patient may be comprised in both identification and medical data.

[0038] Typically, when dealing with patient data, privacy and security of the data may be of concern. Embodiments of the present technology may be of particular advantage when considering privacy and security of the patient data. The system 1 may comprise a plurality of data handling components. A first data handling component 10, that may be called an identification data handling component, may be used, at least in part, to store the identification data as described above. A second data handling component 20, that may be called a medical data handling component, may be used, at least in part, to store the medical data as described above. Further, the system 1 may comprise a third data handling component 30, that may be called a user data handling component. A fourth data handling component 40, that may be called a pseudonym data handling component, may be used, at least in part, to generate, store, or retrieve pseudonym data as will be described further below.

[0039] The identification data handling component 10 and the pseudonym data handling component 40 may, preferably, run on the same server.

[0040] Any of the plurality of data handling components may itself comprise a plurality of components. In the embodiment depicted in Figure 1, the identification data handling component 10 comprises an identification data storage unit 102 configured, at least in part, to store identification data as described above, an identification data processing unit 104, and an identification data communication unit 106. Similarly, the medical data handling component 20 comprises a medical data storage unit 202 configured, at least in part, to store medical data as described above, a medical data processing unit 204, and a medical data communication unit 206. The user data handling component 30 may comprise a user data storage unit 302, a user data processing unit 304, and a user data communication unit 306, and the pseudonym data handling component 40 may comprise a pseudonym data storage unit 402, a pseudonym data processing unit 404, and a pseudonym data communication unit 406.

[0041] Any of the plurality of data handling components may provide hardware and software protection for maintaining the secrecy of data in the data handling component. For example, each of the identification data handling component 10, the pseudonym handling component 40 and the medical data handling component 20 may be programmed so that only defined data may leave the data handling components 10, 20, 40, while other data cannot leave the data handling components 10, 20, 40.

[0042] Any of the plurality of data handling components may be queried to retrieve the data, or at least a part thereof, stored in the corresponding data storage unit. In particular, each of the plurality of data handling components may be configured to allow retrieval of data, or at least a part thereof, based, at least in part, on a filter. In other words, the data handling component may receive a set of conditions. In response to receiving the set of conditions, the data handling component may return data, or at least a part thereof, that satisfies each of the conditions in the set of conditions. Examples of typical conditions that may be supported are described further below.

[0043] The different data handling components 10, 20, 30, 40 may provide different levels of data security and / or privacy. For example, the data handling components 10 and 40 may be configured to provide a higher level of data security and privacy than the data handling components 20 and 30.

[0044] The solid arrows in Figure 1 depict possible connections between different units / components that allow flow of data. Thus, for example, within each data handling component, data may flow between the data communication unit and the data processing unit, and between the data processing unit and the data storage unit. Further, the data communication units of each of the data handling components may allow exchange of data with any of the other data handling components. For the user data handling component 30, data may additionally flow between the user data communication unit 306 and an external device 2, 3, or 4, as described further below. Further, the data flows between the different data handling components 10, 20, 30, 40 may only be initiated via protected and access- restricted interfaces.

[0045] In some embodiments, the communication between the different data handling components 10, 20, 30, 40 may take place over a plurality of channels. At least one of the plurality of channels may comprise a one-way communication channel such that the data may only be sent by a first data handling component to a second data handling component without a possibility for the second data handling component to send data to the first data handling component, over which patient data may be communicated. The one-way communication channel may comprise a secure one-way channel. This may be of advantage in further enhancing data security as the patient data may not be accessible if, for example, no secure communication channel is available between the source of the patient data and the requesting component. The dashed arrows in Figure 1 depict one-way communication channels.

[0046] For example, the user data handling component 30 and the medical data handling component 20 may exchange patient data over a one-way communication channel such that the user data handling component 30 may only send the medical data to the medical data handling component 20, but may not be allowed to access the medical data thereafter. Similarly, a oneway communication channel may exist between the user data handling component 30 and the identification data handling component 10.

[0047] Generally, in the following, it may be understood, that whenever patient data is sent from a first data handling component to a second data handling component, there exists a, preferably secure, one-way communication channel between them.

[0048] The identification data handling component 10 may be configured to store the identification data related to a patient. In particular, the identification data may be stored in the identification data storage unit 102. The identification data handling component 10, particularly the identification data processing unit 104 thereof, may be configured to associate a unique identification data identifier with the identification data related to a patient, i.e., for each patient whose identification is stored in the identification data storage unit 102, a unique identification data identifier may be generated. In some embodiments, the identification data identifier may also be stored in the identification data storage unit 102.

[0049] The identification data handling component 10 may be further configured to send the identification data identifier. In particular, the identification data handling component 10 may be configured to send the identification data identifier to the pseudonym data handling component 40, where the pseudonym data handling component 40 may generate a master pseudonym based, at least in part, on and / or associated with, the identification data identifier. The pseudonym data handling component 40 may be configured to store the identification data identifier and the associated master pseudonym.

[0050] The medical data handling component 20 may be configured to store the medical data related to a patient. The medical data handling component 20 may be configured to receive the medical data related to a patient in a defined format. The defined format may comprise, for example, the PhenoPacket format. Further, the medical data received by the medical data handling component 20 may be encrypted. The medical data handling component 20, particularly the medical data processing unit 204 thereof, may be configured to decrypt the received medical data.

[0051] In particular, the medical data handling component 20, particularly the medical data processing unit 204 thereof, may be configured to generate a private-public key pair using an asymmetric key generation procedure such as a procedure based, at least in part, on RSA (such as 4096-bit RSA) or Elliptic Curve Cryptography. The private key may be stored in the medical data storage unit 202, or at least a portion thereof, and may be retrieved by the medical data processing unit 204, when needed. The public key may be sent to the user data handling component 30 and may be used for encrypting the medical data of a patient, thus allowing enhanced security of the medical data.

[0052] The medical data handling component 20 may be further configured to receive a medical data pseudonym, from the pseudonym data handling component 40. The medical data handling component 20 may be configured to associate the medical data pseudonym with the medical data of a patient. The medical data pseudonym may be of advantage in allowing access to the medical data of a patient without having to send the medical data outside of the medical data handling component 20.

[0053] For example, as described further below, the medical data handling component 20 may receive a set of conditions according to which to filter the medical data stored in the medical data storage unit 202. The medical data handling component 20 may filter the medical data accordingly and only return the medical data pseudonyms corresponding to / associated with the medical data satisfying the set of conditions. Thus, medical data may not be transferred outside the medical data handling component 20. This may be of advantage in further enhancing data security and privacy. The user data handling component 30 may allow the external device 2, 3, or 4, to communicate with the system 1. Further, the user data handling component 30, particularly the user data communication unit 306 thereof, may be configured to connect to other external devices, such as over the Internet, thus allowing the system 1 to communicate over the Internet. Thus, the user data handling component 30 may serve as an interface to the system 1. The user data handling component 30 may allow the system 1 to receive requests for data stored in the system 1 as well as allow data to be added to the system 1. Thus, the user data handling component 30 may allow the creation and / or usage of the database of patient data. The user data handling component 30 may be further configured to receive and to store the public key sent by the medical data handling component 20, as described above.

[0054] The pseudonym data handling component 40 may be configured to generate and / or store and / or send pseudonyms. The pseudonym data handling component 40 may be configured to generate the pseudonyms based, at least in part, on a specification received, for example, from the user data handling component 30. The specification may comprise a length of the pseudonym, a character set for the pseudonyms, defined prefixes or suffixes for the pseudonyms, check digits (for example, any of Hamming, Reed-Solomon-Lagrange, Verhoeff, or other such codes), or other suitable specifications. The specification may be received by the system 1, particularly the user data handling component 30 thereof, from a user. Alternatively, the specification may be pre-defined. Preferably, the specification may be received once while setting up the system 1, particularly the pseudonym data handling component 40 thereof.

[0055] The pseudonym data handling component 40 may be further configured to generate pseudonyms hierarchically. A desired hierarchy may be pre-defined or may be received by the system 1 from a user. An exemplary hierarchy for the pseudonyms will be described further below.

[0056] In particular, as described above, the pseudonym data handling component 40 may receive an identification data identifier from the identification data handling component 10 and based, at least in part, thereon, generate a master pseudonym associated with the received identification data identifier. The pseudonym data handling component 40 may be further configured to generate a contact data pseudonym and / or a medical data pseudonym based, at least in part, on, and associated with, the master pseudonym. In some embodiments, the medical data pseudonym may, alternatively, be generated based, at least in part, on the contact data pseudonym. The pseudonym data handling component 40 may be further configured to generate a transport pseudonym, that may, at generation, not be derived from or linked to any other pseudonym or data. The pseudonym data handling component 40 may be further configured to store any of the master pseudonym, the contact data pseudonym, the transport pseudonym, or the medical data pseudonym. Preferably, the pseudonym data handling component 40 may store all of them. The pseudonym data handling component 40 may be configured to send any of the transport pseudonym, contact data pseudonym, and the medical data pseudonym. In particular, the medical data pseudonym may be sent, directly (i.e., without any other data handling component in between) or indirectly (i.e., with another data handling component in between) to the medical handling component 20 where it may be associated with the medical data related to a patient as described above. The contact data pseudonym may, in some embodiments, be sent to the user data handling component 30. The transport pseudonym may, in some embodiments, be sent to the user data handling component 30 in order to be forwarded by the user data handling component 30 to the device 2, 3, 4 communicating with the user data handling component 30. The user data handling component 30 may be configured not to store the transport pseudonym permanently in its user data storage unit 302.

[0057] Note that, the data handling components 10, 20, 30, 40 have been described above to comprise various functional units, and that this should only be considered exemplary but not limiting to the physical configuration of the different data handling components. For example, in some embodiments, each unit may be comprised in a different device, or two units may be comprised in one device and the other units in another device, and so on. Generally, the physical distribution of the units may be varied, as long as the functional configuration of the units corresponds to the embodiment depicted in Figure 1.

[0058] The external device 2 may comprise a device capable of executing a computer program. For example, the external device 2 may comprise a computer, a smartphone, a tablet, or any other suitable device. The external device 2 may correspond, for example, to a computer at a laboratory or a physician where the patient is being tested / treated. The external device 2 may further comprise means to allow input of data. In particular, the external device 2 may comprise means to capture data optically, i.e., by means of a camera, a code scanner, or other suitable optical devices. These means may be of advantage in capturing medical data of the patient as will be described in further detail below.

[0059] Embodiments of the system 1 as depicted in Figure 1, and as described above, may be of advantage for creating and / or using a database of patient data. Various steps of an embodiment of a method according to the present invention to create and / or use a database of patient data will now be described.

[0060] Generally, embodiments of the method according to the present technology may be divided into two phases. A first phase may comprise a preparation phase comprising preparing the medical data of a patient for adding to the database. The preparation phase may be of particular relevance when the medical data is received by the patient from a physician or a laboratory. For example, the laboratory or the physician may provide the medical data to the patient in a format that may be suitable for adding to the database. A subsequent phase may comprise addition of the medical data to the database. In each of these phases, it may be of advantage to enhance data security and privacy. These phases will now be described in further detail.

[0061] Figure 2 depicts an embodiment of the preparation phase of the method according to the present invention. A first step, Pl, of the method may comprise establishing a channel between the external device 2 and the system 1, particularly the user data handling component 30 thereof. For example, the external device 2 may comprise a computer at a laboratory or a physician where a patient is being treated / tested.

[0062] The channel between the external device 2 and the system 1, particularly the user data communication unit 306 thereof, may allow data to be exchanged between the external device 2 and the system 1. In particular, the channel may allow the external device 2 to send requests to the system 1, and for the system 1 to send responses based, at least in part, on the requests from the external device 2.

[0063] The external device 2 and the system 1 may be appropriately configured to allow establishing the channel between the external device 2 with the system 1. For example, the external device 2 may comprise a communication unit capable of establishing the channel with the user data communication unit 306 of the system 1. Further exemplarily, the system 1 may only allow a recognized external device 2 to establish a channel with the system 1, wherein the system 1 may be configured to determine whether or not a defined external device 2 is recognized.

[0064] Establishing the channel between the external device 2 and the system 1 may comprise executing, on the external device 2, a computer program product. The computer program product may comprise instructions, at least part of which, when executed on the external device 2, allow the external device 2 to establish a channel with the system 1.

[0065] The computer program product may comprise instructions, for example, to automatically establish a channel with the system 1 in response to a defined action performed on the external device 2. In other words, performance of the defined action on the external device 2 may automatically trigger establishing of the channel between the external device 2 and the system 1.

[0066] As described above, the external device 2 may comprise a computer at a laboratory or a physician where a patient is being treated / tested. The computer program product may be preinstalled on the computer and may be configured such that whenever a genetic origin of a patient's disease is confirmed, either by the physician or by the laboratory testing, the channel to the system 1 is established.

[0067] Alternatively, in some embodiments, the physician or a laboratory employee may connect to the system 1, via a website for example, and download the computer program product that may then be executed locally on the computer to establish the channel between the system 1 and the computer. As may be appreciated, the system 1, particularly the user data storage unit 302 thereof, may store the computer program product to allow it to be retrieved later on.

[0068] The connection to the system 1 to allow access to the computer program product may be restricted such that only a recognized user can access the computer program product. For example, the system 1 may be configured to prompt the user for an input and based, at least in part, thereon, determine whether or not the user is recognized. Various forms of input as generally known for authentication may be employed.

[0069] In a next step, P2, the external device 2 may send a request for a pseudonym, that may be called a transport pseudonym, to the system 1, particularly to the user data handling component 30 and the user data communication unit 306 thereof.

[0070] Requesting the transport pseudonym may be triggered automatically. For example, the computer program product may send the request for the transport pseudonym automatically in response to the channel between the system 1 and the external device 2 being established. Alternatively, or additionally, the request for the transport pseudonym may be triggered manually. For example, once the channel between the system 1 and the external device 2 has been established, a prompt may be generated to send the request for the transport pseudonym.

[0071] The next step, P3, may comprise generating the transport pseudonym. In response to receiving a request for the transport pseudonym, the system 1, particularly the user data handling component 30 thereof, may send a request to the pseudonym data handling component 40 to generate the transport pseudonym.

[0072] The pseudonym data handling component 40, particularly the pseudonym data processing component 404 thereof, may generate the transport pseudonym and send it to the user data handling component 30. In some embodiments, the pseudonym data processing component 404 may also send the generated transport pseudonym to the pseudonym data storage component 402 for storage. This may be of advantage in determining if a received transport pseudonym is a valid transport pseudonym as will be described further below.

[0073] In a further step, P4, the generated transport pseudonym may be sent to the external device 2 by means, for example, of the user data communication unit 306. Thus, generally, the method may comprise the step of obtaining a transport pseudonym. The external device 2 may be configured to store the transport pseudonym and to associate the transport pseudonym with the patient, or at least data related thereto. The same transport pseudonym may then be provided to the patient together with medical data in future. This may be of advantage in improving an efficiency of updating the database, for example. The method may further comprise obtaining a public key. The public key may be used to encrypt the medical data of the patient. Encryption of the medical data may be of particular advantage in enhancing the privacy and security of the patient data.

[0074] To obtain the public key, the external device 2 may, in a next step, P5, send a request for the public key to the user data handling component 30. The request may be sent automatically, for example, as part of the instructions comprised in the computer program product as described above. Alternatively, or additionally, a prompt may be generated to confirm sending the request for the public key, corresponding to a manual sending of the request.

[0075] The user data handling component 30 may, in response to the request for the public key, retrieve the public key, received earlier from the medical data handling component 20 as described above, and send it to the external device 2, as a next step, P6.

[0076] The next step, P7, may comprise compressing the medical data of the patient. The compression may be carried out, for example, as part of the instructions comprised the computer program product. In other words, as part of the execution, the computer program product may prompt for the medical data of the patient. The physician or the laboratory employee may provide the medical data of the patient, that may then be compressed.

[0077] The medical data may be provided in a defined format, such as PhenoPacket, before compression. This may be of advantage in enhancing the compression efficiency. In particular, the computer program product may comprise instructions to convert the medical data to the defined format, if needed.

[0078] The compressed medical data may then, in step P8, be encrypted using the public key received from the system 1. In a further step, P9, a medical data code may be generated based, at least in part, on the encrypted, compressed medical data and on the transport pseudonym. The medical data code may be scanned or read to allow access to the encrypted medical data and the transport pseudonym. For example, the medical data code may comprise a matrix- data-code, a QR code, a bar-code. In some embodiments, the medical data code may be provided on a means for data carriage such as a USB-drive, a memory card, an NFC / RFID chip, or other suitable means for data carriage.

[0079] In some embodiments, the medical data code may be generated based also on additional data. The additional data may comprise, for example, metadata related, at least in part, to the medical data, such as a name of the laboratory or the physician where the medical data was obtained, a date when the medical data was obtained, or a method by which the medical data was obtained. The additional data may also be compressed and / or encrypted before being used to generate the medical data code. The medical data code may then be provided, in a next step PIO, to the patient. The steps Pl to PIO of the method, as described above, may comprise the first phase of the method as described above. An end result of the first phase of the method may, thus, be provision of the medical data code, that may be used to access the encrypted medical data, the additional data, and the transport pseudonym, to the patient.

[0080] The second phase of the method may comprise the patient adding their medical data to the database, using the system 1. Note that the second phase can only be initiated by the patient, or their legally authorized representative. In the following, it may be understood, that any steps that are described as being carried out by the patient may also be carried out by the legally authorized representative. Therefore, there may be cases where the second phase is not initiated and / or completed. In the following, the second phase will be described. For the second phase, it may be assumed that the patient is already in possession of the medical data code. An embodiment of the second phase of the method according to the present invention is depicted in Figure 3.

[0081] A first step, QI, of the method may comprise receiving a request to add medical data and / or additional data. The request may be sent by a patient in possession a medical data code as described above. The request may be sent to the system 1 by means of an external device 3.

[0082] The external device 3 may correspond to a device used by the patient. In particular, the external device 3 may allow for input by the patient. For example, the external device 3 may comprise a keyboard, a mouse, a touchscreen, a joystick, a gamepad, or a remote controller. Further, the external device 3 may comprise means for capturing an image, for reading, or for scanning the medical data code. For example, the external device 3 may comprise a camera, a bar-code reader, a QR-code reader, or a matrix-data-code reader. The external device 3 may additionally, or alternatively, comprise means for retrieving data from the means for data carriage as described above. In particular, the external device 3 may comprise a USB-port, a memory card reader, an NFC / RFID reader, or other readers corresponding to the means of data carriage as described above.

[0083] The patient may be required to create and / or login to a user account before being allowed to add the medical data and / or additional data. The system 1, particularly the user data handling component 30 thereof, may be configured to allow the patient to create and / or login to a user account. Creating and / or logging in to a user account may comprise providing login details comprising, for example, a username and a password. In some embodiments, creation of a user account may comprise receiving an email address of the user. The user data handling component 30, particularly the user data storage unit 302 thereof, may be configured to store the login details including the email address of the patient.

[0084] The next step, Q2, may comprise receiving the transport pseudonym, the (encrypted) medical data, the additional data, and the identification data. The transport pseudonym, the medical data, the additional data, and the identification data may be sent to the system 1, particularly the user data handling component 30 thereof, by the patient via, for example, the external device 3, as described above.

[0085] In particular, receiving the transport pseudonym, the medical data, and the additional data may comprise receiving encrypted medical data from the patient. The transport pseudonym, the medical data, and the additional data may be sent to the system 1, for example, by means of reading and or scanning the medical data code using, for example, the external device 3. For example, the medical data code may comprise a QR-code and the patient may scan the QR-code using means provided therefor in the external device 3.

[0086] Further exemplarily, receiving the transport pseudonym, the (encrypted) medical data, and the additional data, may comprise sending a computer program product to the external device 3. The computer program product may comprise instructions to retrieve the medical data, the additional data, and the transport pseudonym from the external device 3. For example, the computer program product may prompt the patient to read / scan the medical data code. Alternatively, the computer program product may prompt the patient to capture an image of the medical data code, or to provide a location on the external device 3 where such an image may be stored.

[0087] The computer program product may further comprise instructions to prompt the patient for confirmation to send the retrieved data, that may comprise the (encrypted) medical data, the additional data, and the transport pseudonym (in case the medical data code is read / scanned), or that may comprise the image of the medical data code, to the system 1.

[0088] Receiving the identification data may comprise sending a computer program product to the external device 3. The computer program product may comprise instructions, when executed on the external device 3, to retrieve the identification data from the external device 3. For example, the computer program product may comprise instructions to prompt the patient for the identification data. Alternatively, or additionally, the computer program product may be configured to retrieve the identification data, at least in part, from an NFC-capable identity card of the patient by means, for example, of an NFC reader of the external device 3. Or, for example, the computer program product may allow the patient to capture an image of an identity card of the patient and process the image to obtain the identification data.

[0089] In some embodiments, receiving the identification data may further comprise authenticating the identification data. For example, the system 1 may prompt the patient for further authentication of their identity by means, for example, of a government-issued identity card.

[0090] The computer program product may further comprise instructions to prompt the patient for confirmation to send the identification data to the system 1. The computer program product may, thus, allow sending the identification data to the system 1 more simply, easily, and efficiently.

[0091] As may be appreciated, the computer program product, as described above, may comprise instructions to retrieve the identification data, and any of the image of the medical data code or the data from reading / scanning the medical data code, accumulate all the data, and send it to the system 1 together. In other words, the same computer program product may be used to obtain the identification data, and to obtain the medical data, the additional data, and the transport pseudonym.

[0092] In response to the patient confirming the sending of the retrieved data, the computer program product may send the retrieved data to the system 1.

[0093] The retrieved data may be received by the system 1, particularly the user data handling component 30 thereof. The user data handling component 30 may be configured to determine a kind of data received, e.g., if the data received comprises an image of the medical data code. If the received data is determined to comprise (encrypted) medical data, additional data, and the transport pseudonym, the user data handling component 30 may process it as described further below. If, on the other hand, the received data comprises an image, for example of the medical data code, the user data handling component 30 may be configured, to process the image to retrieve the (encrypted) medical data, the additional data, and the transport pseudonym. Thus, generally, it may be understood that at the end of step Q2, the system 1 may have access to the (encrypted) medical data, the additional data, and the transport pseudonym.

[0094] In response to receiving the transport pseudonym, the user data handling component 30 may send it to the pseudonym data handling component 40, where the pseudonym data handling component 40 may, in a step Q3, determine if the transport pseudonym is a valid transport pseudonym. Determination if the transport pseudonym is a valid pseudonym may comprise determining if the transport pseudonym corresponds to a transport pseudonym stored in the pseudonym data handling component 40, corresponding to a valid generation of the transport pseudonym.

[0095] Then, in a step, Q4, if the transport pseudonym is determined to be valid, the pseudonym data handling component 40 may determine if the transport pseudonym is already associated with a master pseudonym, corresponding to a prior association of the transport pseudonym with a patient. Association with the master pseudonym may be understood to comprise the pseudonym data handling component 40 being able to determine based, at least in part, on the master pseudonym the transport pseudonym and based, at least in part, on the transport pseudonym the master pseudonym. As may be appreciated, the association between the master and the transport pseudonym may, thus, comprise a one-to-one association. If the transport pseudonym is determined to not already be associated with a master pseudonym, the system 1 may, in subsequent steps (Q5 to Q10) as described below, be configured to generate a master pseudonym and to associate the transport pseudonym with the master pseudonym. To this end, a corresponding notification may be sent to the user data handling component 10. In a next step, Q5, the system 1, particularly the user data handling component 30 thereof, may, in response to receiving the notification from the pseudonym data handling component 40, send the received identification data and the transport pseudonym to the identification data handling component 10. The identification data may or may not be encrypted before being sent to the identification data handling component 10.

[0096] The identification data handling component 10 may, in a next step, Q6, store the identification data in the identification data storage unit 102. In particular, the identification data handling component 10 may send the received identification data to the identification data storage unit 102.

[0097] In a further step, Q7, the identification data handling component 10 may associate a unique identifier with the identification data, as described above. The identification data identifier, thus associated, may comprise, at least in part, for example, a reference to or an address of a location in the identification data storage unit 102 where the identification data is stored. Generally, it may be understood that the identification data handling component 10 may be configured to use, at least in part, the identification data identifier to retrieve the identification data associated with the patient.

[0098] In some embodiments, the identification data handling component 10 may generate the identification data identifier satisfying, at least in part, a condition. Such generation of the identification data identifier may be of particular advantage if the identification data identifier is required to satisfy some conditions such as being composed of characters from a defined character set, a starting substring, or an ending substring.

[0099] The identification data handling component 10 may, in a subsequent step, Q8, send the identification data identifier and the transport pseudonym to the pseudonym data handling component 40.

[0100] The pseudonym data handling component 40 may generate, in response to receiving the identification data identifier, a master pseudonym based, at least in part, on the identification data identifier as a next step, Q9.

[0101] The master pseudonym generated by the pseudonym data handling component 40 may be of advantage in connecting the identification data of the patient with their medical data, as will be described further below. The pseudonym data handling component 40 may, in a subsequent step Q10, associate the transport pseudonym with the master pseudonym generated based, at least in part, on the identification data identifier. Thus, at the end of step Q10, the transport pseudonym is associated with a master pseudonym.

[0102] If, however, at step Q4, the transport pseudonym is determined to be already associated with a master pseudonym, a corresponding notification may be sent to the user data handling component 10.

[0103] Regardless of whether or not the transport pseudonym was determined to be already associated with a master pseudonym, the transport pseudonym is associated with a master pseudonym at the end of step Q4, or Q10 as described above.

[0104] In some embodiments, the pseudonym data handling component 40 may generate, in response to generating the master pseudonym, a contact data pseudonym based, at least in part, on the master pseudonym. The generation of the contact pseudonym may comprise a step Qll of the method.

[0105] In a next step, Q12, the pseudonym data handling component 40 may send the contact data pseudonym, generated as described above, to the user data handling component 30. The user data handling component 30 may be configured to associate the contact data pseudonym with the user account as described above, in a next step, Q13. The user data handling component 30 may further be configured to store the contact data pseudonym and its association with the user account.

[0106] The user data handling component 30 may, in a next step, Q14, send a request to the pseudonym data handling component 40 to generate a medical data pseudonym. In a subsequent step, Q15, the pseudonym data handling component 40 may generate a medical data pseudonym based, at least in part, on the master pseudonym associated with the transport pseudonym, and send it to the user data handling component 30. Alternatively, or additionally, in embodiments where a contact pseudonym has been generated, the medical data pseudonym may be generated based, at least in part, on the contact pseudonym.

[0107] In a subsequent step, Q15', the medical data pseudonym may be associated with the contact data pseudonym, if the medical data pseudonym in not generated based, at least in part, on the contact data pseudonym.

[0108] The user data handling component 30 may, in a next step, Q16, send the (encrypted) medical data, and the additional data, to the medical data handling component 20 together with the medical data pseudonym received from the pseudonym data handling component 40 in step Thus, overall, owing to the encryption, the medical data may be securely delivered to the system 1, without a possibility for accessing the decrypted medical data. The medical data is also secured against middle-man attacks as it remains encrypted until it reaches the medical data handling component 20 of the system 1.

[0109] The medical data handling component 20 may, in a further step Q17, decrypt the encrypted medical data received from the user data handling component 30. The decryption may be carried out using the private key stored, as described above, in the medical data storage unit 202. The decrypted medical data and the additional data may be sent to the medical data storage unit 202 for storage.

[0110] In a next step, Q18, the medical data handling component 20 may associate the received medical data pseudonym with the medical data and the additional data stored in the medical data storage unit 202. In other words, the medical data handling component 20 may be configured to retrieve based, at least in part, on the medical data pseudonym, the associated medical data and / or the additional data and to retrieve based, at least in part, on the medical data, the associated medical data pseudonym.

[0111] The medical data handling component 20 may be configured to store the medical data pseudonym, and its association with the medical data and the additional data.

[0112] Thus, an end result of the second phase of the method may be the addition of the medical data and / or additional data of the patient to the medical data storage unit 202, with a medical data pseudonym associated with it, separate from identification data of the patient, that may be stored in the identification data storage unit 102, associated with the identification data identifier, and separate from the contact data, that may be stored in the user data storage unit 302, associated with the contact pseudonym. The separation between the medical data, the identification data, and the contact data may allow greater privacy and security as the medical data may not be linked to the patient.

[0113] The system 1, particularly the patient data stored in the system 1, may be of particular relevance for sending information efficiently to patients whose data is stored in the system 1. For example, a clinical study may be planned to test a drug for treatment of a genetic disease. In order to test the drug, patients with the genetic disease may be sought. By allowing for creation of a database of patients with genetic diseases, the system 1 may allow recruitment of participants for the clinical study easily.

[0114] Figure 4 depicts one embodiment of a method for sending information to one or more patients with a defined genetic disease using the system 1, as will now be described. The system 1 may be particularly advantageous for sending such information. A first step, R.1, of the method may comprise receiving a request for sending information to one or more patients. The request may comprise search criteria for determining the one or more patients to which the information may be sent. For example, the search criteria may comprise data related, at least in part, to the defined genetic disease. The request may further comprise the information, or at least a part thereof, to be sent to the one or more patients. The request may additionally comprise a sex or age, or specific symptoms which may not be present in all patients with a certain disease, for example, if the treatment to be investigated targets a specific age group, sex, or only a particular symptom that may be part of the disease.

[0115] The request may be sent to the system 1, particularly to the user data handling component 30 thereof, by means of an external device 4. The external device 4 may be, at least in part, similar to the external device 2, and may allow a user to input data into the system 1.

[0116] A next step, R2, may comprise reviewing the request. Review of the request may be carried out automatically, at least in part, by the system 1, particularly the user data handling component 30 thereof. Alternatively, the review may be carried out manually, by one or more parties. Access to the request may be restricted, and the one or more parties may be required to have allowance to access the request. Reviewing the request may comprise, for example, verifying an identity of the requester, determining if the requester is allowed to make the request, verifying the contents of the request for scientific accuracy, for example, or satisfaction of other suitable conditions or respecting ethical standards / requirements. The system 1 may, in particular, be configured to allow receiving one or more conditions that may have to be satisfied by the request. Alternatively, or additionally, the review of the request may be carried out by means of an artificial intelligence-based model, that may have been trained on data comprising allowable and dis-allowable requests.

[0117] A result of the review may be success or failure. A notification about the result of the review may be sent, as a next step, R3. If the result of the review is success, a next step, R4, may comprise filtering the medical data stored in the medical data storage unit 202 based, at least in part, on the request. In particular, for example, the request may be sent to the medical data handling component 20, particularly to the medical data processing unit 204 thereof, that may be configured to process the request and to filter the medical data based, at least in part, on the request, particularly the search criteria therein.

[0118] In a further step, R5, the medical data handling component 20 may send, to the pseudonym data handling component 40, medical data pseudonyms corresponding to medical data that satisfy the search criteria. For example, the medical data may correspond to the medical data of patients with the defined genetic disease. Note that the medical data handling component 20 only returns medical data pseudonyms and not the medical data itself, thereby enhancing the privacy of the medical data.

[0119] The pseudonym data handling component 40, in response to receiving the medical data pseudonyms, may retrieve the contact data pseudonyms associated with the received medical data pseudonyms based, at least in part, on the association between the medical data pseudonym and the master pseudonym and between the master pseudonym and the contact data pseudonym. This may comprise a next step, R6, of the method.

[0120] The next step, R7, of the method may comprise the pseudonym data handling component 40 sending the retrieved contact data pseudonyms to the user data handling component 30.

[0121] The user data handling component 30 may, in a next step R8, associate any of the information to be sent to the one or more patients, or the contact data of the contact person for the request, with the user account associated with each of the contact data pseudonyms received. Thus, the one or more patients may be able to access the information and / or the contact data by accessing their user account.

[0122] The user data handling component 30 may, in a next step R9', send the contact data pseudonyms to the identification data handling component 10.

[0123] The identification data handling component 10 may be configured, in response to receiving the contact data pseudonyms from the user data handling component 30, to retrieve, in a next step, R10', the contact data of patients associated with the contact data pseudonyms and to send the contact data to the user data handling component 30. For example, the identification data handling component 10 may send the received contact data pseudonym to the pseudonym data handling component 40, and receive, in response, from the pseudonym data handling component 40, the identification data identifiers associated with the contact data pseudonyms.

[0124] In a further step, Rll', the user data handling component 30 may be configured to contact the patients based, at least in part, on the identification data stored in the identification data storage unit 102 associated with the chosen contact data pseudonyms, notifying them of new information in their user accounts and prompting them to access their user accounts.

[0125] Alternatively, in some embodiments, as described above, the user may be required to provide contact information, that may be less sensitive such as an email address, for creation of the user account. Such contact information may be stored in the user data handling component 30, particularly the user data storage component 302 thereof. In such embodiments, the user data handling component 30 may, in a step R9, notify the patients based on the contact information associated with their user accounts, without sending the contact data pseudonyms to the identification data handling component 10. This may be of advantage in further enhancing an efficiency of the system 1.

[0126] Thus, information may be sent to one or more patients with the defined genetic disease with enhanced anonymity, and better data privacy and security. Overall, embodiments of the present technology thus allow management and usage of medical data of patients with defined genetic diseases with greater efficiency, privacy, and security.

[0127] Whenever a relative term, such as "about", "substantially" or "approximately" is used in this specification, such a term should also be construed to also include the exact term. That is, e.g., "substantially straight" should be construed to also include "(exactly) straight".

[0128] Whenever steps were recited in the above or also in the appended claims, it should be noted that the order in which the steps are recited in this text may be accidental. That is, unless otherwise specified or unless clear to the skilled person, the order in which steps are recited may be accidental. That is, when the present document states, e.g., that a method comprises steps (A) and (B), this does not necessarily mean that step (A) precedes step (B), but it is also possible that step (A) is performed (at least partly) simultaneously with step (B) or that step (B) precedes step (A). Furthermore, when a step (X) is said to precede another step (Z), this does not imply that there is no step between steps (X) and (Z). That is, step (X) preceding step (Z) encompasses the situation that step (X) is performed directly before step (Z), but also the situation that (X) is performed before one or more steps (Yl), ..., followed by step (Z). Corresponding considerations apply when terms like "after" or "before" are used.

[0129] While in the above, preferred embodiments have been described with reference to the accompanying drawings, the skilled person will understand that these embodiments were provided for illustrative purpose only and should by no means be construed to limit the scope of the present invention, which is defined by the claims.

Claims

Claims1. A method for adding data to a database, wherein the method comprises: retrieving a transport pseudonym based, at least in part, on a medical data code assigned to a user, and retrieving a medical data pseudonym based, at least in part, on the transport pseudonym.

2. The method according to the preceding claim, wherein the method further comprises retrieving medical data based, at least in part, on the medical data code.

3. The method according to the preceding claim, wherein the retrieved medical data comprises encrypted medical data.

4. The method according to any of the 2 preceding claims, wherein the method comprises storing the retrieved medical data and storing an association between the medical data pseudonym and the retrieved medical data.

5. The method according to any of the preceding claims, wherein the method comprises generating the medical data code.

6. The method according to the preceding claim, wherein generating the medical data code comprises obtaining the transport pseudonym and generating the medical data code based, at least in part, on the transport pseudonym.

7. The method according to any of the preceding claims and with the features of claim 5, wherein generating the medical data code comprises obtaining unencrypted medical data.

8. The method according to the preceding claim, wherein the method comprises determining if the unencrypted medical data comprises a defined format.

9. The method according to the preceding claim, wherein the method comprises, in response to determining that the unencrypted medical data does not comprise the defined format, converting the unencrypted medical data to the defined format.

10. The method according to any of the 2 preceding claims, wherein generating the medical data code comprises, in response to the unencrypted medical data comprising the defined format, compressing the unencrypted medical data comprising the defined format.

11. The method according to the preceding claim, wherein generating the medical data code comprises obtaining a public key and encrypting the compressed unencrypted medical data using the public key.

12. The method according to the preceding claim, wherein the method comprises generating the medical data code based, at least in part, on the encrypted medical data.

13. The method according to any of the preceding claims and with the features of claim 5, wherein the method comprises providing the generated medical data code to the user.

14. The method according to any of the preceding claims, wherein the medical data code comprises a QR-code.

15. The method according to any of the preceding claims, wherein the user comprises a patient with a genetically-confirmed medical disease.

16. A computer program product comprising instructions, when executed on a device capable of executing the computer program product, to generate a medical data code, generating the medical data code comprising at least one of: obtaining a transport pseudonym, retrieving unencrypted medical data, converting the retrieved unencrypted medical data to a defined format, compressing the unencrypted medical data in the defined format, obtaining a public key and encrypting the unencrypted, compressed medical data in the defined format based, at least in part, on the public key.

17. The method according to any of the claims 1 to 15, wherein the method further comprises providing, to the user, the computer program product according to claim 16.

18. A system for adding data to a database, wherein the system comprises: a user data handling component configured to retrieve a transport pseudonym based, at least in part, on a medical data code assigned to a user, the user data handling component further configured to retrieve a medical data pseudonym based, at least in part, on the transport pseudonym.

19. The system according to the preceding claim, wherein the system is further configured : to retrieve medical data based, at least in part, on the medical data code, to store the retrieved medical data and to store an association between the retrieved medical data and the medical data pseudonym, and to receive and to store contact data for the user.

20. A use of a system according to the preceding claim, the system further configured to accept search criteria, the use comprising identifying users with a defined genetic diagnosis based, at least in part, on the search criteria, and sending information to the identified users.

Images