[go: up one dir, main page]

EP3657508A1 - Systèmes et procédés de recrutement sécurisés - Google Patents

Systèmes et procédés de recrutement sécurisés Download PDF

Info

Publication number
EP3657508A1
EP3657508A1 EP18462005.2A EP18462005A EP3657508A1 EP 3657508 A1 EP3657508 A1 EP 3657508A1 EP 18462005 A EP18462005 A EP 18462005A EP 3657508 A1 EP3657508 A1 EP 3657508A1
Authority
EP
European Patent Office
Prior art keywords
server
database
data
person
query
Prior art date
Legal status (The legal status 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 status listed.)
Withdrawn
Application number
EP18462005.2A
Other languages
German (de)
English (en)
Inventor
Christopher Joseph Farkas
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Healcloud Kft
Original Assignee
Healcloud Kft
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 Healcloud Kft filed Critical Healcloud Kft
Priority to EP18462005.2A priority Critical patent/EP3657508A1/fr
Priority to EP19891678.5A priority patent/EP3884495A2/fr
Priority to PCT/EP2019/082313 priority patent/WO2020135951A2/fr
Publication of EP3657508A1 publication Critical patent/EP3657508A1/fr
Withdrawn legal-status Critical Current

Links

Images

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
    • G16H10/00—ICT specially adapted for the handling or processing of patient-related medical or healthcare data
    • G16H10/60—ICT specially adapted for the handling or processing of patient-related medical or healthcare data for patient-specific data, e.g. for electronic patient records
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/10—Office automation; Time management
    • G06Q10/105—Human resources
    • G06Q10/1053—Employment or hiring

Definitions

  • the present invention relates to secure recruitment systems and methods, in particular secure patient recruitment systems and methods for real world evidence (RWE) information collection, through schemes of extracting and managing personal data records.
  • RWE real world evidence
  • the document US 2005/0236474 A1 discloses a system for processing patient health information (PHI) while protecting the confidentiality of PHI to achieve regulatory compliance.
  • the PHI contains patient medical data and associated patient identification data.
  • a de-identification agent extracts patient medical data and creates de-identified patient information.
  • a key is generated that allows subsequent re-association of the patient medical data and the patient identification data.
  • the de-identified patient data base may be queried for patient screening purposes. Patient queries are processed only if the study or patient screening has been authorized by appropriate authorities (i.e., medical personnel). Patients whose medical characteristics conform with the patient query are selected for possible use in a study. If re-identification of the selected patients is necessary and authorized, the key may be used to provide the necessary re-association between the patient medical data and the respective patient identification data.
  • One of the drawbacks of the above system is that is does not provide a global data management for a particular patient who is treated in various health care sites, such as hospitals, clinics, physicians, etc. Due to the lack of a method to uniquely identify patients in the overall system, it is impossible to provide a global, holistic view of a patient on the basis of multiple patient medical records collected from various health care entities.
  • a further drawback of the above system is that the keys and the associated pieces of identification information are permanently stored together in a key file which may be thus exposed to a malicious attack.
  • a first computer-implemented method of identifying a person of interest in a computerized recruitment system comprising a first server, a second server, a first database containing, for each person, a plurality of data records formed of application-specific person-related data and personally identifiable data associated with said person-related data, and a second database containing a plurality of de-identified data records, said second database being consistent with said first database, the method comprising:
  • a second computer-implemented method of identifying a person of interest in a computerized recruitment system comprising a first server, a second server, a first database containing, for each person, a plurality of data records formed of application-specific person-related data and personally identifiable data associated with said person-related data, and a second database containing a plurality of de-identified data records, said second database being consistent with said first database, the method comprising:
  • a first computerized recruitment system for identifying a person of interest comprising:
  • a second computerized recruitment system for identifying a person of interest comprising:
  • the present invention may be applied across a broad range of industries, e.g., in life sciences, insurance, financial services, social media and human resources.
  • the present invention enables life science researchers to access both retrospective and prospective medical data in a secure, auditable and legally compliant way, facilitating the selection of matching patients for early phase clinical trials and supporting RWE information collection for observational trials.
  • the present invention allows researchers to see the entirety of patient pathways, i.e. the health status and treatment history of a given patient across various healthcare institutions.
  • the computer systems and methods of operation described herein may be used to provide multiple levels of security and access to patient data. Access to patient data in a legally compliant manner is particularly important for patient identification and selection for the purpose of clinical trials and late phase observational studies. Although concern for patient privacy has always been an issue, the personal privacy in a broader sense has an increasing importance in many other fields like employment agencies, social networking services, etc, wherein sensitive personal data are stored and used for various purposes.
  • Sensitive personal information refers to any kind of personal information that is considered confidential and must therefore be protected. Sensitive personal information refers to any personally identifiable data, i.e. information that is directly or indirectly indicative to a person's identity.
  • personally identifiable data record should in particular be understood to mean data records that contain application-specific information and personally identifiable data about a person who is registered in a source database.
  • the personally identifiable data records are patient data records kept by one or more health institutions, in particular hospitals.
  • de-identification routine shall be understood as a routine intended to remove or mask, if appropriate, personally identifiable information from a registered person's data record.
  • the de-identification routine may remove further data deemed appropriate by a person skilled in the art, which indirectly suggests the identity of the registered person and / or which is unnecessary for recruitment, from the personally identifiable data record.
  • the de-identification routine may add one-to-one pseudonym information to the personally identifiable data records.
  • search result refers to the information intended to convey to the user a result of his or her research.
  • the search result preferably comprises at least the application-specific information and/or personally identifiable data.
  • the search result preferably has at least information about a number of the personally identifiable data records found.
  • a "source database” is to be understood as meaning in particular a means of the recruitment system which is intended to permanently store the personally identifiable data records of the registered persons.
  • the source database is typically designed as a database that appears appropriate to a person skilled in the art, for example as an SQL database or as an object-oriented database.
  • FIG. 1 illustrates a schematic block diagram of the first embodiment of a recruitment system 100 according to a first aspect of the present invention.
  • the recruitment system 100 comprises a first server 110, a second server 120 and a source database 130.
  • the first server 110 and the second server 120 communicate to each other through a first communication subsystem 140, whereas the second server 120 and the source database 130 communicate to each other through a second communication subsystem 142.
  • the first and second communication subsystems 140, 142 are formed by a communication network, like the internet or an intranet.
  • multiple first servers 110 may be connected to the second server 120 and multiple source databases 130 may be coupled to the second server 120 to form a highly distributed recruitment system.
  • only the first communication subsystem 140 is provided by a communication network, while the second communication subsystem 142 is a dedicated communication line between the second server 120 and the source database 130.
  • This latter configuration is typical in the case where the source database 130 is arranged at the same site (e.g. hospital, employment agency, etc.) where the second server 120 is operating.
  • Figure 1 depicts only one first server 110, one second server 120 and one source database 130, the recruitment system 100 may include any number of these entities.
  • the actual configuration of the system 100 may depend on the specific field of application and is assumed obvious for those skilled in the art.
  • the first server 110 comprises a query composer 112 adapted for creating and managing search queries.
  • a search query is preferably composed of a plurality of fields, each field relating to a searchable data element of the personally identifiable data records stored in the database 130.
  • the search fields may specify a particular numeric value, a range of numeric values, a code of a personal feature, a string or a text element, etc.
  • the first server 110 further comprises a de-identified data storage 114 adapted for storing de-identified data records resulting from a search.
  • the first server further comprises a selection module 116 allowing a user to select one or more de-identified data records from among the de-identified data records stored in the data storage 114 and to send an identifier of each selected data records to the second server 120 for re-identification.
  • the second server 120 comprises a search engine 122, a de-identification engine 124, a search result data storage 126 and a re-identification module 128.
  • the search engine 122 is configured to receive a query from the first server 110 and to forward the query to a local source database 130 through a dedicated communication line or to a remote source database 130 via a communication network, e.g. internet, to find personally identifiable data records that match the query.
  • the search engine 122 is further configured to receive the matching data records as search results containing personally identifiable data and to forward them to the search result data storage 126 and the de-identification engine 124.
  • the de-identification engine 124 is adapted for running a de-identification routine to produce de-identified data records from the search results and to generate an anonymous ID for each search result.
  • the anonymous IDs are also permanently stored in the search result data storage 126 together with the associated identifiable data records.
  • the re-identification module 128 is adapted for receiving the one or more selected anonymous IDs from the first server 110 and to retrieve the corresponding data records from the search result data storage 124 for presenting the retrieved identifiable data records to an authorized person.
  • a query is specified by the user, e.g., a researcher of a health institute, a recruitment administrator of a company, etc., at the first server 110 for searching persons of interest in the application-specific source database 130.
  • application-specific person-related data and personally identifiable data associated with the application specific data are stored in the form of data records in the database 130.
  • a unique query ID is generated so that the queries can be managed at the first server 110 and tracked throughout the system 100.
  • the full content of the executed queries and the associated query IDs are preferably stored at the first server 110 in a query storage 113.
  • a query may be composed of multiple search fields specifying the actual values for various search parameters.
  • the query is forwarded to the search engine 122 of the second server 120 in step 210.
  • the search engine 122 is configured to perform searches in any one or more of the source databases 130 coupled to the second server 120 and to receive the search result from the source database 130 currently used.
  • step 220 application-specific person-related data and associated personally identifiable information are obtained from the application-specific source database 130 based on the query.
  • the returned data records relating to at least one person of interest together form a set of search results.
  • step 230 the currently received identifiable search results are stored in the search result data storage 126 of the second server 120. It means that any authorized operator of the second server 120 can access to and view the search results stored at the second server 120.
  • the search results are then also subject to de-identification in step 240, resulting in a set of de-identified data records in which the application-specific person-related data remains unchanged or is subject to masking so that the end users will be able to analyze the content of these data, while the personally identifiable data records is de-identified so that the end users be unable to directly identify or even guess the identity of the persons of interest who are associated with the de-identified data records.
  • a record ID is generated, which uniquely identifies a de-identified data record stored in the search result data storage 126.
  • the record IDs and the corresponding query IDs are also stored in the search result data storage 126 together with the de-identified data records.
  • a particular combination of a query ID and a record ID uniquely identify one data record in the overall system.
  • a unique anonymous ID may be generated for each person of interest whose data record has been returned as a search result.
  • the anonymous ID is generated according to an algorithm that produces the same anonymous ID for a given person whose data records are stored in more than one source database 130.
  • This scheme allows a global (or holistic) view of the patient pathways of individuals registered in various source databases 130. For example, when a patient has medical records at different hospitals where he or she has been treated with different diseases, his or her anonymous ID will always be the same for any de-identified data record obtained from different hospital databases.
  • the de-identified data records may also be stored together with the respective anonymous IDs in a de-identified data storage 127 at the second server 120 for also allowing certain operators of the second server 120 to access to and use the de-identified data records for statistical, business or other purposes.
  • the de-identified data records as search results, along with the associated record identifiers, like the pairs of a query ID and a record ID, or an anonymous ID alone, are sent to the first server 110 for further processing by the end user.
  • the end user of the first server 110 selects, by means of the selection module 116, at least one de-identified data record from among the de-identified data records received as a set of search results.
  • the selection from the data records may be based on specific recruitment criteria applied by the end user of the first server 110.
  • the query can be specified in a rather sophisticated way and the filtering criteria can be set to precisely define the required features of the persons of interest, it is expected that all of the search results relate to appropriate persons of interest and therefore the selection procedure results in the selection of all data records.
  • the end user may apply further selection criteria for the search results to select a subset of the de-identified data records for re-identification.
  • the end user sends, by means of the selection module 116, the identification data of the selected at least one de-identified data record from the first server 110 to the second server 120 in step 270.
  • the identification data of the selected de-identified data records may include the query ID and the record ID, or simply the anonymous ID belonging to the selected data records.
  • the identifier of the selected de-identified data records are received by the re-identification module 128, which retrieves the respective search result data records (stored in an identifiable form) from the search result data storage 126 for presentation to an authorized operator of the second server 120 in step 280.
  • the re-identification module 128 is configured to present personally identifiable information (e.g. name, contact information, consents, etc.) of the selected persons of interest.
  • the authorized operator of the second server 120 can then directly contact the persons of interest to inform them about the final result of the recruitment process and the further steps of cooperation.
  • Figure 3 illustrates a second embodiment of the system according to the first aspect of the invention.
  • This embodiment corresponds to a specific computer-implementation of the above described system in the medical field for a clinical trial recruitment scheme.
  • the recruitment system 200 comprises additional modules and data storages to provide further functions with respect to the first embodiment of the system described with reference to Figure 1 for allowing an even more flexible and more secure operation of a clinical trial patient recruitment system according to the invention.
  • the recruitment system 300 includes at least one first server 310, at least one second server 320 and at least one database server 340, only one entity of them, respectively, is illustrated in Figure 3 .
  • the first server 310 is operated by the end user, for example a researcher of a clinical research organization.
  • the first server 310 may include a Researcher Dashboard 311, a Heatmap and Statistical Module 312, a Query Manager 313, a Query Builder Module 314, a Custom Mapping handler 315, a Data Storage 316 and a Communication Gateway 317.
  • the Researcher Dashboard 311 may be configured to allow a researcher to build and edit queries with the Query Builder Module 314, to manage query statuses and to request query execution with the Query Manager 313, to create special queries/requests using the Heatmap and Statistics Module 312 and to manage custom data mappings for the queries using the Custom Mapping Handler 315.
  • the query requests/query versions are stored in the Data Storage 316, more particularly in its Query Database 316a.
  • the Communication Gateway 317 preferably uses asymmetric encryption for the communication data flow.
  • the incoming query requests (e.g., query packages) sent by the first server 310 are stored in the Data Storage 324, in particular in its Query Storage 324a.
  • the query requests can be accessed to and processed by an authorized user of the second server 320, for example a Medical Officer and/or an IT Administrator by means of a Medical Officer Dashboard 321 and IT Administrator Dashboard 322, respectively.
  • the Medical Officer may execute or reject the query request using the Medical Officer Dashboard 321.
  • the Custom Mapping Resolver 329 may be configured to allow an authorized user of the second server 320 to use customized code lists to facilitate query building.
  • the Search Engine 331 may be configured to divide the original query into fragments which can be processed by the database server 340.
  • the Search Engine 331 generates a set of queries based on the query request sent by the researcher and determines which database records or what statistical data are to be returned to the researcher.
  • the Search Engine 331 may also be configured to form the resulting data sets according to a predetermined format.
  • the queries are sent from the second server 320 through an Authentication and Communication Module 332 to the Database Server 340, in which the queries are received using a Data Access Application Programming Interface (API) 342 operatively coupled to the Source Database 341.
  • API Application Programming Interface
  • All resulting data sets read from the Source Database 341 are converted into a predetermined format by the Conversion Module 328 and then stored in the Data Storage 324, more particularly in the PID (personally identifiable data) Results Database 324b. These data are accessible for the authorized operators of the second server 320 via the Medical Officer Dashboard 321. In case of statistical data queries, the resulting data sets are subject to pre-processing, enabling the researcher to receive only statistical information gained from the query results.
  • resulting data sets are then de-identified using the De-identification Engine 325 and also forwarded to the Data Storage module 324, more particularly to the Non-PID Results Database 324c. These de-identified data sets may be monitored by an authorized person through the IT Administrator Dashboard 322.
  • the Medical Officer as an authorized operator of the second server 320, may release or deny the queried data via the Medical Officer Dashboard 321.
  • an IT Administrator of the second server 320 may monitor the de-identified data sets using the IT Administrator Dashboard 322.
  • the de-identified data sets are forwarded from the second server 320 through the Communication Gateway 327 to the first server 310, in which the de-identified data sets are received by the Communication Gateway 317 and then stored in the Data Storage 316, more particularly in the Query Results Storage 316b.
  • the researcher can access the de-identified data sets through the Researcher Dashboard 310.
  • the query package formed by the Query Builder Module 314 may be a descriptor file that captures all information required to run the data query, namely the search criteria (inclusion /exclusion fields), custom mappings, the requested result configuration, and the scope of the requested query results / resources.
  • the query packages may be represented in JSON format and edited using the query Builder Module 314.
  • the various entities of the first server 310 allow to easily re-define the inclusion and exclusion criteria for the search. For example, the protocol requirements may be easily transformed into query search parameters with a technical descriptor. Such a descriptor is communicated through the system and only its status changes throughout the process.
  • the Custom Mapping Handler 315 may be configured to allow the researcher to query clinical research sites' medical databases (Source Database 341) not only by using the nomenclature of the international medical code systems (e.g., ICD 10, SNOMED, LOINC, etc.), but also to search in free text format or via any local medical code bases as well. In this way the Custom Mapping Handler 315 preferably allows to establish logical correspondence between various medical code systems.
  • free text tags / terms related to a specific disease e.g. 'hypertension'
  • custom values may appear on the Researcher Dashboard 311 as follows:
  • the array is saved and forms a part of the researcher's custom code lists in the system, allowing the researcher to easily use it in future queries.
  • the Custom Mapping Resolver 329 builds up elementary queries based on the incoming custom fields and values.
  • the aforementioned free text search capability allows the researcher to search for partial code strings or tags within a specific Source Database 341.
  • the Query Builder Module 314 allows the researcher to locate all fields that contain the given expression in a given Source Database 341.
  • the Custom Mapping Handler 315 may be configured to collect the individual disease codes into logically cohesive groups defined as custom fields / arrays. This approach can be applied to other resources as well, for example, in the case of either medications or substances.
  • the second server 320 starts assembling a final query result set that may be represented in a standard JSON format and then converted into a specific data structure as indicated below.
  • each item of the list represents a single resource.
  • the researcher may define which resources are needed for his or her research purposes to help avoid overloading the servers and the communication channels unnecessarily.
  • the nodes of the unselected resources should be left empty.
  • the query results may further contain administrative and generic information as well, including, for example, the server's version and IP address, potential error code, the number of returned elements (e.g. number of patients of interest), and the unique identifiers of the resulting data records.
  • the above example illustrates a comprehensive query, meaning that the entire patient health graph is requested for research. Besides this, there may be other types of queries, like statistical queries and heatmap queries.
  • the statistical queries return the number of unique patients for a specific set of search criteria (along with the number of available resources at each resource grouping).
  • the heatmap queries provide the researcher with a high level summary of the data available at a given Source Database 341, in particular the number of unique diagnoses, organized by the ICD-10 code, for example. In these special cases, the query results appear in the same structure, but the 'DetailedPatients' node is empty and, instead, the 'SiteHeatmap' or the 'SiteStatistics' node is populated.
  • the Conversion Module 328 and the Export Module 326 may be configured to transform the data query results into research-optimized formats to which the researchers are accustomed.
  • the Conversion Module 328 and the Export Module 326 together serve as an output data connector of second server 320.
  • the conversion and export functionality may support the JSON format, which is a standardized structured textual output format.
  • the assembled result set may be converted to the researcher's proprietary data model or OMOP CDM v5.0.1 mapping, for example.
  • the conversion algorithms can easily be adjusted to serve other data models as well.
  • the De-identification Engine 325 of the second server 320 may be configured to automatically and irreversibly de-identify personally identifiable data within (or as an extension to) the IT infrastructure of the second server 320, thus ensuring patient privacy at all times, as required by the respective legal regulations, for example the international standard ISO 25237:2017 on Health informatics (Pseudonymization).
  • the query IDs may be generated by the Query Manager 312 of the first server 310, the record IDs of the records returned in response to a given query may be generated by the Search Engine 331 of the second server 320.
  • the resulting data sets may be identified by unique anonymous IDs of the respective persons (e.g. patients), wherein the anonymous IDs are generated by the De-identification Engine 325.
  • FIG. 4 illustrates a schematic block diagram of a third embodiment of the recruitment system according to a second aspect of the present invention.
  • a first server 420 a second server 410, a first database 430 containing a plurality of identifiable data records formed of application-specific person-related data and personally identifiable information, and a second database 440 containing a plurality of de-identified data records generated and updated on the basis of said first database 430.
  • the identifiable data records of the first database 430 are stored without de-identification and only an authorized person of the first server 420 can access and use the content of the first database 430.
  • This first database 430 may be an integral part of the first server 420, or may be coupled to the first server through a dedicated communication line or a communication subsystem, when the first database 430 is a local database residing at the site of the first server 420, or in some embodiments, the first database 430 may be connected to the first server 420 via a public communication network, like the internet, or a private communication network, like an intranet, when the first database 430 is not an integral part of the first server 420 or it is remote from the first server 420.
  • the de-identified data records of the second database 440 are periodically updated on the basis of the first database 430 and can be accessed only by an authorized user, e.g., a researcher, of the second server 410.
  • the second database 440 is preferably arranged as an integral part of the second server 410, but it may also be remote from the second server 410. In this latter case, the second database 440 may be connected to the second server 410 via a communication subsystem, for example a public or private communication network.
  • the second server 410 further comprises at least a query composer 412, a search engine 414 and a query manager 416.
  • the query composer 412 is configured to provide a user interface for specifying queries for a search in the de-identified database 440 using the search engine 414.
  • the query manager 416 is adapted for managing the queries, in particular for storing the executed queries and sending the current query to the first server 420 for the identification of the persons of interest.
  • the query manager 416 is also adapted for receiving the de-identified data records resulted from a search performed by the search engine 414 based on a particular query.
  • the resulted de-identified data records may be presented to an authorized person, e.g. a researcher, of the second server 410 for deciding whether the query is appropriate for sending it to the first server 420 for re-identifying one or more persons of interest.
  • the selection module is configured to obtain the identifiable data records from the source database, i.e. the first database 430, by means of a search engine 424 using the currently received query, and for presenting the identifiable data records for an authorized person of the first server 420, e.g., hospital physician, therapeutist, etc.
  • the first server 420 further comprises a de-identification engine 426 that is configured to monitor the first database 430 and in case of any modification of the first database 430, e.g., addition of a new data record, modification of any element of an existing data record, removal of a data record, etc., to update the content of the de-identified database 440 coupled to the second server 410. Updating includes the generation of a new de-identified data record on the basis of a new or modified data record of the first database 430, or removal of a de-identified data record from the second database 440 upon removal of the corresponding personally identifiable data record from the first (source) database 430.
  • a de-identification engine 426 that is configured to monitor the first database 430 and in case of any modification of the first database 430, e.g., addition of a new data record, modification of any element of an existing data record, removal of a data record, etc., to update the content of the de-identified database 440 coupled to the second server 410.
  • Figure 5 illustrates a flow diagram including the essential steps of the method.
  • Those terms used in relation with Figure 5 which are the same as used in relation with Figure 2 , have the same meaning unless otherwise defined.
  • a query for searching persons of interest in the de-identified database 440 is specified at the second server 410.
  • the query may be specified using the query composer 412 and can be stored in the query manager 416 for future reference.
  • de-identified data records are obtained from the de-identified database 440 based on the query.
  • This step includes forwarding the query to the search engine 414 of the second server 410, which performs searching for de-identified data records in the de-identified database 440 based on the query, and sending the resulted one or more de-identified data records, if any, from the search engine 414 to the query manager 416.
  • the corresponding query is forwarded to the first server 420 for obtaining the respective identifiable data records. If there is no matching data record in the de-identified database 440, the user of the second server 410 may be prompted to modify the query or to specify a new query.
  • the at least one identifiable data record matching the query is retrieved from the source database 430 by means of the search engine 424 of the first server 420 in step 520.
  • the resulted data records are then returned to the selection module 422, which may present the respective personally identifiable records to an authorized user of the first server 420.
  • step 530 at least one person of interest is re-identified based on the at least one data record obtained from the first (source) database 430.
  • the de-identified database 440 of the second server 410 always be consistent with the first source database 430 coupled to the first server 420 and containing personally identifiable data records.
  • the de-identification engine 426 is responsible for maintaining the consistency between the two databases 430, 440.
  • the personally identifiable information of at least one person of interest may be obtained from the identifiable data record of the given person and may be communicated to the second server for further use by an end user of the second server who is authorized to use said personal data to contact the respective person for the purpose of his or her involvement in the recruitment program, like a clinical trial patient recruitment program.
  • Figure 6 illustrates a fourth embodiment of the system according to the second aspect of the invention.
  • This embodiment corresponds to a specific computer-implementation of the system in the medical field for a clinical trial recruitment scheme.
  • the recruitment system 600 comprises a first server 620 and a second server 610 that are connected via the Internet 680.
  • the secure communication between the first and second server 610, 620 over the Internet 680 is provided by the Communication Gateways 618 and 628, respectively.
  • the first server 620 which is operated, for example, by a physician comprises a Physician User Interface 622, a Query Module 624, a De-Identification Engine 626, a Communication Gateway 628 and a Personal & Health Database 630 serving as a source database for storing identifiable data records.
  • the second server 610 which is operated by an end-user, for example a researcher of a clinical research organization, comprises a Query Module 612, a researcher User Interface 616, a Research Optimized Database 640, a Raw Data Storage 642, a Conversion Module 642 and a Communication Gateway 618.
  • the Research Optimized Database 640 functions as the de-identified database in which persons of interest are searched for by an authorized person of the second server 610 based on a particular query.
  • Figure 7 is a flow diagram including the main steps of the method of identifying a person of interest using the system of Figure 6 .
  • the physician uses the first server 620 and its Personal & Health Database 630 to manage the data records of the database by means of the Physician User Interface 622.
  • Managing the data records may include addition of new data records of new patients, modification of any one of the existing data records of patients having already registered in the database, or eventually removal of any one of the data records if needed.
  • the Anonymization Engine 626 automatically generates an updated data record and de-identifies the updated data record in step 710.
  • the updated de-identified data record is then sent to the Raw Data Storage 642 of the second server 610 and stored therein in step 720.
  • the Raw Data Storage 642 is always maintained consistent with the source database, i.e. the Personal & Health Database 630 and it works as a de-identified mirrored database of the source database.
  • step 730 the updated data records of the Raw Data Storage 642 are processed by the Conversion Module 644 to produce research-optimized data records for facilitating the search in the second server 610 operated by a researcher.
  • the de-identified research-optimized data records are stored in the Research Optimized Database 640 serving as the de-identified database in which the researcher searches using a given query.
  • the queries are specified by the researcher using the Query Module 612 in step 740.
  • Matching research-optimized data records are retrieved from the Research Optimized Database 640 in step 750.
  • the appropriate query will be sent to the first server 620 via the Internet 680.
  • the query is received by the Query Module 624, which based on the query, obtains the matching identifiable data records from the Personal & Health Database 630 in step 760.
  • the retrieved data records are then forwarded to the physician through the Physician User Interface 622 so that the physician can re-identify the person(s) of interest on the basis of the identifiable data record(s) thus obtained, and then contact the identified persons to inform them on the possibility of their involvement in the recruitment procedure of the clinical trials or other research.
  • the search for the persons of interest is directly carried out once in the identifiable source database (first database), whereas in the second aspect, the search is first carried out in the de-identified database (second database) and then once more, in the source database (first database) for the re-identification of the persons of interest.

Landscapes

  • Business, Economics & Management (AREA)
  • Human Resources & Organizations (AREA)
  • Engineering & Computer Science (AREA)
  • Strategic Management (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Tourism & Hospitality (AREA)
  • Theoretical Computer Science (AREA)
  • Marketing (AREA)
  • Operations Research (AREA)
  • Quality & Reliability (AREA)
  • Data Mining & Analysis (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Economics (AREA)
  • Health & Medical Sciences (AREA)
  • Epidemiology (AREA)
  • General Health & Medical Sciences (AREA)
  • Medical Informatics (AREA)
  • Primary Health Care (AREA)
  • Public Health (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
EP18462005.2A 2018-11-23 2018-11-23 Systèmes et procédés de recrutement sécurisés Withdrawn EP3657508A1 (fr)

Priority Applications (3)

Application Number Priority Date Filing Date Title
EP18462005.2A EP3657508A1 (fr) 2018-11-23 2018-11-23 Systèmes et procédés de recrutement sécurisés
EP19891678.5A EP3884495A2 (fr) 2018-11-23 2019-11-22 Systèmes et procédés de recrutement sécurisé
PCT/EP2019/082313 WO2020135951A2 (fr) 2018-11-23 2019-11-22 Systèmes et procédés de recrutement sécurisé

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
EP18462005.2A EP3657508A1 (fr) 2018-11-23 2018-11-23 Systèmes et procédés de recrutement sécurisés

Publications (1)

Publication Number Publication Date
EP3657508A1 true EP3657508A1 (fr) 2020-05-27

Family

ID=64901464

Family Applications (2)

Application Number Title Priority Date Filing Date
EP18462005.2A Withdrawn EP3657508A1 (fr) 2018-11-23 2018-11-23 Systèmes et procédés de recrutement sécurisés
EP19891678.5A Pending EP3884495A2 (fr) 2018-11-23 2019-11-22 Systèmes et procédés de recrutement sécurisé

Family Applications After (1)

Application Number Title Priority Date Filing Date
EP19891678.5A Pending EP3884495A2 (fr) 2018-11-23 2019-11-22 Systèmes et procédés de recrutement sécurisé

Country Status (2)

Country Link
EP (2) EP3657508A1 (fr)
WO (1) WO2020135951A2 (fr)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11688496B2 (en) * 2020-04-03 2023-06-27 Anju Software, Inc. Health information exchange system

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050236474A1 (en) 2004-03-26 2005-10-27 Convergence Ct, Inc. System and method for controlling access and use of patient medical data records
US20110112970A1 (en) * 2009-11-06 2011-05-12 Advanced Business Services Corporation System and method for securely managing and storing individually identifiable information in web-based and alliance-based networks using a token mechanism
US20160147945A1 (en) * 2014-11-26 2016-05-26 Ims Health Incorporated System and Method for Providing Secure Check of Patient Records
US20160283745A1 (en) * 2013-11-01 2016-09-29 Anonos Inc. Systems and methods for anonosizing data

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8037052B2 (en) * 2006-11-22 2011-10-11 General Electric Company Systems and methods for free text searching of electronic medical record data
US10607726B2 (en) * 2013-11-27 2020-03-31 Accenture Global Services Limited System for anonymizing and aggregating protected health information

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050236474A1 (en) 2004-03-26 2005-10-27 Convergence Ct, Inc. System and method for controlling access and use of patient medical data records
US20110112970A1 (en) * 2009-11-06 2011-05-12 Advanced Business Services Corporation System and method for securely managing and storing individually identifiable information in web-based and alliance-based networks using a token mechanism
US20160283745A1 (en) * 2013-11-01 2016-09-29 Anonos Inc. Systems and methods for anonosizing data
US20160147945A1 (en) * 2014-11-26 2016-05-26 Ims Health Incorporated System and Method for Providing Secure Check of Patient Records

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
ANONYMOUS: "Salt (cryptography) - Wikipedia", 15 December 2016 (2016-12-15), XP055451140, Retrieved from the Internet <URL:https://en.wikipedia.org/w/index.php?title=Salt_(cryptography)&oldid=755023716> [retrieved on 20180214] *

Also Published As

Publication number Publication date
WO2020135951A3 (fr) 2020-08-13
EP3884495A2 (fr) 2021-09-29
WO2020135951A2 (fr) 2020-07-02

Similar Documents

Publication Publication Date Title
US8037052B2 (en) Systems and methods for free text searching of electronic medical record data
US7543149B2 (en) Method, system and computer product for securing patient identity
US8032545B2 (en) Systems and methods for refining identification of clinical study candidates
CA2564307C (fr) Algorithmes de mise en correspondance d&#39;enregistrements de donnees pour base de donnees longitudinales au niveau patient
JP5008003B2 (ja) 患者の再識別のためのシステムおよび方法
US20080010254A1 (en) Systems and methods for enrollment of clinical study candidates and investigators
US20210057064A1 (en) Systems and methods for federated searching and retrieval of medical records across disparate databases
CA2590938A1 (fr) Systemes et methodes pour l&#39;identification de candidats d&#39;etude clinique
CA2590752A1 (fr) Systemes et methodes pour l&#39;identification et/ou l&#39;evaluation de preoccupations de securite liees a une therapie medicale
US20140058756A1 (en) Methods and apparatus for responding to request for clinical information
US20230162825A1 (en) Health data platform and associated methods
CA2564317C (fr) Chiffrement de donnees assiste pour bases de donnees longitudinales relatives a des patients
EP3657508A1 (fr) Systèmes et procédés de recrutement sécurisés
US20180247702A1 (en) Secure, accurate, and efficient patient intake systems and methods
AU2012200281A1 (en) &#34;Data record matching algorithms for longitudinal patient level databases&#34;
AU2011247850A1 (en) Mediated data encryption for longitudinal patient level databases

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION HAS BEEN PUBLISHED

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

AX Request for extension of the european patent

Extension state: BA ME

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20201128