WO2020212604A1 - Method and system for selectively transmitting data - Google Patents

Method and system for selectively transmitting data Download PDF

Info

Publication number
WO2020212604A1
WO2020212604A1 PCT/EP2020/060916 EP2020060916W WO2020212604A1 WO 2020212604 A1 WO2020212604 A1 WO 2020212604A1 EP 2020060916 W EP2020060916 W EP 2020060916W WO 2020212604 A1 WO2020212604 A1 WO 2020212604A1
Authority
WO
WIPO (PCT)
Prior art keywords
data
user
server
return message
message
Prior art date
Application number
PCT/EP2020/060916
Other languages
French (fr)
Inventor
Baher AL HAKIM
Bassel ALKHATIB
Makram SALEH
Mouhamad KAWAS
Rafael VARTIAN
Firas ATAYA
Original Assignee
Medicus Ai Gmbh
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Medicus Ai Gmbh filed Critical Medicus Ai Gmbh
Publication of WO2020212604A1 publication Critical patent/WO2020212604A1/en

Links

Classifications

    • G—PHYSICS
    • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H40/00—ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices
    • G16H40/20—ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices for the management or administration of healthcare resources or facilities, e.g. managing hospital staff or surgery rooms
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
    • G06F21/6218—Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database
    • G06F21/6245—Protecting personal data, e.g. for financial or medical purposes
    • G06F21/6254—Protecting personal data, e.g. for financial or medical purposes by anonymising data, e.g. decorrelating personal data from the owner's identification
    • G—PHYSICS
    • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H40/00—ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices
    • G16H40/60—ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices for the operation of medical equipment or devices
    • G16H40/67—ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices for the operation of medical equipment or devices for remote operation
    • G—PHYSICS
    • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H80/00—ICT specially adapted for facilitating communication between medical practitioners or patients, e.g. for collaborative diagnosis, therapy or health monitoring
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L51/00—User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail
    • H04L51/07—User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail characterised by the inclusion of specific contents
    • H04L51/10—Multimedia information
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L51/00—User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail
    • H04L51/42—Mailbox-related aspects, e.g. synchronisation of mailboxes
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0407—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the identity of one or more communicating identities is hidden
    • H04L63/0421—Anonymous communication, i.e. the party's identifiers are hidden from the other party or parties, e.g. using an anonymizer
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/606—Protecting data by securing the transmission between two devices or processes
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks

Definitions

  • the invention relates to data analysis for privacy-sensitive or otherwise confidential data on distributed systems.
  • selective information delivery to users is usually performed by applying the selection criteria centrally in order to extract the contact data, e.g. postal or electronical addresses, of the people to contact or to deliver information to.
  • the information is then transmitted to the user, using the extracted contact data.
  • the procedure is equivalent: Even if information is masked or removed at the information source in order to protect the user's privacy or to protect data that may be confidential in any way, this must be performed at the data-requesting party, the data source or in between.
  • the user has no inherent control of the use of his data, but he has to trust entities holding his data (e.g. a hospital) to ensure the protection of his privacy when they provide his contact data or when they deliver other information such as health data to third parties. Furthermore, even if privacy-sensitive or confidential data is masked or removed, it is at least once available together with the finally requested information (before being removed). Especially for the purpose of medical research, the conflict of interest between the preservation of privacy of the patients and the use of patient data, especially in cases where information from different sources should be linked, is a disputed issue.
  • a supplementary problem in this context is the storage of medical data.
  • Medical data is usually either saved in a distributed way - so basically, every health care provider holds their own data concerning a patient. In this case, to retrieve information that is not comprehensively stored at one single health care provider, it will be necessary to match this data. If all patient data is stored centrally instead, the protection of the patient's privacy is quite difficult as the data is available at least to the processing unit belonging to the central storage system.
  • a double blinded privacy-safe distributed data mining protocol is disclosed, among an aggregator, a data consumer entity having privacy-sensitive information, and data source entities having privacy-sensitive information.
  • the aggregator does not have access to the privacy-sensitive information at either the data consumer entity or the data source entities.
  • the aggregator formulates a query without using privacy-sensitive information, and sends the query to the data consumer entity.
  • the data consumer entity generates a list of specific instances that meet the conditions of the query and sends the list, encrypted, to the data source entities either directly or through the aggregator.
  • the data source entities match the list against transactional data, de-identify the matched results, and send them to the aggregator.
  • the aggregator combines results from data source entities and sends the combined result to the data consumer entity. This allows for privacy-safe data mining where both the data consumer entity and data source entities have privacy-sensitive information not available for the aggregator to see or use.
  • US20020116227A1 discloses a method for searching for medical information executed by one or more computers comprising the steps of formulating a request for medical information concerning an individual or group of individuals, transmitting a record request to a record facilitator, the record facilitator determining which patient record sources to investigate, a record query being sent from the facilitator to the patient record sources which are appropriate, receiving a patient record report back from the patient record sources, normalizing and augmenting the patient record report before forwarding it back to the requester, and de-identifying the patient record to remove any identifying information.
  • US7823207B2 discloses a privacy preserving data-mining protocol, between a secure “aggregator” and “sources” having respective access to privacy-sensitive micro-data, the protocol including : the “aggregator” accepting a user query and transmitting a parameter list for that query to the "sources” (often including privacy-problematic identifiable specifics to be analyzed); the “sources” then forming files of privacy-sensitive data-items according to the parameter list and privacy filtering out details particular to less than a predetermined quantity of micro-data-specific data-items; and the “aggregator” merging the privacy-filtered files into a data-warehouse to formulate a privacy-safe response to the user— even though the user may have included privacy-problematic identifiable specifics.
  • US20090326981A1 provides a system and/or a method that facilitates collecting a portion of health data from a collection of users.
  • An interface component can receive health data communicated from a collection of users, wherein each user within the collection is associated with a respective portion of health data.
  • a verification component can authenticate at least one of a transmission source of the portion of health data, an ownership between a portion of health data and a user, an integrity level associated with the portion of health data, or a user submitting the portion of health data.
  • a collection component can aggregate authenticated health data into a semantic data store in which the health data is indicative of a raw and unmolested source of health information from the collection of users. The collection component can further organize the health data to facilitate identification of a medical related trend.
  • US20060069957A1 discloses a communication system processing element comprises a processor coupled to a memory and implements at least a portion of a distributed expert system.
  • the distributed expert system is arranged in at least two hierarchical levels, including an upper level comprising a central controller, and a lower level comprising a plurality of local agents each associated with one or more communication devices of the system.
  • US6397224B1 discloses a system for anonymously linking a plurality of data records, each data record comprising a plurality of elements for identifying an associated individual, includes a first identity reference encoding module configured to encode a first encoded identity reference from a first subset of the identifying elements of a data record; a second identity reference encoding module configured to encode a second encoded identity reference from a second subset of the identifying elements of the data record; and an anonymization code assignment module configured to assign to each of the first and second encoded identity references an identical anonymization code for anonymously representing the individual associated with the data record.
  • US7543149B2 discloses a method for securing patient identity comprising accessing an electronic medical records database including patient data for a plurality of patients. Each patient in the electronic medical records database is assigned a unique patient identifier. Patient data for a first patient, including a first patient identifier, is retrieved from the electronic medical records database. The first patient is de-identified from the patient data. De-identifying includes the creation of a first encoded patient identifier responsive to the first patient identifier. The de-identifying results in de-identified first patient data and includes the replacement of the first patient identifier with the first encoded patient identifier. The de-identified first patient data is transmitted to a data warehouse system. The method further comprises identifying a second patient in response to receiving report data that includes a second encoded patient identifier from the data warehouse system. The identifying includes the creation of a second patient identifier responsive to the second encoded patient identifier.
  • the prior art discloses either to store multiple patient records or parts thereof at single health care providers or at a central entity.
  • the data needs to be matched by patient, especially if a comprehensive medical record (or excerpts or derived information that is not saved at one health care provider) is needed.
  • a comprehensive medical record or excerpts or derived information that is not saved at one health care provider
  • the data is available to the central entity anyways.
  • the patient has no control of his data and must trust the operator of the storage units - may they be central, or may they be at each health care provider. The user has no means to directly control his data at these storage entities.
  • the patient or user does not control the data storage entity. Furthermore, his data is available to the storage entity and the storage entity will technically govern the access of third parties to the patient's data.
  • the storage entity/ies can be all entities that hold patient data - health care providers, central registers, employers as far as they need to keep a medical record, etc, also including IT-providers operating transmission, processing or storing services, hardware or systems for the aforementioned entities.
  • Data mining analysis and research
  • a method for selectively transmitting data comprises sending an inquiry message comprising at least request criteria from at least one broadcasting party to a plurality of user devices each comprising a comparator node.
  • the method also comprises comparing the request criteria to user data stored on each user device by the comparator node.
  • the method also comprises, on each user device where the comparator node achieved a successful comparison of the request criteria to user data, the comparator node generating at least one return message based on at least parts of user data.
  • the method further comprises, on each user device where the comparator node achieved a successful comparison of the request criteria to user data, sending the return message from the user device to at least one of the server and the broadcasting party.
  • the inquiry message may comprise a plurality of data and/or instructions that can be interpretable by a machine such as a processor.
  • the inquiry message may comprise a request for particular information (that is, user data) from a third party.
  • the third party may be interested in studying correlations between certain patient parameters or researching how many users exhibit particular parameters (as simple examples, the third party may be interested in average blood pressure of female users aged 25-35, or in comparing incidence of cardiovascular disease and white blood cell count in Caucasian male smokers above age 50). That is, the third party may request only a limited and specific set of parameters or data from user devices via the inquiry message.
  • the request criteria may comprise certain parameters identifying an intended recipient and/or further specifying what type of data should be returned. For example, an age range, sex, medical condition or the like can be examples of request criteria.
  • a third party may be interested in knowing how many users (associated with user devices and corresponding user data) suffer from below average kidney function.
  • the request criteria may then comprise instructions to compare kidney function values present in the user data with a certain threshold (such as a value associated with decreased kidney function), and return either simply a confirmation of the corresponding value forming part of user data below the threshold and/or the value itself.
  • the comparator node may comprise a program or part of a program that can be configured to use computational resources of the user device to perform operations.
  • User data may comprise any data related to the user of the user device. Multiple users may also be associated with one user device, where each individual user would then have a unique "user profile" or the like.
  • user data comprises, at least partially, medical data associated with the user. This can comprise results of various medical tests or procedures, diagnoses, measurements from fitness tracking or medical devices and the like.
  • a successful comparison of the request criteria to user data may refer to the comparator node verifying whether the request criteria are satisfied by user data associated with the user of the user device.
  • this comparison may refer to matching the required parameters (such as e.g. age, sex, medical information) of the request criteria to the user data stored on the user device.
  • the return message based on at least parts of user data may comprise parts of user data itself (such as specific parameters requested by the request criteria), and/or simply a confirmation that upon comparison (that is, matching) between request criteria and user data, a successful comparison was achieved (for example, if the request criteria specified that only values of a certain parameter below a threshold of 10 are requested, and user data has a value of 8 for this parameter, a confirmation of a satisfied request criteria can be returned as part of the return message).
  • the return message can be formatted in a way that indicates to the server or to the broadcasting parties that said message is configured to transport data from a user device to a server and/or to a broadcasting party.
  • the return message can comprise returned user data.
  • the return message can comprise user independent data, such as information about the reason for its emission, such as a reference to the inquiry message that triggered the emission/generation of said return message.
  • the return message can be encrypted.
  • the returned data can be at least partially medical data.
  • At least some of the user devices may each comprise a data storage, at least one processing component configured to execute a program in a suitable form and format and a communication component at least configured to communicate with a remote server.
  • the processing component can for example comprise processors, hardware accelerators and/or microcontrollers.
  • the data storage can comprise memory components, such as, main memory (e.g. RAM), cache memory (e.g. SRAM) and/or secondary memory (e.g. HDD, SDD).
  • main memory e.g. RAM
  • cache memory e.g. SRAM
  • secondary memory e.g. HDD, SDD
  • the user devices can comprise busses configured to facilitate data exchange between their components, such as, the communication between the data storage and the processing component.
  • the user device can comprise network interface controllers that can be configured to connect the data processing device to a network, such as, to the Internet
  • the data storage may be at least partially encrypted.
  • this can allow for secure storage of potentially sensitive data, such as medical data.
  • the user device may comprise a user terminal.
  • the user device may be a portable device, such as a laptop, a tablet computer, a smartphone, a wearable device, or an adapted medical device.
  • the present method may allow a third party to gain access to sensitive user data without compromising the privacy and security of the user.
  • a third party may be preferable that it is stored on the user device (that is, under the control of the user), and it may not be optimal to simply send it somewhere for further research or analysis. Therefore, it is particularly useful to extract only the requested parts of the data (or simply a confirmation that the user data corresponds to the parameters set out by the request criteria), particularly without compromising sensitive user data or disclosing more than requested to the third party.
  • the server can comprise a single server, a server system composed of multiple servers, and/or a program emulating the functionality of a server, running on a cloud computing platform or any system configured to implement the functionality of a server.
  • the server can comprise means of data processing, such as, processor units, hardware accelerators and/or microcontrollers.
  • the server can comprise memory components, such as, main memory (e.g. RAM), cache memory (e.g. SRAM) and/or secondary memory (e.g. HDD, SDD).
  • the server can comprise busses configured to facilitate data exchange between components of the server, such as, the communication between the memory components and the processing components of the server.
  • the server can comprise network interface cards that can be configured to connect the server to a network, such as, to the Internet.
  • the server can comprise user interfaces, such as: output user interface, such as screens or monitors configured to display visual data and/or speakers configured to communicate audio data, input user interface, such as a camera, a microphone configured to capture audio data, a keyboard, a trackpad, mouse, touchscreen and/or joystick.
  • output user interface such as screens or monitors configured to display visual data and/or speakers configured to communicate audio data
  • input user interface such as a camera, a microphone configured to capture audio data
  • keyboard a trackpad, mouse, touchscreen and/or joystick.
  • the server can also be configured to be controlled from another computer system, such as via a remote-desktop connection, via a secure shell connection (SSH) or the like.
  • SSH secure shell connection
  • the server can be a processing unit configured to carry out instructions of a program.
  • the server can be a system-on-chip comprising processing units, memory components and busses.
  • the server can be a processing unit or a system-on-chip that can be interfaced with a personal computer, a laptop, a pocket computer, a smartphone, a tablet computer and/or user interfaces (such as the upper-mentioned user interfaces).
  • sending the inquiry message can comprise receiving an inquiry message from at least one broadcasting party by a server and the server transmitting the inquiry message to the plurality of user devices.
  • this may prevent third parties having direct access to user devices.
  • the server can then serve as an intermediary that can already filter some inquiry messages or otherwise process them before forwarding them on to the user devices.
  • the method can further comprise discarding the inquiry message on each device where the comparator node did not achieve a successful comparison of the request criteria to user data. That is, if the user data does not match the request criteria, the inquiry message may be simply discarded, and there may be no generation of the return message (additionally or alternatively, there may be a return message generated to confirm that the comparison between the request criteria and user data was not successful).
  • sending the inquiry message can further comprise transmitting the inquiry message by a connection configured to transfer data from the broadcasting party to the server.
  • sending the inquiry message can further comprise connecting the user devices and the server at least at some points in a period of time by a connection configured to transfer data from the server to the user devices.
  • the sending of the return message can be performed at any point in time after the generating at least one return message. In some such embodiments, the point of time when the sending is performed can depend on a further condition.
  • user data can comprise at least identifying data and technical data.
  • the generating of at least one of said return message can comprise inserting at least a part of the technical data and at least a part of the identifying data to the at least one return message by the comparator node.
  • inserting the technical data and the identifying data can be performed at most to the extent that was requested by the inquiry message that triggered the generation of said return message.
  • the generating of at least one of the return message can comprise furthermore processing the identifying data before inserting it to the return message.
  • the processing of the identifying data can be performed by the comparator node.
  • the method can further comprise the comparator node using a set of rules to invoke certain actions if certain portions of the user data or combinations thereof are requested by the inquiry message.
  • the processing of said inquiry message can comprise anonymising at least parts of the identifying data before inserting it to the return message.
  • the anonymising of at least parts of the identifying data can comprise limiting the precision of at least a portion of said identifying data. For example, this can be done by replacing the date of birth by year of birth, by replacing the address by the ZIP-code, parts thereof, the region in which the address is located or the like.
  • the anonymising of at least parts of the identifying data can comprise replacing at least a portion of the identifying data by pseudonyms or codes. Those pseudonyms or codes can be generated by the comparator node. Additionally or alternatively, they can also be generated by the server if the return message is first sent to the server before being forwarded to the broadcasting parties.
  • the anonymising of at least parts of the identifying data can comprise replacing at least a portion of said identifying data by variables that are deduced from the identifying data, but that do not allow exact determination of the identifying data. For example, the date of birth can be replaced by age.
  • the anonymising of at least parts of the identifying data can comprise treating at least a part of the identifying data with a differential privacy algorithm.
  • Anonymising or otherwise masking user data before it leaves the user device as part of the return message can be very useful to ensure user privacy, as well as security of possibly sensitive data. It is particularly advantageous to perform this anonymising before sharing user data (that is, preferably parts of it) with third parties. It allows such third parties to get access to accurate and useful data for possible further research into treatments, marketing purposes, general research or the like, while not compromising on the users' right to privacy and safe data storage.
  • the technical user data that can be sent to at least one of a server and a broadcasting party as part of the return message can be treated with a differential privacy algorithm before being sent to at least one of a server and a broadcasting party respectively.
  • the processing of the inquiry message can comprise sending at least a plurality of the return messages.
  • the inquiry message may comprise a plurality of independent request criteria. An individual return message can be generated for each such independent request criteria.
  • the return message can comprise at least an indicator for at least one of the following : user data matches the request criteria for the first time and an event concerning user data occurs (for instance, adding a certain value or registering a certain event).
  • the sending can furthermore require that at least one of the user data and an event concerning user data respectively also satisfy a time constraint. For example, this can be the user data matching the matching criteria (4) within a given period of time or that the event occurs within a given period of time.
  • the method can further comprise requesting at least implicit general consent, more preferably explicitly indicated consent, more preferably explicitly indicated consent to each single request of the user data, of the user before at least one of generating or triggering sending at least one return message corresponding to the inquiry message is performed by the comparator node.
  • one or a plurality of return messages that are generated on the user device can be sent to a server or a broadcasting party at a point in time when the user device is at least indirectly connected to the server and/or the broadcasting party respectively.
  • the one or a plurality of return messages that are generated on the user device can be sent to the server or the broadcasting party in at least one of a compressed form, batches and an agglomerated form. This can be advantageous to ensure efficient data management and optimisation of data transfer.
  • the sending to the server or the broadcasting party of the one or a plurality of return message that are generated on the user device can be triggered once during a defined period of time (e.g.
  • the method can further comprise, after the receiving of the return message, forwarding at least parts of the return message that the server received to at least some of the broadcasting parties, preferably forwarding each return message to the broadcasting party that sent the inquiry message that caused the generation of the respective return message.
  • generating the at least one return message can comprise furthermore adding a specification of at least one of the broadcasting party and the inquiry message that caused the generation of the return message.
  • the method can further comprise the server using at least the specification of at least one of the broadcasting party and the inquiry message to forward at least the content of the return message.
  • the method can further comprise the server collecting the return messages corresponding to one inquiry message and making available the return messages or their content, preferably in an agglomerated form, to the broadcasting party that issued said inquiry message.
  • the sending the return messages or their content, preferably in an agglomerated form, can be triggered when a certain condition is met.
  • the condition can comprise, for example, elapsed time, a pre-defined number of received answers, approval by the broadcasting party that sent the inquiry message.
  • the method can further comprise taking measures to mask, remove or conceal elements suitable to identify the user or the user device (such as e.g. IP address) prior to sending the return messages or parts thereof to at least one of the at least one broadcasting parties.
  • the method can further comprise encrypting at least parts of the return message with at least one encryption key by the user device before or while sending it.
  • the method can further comprise decrypting the return message at the respective broadcasting parties.
  • the method can further comprise encrypting at least parts of each the return message at the user device before or while sending it to the server.
  • the method can then further comprise decrypting at least parts of each return message at the server after receiving said return message.
  • the method can then also comprise encrypting at least parts of said return message, of a set of return messages or of the agglomerated content of multiple return messages at the server before sending said return message to the receiving broadcasting party.
  • the method can then further comprise decrypting the data sent by the server at least partially at the receiving broadcasting party.
  • the method can further comprise encrypting at least parts of the return message with a key corresponding to the respective broadcasting party that issued the inquiry message that caused the generation of the return message.
  • the encryption can be then set up in a way so that the server cannot access said parts of the return message (e.g. by sharing a secret key between the broadcasting party and the user device). This can be advantageous, for example, when the third party has certain permissions to access sensitive (preferably medical) user data, that the server does not have permission to access.
  • the method can further comprise encrypting at least parts of the return message at the user device using an asymmetric encryption algorithm before or while sending each return message.
  • This can comprise furthermore using at least a public key for the encryption of each return message, wherein said public key corresponds to the respective broadcasting party that is the intended receiver of said return message.
  • the method can further comprise sending and receiving the inquiry message with one or multiple parts of the server that are at least partially different from parts of the server used for sending and receiving at least parts of the return message at the server.
  • the method can further comprise sending inquiry messages by the broadcasting parties from systems that are for at least one broadcasting party at least partially different from systems that are used for receiving the return messages.
  • the last two embodiments can be particularly advantageous if virtual separation between the inquiry message and the return message (possibly comprising sensitive data) is preferred.
  • a system for selectively transmitting data comprises at least one server.
  • the server is configured to receive an inquiry message from at least one broadcasting party, the inquiry message comprising at least request criteria.
  • the server is also configured to transmit the inquiry message to a plurality of user devices.
  • the system further comprises at least one user device configured to store user data and comprising at least a comparator node and a communication component.
  • the comparator node is configured to at least compare the request criteria to the user data stored on each user device and generate at least one return message comprising at least parts of user data on each user device where a successful comparison of the request criteria to user data was achieved.
  • the communication component is configured to send the return message to at least one of the server and the broadcasting party.
  • the user device, user data, inquiry message, request criteria, return message, and comparator node can be as described above with respect to the method.
  • the present system may be particularly configured to execute or perform the method for selectively transmitting data as described in the above embodiments.
  • the user device can comprise a portable device.
  • the user device can comprise a laptop, a tablet computer, a smartphone, a wearable device, and/or an adapted medical device.
  • user data can comprise at least partially technical medical data.
  • the user device can be further configured to at least partially encode the technical medical data by replacing at least parts of the data by machine-interpretable expressions.
  • the user device can comprise a user interface configured to enable a user to interact with the user device and wherein the user interface can comprise at least one interaction component. That is, the user interface may comprise an interface that the user may use to access the broadcasting message or other associated data, including user data.
  • the interaction component may comprise a display, speakers, or the like.
  • the user interface may be linked to the device by at least one of a direct connection, such as by electro-magnetic waves, integrated or removable wiring, and an indirect connection, such as by a server, such as an interface displaying e-mails sent by the user device or an interface playing voice messages sent by the user device.
  • the user interface can be configured to perform necessary interface steps for a verification of a user's identity. For example, those can comprise reading a password or a PIN entered by a user, scanning a user's fingerprint, taking at least photos of a user that are configured for facial recognition, accepting a hardware authentication element (e.g. hardware key) or any combination thereof.
  • a hardware authentication element e.g. hardware key
  • the user interface can be further configured to perform necessary interface steps for a verification of a user's identity. For example, those can comprise reading a password or a PIN entered by a user, scanning a user's fingerprint, taking at least photos of a user that are configured for facial recognition, accepting a hardware authentication element (e.g. hardware key) or any combination thereof.
  • a hardware authentication element e.g. hardware key
  • the server can be further configured to perform at least one verification on the inquiry message before transmitting it to user devices. For example, a check for malware or for compliance with pre-defined criteria or rules can be performed.
  • the comparator node can be configured to apply the request criteria of received inquiry messages to the user data saved on the device, and wherein said comparator node can be software- based.
  • the comparator node can generally comprise a program installed on a user device and configured to interact with it.
  • the comparator node can be configured to use the user device's hardware (such as a processor, sensors or communication component) to perform its tasks, subroutines or the like.
  • the server can be furthermore configured to send data to the broadcasting parties.
  • the server can further comprise, at least at some points in time, a connection configured for data transfer from at least one of the at least one user devices to the server, and, at least at some points in time, a connection configured for data transfer from the server to at least one of the at least one broadcasting parties.
  • the user device can be configured to store user data in a machine-interpretable form.
  • the user data can comprise medical user data.
  • the user device can be configured to encode the user data with at least a homogenous naming for fields.
  • the user device can be configured to encode values with a same dimension unit for each field.
  • the user device can be further configured to at least partially generate medical data.
  • This data can comprise at least one medical image.
  • the data can also comprise at least one result of a laboratory analysis of material originating from or expelled by the human body.
  • the data can further comprise data from a sensing device that senses biometrical or medical data of a user.
  • the user device may even be configured to generate some of the original data such as images via the user device's sensors such as a camera (further sensors such as biometric sensors may also be used).
  • a method for selectively transmitting data comprising Sending an inquiry message (3) comprising at least request criteria (4) from at least one broadcasting party (40) to a plurality of user devices (10) each comprising a comparator node (23);
  • the comparator node (23) generating at least one return message (6) based on at least parts of user data (20);
  • sending the inquiry message (3) comprises
  • the server transmitting the inquiry message (3) to the plurality of user devices
  • sending the inquiry message (3) further comprises transmitting the inquiry message (3) by a connection (102) configured to transfer data from the broadcasting party (40) to the server (1).
  • sending the inquiry message (3) further comprises connecting the user devices (10) and the server (1) at least at some points in a period of time by a connection (103) configured to transfer data from the server to the user devices (10).
  • M7 The method according to the preceding method embodiment wherein the point of time when the sending is performed depends on a further condition.
  • M8. The method according to any of the preceding method embodiments wherein user data (20) comprises at least identifying data (24) and technical data (25).
  • user data (20) matches the request criteria (4) for the first time
  • generating the at least one return message(s) (6) comprises furthermore adding a specification of at least one of the broadcasting party (40) and the inquiry message (3) that caused the generation of the return message(s) (6).
  • the method according to the preceding embodiment further comprising the server using at least the specification of at least one of the broadcasting party (40) and the inquiry message (3) to forward at least the content of the return message(s) (6).
  • the encryption is set up in a way so that the server (1) cannot access said parts of the return message(s) (6).
  • encrypting at least parts of the return message (6) using an asymmetric encryption algorithm comprises furthermore using at least a public key for the encryption of each return message (6), wherein said public key corresponds to the respective broadcasting party (40) that is the intended receiver of said return message (6).
  • a system for selectively transmitting data comprising
  • At least one server (1) configured to at least
  • At least one user device configured to store user data (20) and comprising at least a comparator node (23) and a communication component,
  • the comparator node (23) is configured to at least compare the request criteria (4) to the user data (20) stored on each user device (10) and generate at least one return message (6) comprising at least parts of user data (20) on each user device (10) where a successful comparison of the request criteria (4) (4) to user data (20) was achieved; and wherein the communication component is configured to send the return message (6) to at least one of the server (1) and the broadcasting party (40).
  • user data (20) comprises at least partially technical medical data (25).
  • the user device (10) further comprises a user interface (11) configured to enable a user to interact with the user device (10) and wherein the user interface (11) comprises at least one interaction component.
  • the user interface (11) is further configured to perform necessary interface steps for a verification of a user's identity.
  • the server (1) is further configured to perform at least one verification on the inquiry message (3) before transmitting it to user devices (10).
  • comparator node (23) is configured to apply the request criteria (4) of received inquiry messages (3) to the user data (20) saved on the device (10), and wherein said comparator node (23) is software-based.
  • server (1) is furthermore configured to send data to the broadcasting parties (40).
  • the server (1) further comprises, at least at some points in time, a connection (104) configured for data transfer from at least one of the at least one user devices (10) to the server (1), and, at least at some points in time, a connection (101) configured for data transfer from the server to at least one of the at least one broadcasting parties (40).
  • At least one medical image At least one medical image
  • At least one result of a laboratory analysis of material originating from or expelled by the human body At least one result of a laboratory analysis of material originating from or expelled by the human body.
  • FIG. 1 schematically depicts an embodiment of a method to selectively transmitting data.
  • Figure 1 shows a scheme of a method to selectively draw medical user data for analytic purpose based on selection criteria that refer to private medical data without disclosing the users' identity (directly or indirectly) to the parties requesting the medical user data.
  • a central server 1 is at least at some points in time connected to at least one device 10 (here: two devices 10) and to at least broadcasting party 40, whereas these points in time do not need to be the same.
  • the broadcasting party 40 sends a data request in the form of an inquiry message 3 to the server 1 using a connection configured to transfer data from the requesting party to the server 102.
  • the message 3 comprises request criteria 4. If a user matches the request criteria 4, a return message 6 is generated.
  • the inquiry message 3 comprises a request for certain medical user data.
  • Device 10 comprises user data 20, wherein the user data 20 comprises identifying data 24 that may directly identify a user, such as the user's name, date of birth, address and the like.
  • the user data 20 comprises furthermore medical technical user data 25. Parts of said medical user data 25 do not per se disclose the user's identity, whereas other parts or combinations thereof may be suitable to identify the user, for example data that can be matched with an insurance company's record of invoiced medical services for their insureds.
  • Device 10 comprises furthermore a comparator node 23 that can apply request criteria 4 to the user data 20, wherein criteria concerning the identifying user data may not make direct comparisons, such as matching for the user's name, the user's date of birth or his address(es). Nevertheless, the criteria may specify an age (e.g.
  • Comparator node 23 may comprise measures to check the compliance of the request criteria 4 to the aforementioned or other limitations.
  • a device 10 can access at least one user interface 11.
  • a server 1 may optionally apply tests to the message, e.g. check the compliance of the request criteria described above in the context of the comparator node 23, check for malware or for exploits that could be used to identify single users and that would pass a comparator node's check (if such a check is implemented).
  • the inquiry message 3 may be encrypted.
  • the server 1 forwards the message to all, a group or at least to a device 10 as soon as they are connected to the server 1.
  • the message may be encrypted, re-formatted, compressed, modified, signed or the like at the server 1.
  • the message is delivered using a connection configured to transfer data from the server 1 to the user device(s) 10.
  • the comparator node 23 installed on the device checks whether user data 20 saved on said device matches the message's request criteria 4, and optionally checks whether the request criteria 4 match the aforementioned conditions concerning requests that might compromise a user's privacy.
  • the comparator node 23 extracts the requested portion(s) of user data 20 and generates a return message 6 with the requested portion(s) as returned user data 7.
  • the requested user data 7 may furthermore comprise interaction with a user, such as supplementary questions concerning his health state, wellbeing or the like.
  • a user's confirmation to send data back may be required for the comparator node 23 to send data back to the server 1.
  • the return message 6 comprises furthermore returned user-independent data 8, especially specifying the inquiry message 3 that triggered the comparator node 23 to send back data.
  • the return message 6 is finally sent back to the server or server system 1 using a connection configured to transfer data from the devices 10 to the server (system) 1, wherein this sending can optionally be performed at a later date following different conditions, and multiple return messages 6 can be agglomerated, they can be sent in chunks or batches, and they can be pre-processed, such as compressed.
  • the connection configured to transfer data from the devices 10 to the server (system) 1 may lead to a server in the server system that was not the sending server if the server 1 is not a single physical server, but a server system, such as a computing cloud or the like.
  • Server 1 collects the return message(s) 6 and either sends or makes them available in an aggregated form or as single messages, in real time upon receival or at a specified point in time (such as 1.1.2020, 00:00 GMT, as soon as 1000 answers reached the server or the like) to at least one broadcasting party (40). Server 1 will strip or mask all data that are still present in the return message(s) 6 and that can be used in order to identify a user or the user's device 10, such as a user device's IP address.
  • connections 103 and 104 may be the same, or they may be different, especially depending on the structure of server or server system 1.
  • connections 101 and 102 may be the same, or they may be different, the latter e.g. being the case if the requesting party 40 requests the data to be sent or to be made available to a different server of theirs.
  • steps are recited in the appended claims, it should be noted that the order in which the steps are recited in this text may be the preferred order, but it may not be mandatory to carry out the steps in the recited order. That is, unless otherwise specified or unless clear to the skilled person, the orders in which steps are recited may not be mandatory. 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).
  • 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).
  • 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).
  • Connection configured for data transfer from server to broadcasting party Connection configured for data transfer from broadcasting party to server Connection configured for data transfer from server to device
  • Connection configured for data transfer from device to server

Abstract

Disclosed are a method and system for selectively transmitting data. The method comprises sending an inquiry message (3) comprising at least request criteria (4) from at least one broadcasting party (40) to a plurality of user devices (10) each comprising a comparator node (23); comparing the request criteria (4) to user data (20) stored on each user device (10) by the comparator node (23); on each user device (10) where the comparator node (23) achieved a successful comparison of the request criteria (4) (4) to user data (20), the comparator node (23) generating at least one return message (6) based on at least parts of user data (20); and sending the return message (6) from the user device (10) to at least one of the server (1) and the broadcasting party (40). The system comprises at least one server (1) configured to at least receive an inquiry message (3) from at least one broadcasting party (40), the inquiry message (3) comprising at least request criteria (4); and transmit the inquiry message (3) to a plurality of user devices (10). The system also comprises at least one user device (10) configured to store user data (20) and comprising at least a comparator node (23) and a communication component. The comparator node (23) is configured to at least compare the request criteria (4) to the user data (20) stored on each user device (10) and generate at least one return message (6) comprising at least parts of user data (20) on each user device (10) where a successful comparison of the request criteria (4) (4) to user data (20) was achieved. The communication component is configured to send the return message (6) to at least one of the server (1) and the broadcasting party (40).

Description

Method and system for selectively transmitting data
Field
The invention relates to data analysis for privacy-sensitive or otherwise confidential data on distributed systems.
Background
It is a known task to deliver information to recipients based on certain criteria, e.g. based on their address or name, but also based on other characteristics such as age, employment status, interests and the like.
Furthermore, the analysis of user data with datamining techniques is a known application. There is often a trade-off to be made between the quality of the data and the privacy of the users, if the original or the generated data are privacy-relevant.
If data is saved centrally (for example in a hospital's medical records of their patients or in the electoral register), selective information delivery to users is usually performed by applying the selection criteria centrally in order to extract the contact data, e.g. postal or electronical addresses, of the people to contact or to deliver information to. The information is then transmitted to the user, using the extracted contact data. To acquire data of a certain user group for the purpose of data mining, the procedure is equivalent: Even if information is masked or removed at the information source in order to protect the user's privacy or to protect data that may be confidential in any way, this must be performed at the data-requesting party, the data source or in between.
In both cases, the user has no inherent control of the use of his data, but he has to trust entities holding his data (e.g. a hospital) to ensure the protection of his privacy when they provide his contact data or when they deliver other information such as health data to third parties. Furthermore, even if privacy-sensitive or confidential data is masked or removed, it is at least once available together with the finally requested information (before being removed). Especially for the purpose of medical research, the conflict of interest between the preservation of privacy of the patients and the use of patient data, especially in cases where information from different sources should be linked, is a disputed issue.
A supplementary problem in this context is the storage of medical data. Medical data is usually either saved in a distributed way - so basically, every health care provider holds their own data concerning a patient. In this case, to retrieve information that is not comprehensively stored at one single health care provider, it will be necessary to match this data. If all patient data is stored centrally instead, the protection of the patient's privacy is quite difficult as the data is available at least to the processing unit belonging to the central storage system.
In both cases, the patient must trust other entities to guarantee his privacy.
By US20090150362A1, a double blinded privacy-safe distributed data mining protocol is disclosed, among an aggregator, a data consumer entity having privacy-sensitive information, and data source entities having privacy-sensitive information. The aggregator does not have access to the privacy-sensitive information at either the data consumer entity or the data source entities. The aggregator formulates a query without using privacy-sensitive information, and sends the query to the data consumer entity. The data consumer entity generates a list of specific instances that meet the conditions of the query and sends the list, encrypted, to the data source entities either directly or through the aggregator. The data source entities match the list against transactional data, de-identify the matched results, and send them to the aggregator. The aggregator combines results from data source entities and sends the combined result to the data consumer entity. This allows for privacy-safe data mining where both the data consumer entity and data source entities have privacy-sensitive information not available for the aggregator to see or use.
US20020116227A1 discloses a method for searching for medical information executed by one or more computers comprising the steps of formulating a request for medical information concerning an individual or group of individuals, transmitting a record request to a record facilitator, the record facilitator determining which patient record sources to investigate, a record query being sent from the facilitator to the patient record sources which are appropriate, receiving a patient record report back from the patient record sources, normalizing and augmenting the patient record report before forwarding it back to the requester, and de-identifying the patient record to remove any identifying information.
US7823207B2 discloses a privacy preserving data-mining protocol, between a secure "aggregator" and "sources" having respective access to privacy-sensitive micro-data, the protocol including : the "aggregator" accepting a user query and transmitting a parameter list for that query to the "sources" (often including privacy-problematic identifiable specifics to be analyzed); the "sources" then forming files of privacy-sensitive data-items according to the parameter list and privacy filtering out details particular to less than a predetermined quantity of micro-data-specific data-items; and the "aggregator" merging the privacy-filtered files into a data-warehouse to formulate a privacy-safe response to the user— even though the user may have included privacy-problematic identifiable specifics.
US20090326981A1 provides a system and/or a method that facilitates collecting a portion of health data from a collection of users. An interface component can receive health data communicated from a collection of users, wherein each user within the collection is associated with a respective portion of health data. A verification component can authenticate at least one of a transmission source of the portion of health data, an ownership between a portion of health data and a user, an integrity level associated with the portion of health data, or a user submitting the portion of health data. A collection component can aggregate authenticated health data into a semantic data store in which the health data is indicative of a raw and unmolested source of health information from the collection of users. The collection component can further organize the health data to facilitate identification of a medical related trend.
US20060069957A1 discloses a communication system processing element comprises a processor coupled to a memory and implements at least a portion of a distributed expert system. The distributed expert system is arranged in at least two hierarchical levels, including an upper level comprising a central controller, and a lower level comprising a plurality of local agents each associated with one or more communication devices of the system.
US6397224B1 discloses a system for anonymously linking a plurality of data records, each data record comprising a plurality of elements for identifying an associated individual, includes a first identity reference encoding module configured to encode a first encoded identity reference from a first subset of the identifying elements of a data record; a second identity reference encoding module configured to encode a second encoded identity reference from a second subset of the identifying elements of the data record; and an anonymization code assignment module configured to assign to each of the first and second encoded identity references an identical anonymization code for anonymously representing the individual associated with the data record.
US7543149B2 discloses a method for securing patient identity comprising accessing an electronic medical records database including patient data for a plurality of patients. Each patient in the electronic medical records database is assigned a unique patient identifier. Patient data for a first patient, including a first patient identifier, is retrieved from the electronic medical records database. The first patient is de-identified from the patient data. De-identifying includes the creation of a first encoded patient identifier responsive to the first patient identifier. The de-identifying results in de-identified first patient data and includes the replacement of the first patient identifier with the first encoded patient identifier. The de-identified first patient data is transmitted to a data warehouse system. The method further comprises identifying a second patient in response to receiving report data that includes a second encoded patient identifier from the data warehouse system. The identifying includes the creation of a second patient identifier responsive to the second encoded patient identifier.
While the prior art approaches may be satisfactory in some regards, they have certain shortcomings and disadvantages. Concretely, the prior art discloses either to store multiple patient records or parts thereof at single health care providers or at a central entity. In the former case of records that are saved in a distributed way, the data needs to be matched by patient, especially if a comprehensive medical record (or excerpts or derived information that is not saved at one health care provider) is needed. In the latter case of a central data storage, the data is available to the central entity anyways. Also, the patient has no control of his data and must trust the operator of the storage units - may they be central, or may they be at each health care provider. The user has no means to directly control his data at these storage entities.
In any of the two cases of data storage or in case of a hybrid combination of those two, the patient or user does not control the data storage entity. Furthermore, his data is available to the storage entity and the storage entity will technically govern the access of third parties to the patient's data. Obviously, the storage entity/ies can be all entities that hold patient data - health care providers, central registers, employers as far as they need to keep a medical record, etc, also including IT-providers operating transmission, processing or storing services, hardware or systems for the aforementioned entities.
Summary
It is therefore an object of the invention to overcome or at least alleviate the shortcomings and disadvantages of the prior art. More particularly, it is an object of the present invention to provide a method and system that allows to selectively request user data and to selectively forward data to third parties - especially for the purpose of analysis and research ("Data mining"), whereas the user has his entire data in his control on a device, which may be a mobile device. Furthermore, apart from the (if necessary anonymised) requested data, no private data is forwarded from the device to third parties.
In a first embodiment, a method for selectively transmitting data is disclosed. The method comprises sending an inquiry message comprising at least request criteria from at least one broadcasting party to a plurality of user devices each comprising a comparator node. The method also comprises comparing the request criteria to user data stored on each user device by the comparator node. The method also comprises, on each user device where the comparator node achieved a successful comparison of the request criteria to user data, the comparator node generating at least one return message based on at least parts of user data. The method further comprises, on each user device where the comparator node achieved a successful comparison of the request criteria to user data, sending the return message from the user device to at least one of the server and the broadcasting party.
The inquiry message may comprise a plurality of data and/or instructions that can be interpretable by a machine such as a processor. Put simply, the inquiry message may comprise a request for particular information (that is, user data) from a third party. In the case of medical applications (that is, when user data comprises medical data), the third party may be interested in studying correlations between certain patient parameters or researching how many users exhibit particular parameters (as simple examples, the third party may be interested in average blood pressure of female users aged 25-35, or in comparing incidence of cardiovascular disease and white blood cell count in Caucasian male smokers above age 50). That is, the third party may request only a limited and specific set of parameters or data from user devices via the inquiry message.
The request criteria may comprise certain parameters identifying an intended recipient and/or further specifying what type of data should be returned. For example, an age range, sex, medical condition or the like can be examples of request criteria. In a simple example, a third party may be interested in knowing how many users (associated with user devices and corresponding user data) suffer from below average kidney function. The request criteria may then comprise instructions to compare kidney function values present in the user data with a certain threshold (such as a value associated with decreased kidney function), and return either simply a confirmation of the corresponding value forming part of user data below the threshold and/or the value itself.
The comparator node may comprise a program or part of a program that can be configured to use computational resources of the user device to perform operations.
User data may comprise any data related to the user of the user device. Multiple users may also be associated with one user device, where each individual user would then have a unique "user profile" or the like. In a preferred embodiment, user data comprises, at least partially, medical data associated with the user. This can comprise results of various medical tests or procedures, diagnoses, measurements from fitness tracking or medical devices and the like.
A successful comparison of the request criteria to user data may refer to the comparator node verifying whether the request criteria are satisfied by user data associated with the user of the user device. In other words, this comparison may refer to matching the required parameters (such as e.g. age, sex, medical information) of the request criteria to the user data stored on the user device.
The return message based on at least parts of user data may comprise parts of user data itself (such as specific parameters requested by the request criteria), and/or simply a confirmation that upon comparison (that is, matching) between request criteria and user data, a successful comparison was achieved (for example, if the request criteria specified that only values of a certain parameter below a threshold of 10 are requested, and user data has a value of 8 for this parameter, a confirmation of a satisfied request criteria can be returned as part of the return message).
The return message can be formatted in a way that indicates to the server or to the broadcasting parties that said message is configured to transport data from a user device to a server and/or to a broadcasting party. The return message can comprise returned user data. The return message can comprise user independent data, such as information about the reason for its emission, such as a reference to the inquiry message that triggered the emission/generation of said return message. The return message can be encrypted. The returned data can be at least partially medical data.
At least some of the user devices may each comprise a data storage, at least one processing component configured to execute a program in a suitable form and format and a communication component at least configured to communicate with a remote server.
The processing component can for example comprise processors, hardware accelerators and/or microcontrollers.
The data storage can comprise memory components, such as, main memory (e.g. RAM), cache memory (e.g. SRAM) and/or secondary memory (e.g. HDD, SDD).
The user devices can comprise busses configured to facilitate data exchange between their components, such as, the communication between the data storage and the processing component. The user device can comprise network interface controllers that can be configured to connect the data processing device to a network, such as, to the Internet
The data storage may be at least partially encrypted. Advantageously, this can allow for secure storage of potentially sensitive data, such as medical data. The user device may comprise a user terminal.
The user device may be a portable device, such as a laptop, a tablet computer, a smartphone, a wearable device, or an adapted medical device.
Optionally advantageously, the present method may allow a third party to gain access to sensitive user data without compromising the privacy and security of the user. Particularly in the case of medical data, it may be preferable that it is stored on the user device (that is, under the control of the user), and it may not be optimal to simply send it somewhere for further research or analysis. Therefore, it is particularly useful to extract only the requested parts of the data (or simply a confirmation that the user data corresponds to the parameters set out by the request criteria), particularly without compromising sensitive user data or disclosing more than requested to the third party.
In some embodiments, the server can comprise a single server, a server system composed of multiple servers, and/or a program emulating the functionality of a server, running on a cloud computing platform or any system configured to implement the functionality of a server.
The server can comprise means of data processing, such as, processor units, hardware accelerators and/or microcontrollers. The server can comprise memory components, such as, main memory (e.g. RAM), cache memory (e.g. SRAM) and/or secondary memory (e.g. HDD, SDD). The server can comprise busses configured to facilitate data exchange between components of the server, such as, the communication between the memory components and the processing components of the server. The server can comprise network interface cards that can be configured to connect the server to a network, such as, to the Internet. The server can comprise user interfaces, such as: output user interface, such as screens or monitors configured to display visual data and/or speakers configured to communicate audio data, input user interface, such as a camera, a microphone configured to capture audio data, a keyboard, a trackpad, mouse, touchscreen and/or joystick.
The server can also be configured to be controlled from another computer system, such as via a remote-desktop connection, via a secure shell connection (SSH) or the like.
To put it simply, the server can be a processing unit configured to carry out instructions of a program. The server can be a system-on-chip comprising processing units, memory components and busses. The server can be a processing unit or a system-on-chip that can be interfaced with a personal computer, a laptop, a pocket computer, a smartphone, a tablet computer and/or user interfaces (such as the upper-mentioned user interfaces).
In some embodiments, sending the inquiry message can comprise receiving an inquiry message from at least one broadcasting party by a server and the server transmitting the inquiry message to the plurality of user devices. Advantageously, this may prevent third parties having direct access to user devices. The server can then serve as an intermediary that can already filter some inquiry messages or otherwise process them before forwarding them on to the user devices.
In some embodiments, the method can further comprise discarding the inquiry message on each device where the comparator node did not achieve a successful comparison of the request criteria to user data. That is, if the user data does not match the request criteria, the inquiry message may be simply discarded, and there may be no generation of the return message (additionally or alternatively, there may be a return message generated to confirm that the comparison between the request criteria and user data was not successful).
In some embodiments, sending the inquiry message can further comprise transmitting the inquiry message by a connection configured to transfer data from the broadcasting party to the server.
In some embodiments, sending the inquiry message can further comprise connecting the user devices and the server at least at some points in a period of time by a connection configured to transfer data from the server to the user devices. In some embodiments, the sending of the return message can be performed at any point in time after the generating at least one return message. In some such embodiments, the point of time when the sending is performed can depend on a further condition.
In some embodiments, user data can comprise at least identifying data and technical data. In some such embodiments, the generating of at least one of said return message can comprise inserting at least a part of the technical data and at least a part of the identifying data to the at least one return message by the comparator node. In some such embodiments, inserting the technical data and the identifying data can be performed at most to the extent that was requested by the inquiry message that triggered the generation of said return message.
In some embodiments, the generating of at least one of the return message can comprise furthermore processing the identifying data before inserting it to the return message. In some such embodiments, the processing of the identifying data can be performed by the comparator node. In some such embodiments, the method can further comprise the comparator node using a set of rules to invoke certain actions if certain portions of the user data or combinations thereof are requested by the inquiry message.
In some such embodiments, the processing of said inquiry message can comprise anonymising at least parts of the identifying data before inserting it to the return message. In some such embodiments, the anonymising of at least parts of the identifying data can comprise limiting the precision of at least a portion of said identifying data. For example, this can be done by replacing the date of birth by year of birth, by replacing the address by the ZIP-code, parts thereof, the region in which the address is located or the like. The anonymising of at least parts of the identifying data can comprise replacing at least a portion of the identifying data by pseudonyms or codes. Those pseudonyms or codes can be generated by the comparator node. Additionally or alternatively, they can also be generated by the server if the return message is first sent to the server before being forwarded to the broadcasting parties.
In some embodiments, the anonymising of at least parts of the identifying data can comprise replacing at least a portion of said identifying data by variables that are deduced from the identifying data, but that do not allow exact determination of the identifying data. For example, the date of birth can be replaced by age. In some such embodiments, the anonymising of at least parts of the identifying data can comprise treating at least a part of the identifying data with a differential privacy algorithm.
Anonymising or otherwise masking user data before it leaves the user device as part of the return message can be very useful to ensure user privacy, as well as security of possibly sensitive data. It is particularly advantageous to perform this anonymising before sharing user data (that is, preferably parts of it) with third parties. It allows such third parties to get access to accurate and useful data for possible further research into treatments, marketing purposes, general research or the like, while not compromising on the users' right to privacy and safe data storage.
In some embodiments, the technical user data that can be sent to at least one of a server and a broadcasting party as part of the return message can be treated with a differential privacy algorithm before being sent to at least one of a server and a broadcasting party respectively.
In some embodiments, the processing of the inquiry message can comprise sending at least a plurality of the return messages. For example, the inquiry message may comprise a plurality of independent request criteria. An individual return message can be generated for each such independent request criteria.
In some embodiments, the return message can comprise at least an indicator for at least one of the following : user data matches the request criteria for the first time and an event concerning user data occurs (for instance, adding a certain value or registering a certain event).
In some embodiments, the sending can furthermore require that at least one of the user data and an event concerning user data respectively also satisfy a time constraint. For example, this can be the user data matching the matching criteria (4) within a given period of time or that the event occurs within a given period of time.
In some embodiments, the method can further comprise requesting at least implicit general consent, more preferably explicitly indicated consent, more preferably explicitly indicated consent to each single request of the user data, of the user before at least one of generating or triggering sending at least one return message corresponding to the inquiry message is performed by the comparator node.
In some embodiments, one or a plurality of return messages that are generated on the user device can be sent to a server or a broadcasting party at a point in time when the user device is at least indirectly connected to the server and/or the broadcasting party respectively. In some such embodiments, the one or a plurality of return messages that are generated on the user device can be sent to the server or the broadcasting party in at least one of a compressed form, batches and an agglomerated form. This can be advantageous to ensure efficient data management and optimisation of data transfer. In some such embodiments, the sending to the server or the broadcasting party of the one or a plurality of return message that are generated on the user device can be triggered once during a defined period of time (e.g. once an hour, a day, a week etc), by a message from a server or a broadcasting party, and/or by a matching of a condition on the user device, such as existence of at least one of a defined number of return messages. In some embodiments where the return message can be sent to the server, the method can further comprise, after the receiving of the return message, forwarding at least parts of the return message that the server received to at least some of the broadcasting parties, preferably forwarding each return message to the broadcasting party that sent the inquiry message that caused the generation of the respective return message.
In some such embodiments, generating the at least one return message can comprise furthermore adding a specification of at least one of the broadcasting party and the inquiry message that caused the generation of the return message.
In some such embodiments, the method can further comprise the server using at least the specification of at least one of the broadcasting party and the inquiry message to forward at least the content of the return message.
In some such embodiments, the method can further comprise the server collecting the return messages corresponding to one inquiry message and making available the return messages or their content, preferably in an agglomerated form, to the broadcasting party that issued said inquiry message. The sending the return messages or their content, preferably in an agglomerated form, can be triggered when a certain condition is met. The condition can comprise, for example, elapsed time, a pre-defined number of received answers, approval by the broadcasting party that sent the inquiry message.
In some such embodiments, the method can further comprise taking measures to mask, remove or conceal elements suitable to identify the user or the user device (such as e.g. IP address) prior to sending the return messages or parts thereof to at least one of the at least one broadcasting parties.
In some embodiments, the method can further comprise encrypting at least parts of the return message with at least one encryption key by the user device before or while sending it. In some such embodiments where the return message is sent to the broadcasting parties the method can further comprise decrypting the return message at the respective broadcasting parties.
In some embodiments where the return message is sent to the server, the method can further comprise encrypting at least parts of each the return message at the user device before or while sending it to the server. The method can then further comprise decrypting at least parts of each return message at the server after receiving said return message. The method can then also comprise encrypting at least parts of said return message, of a set of return messages or of the agglomerated content of multiple return messages at the server before sending said return message to the receiving broadcasting party. The method can then further comprise decrypting the data sent by the server at least partially at the receiving broadcasting party. In some embodiments where the return message is sent to the server, the method can further comprise encrypting at least parts of the return message with a key corresponding to the respective broadcasting party that issued the inquiry message that caused the generation of the return message. The encryption can be then set up in a way so that the server cannot access said parts of the return message (e.g. by sharing a secret key between the broadcasting party and the user device). This can be advantageous, for example, when the third party has certain permissions to access sensitive (preferably medical) user data, that the server does not have permission to access.
In some embodiments, the method can further comprise encrypting at least parts of the return message at the user device using an asymmetric encryption algorithm before or while sending each return message. This can comprise furthermore using at least a public key for the encryption of each return message, wherein said public key corresponds to the respective broadcasting party that is the intended receiver of said return message.
In some embodiments where the return message is sent to the server, the method can further comprise sending and receiving the inquiry message with one or multiple parts of the server that are at least partially different from parts of the server used for sending and receiving at least parts of the return message at the server.
In some embodiments, the method can further comprise sending inquiry messages by the broadcasting parties from systems that are for at least one broadcasting party at least partially different from systems that are used for receiving the return messages.
The last two embodiments can be particularly advantageous if virtual separation between the inquiry message and the return message (possibly comprising sensitive data) is preferred. There can be subservers/subroutines that are isolated from each other (such as virtual isolated environments) handling the inquiry message and the return message, either on the server, at the broadcasting parties and/or both.
In a second embodiment, a system for selectively transmitting data is disclosed. The system comprises at least one server. The server is configured to receive an inquiry message from at least one broadcasting party, the inquiry message comprising at least request criteria. The server is also configured to transmit the inquiry message to a plurality of user devices. The system further comprises at least one user device configured to store user data and comprising at least a comparator node and a communication component. The comparator node is configured to at least compare the request criteria to the user data stored on each user device and generate at least one return message comprising at least parts of user data on each user device where a successful comparison of the request criteria to user data was achieved. The communication component is configured to send the return message to at least one of the server and the broadcasting party.
The user device, user data, inquiry message, request criteria, return message, and comparator node can be as described above with respect to the method. The present system may be particularly configured to execute or perform the method for selectively transmitting data as described in the above embodiments.
In some embodiments, the user device can comprise a portable device. For example, the user device can comprise a laptop, a tablet computer, a smartphone, a wearable device, and/or an adapted medical device.
In some embodiments, user data can comprise at least partially technical medical data. The user device can be further configured to at least partially encode the technical medical data by replacing at least parts of the data by machine-interpretable expressions.
In some embodiments, the user device can comprise a user interface configured to enable a user to interact with the user device and wherein the user interface can comprise at least one interaction component. That is, the user interface may comprise an interface that the user may use to access the broadcasting message or other associated data, including user data. The interaction component may comprise a display, speakers, or the like. The user interface may be linked to the device by at least one of a direct connection, such as by electro-magnetic waves, integrated or removable wiring, and an indirect connection, such as by a server, such as an interface displaying e-mails sent by the user device or an interface playing voice messages sent by the user device.
In some such embodiments, the user interface can be configured to perform necessary interface steps for a verification of a user's identity. For example, those can comprise reading a password or a PIN entered by a user, scanning a user's fingerprint, taking at least photos of a user that are configured for facial recognition, accepting a hardware authentication element (e.g. hardware key) or any combination thereof.
In some such embodiments, the user interface can be further configured to perform necessary interface steps for a verification of a user's identity. For example, those can comprise reading a password or a PIN entered by a user, scanning a user's fingerprint, taking at least photos of a user that are configured for facial recognition, accepting a hardware authentication element (e.g. hardware key) or any combination thereof.
In some embodiments, the server can be further configured to perform at least one verification on the inquiry message before transmitting it to user devices. For example, a check for malware or for compliance with pre-defined criteria or rules can be performed. In some embodiments the comparator node can be configured to apply the request criteria of received inquiry messages to the user data saved on the device, and wherein said comparator node can be software- based. The comparator node can generally comprise a program installed on a user device and configured to interact with it. The comparator node can be configured to use the user device's hardware (such as a processor, sensors or communication component) to perform its tasks, subroutines or the like.
In some embodiments, the server can be furthermore configured to send data to the broadcasting parties.
In some embodiments, the server can further comprise, at least at some points in time, a connection configured for data transfer from at least one of the at least one user devices to the server, and, at least at some points in time, a connection configured for data transfer from the server to at least one of the at least one broadcasting parties.
In some embodiments, the user device can be configured to store user data in a machine-interpretable form.
In some preferred embodiments, the user data can comprise medical user data.
The user device can be configured to encode the user data with at least a homogenous naming for fields. The user device can be configured to encode values with a same dimension unit for each field.
The user device can be further configured to at least partially generate medical data. This data can comprise at least one medical image. The data can also comprise at least one result of a laboratory analysis of material originating from or expelled by the human body. The data can further comprise data from a sensing device that senses biometrical or medical data of a user. The user device may even be configured to generate some of the original data such as images via the user device's sensors such as a camera (further sensors such as biometric sensors may also be used).
The following numbered embodiments also form part of the invention.
Below, method embodiments will be discussed. These embodiments are abbreviated by the letter "M" followed by a number. Whenever reference is herein made to "method embodiments", these embodiments are meant.
Ml. A method for selectively transmitting data, the method comprising Sending an inquiry message (3) comprising at least request criteria (4) from at least one broadcasting party (40) to a plurality of user devices (10) each comprising a comparator node (23);
Comparing the request criteria (4) to user data (20) stored on each user device (10) by the comparator node (23);
On each user device (10) where the comparator node (23) achieved a successful comparison of the request criteria (4) (4) to user data (20),
The comparator node (23) generating at least one return message (6) based on at least parts of user data (20); and
Sending the return message (6) from the user device (10) to at least one of the server (1) and the broadcasting party (40).
M2. The method according to the preceding embodiment wherein sending the inquiry message (3) comprises
Receiving an inquiry message (3) from at least one broadcasting party (40) by a server (1);
The server transmitting the inquiry message (3) to the plurality of user devices
(10).
M3. The method according to any of the preceding method embodiments further comprising discarding the inquiry message (3) on each device where the comparator node (23) did not achieve a successful comparison of the request criteria (4) to user data (20).
M4. The method according to any of the preceding method embodiments and with the features of embodiment M2 wherein sending the inquiry message (3) further comprises transmitting the inquiry message (3) by a connection (102) configured to transfer data from the broadcasting party (40) to the server (1).
M5. The method according to any of the preceding method embodiments and with features of embodiment M2 wherein sending the inquiry message (3) further comprises connecting the user devices (10) and the server (1) at least at some points in a period of time by a connection (103) configured to transfer data from the server to the user devices (10).
M6. The method according to any of the preceding method embodiments wherein the sending of the return message (6) is performed at any point in time after the generating at least one return message (6).
M7. The method according to the preceding method embodiment wherein the point of time when the sending is performed depends on a further condition. M8. The method according to any of the preceding method embodiments wherein user data (20) comprises at least identifying data (24) and technical data (25).
M9. The method according to the preceding embodiment wherein the generating of at least one of said return message(s) (6) comprises inserting at least a part of the technical data (25) and at least a part of the identifying data (24) to the at least one return message (6) by the comparator node (23).
M10. The method according to the preceding embodiment wherein inserting the technical data (25) and the identifying data (24) is performed at most to the extent that was requested by the inquiry message (3) that triggered the generation of said return message (6).
Mi l. The method according to any of the three preceding embodiments wherein the generating of at least one of the return message(s) (6) comprises furthermore processing the identifying data (24) before inserting it to the return message (6).
M12. The method according to the preceding embodiment, wherein the processing of the identifying data (24) is performed by the comparator node (23).
M13. The method according to the preceding embodiment further comprising the comparator node (23) using a set of rules to invoke certain actions if certain portions of the user data (20) or combinations thereof are requested by the inquiry message (3).
M14. The method according to any of the three preceding embodiments wherein the processing of said inquiry message (3) comprises anonymising at least parts of the identifying data (24) before inserting it to the return message(s) (6).
M15. The method according to the preceding embodiment wherein the anonymising of at least parts of the identifying data (24) comprises limiting the precision of at least a portion of said identifying data (24).
M16. The method according to any of the two preceding embodiments wherein the anonymising of at least parts of the identifying data (24) comprises replacing at least a portion of the identifying data (24) by pseudonyms or codes.
M17. The method according to the preceding embodiment wherein the pseudonyms or codes are generated by the comparator node (23).
M18. The method according to any of the four preceding embodiments wherein the anonymising of at least parts of the identifying data (24) comprises replacing at least a portion of said identifying data (24) by variables that are deduced from the identifying data (24), but that do not allow exact determination of the identifying data (24). M19. The method according to any of the five preceding embodiments wherein the anonymising of at least parts of the identifying data (24) comprises treating at least a part of the identifying data (24) with a differential privacy algorithm.
M20. The method according to any of the preceding method embodiments and with features of embodiment M8 wherein the technical user data (25) that is sent to at least one of a server (1) and a broadcasting party (40) as part of the return message (6) is treated with a differential privacy algorithm before being sent to at least one of a server (1) and a broadcasting party (40) respectively.
M21. The method according to any of the preceding method embodiments wherein the processing of the inquiry message (3) comprises sending at least a plurality of the return messages (6).
M22. The method according to any of the preceding method embodiments wherein the return message (6) comprises at least an indicator for at least one of the following :
user data (20) matches the request criteria (4) for the first time and
an event concerning user data (20) occurs.
M23. The method according to any of the preceding method embodiments wherein the sending requires furthermore that at least one of the user data (20) and an event concerning user data (20) respectively also satisfy a time constraint.
M24. The method according to any of the preceding method embodiments further comprising requesting at least implicit general consent, more preferably explicitly indicated consent, more preferably explicitly indicated consent to each single request of the user data (20), of the user before at least one of generating or triggering sending at least one return message (6) corresponding to the inquiry message (3) is performed by the comparator node (23).
M25. The method according to any of the preceding method embodiments wherein one or a plurality of return message(s) (6) that are generated on the user device (10) are sent to a server (1) or a broadcasting party (40) at a point in time when the user device (10) is at least indirectly connected to the server (1) and/or the broadcasting party (40) respectively.
M26. The method according to the preceding embodiment, wherein the one or a plurality of return message(s) (6) that are generated on the user device (10) are sent to the server (1) or the broadcasting party (40) in at least one of a compressed form, batches and an agglomerated form.
M27. The method according to any of the two preceding returning method embodiments, wherein the sending to the server (1) or the broadcasting party (40) of the one or a plurality of return message(s) (6) that are generated on the user device (10) is triggered (a) once during a defined period of time,
(b) by a message from a server (1) or a broadcasting party (40), and/or
(c) by a matching of a condition on the user device (10), such as existence of at least one of a defined number of return message(s) (6).
M28. The method according to any of the preceding method embodiments wherein the return message (6) is sent to the server (1), further comprising, after the receiving of the return message(s) (6), forwarding at least parts of the return message(s) that the server (1) received to at least some of the broadcasting parties (40), preferably forwarding each return message (6) to the broadcasting party (40) that sent the inquiry message (3) that caused the generation of the respective return message (6).
M29. The method according to the preceding embodiment wherein generating the at least one return message(s) (6) comprises furthermore adding a specification of at least one of the broadcasting party (40) and the inquiry message (3) that caused the generation of the return message(s) (6).
M30. The method according to the preceding embodiment further comprising the server using at least the specification of at least one of the broadcasting party (40) and the inquiry message (3) to forward at least the content of the return message(s) (6).
M31. The method according to any of the three preceding embodiments further comprising the server (1) collecting the return messages (6) corresponding to one inquiry message (3) and making available the return messages (6) or their content, preferably in an agglomerated form, to the broadcasting party (40) that issued said inquiry message (3).
M32. The method according to the preceding embodiment wherein the sending the return messages (6) or their content, preferably in an agglomerated form, is triggered when a certain condition is met.
M33. The method according to any of the five preceding embodiments further comprising taking measures to mask, remove or conceal elements suitable to identify the user or the user device (10) prior to sending the return messages (6) or parts thereof to at least one of the at least one broadcasting parties (40).
M34. The method according to any of the preceding method embodiments further comprising encrypting at least parts of the return message (6) with at least one encryption key by the user device (10) before or while sending it.
M35. The method according to the preceding embodiment wherein the return message (6) is sent to the broadcasting parties (40) further comprising decrypting the return message (6) at the respective broadcasting parties (40). M36. The method according to any of the preceding method embodiments wherein the return message (6) is sent to the server (1) further comprising
encrypting at least parts of each the return message (6) at the user device (10) before or while sending it to the server (1),
decrypting at least parts of each return message (6) at the server (10) after receiving said return message (6),
encrypting at least parts of said return message (6), of a set of return messages (6) or of the agglomerated content of multiple return messages (6) at the server (10) before sending said return message(s) (6) to the receiving broadcasting party (40) and decrypting the data sent by the server (1) at least partially at the receiving broadcasting party (40).
M37. The method according to any of the preceding method embodiments wherein the return message (6) is sent to the server (1) further comprising encrypting at least parts of the return message(s) (6) with a key corresponding to the respective broadcasting party (40) that issued the inquiry message (3) that caused the generation of the return message(s) (6),
wherein the encryption is set up in a way so that the server (1) cannot access said parts of the return message(s) (6).
M38. The method according to any of the preceding method embodiments further comprising encrypting at least parts of the return message(s) (6) at the user device (10) using an asymmetric encryption algorithm before or while sending each return message (6).
M39. The method according to the preceding embodiment wherein encrypting at least parts of the return message (6) using an asymmetric encryption algorithm comprises furthermore using at least a public key for the encryption of each return message (6), wherein said public key corresponds to the respective broadcasting party (40) that is the intended receiver of said return message (6).
M40. The method according to any of the preceding method embodiments wherein the return message (6) is sent to the server (1) further comprising sending and receiving the inquiry message (3)s with one or multiple parts of the server (1) that are at least partially different from parts of the server (1) used for sending and receiving at least parts of the return message(s) (6) at the server (1).
M41. The method according to any of the preceding method embodiments further comprising sending inquiry messages (3) by the broadcasting parties (40) from systems that are for at least one broadcasting party (40) at least partially different from systems that are used for receiving the return messages (6). Below, system embodiments will be discussed. These embodiments are abbreviated by the letter "S" followed by a number. Whenever reference is herein made to "system embodiments", these embodiments are meant.
51. A system for selectively transmitting data comprising
at least one server (1) configured to at least
receive an inquiry message (3) from at least one broadcasting party (40), the inquiry message (3) comprising at least request criteria (4); and transmit the inquiry message (3) to a plurality of user devices (10);
at least one user device (10) configured to store user data (20) and comprising at least a comparator node (23) and a communication component,
wherein the comparator node (23) is configured to at least compare the request criteria (4) to the user data (20) stored on each user device (10) and generate at least one return message (6) comprising at least parts of user data (20) on each user device (10) where a successful comparison of the request criteria (4) (4) to user data (20) was achieved; and wherein the communication component is configured to send the return message (6) to at least one of the server (1) and the broadcasting party (40).
52. The system according to the preceding embodiment wherein the user device comprises a portable device.
53. The system according to any of the preceding system embodiments wherein user data (20) comprises at least partially technical medical data (25).
54. The system according to the preceding embodiment wherein the user device (10) is further configured to at least partially encode the technical medical data (25) by replacing at least parts of the data by machine-interpretable expressions.
55. The system according to any of the preceding system embodiments wherein the user device (10) further comprises a user interface (11) configured to enable a user to interact with the user device (10) and wherein the user interface (11) comprises at least one interaction component.
56. The system according to the preceding embodiment wherein the user interface (11) is further configured to perform necessary interface steps for a verification of a user's identity. 57. The system according to any of the preceding system embodiments wherein the server (1) is further configured to perform at least one verification on the inquiry message (3) before transmitting it to user devices (10).
58. The system according to any of the preceding system embodiments wherein the comparator node (23) is configured to apply the request criteria (4) of received inquiry messages (3) to the user data (20) saved on the device (10), and wherein said comparator node (23) is software-based.
59. The system according to any of the preceding system embodiments wherein the server (1) is furthermore configured to send data to the broadcasting parties (40).
510. The system according to any of the preceding system embodiments wherein the server (1) further comprises, at least at some points in time, a connection (104) configured for data transfer from at least one of the at least one user devices (10) to the server (1), and, at least at some points in time, a connection (101) configured for data transfer from the server to at least one of the at least one broadcasting parties (40).
511. The system according to any of the preceding system embodiments wherein the user device (10) is configured to store user data (20) in a machine-interpretable form.
512. The system according to the preceding system embodiment wherein the user data (20) comprises medical user data.
513. The system according to any of the two preceding embodiments wherein the user device (10) is configured to encode the user data (20) with at least a homogenous naming for fields.
514. The system according to any of the three preceding embodiments wherein the user device (10) is configured to encode values with a same dimension unit for each field.
515. The system according to any of the four preceding embodiments wherein the user device (10) is further configured to at least partially generate medical data comprising at least one of
At least one medical image;
At least one result of a laboratory analysis of material originating from or expelled by the human body; and
Data from a sensing device that senses biometrical or medical data of a user.
516. The system according to any of the preceding system embodiments configured to perform the method according to any of the preceding method embodiments.
Brief description of the drawing Figure 1 schematically depicts an embodiment of a method to selectively transmitting data.
Figure 1 shows a scheme of a method to selectively draw medical user data for analytic purpose based on selection criteria that refer to private medical data without disclosing the users' identity (directly or indirectly) to the parties requesting the medical user data.
A central server 1 is at least at some points in time connected to at least one device 10 (here: two devices 10) and to at least broadcasting party 40, whereas these points in time do not need to be the same.
The broadcasting party 40 sends a data request in the form of an inquiry message 3 to the server 1 using a connection configured to transfer data from the requesting party to the server 102. The message 3 comprises request criteria 4. If a user matches the request criteria 4, a return message 6 is generated. In the case of requesting medical data for datamining purpose, the inquiry message 3 comprises a request for certain medical user data.
Device 10 comprises user data 20, wherein the user data 20 comprises identifying data 24 that may directly identify a user, such as the user's name, date of birth, address and the like. The user data 20 comprises furthermore medical technical user data 25. Parts of said medical user data 25 do not per se disclose the user's identity, whereas other parts or combinations thereof may be suitable to identify the user, for example data that can be matched with an insurance company's record of invoiced medical services for their insureds. Device 10 comprises furthermore a comparator node 23 that can apply request criteria 4 to the user data 20, wherein criteria concerning the identifying user data may not make direct comparisons, such as matching for the user's name, the user's date of birth or his address(es). Nevertheless, the criteria may specify an age (e.g. by year of birth or interval of dates of birth), a (sufficiently extended) geographic region (that can be matched using a user's address or parts thereof, such as a user's ZIP code), a gender or the like. The criteria may obviously also apply to the medical user data 25, even though those criteria may not be too specific as they might otherwise allow to target single users, e.g. based on their known medical treatment. Comparator node 23 may comprise measures to check the compliance of the request criteria 4 to the aforementioned or other limitations. A device 10 can access at least one user interface 11.
Once a server 1 receives an inquiry message 3 from a broadcasting party 40, the server 1 may optionally apply tests to the message, e.g. check the compliance of the request criteria described above in the context of the comparator node 23, check for malware or for exploits that could be used to identify single users and that would pass a comparator node's check (if such a check is implemented). The inquiry message 3 may be encrypted. The server 1 forwards the message to all, a group or at least to a device 10 as soon as they are connected to the server 1. The message may be encrypted, re-formatted, compressed, modified, signed or the like at the server 1. The message is delivered using a connection configured to transfer data from the server 1 to the user device(s) 10.
Once a device 10 receives a broadcasted message 3 with a request to provide data, the comparator node 23 installed on the device checks whether user data 20 saved on said device matches the message's request criteria 4, and optionally checks whether the request criteria 4 match the aforementioned conditions concerning requests that might compromise a user's privacy.
If the user data 20 match the request criteria 4, the comparator node 23 extracts the requested portion(s) of user data 20 and generates a return message 6 with the requested portion(s) as returned user data 7. The requested user data 7 may furthermore comprise interaction with a user, such as supplementary questions concerning his health state, wellbeing or the like. Optionally, a user's confirmation to send data back may be required for the comparator node 23 to send data back to the server 1. The return message 6 comprises furthermore returned user-independent data 8, especially specifying the inquiry message 3 that triggered the comparator node 23 to send back data. The return message 6 is finally sent back to the server or server system 1 using a connection configured to transfer data from the devices 10 to the server (system) 1, wherein this sending can optionally be performed at a later date following different conditions, and multiple return messages 6 can be agglomerated, they can be sent in chunks or batches, and they can be pre-processed, such as compressed. The connection configured to transfer data from the devices 10 to the server (system) 1 may lead to a server in the server system that was not the sending server if the server 1 is not a single physical server, but a server system, such as a computing cloud or the like. Server 1 collects the return message(s) 6 and either sends or makes them available in an aggregated form or as single messages, in real time upon receival or at a specified point in time (such as 1.1.2020, 00:00 GMT, as soon as 1000 answers reached the server or the like) to at least one broadcasting party (40). Server 1 will strip or mask all data that are still present in the return message(s) 6 and that can be used in order to identify a user or the user's device 10, such as a user device's IP address.
The connections 103 and 104 may be the same, or they may be different, especially depending on the structure of server or server system 1.
The connections 101 and 102 may be the same, or they may be different, the latter e.g. being the case if the requesting party 40 requests the data to be sent or to be made available to a different server of theirs.
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".
Whenever steps are recited in the appended claims, it should be noted that the order in which the steps are recited in this text may be the preferred order, but it may not be mandatory to carry out the steps in the recited order. That is, unless otherwise specified or unless clear to the skilled person, the orders in which steps are recited may not be mandatory. 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.
Numbered elements
1 Server Inquiry message
Request criteria
Return message
Returned user data
Returned user-independent data
Device
User interface
User data
Comparator node
Identifying data
Technical data
User
Broadcasting/Requesting parties
Connection configured for data transfer from server to broadcasting party Connection configured for data transfer from broadcasting party to server Connection configured for data transfer from server to device
Connection configured for data transfer from device to server

Claims

Claims
1. A method for selectively transmitting data, the method comprising
Sending an inquiry message (3) comprising at least request criteria (4) from at least one broadcasting party (40) to a plurality of user devices (10) each comprising a comparator node (23);
Comparing the request criteria (4) to user data (20) stored on each user device (10) by the comparator node (23);
On each user device (10) where the comparator node (23) achieved a successful comparison of the request criteria (4) (4) to user data (20),
The comparator node (23) generating at least one return message (6) based on at least parts of user data (20); and
Sending the return message (6) from the user device (10) to at least one of the server (1) and the broadcasting party (40).
2. The method according to the preceding claim wherein sending the inquiry message (3) comprises
Receiving an inquiry message (3) from at least one broadcasting party (40) by a server (1);
The server transmitting the inquiry message (3) to the plurality of user devices
(10).
3. The method according to any of the preceding claims wherein the sending of the return message (6) is performed at any point in time after the generating at least one return message (6) and wherein the point of time when the sending is performed depends on a further condition.
4. The method according to any of the preceding claims wherein user data (20) comprises at least identifying data (24) and technical data (25) and
wherein the generating of at least one of said return message(s) (6) comprises inserting at least a part of the technical data (25) and at least a part of the identifying data (24) to the at least one return message (6) by the comparator node (23) and wherein inserting the technical data (25) and the identifying data (24) is performed at most to the extent that was requested by the inquiry message (3) that triggered the generation of said return message (6).
5. The method according to the preceding claim
wherein the generating of at least one of the return message(s) (6) comprises furthermore processing the identifying data (24) before inserting it to the return message (6) and
wherein the processing of the identifying data (24) is performed by the comparator node (23) and
wherein the method further comprises the comparator node (23) using a set of rules to invoke certain actions if certain portions of the user data (20) or combinations thereof are requested by the inquiry message (3).
6. The method according to the preceding claim
wherein the processing of said inquiry message (3) comprises anonymising at least parts of the identifying data (24) before inserting it to the return message(s) (6).
7. The method according to the preceding claim wherein the anonymising of at least parts of the identifying data (24) comprises at least one of
limiting the precision of at least a portion of said identifying data (24) and replacing at least a portion of the identifying data (24) by pseudonyms or codes and
replacing at least a portion of said identifying data (24) by variables that are deduced from the identifying data (24), but that do not allow exact determination of the identifying data (24) and
treating at least a part of the identifying data (24) with a differential privacy algorithm.
8. The method according to any of the preceding claims further comprising requesting at least implicit general consent, more preferably explicitly indicated consent, more preferably explicitly indicated consent to each single request of the user data (20), of the user before at least one of generating or triggering sending at least one return message (6) corresponding to the inquiry message (3) is performed by the comparator node (23).
9. The method according to any of the preceding claims
wherein one or a plurality of return message(s) (6) that are generated on the user device (10) are sent to a server (1) or a broadcasting party (40) at a point in time when the user device (10) is at least indirectly connected to the server (1) and/or the broadcasting party (40) respectively and
wherein the one or a plurality of return message(s) (6) that are generated on the user device (10) are sent to the server (1) or the broadcasting party (40) in at least one of a compressed form, batches and an agglomerated form.
10. The method according to the preceding claim, wherein the sending to the server (1) or the broadcasting party (40) of the one or a plurality of return message(s) (6) that are generated on the user device (10) is triggered
(a) once during a defined period of time,
(b) by a message from a server (1) or a broadcasting party (40), and/or
(c) by a matching of a condition on the user device (10), such as existence of at least one of a defined number of return message(s) (6).
11. The method according to any of the preceding claims further comprising further comprising encrypting at least parts of the return message(s) (6) at the user device (10) using an asymmetric encryption algorithm before or while sending each return message (6).
12. The method according to the preceding claim wherein encrypting at least parts of the return message (6) using an asymmetric encryption algorithm comprises furthermore using at least a public key for the encryption of each return message (6), wherein said public key corresponds to the respective broadcasting party (40) that is the intended receiver of said return message (6).
13. A system for selectively transmitting data comprising
at least one server (1) configured to at least receive an inquiry message (3) from at least one broadcasting party (40), the inquiry message (3) comprising at least request criteria (4); and transmit the inquiry message (3) to a plurality of user devices (10);
at least one user device (10) configured to store user data (20) and comprising at least a comparator node (23) and a communication component,
wherein the comparator node (23) is configured to at least compare the request criteria (4) to the user data (20) stored on each user device (10) and generate at least one return message (6) comprising at least parts of user data (20) on each user device (10) where a successful comparison of the request criteria (4) (4) to user data (20) was achieved; and
wherein the communication component is configured to send the return message (6) to at least one of the server (1) and the broadcasting party (40).
14. The system according to the preceding claim wherein user data (20) comprises at least partially technical medical data (25) and wherein the user device (10) is further configured to at least partially encode the technical medical data (25) by replacing at least parts of the data by machine-interpretable expressions.
15. The system according to any of the preceding system claims wherein the user device (10) further comprises a user interface (11) configured to enable a user to interact with the user device (10) and wherein the user interface (11) comprises at least one interaction component and wherein the user interface (11) is further configured to perform necessary interface steps for a verification of a user's identity.
16. The system according to any of the preceding system claims
wherein the user device (10) is configured to store user data (20) in a machine- interpretable form and
wherein the user data (20) comprises medical user data and
wherein the user device (10) is configured to encode the user data (20) with at least a homogenous naming for fields and
wherein the user device (10) is configured to encode values with a same dimension unit for each field.
17. The system according to the preceding clam wherein the user device (10) is further configured to at least partially generate medical data comprising at least one of
At least one medical image;
At least one result of a laboratory analysis of material originating from or expelled by the human body; and
Data from a sensing device that senses biometrical or medical data of a user.
PCT/EP2020/060916 2019-04-18 2020-04-17 Method and system for selectively transmitting data WO2020212604A1 (en)

Applications Claiming Priority (8)

Application Number Priority Date Filing Date Title
EP19170111.9 2019-04-18
EP19170091 2019-04-18
EP19170096 2019-04-18
EP19170100.2 2019-04-18
EP19170096.2 2019-04-18
EP19170100 2019-04-18
EP19170111 2019-04-18
EP19170091.3 2019-04-18

Publications (1)

Publication Number Publication Date
WO2020212604A1 true WO2020212604A1 (en) 2020-10-22

Family

ID=69846023

Family Applications (4)

Application Number Title Priority Date Filing Date
PCT/EP2020/060916 WO2020212604A1 (en) 2019-04-18 2020-04-17 Method and system for selectively transmitting data
PCT/EP2020/060926 WO2020212610A1 (en) 2019-04-18 2020-04-17 Method and system for selective broadcasting
PCT/EP2020/060925 WO2020212609A1 (en) 2019-04-18 2020-04-17 Secure medical data analysis for mobile devices
PCT/EP2020/060927 WO2020212611A1 (en) 2019-04-18 2020-04-17 Method and system for transmitting combined parts of distributed data

Family Applications After (3)

Application Number Title Priority Date Filing Date
PCT/EP2020/060926 WO2020212610A1 (en) 2019-04-18 2020-04-17 Method and system for selective broadcasting
PCT/EP2020/060925 WO2020212609A1 (en) 2019-04-18 2020-04-17 Secure medical data analysis for mobile devices
PCT/EP2020/060927 WO2020212611A1 (en) 2019-04-18 2020-04-17 Method and system for transmitting combined parts of distributed data

Country Status (1)

Country Link
WO (4) WO2020212604A1 (en)

Citations (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6397224B1 (en) 1999-12-10 2002-05-28 Gordon W. Romney Anonymously linking a plurality of data records
US20020116227A1 (en) 2000-06-19 2002-08-22 Dick Richard S. Method and apparatus for requesting, retrieving, and obtaining de-identified medical informatiion
US20060069957A1 (en) 2004-09-13 2006-03-30 Sangeetha Ganesh Distributed expert system for automated problem resolution in a communication system
US7543149B2 (en) 2003-04-22 2009-06-02 Ge Medical Systems Information Technologies Inc. Method, system and computer product for securing patient identity
US20090150362A1 (en) 2006-08-02 2009-06-11 Epas Double Blinded Privacy-Safe Distributed Data Mining Protocol
US20090326981A1 (en) 2008-06-27 2009-12-31 Microsoft Corporation Universal health data collector and advisor for people
US7823207B2 (en) 2004-04-02 2010-10-26 Crossix Solutions Inc. Privacy preserving data-mining protocol
US20160357173A1 (en) * 2015-06-08 2016-12-08 Evidation Health Evidence Generation and Data Interpretation Platform
US20170161439A1 (en) * 2007-07-03 2017-06-08 Eingot Llc Records access and management
EP3327726A1 (en) * 2016-11-04 2018-05-30 Siemens Healthcare GmbH Anonymous and secure classification using a deep learning network

Family Cites Families (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5660176A (en) 1993-12-29 1997-08-26 First Opinion Corporation Computerized medical diagnostic and treatment advice system
JP2995496B2 (en) * 1995-06-19 1999-12-27 インターナシヨナル・ビジネス・マシーンズ・コーポレーシヨン Method and system for receiving data packets in a unidirectional broadcast system
NL1019277C2 (en) 2001-11-01 2003-05-07 Vivici Device for making a diagnosis.
US20030225597A1 (en) 2002-05-29 2003-12-04 Levine Joseph H. Methods and systems for the creation and use of medical information
US7966368B2 (en) * 2003-05-02 2011-06-21 Microsoft Corporation Communicating messages over transient connections in a peer-to-peer network
US20050086481A1 (en) * 2003-10-15 2005-04-21 Cisco Technology, Inc. Naming of 802.11 group keys to allow support of multiple broadcast and multicast domains
US7433853B2 (en) 2004-07-12 2008-10-07 Cardiac Pacemakers, Inc. Expert system for patient medical information analysis
DE202005012454U1 (en) 2005-08-08 2005-10-20 Bitos Gmbh Mobile medical expert system, e.g. a first aid system, comprises a mobile terminal with a medical expert system software application which can connect to a central database via wireless communications for information exchange
US10410308B2 (en) 2006-04-14 2019-09-10 Fuzzmed, Inc. System, method, and device for personal medical care, intelligent analysis, and diagnosis
GB2502750A (en) * 2011-03-22 2013-12-04 Nant Holdings Ip Llc Healthcare Management objects
WO2014116968A1 (en) 2013-01-25 2014-07-31 Vanderbilt University Smart mobile health monitoring system and related methods
WO2016044920A1 (en) * 2014-09-23 2016-03-31 Surgical Safety Technologies Inc. Operating room black-box device, system, method and computer readable medium
US11616825B2 (en) * 2015-12-18 2023-03-28 Aetna Inc. System and method of aggregating and interpreting data from connected devices

Patent Citations (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6397224B1 (en) 1999-12-10 2002-05-28 Gordon W. Romney Anonymously linking a plurality of data records
US20020116227A1 (en) 2000-06-19 2002-08-22 Dick Richard S. Method and apparatus for requesting, retrieving, and obtaining de-identified medical informatiion
US7543149B2 (en) 2003-04-22 2009-06-02 Ge Medical Systems Information Technologies Inc. Method, system and computer product for securing patient identity
US7823207B2 (en) 2004-04-02 2010-10-26 Crossix Solutions Inc. Privacy preserving data-mining protocol
US20060069957A1 (en) 2004-09-13 2006-03-30 Sangeetha Ganesh Distributed expert system for automated problem resolution in a communication system
US20090150362A1 (en) 2006-08-02 2009-06-11 Epas Double Blinded Privacy-Safe Distributed Data Mining Protocol
US20170161439A1 (en) * 2007-07-03 2017-06-08 Eingot Llc Records access and management
US20090326981A1 (en) 2008-06-27 2009-12-31 Microsoft Corporation Universal health data collector and advisor for people
US20160357173A1 (en) * 2015-06-08 2016-12-08 Evidation Health Evidence Generation and Data Interpretation Platform
EP3327726A1 (en) * 2016-11-04 2018-05-30 Siemens Healthcare GmbH Anonymous and secure classification using a deep learning network

Also Published As

Publication number Publication date
WO2020212611A1 (en) 2020-10-22
WO2020212609A1 (en) 2020-10-22
WO2020212610A1 (en) 2020-10-22

Similar Documents

Publication Publication Date Title
US20220050921A1 (en) Systems and methods for functionally separating heterogeneous data for analytics, artificial intelligence, and machine learning in global data ecosystems
US11616825B2 (en) System and method of aggregating and interpreting data from connected devices
US11688015B2 (en) Using de-identified healthcare data to evaluate post-healthcare facility encounter treatment outcomes
US10348699B2 (en) Identity binding systems and methods in a personal data store in an online trust system
US9361481B2 (en) Systems and methods for contextualized data protection
US20180343120A1 (en) Systems and methods for providing a universal decentralized solution for verification of users with cross-verification features
US10454901B2 (en) Systems and methods for enabling data de-identification and anonymous data linkage
US20160188805A1 (en) Privacy compliant consent and data access management system and methods
US11710132B2 (en) User controlled event record system
US20230054446A1 (en) Systems and methods for functionally separating geospatial information for lawful and trustworthy analytics, artificial intelligence and machine learning
US20060293925A1 (en) System for storing medical records accessed using patient biometrics
van den Braak et al. Trusted third parties for secure and privacy-preserving data integration and sharing in the public sector
US10622104B2 (en) System and method utilizing facial recognition with online (social) network to access casualty health information in an emergency situation
CA3104119A1 (en) Systems and methods for enforcing privacy-respectful, trusted communications
EP4026135B1 (en) System for protecting and anonymizing personal data
US20210035666A1 (en) Integrating distributed systems using biometric identification
US20230077823A1 (en) System and method to access casualty health information in an emergency situation
WO2020212604A1 (en) Method and system for selectively transmitting data
Syed et al. API driven on-demand participant ID pseudonymization in heterogeneous multi-study research
Lynda et al. Data security and privacy in e-health cloud: Comparative study
El et al. A mobile crowd sensing framework for suspect investigation: an objectivity analysis and de-identification approach
US20210056563A1 (en) Biometric medical proxies
US20230153242A1 (en) Biometric caching
US20240005719A1 (en) Distributed biometric identity system enrollment with live confirmation
CN115277083A (en) Data transmission control method, device, system and computer equipment

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 20717072

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

32PN Ep: public notification in the ep bulletin as address of the adressee cannot be established

Free format text: NOTING OF LOSS OF RIGHTS PURSUANT TO RULE 112(1) EPC (EPO FORM 1205A DATED 23/02/2022)

122 Ep: pct application non-entry in european phase

Ref document number: 20717072

Country of ref document: EP

Kind code of ref document: A1