Managing access to patient consent data

Abstract

The invention relates to a method for managing access to consent data. A first database comprises associations between patient consent data and pseudonymous identifiers, and a second database comprises associations between pseudonymous identifiers and identity information. Upon receiving (210) a first request including an identifier of a patient group, the platform obtains, from the first database, consent data associated with pseudonymous identifiers and grants access (213) to this consent data to a first requesting terminal.Upon receipt (220) of a second request, the platform requests (222) consent to access additional data or patient identity information, at a second terminal (160), and upon receipt (224) of validation of the consent, the platform grants access (236) at the first terminal to the additional consent data and identity information. FIG. 2.

Description

Title of the invention: Management of access to patient consent data

[0001] The present invention belongs to the field of managing access to patient consent data. It relates in particular to a method for managing consent data and a platform capable of ensuring such management.

[0002] It is particularly advantageous when a third party seeks to access patient consent data, in particular in order to audit the consent data and verify that it was obtained in accordance with a given regulation.

[0003] The dematerialization of documents and data also concerns the health sector. It is generally necessary to obtain a patient's consent in order to be able to use personal health data concerning them, in particular for the purposes of research, study and scientific evaluation to include them in research involving the human person.

[0004] A patient's consent data, including a consent status indicating whether the patient accepts or refuses the use of the personal health data corresponding to the consent status, may be stored in a database, with access via a platform to allow the owner of the consent data, the healthcare professional, to be able to consult it when needed.

[0005] It is also possible to provide a platform that centralizes patient consent data for several health professionals.

[0006] However, it is not intended to allow third parties to access consent data collected for patients from healthcare professionals.

[0007] Furthermore, consent data is sensitive data, which cannot be shared with just anyone, especially when it is associated with patient identity information, such as name, address, age, etc.

[0008] It is nevertheless desirable to allow access to consent data for third parties, in particular for a third-party auditor seeking to verify the conformity of the consent data and its management.

[0009] There is thus a need to allow controlled access to patient consent data, for a third party other than the owner of this consent data.

[0010] The present invention improves the situation.

[0011] To this end, a first aspect of the invention relates to a method for managing access to patient consent data implemented by an in- computer science, and including the following operations: • have a first database comprising associations between patient consent data and pseudonymous patient identifiers, and a second database comprising associations between pseudonymous patient identifiers and patient identity information; • upon receipt of a first request from a first terminal requesting access to consent data, the first request comprising an identifier of a group of patients, obtaining from the first database a first set of consent data associated with pseudonymous identifiers, based on the identifier of the group of patients, without querying the second database; • provide access to the first terminal to the first set of consent data obtained from the first database; • upon receipt of a second request from the first terminal to obtain additional consent data and / or identity information of the patient group, request consent from a second terminal from an owner of the consent data of the identified patient group; • if validation of the agreement is received by the second terminal, give the first terminal access to the additional consent data and / or identity information of at least one patient from the identified patient group.

[0012] Thus, the method according to the invention proposes to de-identify the consent data of the patients of a group of patients, in order to allow a third party to access it, initially, without knowing the identity of the patients concerned. However, the first terminal has the possibility of requesting an enrichment of this de-identified consent data, but this enrichment, which may include an identification of the consent data and / or access to additional consent data, is conditioned by an agreement from the owner of the data. Access to the consent data is thus permitted but controlled, with confidentiality management adapted to the sensitivity of the data.

[0013] According to embodiments, the patient group identifier may comprise a study identifier and / or a medical site identifier, and the patient group identifier does not comprise any individual personal information of patients in the group.

[0014] It is thus possible to request patients' consent data without knowing their identity, simply by specifying, in a single request, the medical site or study for which one wishes to consult the consent data. We call “study” means any medical analysis carried out on a group of several patients, particularly for research or diagnostic purposes.

[0015] According to embodiments, in the event of validation of the agreement by the second terminal, the platform can record the agreement in the form of a smart contract in a distributed ledger, and an execution of the agreement by the distributed ledger can cause a query of the first and second databases to identify the consent data of the patients of the identified group of patients, with the identity information of the patients of the identified group of patients, and the platform can give access to the first terminal to the identified consent data of at least one patient of the group of patients, with the identity information of said at least one patient.

[0016] Recording in a distributed ledger, such as a blockchain, ensures the integrity of the stored agreement, allowing subsequent execution with the certainty that the agreement has not been modified in the meantime.

[0017] According to embodiments, the agreement may include at least some of the following elements: - an identifier of a first organization comprising the first terminal and an identifier of a second organization comprising the second terminal; - the patient group identifier; - a duration of access to additional consent data and / or patient group identity information

[0018] Thus, access to consent data is enabled not only on the first terminal, but also on other terminals in the same organization. Furthermore, access can be enabled for a group of patients only, which allows for good granularity in access management. Finally, temporary access is enabled, with control over the duration of access.

[0019] According to embodiments, the second request may be a request to obtain an agreement to access the additional consent data and / or the identity information of the patient group, and, upon receipt of validation of the agreement by the second terminal, the platform may record said agreement locally and / or in a distributed ledger. The method may further comprise receiving a third request to access the additional consent data and / or the identity information of the patient group, the platform and / or the distributed ledger may verify compliance of the third request with the recorded agreement, and, only in the event of compliance of the third request with the recorded agreement, the platform may give access to the first terminal to the additional consent data and / or the identity information of said at least one patient of the identified patient group.

[0020] Thus, the agreement obtained according to the second request can be distinct from the actual access to the data according to the third request. It is thus made possible to conclude an agreement at a given time for a subsequent consultation of the enriched consent data.

[0021] In addition, the verification of conformity of the third request with the agreement may include: - a comparison of an organization identifier from the third request with the first organization identified in the agreement; - a comparison of a required access duration with the access duration; and / or - a comparison between a patient group identifier from the third query and the patient group identifier from the agreement.

[0022] Thus, the third request is authorized only if it complies with the previously concluded agreement. Note that the third request may be more specific than the agreement made, i.e. the third request may request a shorter access duration than the access duration authorized in the agreement, or may access a subset of the patient group authorized in the agreement.

[0023] According to embodiments, for each patient, the consent data stored in the first database may comprise a consent status, information relating to a consent status update history and a consent form, the first set of consent data may comprise the consent statuses of the patients in the identified group, and the additional consent data may comprise the consent status update histories and the consent forms of the patients in the identified group.

[0024] Thus, it is possible to control access to consent data with good granularity, since some consent data is accessible from the first request, while others require agreement from the data owner.

[0025] Additionally, the consent status update history, for each patient, may be stored in a distributed ledger, and the information relating to the consent status update history may be an element of access to the consent status update history in the distributed ledger.

[0026] Thus, the integrity of the consent status update history is ensured, which makes it possible to verify that the consent status stored in the first database has not been modified.

[0027] A second aspect of the invention relates to a computer program comprising instructions for implementing the method according to the first aspect of the invention, when these instructions are executed by a processor.

[0028] A third aspect of the invention relates to a computer platform capable of accessing a first database comprising associations between patient consent data and pseudonymous patient identifiers, and a second database comprising associations between the pseudonymous patient identifiers and patient identity information, the platform comprising: a first interface capable of receiving a first request from a first terminal requesting access to consent data, the first request comprising an identifier of a group of patients; a processor capable of, upon receipt of the first request: - obtaining from the first database a first set of consent data associated with pseudonymous identifiers, based on the patient group identifier, without querying the second database; - providing access to the first terminal to the first set of consent data obtained from the first database; - upon receipt of a second request from the first terminal to obtain additional consent data and / or identity information of the patient group, requesting agreement from a second terminal from an owner of the consent data of the identified patient group, via a second interface; - if validation of the agreement is received by the second terminal, give the first terminal access to the additional consent data and / or identity information of at least one patient from the identified patient group.

[0029] Other characteristics and advantages of the invention will appear on examining the detailed description below, and the appended drawings in which:

[0030] [Fig-1] illustrates a system for managing access to consent data according to embodiments of the invention;

[0031] [Fig.2] is a diagram illustrating the steps of a method for managing access to patient consent data according to embodiments of the invention;

[0032] [Fig.3] illustrates a structure of a platform according to embodiments of the invention.

[0033] [Fig.l] shows a system 10 for managing access to patient consent data, according to one embodiment of the invention.

[0034] The system 10 comprises a platform 100, accessible via a network, such as an IP-type wide area network for example, not shown in [Fig.l]. The operation and structure of the platform 100 will be better understood by reading the following.

[0035] The system comprises a first database 110, capable of storing consent data and allowing access to such consent data to external entities, in particular to the platform 100. The platform 100 may in particular ensure the management of the first database 110.

[0036] Furthermore, according to the invention, the first database 110 stores consent data in association with pseudonymous patient identifiers. A pseudonymous patient identifier is understood to mean any identifier that does not give any indication of the patient's identity. In particular, the pseudonymous identifier does not include any information relating to the patient's name, first name, address, age, weight, or any other identity information. No restrictions are attached to a patient's pseudonymous identifier, which may, for example, take the form of an alphanumeric string.

[0037] "Consent data" refers to data relating to a patient's consent to authorize access to personal health data by third parties, for the purposes of research, studies or diagnosis. Consent data may include, in particular:

[0038] - a consent status. The consent status can be an “accepted” status or a “refused” status. Under the accepted status, the patient authorizes a third party to access certain personal health data concerning him, while under the “refused” status, he refuses the sharing of such personal health data with a third party;

[0039] - a history of updating the consent status, when the patient has the pos ability to dynamically update the consent status. Such a possibility may be enabled by the platform 100, as detailed in the following;

[0040] - a consent form which corresponds to the form by which the patient has indicated the consent status for their personal health data, and any information relating to the assessment of the specific, unequivocal, free and informed nature of the consent. The consent form may include a first time-stamped signature of the patient, and possibly a second time-stamped signature of the healthcare professional who owns the consent data. In particular, the first signature may be prior to the second signature, and may be a condition for obtaining the second signature. The first and second signatures may be electronic signatures.

[0041] Furthermore, the first database 110 may store patient consent data in association with an identifier of a patient group. The patient group may be a group on which a study has been conducted and / or having in common having received care at the same medical site. The identifier of a patient group may thus be an identifier of a study conducted on several patients for example, or may be an identifier of a medical site in which the personal health data of several patients have been obtained. Note that the identifier of the patient group does not individually identify the patients, but identifies either a medical site, a study, or both. The patient group identifier thus does not include any patient identity information of the patient group.

[0042] A second database 111 stores pseudonymous patient identifiers in association with patient identity information. The patient identity information may include, in particular, the information listed above, namely name, first name, address, age, weight, electronic signature, etc.

[0043] The system further comprises a distributed ledger 120, such as a blockchain ledger, more commonly referred to as a Blockchain. The distributed ledger 120 is capable of storing data, timestamping such data and making it impossible to modify them subsequently. Such a ledger 120 is well known and will not be detailed further in the present description.

[0044] At least one consent data item for a given patient may be stored in the distributed ledger. Preferably, the history of updates to consent statuses for a given patient and for certain personal health data of that patient is stored in the distributed ledger. In this case, the first database 110 may not store such a history, but may instead store an element allowing access to the history in the distributed ledger 120. Such an element may be a hash value in particular allowing the history to be found in the distributed ledger.

[0045] This allows for partitioning between the consent data and the identity information of a patient, which allows for better control of access to the consent data of a patient. It is in fact made possible for a third party to access some of the consent data of a patient without, however, allowing access to the identity information of the patient, or to certain other consent data. According to the invention, and as described later, the third party may however request access to all of the consent data identified with the identity information of the patient. This is particularly the case when the third party is an auditor in charge of controlling the consent data, in particular to verify their compliance with a given regulation.

[0046] Note that the consent data associated with a pseudonymous identifier of a patient may comprise several consent statuses respectively associated with several sets of personal health data. The patient can thus give his consent for the sharing of some of his personal health data by associating them with an “accepted” status while he can refuse the sharing of other personal health data by associating them with the “refused” status. Thus, better granularity in the attribution of consent statuses to personal health data can be allowed for the patient.

[0047] The system according to the invention further comprises a first interface 130 for accessing the platform 100. The first access interface 130 is capable of enabling exchanges of data / information between a first terminal 140 and the platform 100.

[0048] No restriction is attached to the first interface 130, which may be a user interface dedicated to an application associated with the platform 100 or to a website allowing access to the platform 100.

[0049] According to the invention, the first terminal 140 is a requesting terminal or third-party terminal, i.e. a terminal of a user wishing to access data stored in at least one of the databases 110 and 111 previously described.

[0050] Access to the services of the platform 100 may be conditioned by an identification / authentication of the third-party user using the first terminal 140, in which case the user is associated with a user account, or a third-party account, on the platform 100. The user of the first terminal may consult some of the consent data in the first database 110 for at least one patient, in particular for a group of patients corresponding to a given medical site and / or study. More specifically, the first interface 130 may present some of the consent data from the first database 110, again noting that this consent data does not allow the user of the first terminal 140 to identify the patient to whom it corresponds. In particular, the consent data of a given patient in the group of patients may be accessible in the form of a sheet, the sheet being able to comprise: - the patient's pseudonymous identifier, not including any patient identity information; - some of the consent data, for example only the consent status for each set of personal health data of the patient. The other consent data, or additional consent data, such as the consent status update history and the consent form may not be accessible on the first interface 130. They may however be made accessible upon request from the first terminal 140 as will be better understood upon reading the description of [Fig.2]; - a group identifier to which the patient is attached. Such a group identifier may include a study name for which consent data was obtained and / or a medical site identifier at which the study was conducted. Several patient records may thus have the same group identifier, when they are patients who contributed to the same study and / or received care at the same medical site;

[0051] - an identifier of an owner of the consent data, the owner being described later.

[0052] Thus, it is made possible to consult certain of the consent data to a third party, for a given study and / or for a given medical site, without communicating to this third party the identity information of the patients or all of the data consent. The management of sensitive data such as consent data relating to medical data is thus improved.

[0053] However, as will be better understood upon reading the description of [Fig.2], the requesting terminal 140 may request, in a second step, access to all of the consent data identified on the basis of the identity information stored in the second database 111.

[0054] The first terminal 140 may be attached to a first organization, for example an organization responsible for auditing consent data for given studies and / or for given medical sites, in order to verify their compliance with a regulation for example.

[0055] The first interface 130 can be shared between several terminals of several given organizations, via an IP network in particular, that is to say that different terminals of third-party users identified as requiring personal consent data, access the platform 100 via the first interface 130. The first terminal 140 is thus any terminal capable of accessing an IP network, such as a touchscreen tablet, a Smartphone, a laptop, a desktop computer, or other.

[0056] The access management system 10 according to the invention may further comprise a second interface 150 for accessing the service platform 100. Such a second interface 150 is accessible by at least one second terminal 160 which is a terminal of a user having rights to personal health data corresponding to at least some of the consent data stored in the databases 110 and 111, or proprietary terminal.

[0057] Note that the personal health data may be stored in another database, not shown in [Fig.l], access to the personal health data not being detailed in the present description. In particular, the personal health data may be stored on a server or a terminal of a second organization to which the second terminal 160 belongs.

[0058] In particular, the second organization may have previously collected the personal health data, then required obtaining consent data for the patients concerned via the platform 100. For example, the second organization may have collected personal health data for a given group of patients, corresponding to a given study and / or a given medical site, and the corresponding consent data were then obtained via the platform 100.

[0059] No restriction is attached to the second terminal 160 which can be any terminal capable of accessing an IP network, such as a touchscreen tablet, a Smartphone, a laptop, a desktop computer, or other.

[0060] In the following, the first organization having the first terminal 140 is considered as an organization requiring consent data, or organization third party, and the first terminal 140 is a requesting terminal 140 or third party terminal 140. The second organization owning the second terminal 160 is an organization owning personal health data, and the second terminal 160 is said to be the owner terminal.

[0061] The platform 100 can also be accessible by a third terminal 180 belonging to a patient, via a third interface 170. The patient can be associated with a user account on the platform 100, in which he can enter his identity information, if it has not already been entered by a user of the second organization, for example by means of the second terminal 160. The patient can also communicate, via the third interface 170, consent data relating to personal health data relating to him. In particular, he can respond to a consent form discussed previously.

[0062] As previously explained, the third interface 170 may allow dynamic updating of the consent status corresponding to each set of personal health data of a patient accessing the third interface 170 by means of the third user terminal 180.

[0063] No restriction is attached to the third user terminal 180 which can be any terminal capable of accessing an IP network, such as a touchscreen tablet, a Smartphone, a laptop, a desktop computer, or other.

[0064] The third interface 170 can be shared between all users having a “patient” account.

[0065] Thus, the first interface 130 can be dedicated to terminals 140 requesting data from the platform 100, the second interface 150 can be dedicated to proprietary terminals 160 of consent data and the third interface 170 is dedicated to patient terminals 180 providing consent data and optionally identity information if they have not already been provided by the proprietary terminals 160, for storage in the first and second databases 110 and 111. Some of the consent data are also preferentially stored in the distributed ledger 120.

[0066] [Fig.2] is an exchange diagram illustrating the steps of a method for managing access to consent data of a group of patients according to embodiments of the invention.

[0067] The exchanges represented take place between the entities of the system 10 presented with reference to [Fig.l].

[0068] The interfaces 130 and 150 are not shown, for the sake of simplification, but all the exchanges between the first terminal 140 and the platform 100 on the one hand, and between the second terminal 160 and the platform 100 on the other hand, are preferably carried out via the first and second interfaces 130 and 150 pre- previously described.

[0069] The third terminal 180 and the third interface 170 are not shown, because the method described concerns the management of patient consent data, and not their obtaining or updating.

[0070] It will be understood, however, that at a step 200, the platform has consent data and identity information for at least one patient, and preferably for several patients, in particular several tens, hundreds or even thousands of patients. The patient's personal health data may be stored in another database, not shown in the figures described in this description, for example in a server or terminal of the second owner organization.

[0071] Step 200 may follow the receipt of consent data by a patient, or the receipt of an update of consent data, for example, or following the receipt of identity information from a patient. Alternatively, step 200 may follow a request for consent data by a second organization having personal health data for at least one patient, the platform then being responsible for collecting the consents of the patients concerned via the third interface 170.

[0072] In step 200, the platform 100 may have consent data and identity information for several patients, from the same study or the same medical site, or from several studies and / or several medical sites.

[0073] As already explained, the consent data is further associated with a given owner, who is preferably the healthcare professional who obtained the personal health data of the patient(s).

[0074] Step 200 further comprises the generation by the platform 100 of a pseudonymous identifier for the patient(s) whose consent data and identity information are available to the platform 100.

[0075] In a step 201, the platform 100 stores, for each patient, the pseudonymous identifier generated for this patient with the patient's consent data, in the first database 110. Furthermore, the consent data may be associated with an identifier of the owner who has personal health data of the patient for which the consent data was obtained. The consent data may further be associated with a patient group identifier, for example a medical site identifier and / or a study identifier.

[0076] At a step 202, the platform 100 stores, for each patient, the pseudonym identifier generated for this patient, with the patient's identity information, in the second database 111.

[0077] Thus, at the end of steps 200 to 202, the platform has a first base of data 110 comprising associations between patient consent data and pseudonymous patient identifiers, and a second database 111 comprising associations between the pseudonymous patient identifiers and patient identity information.

[0078] Additionally or alternatively, the identifier of the owner who owns the patient's personal data and for which consent data has been obtained is stored in the distributed ledger storing the patient's consent data.

[0079] De-identification of the consent data is thus enabled by the partitioning between the first and second databases 110 and 111.

[0080] In a step 210, the first terminal 140 accesses the platform 100 and sends a first access request REQ1 to the consent data of at least one patient. Step 210 may comprise the prior identification / authentication of the user of the first terminal 140 with the platform 100, giving him access to the platform via the first interface 130 dedicated to the requesting terminals 140.

[0081] The first access request REQ1 comprises a patient group identifier, such as a study identifier and / or a medical site identifier.

[0082] Upon receipt of the first request REQ1, the platform 211 determines at least one patient corresponding to the patient group identifier included in the first request REQ1, by querying the first database 110.

[0083] In a step 212, a first set of consent data of at least one patient corresponding to the patient group identifier is obtained by the platform 100 following the query of the first database 110. Preferably, the first set comprises all the consent data of all the patients which correspond to the patient group identifier are obtained by the platform 100 in step 110.

[0084] At a step 213, the platform 100 provides access, via the first interface, to at least some of the consent data of the first set obtained. Thus, the presentation of the consent data may be partial at this stage: for example, only the consent status associated with the patient's personal data is accessible by the first terminal 140 on the first interface, the other consent data such as the update history and the consent form not being presented to the first terminal 140 on the first interface 130. Furthermore, the consent data presented is not identified, since the second database 111 has not been consulted, which makes it impossible for the user of the first terminal 140 to make the link between the consent data and the identity of patients.

[0085] Alternatively, all consent data in the first set is rendered accessible to the user of the first terminal 140 at step 213, but not the identity information of the associated patients.

[0086] The first interface 130 can further make accessible other information than the partial or complete consent data:

[0087] - at least one owner identifier. If the owner of the data consent of the patient group is unique, then a single owner identifier is displayed. On the contrary, the consent data of the patient group may belong to multiple owners, and multiple owner identifiers may be made accessible by the first interface 130. In the following, the example of a single owner is considered for illustrative purposes and to simplify the disclosure of the invention; and

[0088] - an identifier of the patient group, in particular the identifier of the study and / or the site medical.

[0089] The consent data, the patient group identifier, and the owner identifier can be made accessible, for each patient, in a single file, downloadable or consultable on the first interface 130.

[0090] It is thus possible for a third party such as the user of the first terminal 140 to simply access certain consent data of at least one patient for a given study and / or for a given medical site.

[0091] In certain cases, the user of the first terminal 140 must collect more information to carry out his mission: - the identity information of the patient(s) for whom consent data was obtained in step 213; and / or - consent data supplementary to the consent data that was made accessible in step 213, the supplementary consent data possibly including the consent status update history and / or the consent form.

[0092] To do this, the first terminal 140 can transmit a second request REQ2 at a step 220 to request an agreement with the owner of the data of the group of patients identified in the first request REQ1, the agreement aiming to allow access to additional consent data and / or to identify the consent data with the identity information of the patient(s).

[0093] For this purpose, the second request REQ2 may include the following elements: - an identity of the user of the first terminal 140 or an identity of the first organization; - an identifier of the patient group concerned, in particular a study identifier and / or a medical site identifier; - optionally, an explanation concerning the reason why the user of the first terminal 140 wants to access the additional consent data and / or the identified consent data; - optionally, but preferably, a duration of access to additional consent data and / or identified consent data.

[0094] Upon receipt of the request REQ2, the platform 100 determines the owner of the data of the group of patients identified in the second request REQ2 and generates at a step 221 an agreement proposal on the basis of the elements of the second request REQ2, the agreement proposal comprising these elements, and submits the agreement proposal to the owner terminal 160 at a step 222, via the second interface 150.

[0095] Alternatively, the owner identifier is included in the second request REQ2, since the first terminal 140 was able to access such an identifier in step 213. In this case, the platform 100 determines the owner based on the owner identifier included in the second request REQ2.

[0096] The user of the second terminal 160 can thus check whether the criteria of the agreement proposal suit him, in particular whether the first organization identified is known or is a partner of the second organization, whether the access duration is acceptable, whether the study concerned is not confidential and / or whether the reason indicated is acceptable.

[0097] At a step 223, the user of the second terminal 160 accepts or refuses the agreement proposal on the second terminal 160, via the second interface 150.

[0098] A response, comprising a validation of the agreement or a refusal of the agreement, is received by the platform 100 from the second terminal 160 at a step 224.

[0099] In the event of an agreement, the platform 100 can record locally, i.e. in a memory not shown in [Fig.l], the agreement between the first organization and the second organization, the agreement identifying the group of patients concerned by the agreement, and optionally a maximum access duration to the additional consent data and to the patient identity information, which can be the access duration specified in the second request REQ2 or an access duration resulting from a modification made by the second terminal 160.

[0100] Alternatively, or in addition, the platform 100 may record the agreement in the form of a smart contract in the distributed ledger 120 at a step 226. Recording a smart contract in the distributed ledger 120 makes it possible to prevent any subsequent modification of the agreement, thus ensuring its integrity, and furthermore allows automatic execution of the agreement when its execution condition(s) are met. The execution condition of the smart contract may be the receipt of an execution request identifying the group of patients subject to the agreement, and optionally including an access duration in- less than or equal to the smart contract access duration.

[0101] In case of refusal of the second organization in step 224, the platform 100 can record the refusal. In addition, the refusal as well as the offer proposal can be stored in the distributed ledger 120 in step 226.

[0102] At a step 227, the platform 100 indicates, via the first interface 130 accessed by the first terminal 140, the refusal or validation of the agreement between the second organization and the first organization of the first terminal 140.

[0103] In the event of refusal of the agreement, the method can end at step 227. The user of the first terminal 140 can also request a new agreement with the second organization, by sending a new second request REQ2 at a step 220, the new second request REQ2 comprising elements modified compared to the second request REQ2 previously described, for example: - the new second request REQ2 may include a different reason from the second request REQ2, which allows the user of the first terminal 140 to further justify his request; and / or - the new second request REQ2 may comprise a new access duration, less than the access duration of the second request REQ2 previously transmitted.

[0104] In the event of receipt of a validation of the agreement between the second organization and the first organization, the method may comprise a step 230 during which the first terminal 140 sends a third request REQ3 for access to the additional consent data and / or to the identity information of the patients.

[0105] The third request REQ3 may comprise one or more of the following elements:

[0106] - the identity of the user of the first terminal 140 or the identity of the first organization nization; - an identifier of the patient group concerned, in particular a study identifier and / or a medical site identifier. The identified patient group is preferably included in the patient group identified in the second request REQ2 and for which an agreement has been obtained. In particular, the patient group identified in the third request REQ3 may be identical to the patient group identified in the second request REQ2. In the case where the patient group identified in the third request REQ3 differs from the patient group identified in the second request REQ2, without being included therein, the platform 100 may refuse access to the patient group identified in REQ3, as will be better understood in the following; - optionally, but preferably, a required duration of access to the additional consent data and / or the identified consent data. The required duration of access of the third request REQ3 must be less than or equal to the duration of access of the second request REQ2 for which consent has been obtained, for that the third request REQ3 be accepted.

[0107] In a step 231, the platform 100 verifies whether the third request REQ3 complies with the agreement between the first organization and the second organization. Such verification may comprise, as indicated above: - comparing the required access duration of the request REQ3, and the maximum access duration authorized by the second organization, which may be the access duration identified in the second request REQ2. If the required access duration of the request REQ3 is greater than the maximum authorized access duration, the platform 100 considers the third request REQ3 as non-compliant; - the comparison of the group of patients identified in the third request REQ3 with the group of patients identified in the second request REQ2. If the group of patients identified in REQ3 is different from the group of patients identified in REQ2, without being included therein, the platform 100 considers the third request REQ3 as non-compliant;

[0108] - the comparison between the identity of the user of the first terminal 140 or the identity of the first organization, between the second request REQ2 (i.e. the one mentioned in the agreement) and the third request REQ3. In the event of a difference in the identification of the user of the first terminal 140 or the identity of the first organization between the third request REQ3 and the agreement, the platform 100 considers the third request REQ3 as non-compliant.

[0109] Alternatively, the third request REQ3 only comprises an identifier of the agreement between the first organization and the second organization as well as the identity of the user of the first terminal 140 or of the first organization. In this case, the platform considers that the third request REQ3 is compliant if the identified agreement does indeed exist, and if this agreement involves the identified user or the first identified organization. Otherwise, the platform 100 considers that the third request REQ3 is non-compliant.

[0110] If the third request REQ3 is considered compliant by the platform 100 and the agreement is stored locally by the platform 100, then the platform executes the agreement in accordance with the third request REQ3, i.e.: - the platform 100 obtains the additional consent data and / or the identity information of the patients of the identified group by querying the first and second databases 110 and 111, at the respective steps 234 and 235;

[0111] - the platform 100 gives access, at a step 236, to the first terminal 140, to the additional consent data and / or identity information of the patients of the group identified in the third request REQ3, or of the group identified in the agreement if the third request REQ3 does not identify a group of patients again, via the first interface 130. In particular, the platform 100 can use the associations between identity information and pseudonymous identifiers of the patients obtained from the second database 111, to identify the consent data presented to the first terminal 140 on the first interface 130;

[0112] - optionally, but preferentially, if the third request REQ3 includes a required access duration, then the platform 100 maintains a counter at a step 238, the counter being able to be initialized to the required access duration and being able to be updated on the basis of a clock signal by being decremented. If the third request REQ3 does not include a required access duration, the counter can be initialized to the maximum access duration specified in the agreement. When the counter expires, that is to say when it reaches the value zero, an end of access message to the additional consent data and / or the identity information of the patients of the identified group, is transmitted from the platform 100 to the first terminal 140 at a step 239, and the first terminal can no longer access it.

[0113] The user of the first terminal 140 can thus access all of the identified consent data, i.e. enriched with the identity information of the patients of the identified group of patients, at a step 237 having the same duration as step 238. The user can thus access this enriched consent data for the access duration less than or equal to the maximum access duration specified in the agreement established with the second organization.

[0114] If the agreement is stored as a smart contract in the distributed ledger 120, then verifying the conformity of the third request may comprise extracting the elements of the third request REQ3 in step 231 and transmitting the elements of the third request REQ3 to the distributed ledger in a step 232. The distributed ledger 120 executes the smart contract in the event of conformity of the received elements with the conditions of the smart contract, such conformity being able to be based on the same comparisons as those described previously for the conformity verification implemented by the platform 100.The execution of the smart contract may comprise the execution at a step 233 of software on the platform 100 allowing the interrogation of the databases 110 and 111 in order to obtain the additional consent data and / or the identity information of the identified group of patients, in accordance with the steps 234 and 235 described previously. Steps 236 to 239 are then implemented in the same manner as described previously.

[0115] As a further variant, a double check is carried out:

[0116] - a first verification is implemented locally by the platform 100 at step 231 previously described; then - the elements of the third request REQ3 are transmitted to the distributed register 120 for a second verification by the distributed register 120.

[0117] It is advantageous to carry out a verification of the conformity of the third request REQ3 for execution of the agreement, in the distributed register 120, since the agreement stored in the distributed register cannot be modified.

[0118] If the third request REQ3 is determined to be non-compliant by the platform in step 230, a refusal of access may be indicated to the first terminal 140 via the first interface 130. Such a refusal of access may be stored in the distributed ledger in association with the third request REQ3.

[0119] In the example of [Fig.2], the second and third requests REQ2 and REQ3 are separate requests. Alternatively, the first terminal 140 can access the additional consent data and / or the patient identity information as early as step 227, i.e. upon receipt of the agreement from the second organization. In this case, there is no need to return a third request REQ3. In the event of storage of a smart contract in the distributed ledger 120, its execution is immediate, for the group of patients specified in the second request REQ2 and identified in the contract and for the maximum access duration indicated in the contract.

[0120] In this case: - the storage of the agreement in the distributed ledger 120 at step 226 in the form of a smart contract, when implemented, is followed by its immediate execution, and step 233 can thus immediately follow step 226; and - step 227 is followed by steps 234 and 235 of querying the two databases 110 and 111, then by steps 236 to 239 previously described.

[0121] [Fig.3] shows a structure of a platform 100 according to an embodiment of the invention.

[0122] The platform 100 comprises a processor 301 configured to communicate unidirectionally or bidirectionally, via one or more buses or via a direct wired connection, with a memory 302 such as a memory of the “Random Access Memory” type, RAM, or a memory of the “Read Only Memory” type, ROM, or any other type of memory (Flash, EEPROM, etc.). Alternatively, the memory 302 comprises several memories of the aforementioned types.

[0123] The memory 302 is capable of storing, permanently or temporarily, at least some of the data used and / or resulting from the implementation of the method according to the invention. In particular, the memory 302 can store, temporarily or permanently, data relating to the agreements between the first organization and the second organization, when they are stored locally.

[0124] The processor 301 is capable of executing instructions, stored in the memory 302, for the implementation of the steps of [Fig.2], with the exception of steps 223, 233 and 237 which are executed outside the platform 100. Alternatively, the processor 301 can be replaced by a microcontroller designed and configured for carry out the steps in [Fig.2], except steps 223, 233 and 237.

[0125] The platform 100 comprises a first network interface 303 capable of communicating with the first interface 130. Alternatively, the first network interface 303 and the first interface 130 are the same.

[0126] The platform 100 comprises a second network interface 304 capable of communicating with the second interface 150. Alternatively, the second network interface 304 and the second interface 150 are combined.

[0127] The platform 100 may further comprise a third network interface 305 capable of communicating with the third interface 170. Alternatively, the third network interface 305 and the third interface 170 are combined.

[0128] The platform 100 further comprises a fourth interface 306 capable of communicating with the first database 110.

[0129] The platform 100 further comprises a fifth interface 307 capable of communicating with the second database.

[0130] Alternatively, the first database 110 and / or the second database 111 may be integrated into the platform 100, in particular in the memory 302, in which case the platform 100 does not include the fourth interface 306 and / or the fifth interface 307.

[0131] The platform 100 comprises a sixth interface 308 arranged to communicate with the distributed ledger 120.

[0132] The present invention is not limited to the embodiments described above as examples; it extends to other variants.

Claims

Claims

1. A method for managing access to patient consent data implemented by a computer platform (100), and comprising the following operations: • providing (200) a first database (110) comprising associations between patient consent data and pseudonymous patient identifiers, and a second database (111) comprising associations between the pseudonymous patient identifiers and patient identity information; • upon receiving (210) a first request from a first terminal requesting (140) access to consent data, the first request comprising an identifier of a group of patients, obtaining from the first database a first set of consent data associated with pseudonymous patient identifiers, as a function of the identifier of the group of patients, without querying the second database;• giving access (213) to the first terminal to the first set of consent data obtained from the first database; • upon receipt (220) of a second request from the first terminal to obtain identity information of the patient group, requesting (222) an agreement from a second terminal (160) from an owner of the consent data of the identified patient group; • upon receipt (224) of a validation of the agreement by the second terminal, giving access (236) to the first terminal to the identity information of at least one patient of the identified patient group.;

2. The method of claim 1, wherein the patient group identifier comprises a study identifier and / or a medical site identifier, and wherein the patient group identifier does not include any individual personal information of patients in the group.

3. Method according to one of the preceding claims, in which, in case validation of the agreement by the second terminal (160), the platform (100) records the agreement in the form of a smart contract in a distributed ledger (120), and wherein an execution (233) of the agreement by the distributed ledger causes a query (234; 235) of the first and second databases (110; 111) to identify the consent data of the patients of the identified group of patients, with the identity information of the patients of the identified group of patients, and wherein the platform gives access (236) to the first terminal to the identified consent data of at least one patient of the group of patients, with the identity information of said at least one patient.

4. Method according to one of claims 1 to 3, wherein the agreement comprises at least some of the following elements: - an identifier of a first organization comprising the first terminal (140) and an identifier of a second organization comprising the second terminal (160); - the identifier of the patient group; - a duration of access to the identity information of the patient group

5. Method according to one of the preceding claims, in which the second request is a request to obtain an agreement to access the identity information of the group of patients, in which, upon receipt (224) of the validation of the agreement by the second terminal (160), the platform (100) records (225; 226) said agreement locally and / or in a distributed ledger (120), and in which the method further comprises the receipt (230) of a third request to access the identity information of the group of patients, and in which the platform and / or the distributed ledger verifies (231; 232) a conformity of the third request with the recorded agreement, and in which, only in the event of conformity of the third request with the recorded agreement, the platform gives access (236) to the first terminal to the identity information of said at least one patient of the identified group of patients.

6. Method according to claims 4 and 5, wherein the verification (231; 232) of conformity of the third request with the agreement comprises: - a comparison of an organization identifier of the third request with the first organization identified in the agreement; - a comparison of a required duration of access with the duration of access; and / or - a comparison between a patient group identifier of the third query and the patient group ID of the agreement.

7. Method according to one of the preceding claims, in which, for each patient, the consent data stored in the first database (110) comprises a consent status, information relating to a consent status update history and a consent form, in which the first set of consent data comprises the consent statuses of the patients of the identified group, and in which, in the event of reception (224) of the validation of the agreement by the second terminal, the first terminal further accesses additional consent data comprising the consent status update histories and the consent forms of the patients of the identified group.

8. The method of claim 7, wherein the consent status update history, for each patient, is stored in a distributed ledger (120), and wherein the information relating to the consent status update history is an access element to the consent status update history in the distributed ledger.

9. Computer program comprising instructions for implementing the method according to any one of the preceding claims, when these instructions are executed by a processor (301).

10. A computer platform (100) capable of accessing a first database (110) comprising associations between patient consent data and pseudonymous patient identifiers, and a second database (111) comprising associations between the pseudonymous patient identifiers and patient identity information, the platform comprising: a first interface (303) capable of receiving a first request from a first requesting terminal (140) to access consent data, the first request comprising an identifier of a group of patients; a processor (301) capable of, upon receipt of the first request: - obtaining from the first database a first set of consent data associated with pseudonymous identifiers, as a function of the identifier of the group of patients, without querying the second database; - providing access to the first terminal to the first set of consent data obtained from the first database; - upon receipt of a second request from the first terminal to obtain identity information of the patient group, requesting agreement from a second terminal (160) from an owner of the consent data of the identified patient group, via a second interface; - if validation of the agreement is received by the second terminal, give the first terminal access to the identity information of at least one patient in the identified patient group.

Images