FR 3147659 A1 20241011 FR 2303545 A 20230407 L’invention concerne un procédé de gestion de l’accès à des données de consentement. Une première base de données comprend des associations entre des données de consentement de patients et des identifiants pseudonymes, et une deuxième base de données comprend des associations entre les identifiants pseudonymes et des informations d’identité. Sur réception (210) d’une première requête comprenant un identifiant d’un groupe de patients, la plateforme obtient, de la première base, des données de consentement associées à des identifiants pseudonymes et donne accès (213), à un premier terminal requérant, à ces données de consentement. Sur réception (220) d’une deuxième requête, la plateforme demande (222) un accord pour accéder à des données complémentaires ou à des informations d’identité de patients, à un deuxième terminal (160), et en cas de réception (224) d’une validation de l’accord, la plateforme donne accès (236) au premier terminal aux données de consentement complémentaires et aux informations d’identité. FIG. 2 Gestion de l’accès à des données de consentement de patients La présente invention appartient au domaine de la gestion de l’accès à des données de consentement de patients. Elle concerne en particulier un procédé de gestion de données de consentement et une plateforme apte à assurer une telle gestion. Elle est particulièrement avantageuse lorsqu’un tiers cherche à accéder à des données de consentement de patients, notamment afin d’auditer les données de consentement et de vérifier qu’elles ont été obtenues en accord avec une réglementation donnée. La dématérialisation des documents et données concerne également le secteur de la santé. Il est généralement nécessaire de recueillir le consentement d’un patient afin de pouvoir utiliser des données personnelles de santé le concernant, notamment à des fins de recherche, d’étude et d’évaluation scientifique pour l’inclure dans une recherche impliquant la personne humaine. Les données de consentement d’un patient, incluant un statut de consentement indiquant si le patient accepte ou refuse l’utilisation des données personnelles de santé correspondant au statut de consentement, peuvent être stockées dans une base de données, avec un accès via une plateforme pour permettre au propriétaire des données de consentement, le professionnel de santé, de pouvoir les consulter lorsqu’il en a besoin. Il est d’ailleurs possible de prévoir une plateforme qui centralise les données de consentement de patients pour plusieurs professionnels de santé. Il n’est toutefois pas prévu de permettre à des tiers d’accéder aux données de consentement recueillies pour des patients de professionnels de santé. En outre, les données de consentement sont des données sensibles, qui ne peuvent être partagées avec n’importe qui, qui plus est lorsqu’elles sont associées à des informations d’identité de patients, telles que le nom, l’adresse, l’âge, etc. Il est pourtant souhaitable de permettre l’accès aux données de consentement pour des tiers, notamment pour un tiers auditeur cherchant à vérifier la conformité des données de consentement et de leur gestion. Il existe ainsi un besoin de permettre un accès contrôlé à des données de consentement de patients, pour un tiers différent du propriétaire de ces données de consentement. La présente invention vient améliorer la situation. A cet effet, un premier aspect de l’invention concerne un procédé de gestion de l’accès à des données de consentement de patients mis en œuvre par une plateforme informatique, et comprenant les opérations suivantes : disposer d’une première base de données comprenant des associations entre des données de consentement de patients et des identifiants pseudonymes de patients, et d’une deuxième base de données comprenant des associations entre les identifiants pseudonymes de patients et des informations d’identité de patients ; sur réception d’une première requête d’un premier terminal requérant d’accéder à des données de consentement, la première requête comprenant un identifiant d’un groupe de patients, obtenir de la première base de données un premier ensemble de données de consentement associées à des identifiants pseudonymes, en fonction de l’identifiant du groupe de patients, sans interroger la deuxième base de données ; donner accès au premier terminal au premier ensemble de données de consentement obtenu de la première base de données ; sur réception d’une deuxième requête du premier terminal pour obtenir des données de consentement complémentaires et/ou des informations d’identité du groupe de patients, demander un accord à un deuxième terminal d’un propriétaire des données de consentement du groupe de patients identifié ; en cas de réception d’une validation de l’accord par le deuxième terminal, donner accès au premier terminal aux données de consentement complémentaires et/ou aux informations d’identité d’au moins un patient du groupe de patients identifié. Ainsi, le procédé selon l’invention propose de dé-identifier les données de consentement des patients d’un groupe de patients, afin de permettre à un tiers d’y accéder, dans un premier temps, sans connaître l’identité des patients concernés. Toutefois, le premier terminal a la possibilité de requérir un enrichissement de ces données de consentement dé-identifiées, mais cet enrichissement, qui peut comprendre une identification des données de consentement et/ou un accès à des données de consentement complémentaires, est conditionné par un accord du propriétaire des données. L’accès aux données de consentement est ainsi permis mais contrôlé, avec une gestion de la confidentialité adaptée à la sensibilité des données. Selon des modes de réalisation, l’identifiant de groupe de patients peut comprendre un identifiant d’étude et/ou un identifiant de site médical, et l’identifiant de groupe de patients ne comprend aucune information personnelle individuelle de patients du groupe. Il est ainsi permis de requérir les données de consentement de patients sans connaître leur identité, simplement en spécifiant, dans une unique requête, le site médical ou l’étude pour laquelle on souhaite consulter les données de consentement. On appelle « étude », toute analyse médicale menée sur un groupe de plusieurs patients, à des fins de recherche ou de diagnostic notamment. Selon des modes de réalisation, en cas de validation de l’accord par le deuxième terminal, la plateforme peut enregistrer l’accord sous forme de contrat intelligent dans un registre distribué, et une exécution de l’accord par le registre distribué peut provoquer une interrogation des première et deuxième bases de données pour identifier les données de consentement des patients du groupe de patients identifié, avec les informations d’identité des patients du groupe de patients identifié, et la plateforme peut donner accès au premier terminal aux données de consentement identifiées d’au moins un patient du groupe de patients, avec les informations d’identité dudit au moins un patient. L’enregistrement dans un registre distribué, telle qu’une chaîne de blocs, permet d’assurer l’intégrité de l’accord stocké, ce qui permet une exécution ultérieure en ayant la certitude de que l’accord n’a pas été modifié entre temps. Selon des modes de réalisation, l’accord peut comprendre au moins certains des éléments suivants : - un identifiant d’une première organisation comprenant le premier terminal et un identifiant d’une deuxième organisation comprenant le deuxième terminal ; - l’identifiant du groupe de patients ; - une durée d’accès aux données de consentement complémentaires et/ou aux informations d’identité du groupe de patients Ainsi, il est rendu permis l’accès à des données de consentement, non seulement au premier terminal, mais également à d’autres terminaux de la même organisation. En outre, l’accès peut être permis pour un groupe de patients uniquement, ce qui permet une bonne granularité dans la gestion de l’accès. Enfin, il est rendu possible un accès temporaire, avec un contrôle de la durée d’accès. Selon des modes de réalisation, la deuxième requête peut être une requête d’obtention d’un accord pour accéder aux données de consentement complémentaires et/ou aux informations d’identité du groupe de patients , et, sur réception de la validation de l’accord par le deuxième terminal, la plateforme peut enregistrer ledit accord localement et/ou dans un registre distribué. Le procédé peut comprendre en outre la réception d’une troisième requête d’accès aux données de consentement complémentaires et/ou aux informations d’identité du groupe de patients, la plateforme et/ou le registre distribué peut vérifier une conformité de la troisième requête à l’accord enregistré, et, uniquement en cas de conformité de la troisième requête à l’accord enregistré, la plateforme peut donner accès au premier terminal aux données de consentement complémentaires et/ou aux informations d’identité dudit moins un patient du groupe de patients identifié. Ainsi, l’accord obtenu selon la deuxième requête peut être distinct de l’accès effectif aux données selon la troisième requête. Il est ainsi rendu possible de conclure un accord à un instant donné pour une consultation ultérieure des données de consentement enrichies. En complément, la vérification de conformité de la troisième requête avec l’accord peut comprendre : - une comparaison d’un identifiant d’organisation de la troisième requête avec la première organisation identifiée dans l’accord ; - une comparaison d’une durée requise d’accès avec la durée d’accès ; et/ou - une comparaison entre un identifiant de groupe de patients de la troisième requête et l’identifiant de groupe de patients de l’accord. Ainsi, la troisième requête est autorisée uniquement si elle est conforme à l’accord préalablement conclu. A noter que la troisième requête peut être plus spécifique que l’accord passé, c’est à dire que la troisième requête peut demander une durée d’accès plus courte que la durée d’accès autorisée dans l’accord, ou peut accéder à un sous-ensemble du groupe de patients autorisé dans l’accord. Selon des modes de réalisation, pour chaque patient, les données de consentement stockées dans la première base de données peuvent comprendre un statut de consentement, une information relative à un historique de mise à jour du statut de consentement et un formulaire de consentement, le premier ensemble de données de consentement peut comprendre les statuts de consentement des patients du groupe identifié, et les données de consentement complémentaires peuvent comprendre les historiques de mise à jour du statut de consentement et les formulaires de consentement des patients du groupe identifié. Ainsi, il est permis de contrôler l’accès aux données de consentement avec une bonne granularité, puisque certaines données de consentement sont accessibles dès la première requête, tandis que d’autres nécessitent un accord du propriétaire des données. En complément, l’historique de mise à jour de statut de consentement, pour chaque patient, peut être stocké dans un registre distribué, et l’information relative à l’historique de mise à jour du statut de consentement peut être un élément d’accès à l’historique de mise à jour du statut de consentement dans le registre distribué. Ainsi, l’intégrité de l’historique de mise à jour du statut de consentement est assuré, ce qui permet de vérifier que le statut de consentement stocké dans la première base de données n’a pas été modifié. Un deuxième aspect de l’invention concerne un programme informatique comportant des instructions pour la mise en œuvre du procédé selon le premier aspect de l’invention, lorsque ces instructions sont exécutées par un processeur. Un troisième aspect de l’invention concerne une plateforme informatique apte à accéder à une première base de données comprenant des associations entre des données de consentement de patients et des identifiants pseudonymes de patients, et à une deuxième base de données comprenant des associations entre les identifiants pseudonymes de patients et des informations d’identité de patients, la plateforme comprenant : une première interface apte à recevoir une première requête d’un premier terminal requérant pour accéder à des données de consentement, la première requête comprenant un identifiant d’un groupe de patients ; un processeur apte à, sur réception de la première requête : - obtenir de la première base de données un premier ensemble de données de consentement associées à des identifiants pseudonymes, en fonction de l’identifiant du groupe de patients, sans interroger la deuxième base de données ; - donner accès au premier terminal au premier ensemble de données de consentement obtenu de la première base de données ; - sur réception d’une deuxième requête du premier terminal pour obtenir des données de consentement complémentaires et/ou des informations d’identité du groupe de patients, demander un accord à un deuxième terminal d’un propriétaire des données de consentement du groupe de patients identifié, par une deuxième interface ; - en cas de réception d’une validation de l’accord par le deuxième terminal, donner accès au premier terminal aux données de consentement complémentaires et/ou aux informations d’identité d’au moins un patient du groupe de patients identifié. D’autres caractéristiques et avantages de l’invention apparaîtront à l’examen de la description détaillée ci-après, et des dessins annexés sur lesquels : illustre un système de gestion d’accès à des données de consentement selon des modes de réalisation de l’invention ; est un diagramme illustrant les étapes d’un procédé de gestion d’accès à des données de consentement de patients selon des modes de réalisation de l’invention ; illustre une structure d’une plateforme selon des modes de réalisation de l’invention. La présente un système 10 de gestion d’accès à des données de consentement de patients, selon un mode de réalisation de l’invention. Le système 10 comprend une plateforme 100, accessible via un réseau, tel qu’un réseau étendu de type IP par exemple, non représenté sur la . Le fonctionnement et la structure de la plateforme 100 seront mieux compris à la lecture de ce qui suit. Le système comprend une première base de données 110, apte à stocker des données de consentement et à permettre l’accès à de telles données de consentement à des entités externes, notamment à la plateforme 100. La plateforme 100 peut notamment assurer la gestion de la première base de données 110. En outre, selon l’invention, la première base de données 110 stocke des données de consentement en association avec des identifiants pseudonymes de patients. On entend par identifiant pseudonyme de patient tout identifiant ne donnant aucune indication sur l’identité du patient. En particulier, l’identifiant pseudonyme ne comprend aucune information relative au nom, prénom, adresse, âge, poids, ou toute autre information d’identité du patient. Aucune restriction n’est attachée à l’identifiant pseudonyme d’un patient, qui peut par exemple prendre la forme d’une chaîne alpha-numérique. On appelle « données de consentement » des données relatives au consentement d’un patient d’autoriser l’accès à des données personnelles de santé par des tiers, à des fins de recherche, d’études ou de diagnostic. Les données de consentement peuvent notamment comprendre : - un statut de consentement. Le statut de consentement peut être un statut « accepté » ou un statut « refusé ». Selon le statut accepté, le patient autorise un tiers à accéder à certaines données personnelles de santé qui le concerne, tandis que selon le statut « refusé », il refuse le partage de telles données personnelles de santé à un tiers ; - un historique de mise à jour du statut de consentement, lorsque le patient a la possibilité de mettre à jour dynamiquement le statut de consentement. Une telle possibilité peut être permis par la plateforme 100, comme détaillé dans ce qui suit ; - un formulaire de consentement qui correspond au formulaire par lequel le patient a indiqué le statut de consentement pour ses données personnelles de santé, et toute information relative à l’évaluation du caractère spécifique, univoque, libre et éclairé du consentement. Le formulaire de consentement peut notamment comprendre une première signature horodatée du patient, et éventuellement, une deuxième signature horodatée du professionnel de santé propriétaire des données de consentement. En particulier, la première signature peut être antérieure à la deuxième signature, et peut conditionner l’obtention de la deuxième signature. Les première et deuxième signatures peuvent être des signatures électroniques. En outre, la première base de données 110 peut stocker les données de consentement de patients en association avec un identifiant d’un groupe de patients. Le groupe de patients peut être un groupe sur lequel une étude a été menée et/ou ayant en commun d’avoir reçu des soins sur un même site médical. L’identifiant d’un groupe de patient peut ainsi être un identifiant d’une étude menée sur plusieurs patients par exemple, ou peut être un identifiant d’un site médical dans lequel les données personnelles de santé de plusieurs patients ont été obtenues. A noter que l’identifiant du groupe de patient n’identifie pas individuellement les patients, mais identifie soit un site médical, soit une étude, soit les deux. L’identifiant de groupe de patient ne comprend ainsi aucune information d’identité de patient du groupe de patients. Une deuxième base de données 111 stocke des identifiants pseudonymes de patients en association avec des informations d’identité de patient. Les informations d’identité de patient peuvent notamment comprendre les informations listées ci-dessus, à savoir nom, prénom, adresse, âge, poids, signature électronique etc. Le système comprend en outre un registre distribué 120, tel qu’un registre à chaîne de blocs, plus communément appelé Blockchain. Le registre distribué 120 est apte à stocker des données, à horodater de telles données et rendre impossible leur modification a posteriori. Un tel registre 120 est bien connu et ne sera pas détaillé davantage dans la présente description. Au moins une donnée de consentement pour un patient donnée peut être stockée dans le registre distribué. De manière préférentielle, l’historique des mises à jour des statuts de consentement pour un patient donné et pour certaines données personnelles de santé de ce patient, est stocké dans le registre distribué. Dans ce cas, la première base de données 110 peut ne pas stocker un tel historique, mais peut stocker en remplacement un élément permettant un accès à l’historique dans le registre distribué 120. Un tel élément peut être une valeur de hachage notamment permettant de retrouver l’historique dans le registre distribué. Il est ainsi permis un cloisonnement entre les données de consentement et les informations d’identité d’un patient, ce qui permet un meilleur contrôle de l’accès aux données de consentement d’un patient. Il est en effet rendu possible à un tiers d’accéder à certaines des données de consentement d’un patient sans toutefois permettre l’accès aux informations d’identité du patient, ou à certaines autres données de consentement. Selon l’invention, et comme décrit ultérieurement, le tiers peut toutefois requérir d’accéder à l’ensemble des données de consentement identifiées avec les informations d’identité du patient. C’est notamment le cas lorsque le tiers est un auditeur en charge du contrôle des données de consentement, notamment pour vérifier leur conformité à une réglementation donnée. A noter que les données de consentement associée à un identifiant pseudonyme d’un patient peuvent comprendre plusieurs statuts de consentement respectivement associés à plusieurs ensembles de données personnelles de santé. Le patient peut ainsi donner son accord pour le partage de certaines de ses données personnelles de santé en les associant à un statut « accepté » tandis qu’il peut refuser le partage d’autres données personnelles de santé en les associant au statut « refusé ». Ainsi, une meilleure granularité dans l’attribution de statuts de consentement à des données personnelles de santé peut être permis pour le patient. Le système selon l’invention comprend en outre une première interface 130 d’accès à la plateforme 100. La première interface d’accès 130 est apte à permettre des échanges de données/informations entre un premier terminal 140 et la plateforme 100. Aucune restriction n’est attachée à la première interface 130, qui peut être une interface utilisateur dédiée à une application associée à la plateforme 100 ou à un site internet permettant l’accès à la plateforme 100. Selon l’invention, le premier terminal 140 est un terminal requérant ou terminal tiers, c’est à dire un terminal d’un utilisateur souhaitant accéder à des données stockées dans au moins l’une des bases de données 110 et 111 précédemment décrites. L’accès aux services de la plateforme 100 peut être conditionné par une identification/authentification de l’utilisateur tiers utilisant le premier terminal 140, auquel cas l’utilisateur est associé à un compte utilisateur, ou un compte tiers, sur la plateforme 100. L’utilisateur du premier terminal peut consulter certaines des données de consentement dans la première base de données 110 pour au moins un patient, notamment pour un groupe de patients correspondant à un site médical et/ou à une étude donnée. Plus précisément, la première interface 130 peut présenter certaines des données de consentement de la première base de données 110, en notant à nouveau que ces données de consentement ne permettent pas à l’utilisateur du premier terminal 140 d’identifier le patient auquel elles correspondent. En particulier, les données de consentement d’un patient donné du groupe de patients, peuvent être accessibles sous la forme d’une fiche, la fiche pouvant comprendre : - l’identifiant pseudonyme du patient, ne comprenant aucune information d’identité du patient ; - certaines des données de consentement, par exemple uniquement le statut de consentement pour chaque ensemble de données personnelles de santé du patient. Les autres données de consentement, ou données de consentement complémentaires, telles que l’historique de mise à jour des statuts de consentement et le formulaire de consentement peuvent ne pas être accessibles sur la première interface 130. Elles peuvent toutefois être rendues accessibles sur requête du premier terminal 140 comme il sera mieux compris à la lecture de la description de la ; - un identifiant de groupe auquel est rattaché le patient. Un tel identifiant de groupe peut comprendre un nom d’étude pour laquelle les données de consentement ont été obtenues et/ou un identifiant de site médical sur lequel l’étude a été menée. Plusieurs fiches de patients peuvent ainsi présenter le même identifiant de groupe, lorsqu’il s’agit de patients ayant contribué à la même étude et/ou ayant reçu des soins sur le même site médical ; - un identifiant d’un propriétaire des données de consentement, le propriétaire étant décrit ultérieurement. Ainsi, il est rendu possible de consulter certaines des données de consentement à un tiers, pour une étude donnée et/ou pour un site médical donné, sans pour autant communiquer à ce tiers les informations d’identité des patients ni l’intégralité des données de consentement. La gestion de données sensibles telles que des données de consentement relatives à des données médicales est ainsi améliorée. Toutefois, comme il sera mieux compris à la lecture de la description de la , le terminal requérant 140 peut requérir, dans un second temps, l’accès à l’ensemble des données de consentement identifiées sur la base des informations d’identité stockées dans la deuxième base de données 111. Le premier terminal 140 peut être rattaché à une première organisation, par exemple une organisation en charge d’auditer les données de consentement pour des études données et/ou pour des sites médicaux donnés, afin de vérifier leur conformité à une règlementation par exemple. La première interface 130 peut être partagée entre plusieurs terminaux de plusieurs organisations données, via un réseau IP notamment, c’est-à-dire que différents terminaux d’utilisateurs tiers identifiés comme requérant des données personnelles de consentement, accèdent à la plateforme 100 via la première interface 130. Le premier terminal 140 est ainsi tout terminal apte à accéder à un réseau IP, tel qu’une tablette tactile, un Smartphone, un ordinateur portable, un ordinateur de bureau, ou autre. Le système de gestion d’accès 10 selon l’invention peut comprendre en outre une deuxième interface 150 d’accès à la plateforme de service 100. Une telle deuxième interface 150 est accessible par au moins un deuxième terminal 160 qui est un terminal d’un utilisateur ayant des droits sur des données personnelles de santé correspondant à au moins certaines des données de consentement stockées dans les bases de données 110 et 111, ou terminal propriétaire. A noter que les données personnelles de santé peuvent être stockées dans une autre base de données, non représentée sur la , l’accès aux données personnelles de santé n’étant pas détaillée dans la présente description. En particulier, les données personnelles de santé peuvent être stockées sur un serveur ou un terminal d’une deuxième organisation à laquelle appartient le deuxième terminal 160. En particulier, la deuxième organisation peut avoir au préalable collecté les données personnelles de santé, puis avoir requis l’obtention de données de consentement pour les patients concernés via la plateforme 100. Par exemple, la deuxième organisation peut avoir collecté des données personnelles de santé pour un groupe de patients donné, correspondant à une étude donnée et/ou à un site médical donné, et les données de consentement correspondantes ont ensuite été obtenues via la plateforme 100. Aucune restriction n’est attachée au deuxième terminal 160 qui peut être tout terminal apte à accéder à un réseau IP, tel qu’une tablette tactile, un Smartphone, un ordinateur portable, un ordinateur de bureau, ou autre. Dans ce qui suit, on considère la première organisation possédant le premier terminal 140 comme une organisation requérant des données de consentement, ou organisation tiers, et le premier terminal 140 est un terminal requérant 140 ou terminal tiers 140. La deuxième organisation possédant le deuxième terminal 160 est une organisation propriétaire de données personnelles de santé, et le deuxième terminal 160 est dit terminal propriétaire. La plateforme 100 peut également être accessible par un troisième terminal 180 appartenant à un patient, via une troisième interface 170. Le patient peut être associé à un compte utilisateur sur la plateforme 100, dans lequel il peut renseigner ses informations d’identité, si elles n’ont pas déjà été renseignées par un utilisateur de la deuxième organisation, par exemple au moyen du deuxième terminal 160. Le patient peut également communiquer, via la troisième interface 170, des données de consentement relatives à des données personnelles de santé qui lui sont relatives. Il peut notamment répondre à un formulaire de consentement discuté précédemment. Comme précédemment expliqué, la troisième interface 170 peut permettre une mise à jour dynamique du statut de consentement correspondant à chaque ensemble de données personnelles de santé d’un patient accédant à la troisième interface 170 au moyen du troisième terminal utilisateur 180. Aucune restriction n’est attachée au troisième terminal utilisateur 180 qui peut être tout terminal apte à accéder à un réseau IP, tel qu’une tablette tactile, un Smartphone, un ordinateur portable, un ordinateur de bureau, ou autre. La troisième interface 170 peut être mutualisée entre tous les utilisateurs possédant un compte « patient ». Ainsi, la première interface 130 peut être dédiée à des terminaux 140 requérant des données de la plateforme 100, la deuxième interface 150 peut être dédiée à des terminaux propriétaires 160 de données de consentement et la troisième interface 170 est dédiée à des terminaux de patients 180 fournissant des données de consentement et optionnellement des informations d’identité si elles n’ont pas déjà été fournies par les terminaux propriétaires 160, pour stockage dans les première et deuxième bases de données 110 et 111. Certaines des données de consentement sont également préférentiellement stockées dans le registre distribué 120. La est un diagramme d’échanges illustrant les étapes d’un procédé de gestion d’accès à des données de consentement d’un groupe de patients selon des modes de réalisation de l’invention. Les échanges représentés ont lieu entre les entités du système 10 présentées en référence à la . Les interfaces 130 et 150 ne sont pas représentées, dans un but de simplification, mais tous les échanges entre le premier terminal 140 et la plateforme 100 d’une part, et entre le deuxième terminal 160 et la plateforme 100 d’autre part, se font préférentiellement par l’intermédiaire des première et deuxième interfaces 130 et 150 précédemment décrites. Le troisième terminal 180 et la troisième interface 170 ne sont pas représentés, car le procédé décrit concerne la gestion des données de consentement de patients, et non pas leur obtention ou leur mise à jour. On comprendra toutefois qu’à une étape 200, la plateforme dispose de données de consentement et d’informations d’identité pour au moins un patient, et de préférence pour plusieurs patients, notamment plusieurs dizaines, centaines voire milliers de patients. Les données personnelles de santé du patient peuvent être stockées dans une autre base de données, non représentée sur les figures décrites dans la présente description, par exemple dans un serveur ou un terminal de la deuxième organisation propriétaire. L’étape 200 peut être consécutive à la réception de données de consentement par un patient, ou à la réception d’une mise à jour de données de consentement, par exemple, ou suite à la réception d’informations d’identité d’un patient. En variante, l’étape 200 peut faire suite à une demande de données de consentement par une deuxième organisation possédant des données personnelles de santé pour au moins un patient, la plateforme étant en charge ensuite de recueillir les consentements des patients concernés via la troisième interface 170. A l’étape 200, la plateforme 100 peut disposer de données de consentement et d’informations d’identité pour plusieurs patients, d’une même étude ou d’un même site médical, ou de plusieurs études et/ou de plusieurs sites médicaux. Comme déjà expliqué, les données de consentement sont en outre associées à un propriétaire donné, qui est de préférence le professionnel de santé ayant obtenu les données personnelles de santé du ou des patients. L’étape 200 comprend en outre la génération par la plateforme 100 d’un identifiant pseudonyme pour le ou les patients dont les données de consentement et les informations d’identité sont disponibles pour la plateforme 100. A une étape 201, la plateforme 100 stocke, pour chaque patient, l’identifiant pseudonyme généré pour ce patient avec les données de consentement du patient, dans la première base de données 110. En outre, les données de consentement peuvent être associées à un identifiant du propriétaire qui possède des données personnelles de santé du patient pour lesquelles les données de consentement ont été obtenues. Les données de consentement peuvent en outre être associées à un identifiant de groupe de patients, par exemple à un identifiant de site médical et/ou à un identifiant d’une étude. A une étape 202, la plateforme 100 stocke, pour chaque patient, l’identifiant pseudonyme généré pour ce patient, avec les informations d’identité du patient, dans la deuxième base de données 111. Ainsi, à l’issue des étapes 200 à 202, la plateforme dispose d’une première base de données 110 comprenant des associations entre des données de consentement de patients et des identifiants pseudonymes de patients, et d’une deuxième base de données 111 comprenant des associations entre les identifiants pseudonymes de patients et des informations d’identité de patients. En complément ou en variante, l’identifiant du propriétaire qui possède les données personnelles du patient et pour lesquelles des données de consentement ont été obtenues, est stocké dans le registre distribué stockant les données de consentement du patient. Une dé-identification des données de consentement est ainsi permise par le cloisonnement entre les première et deuxième bases de données 110 et 111. A une étape 210, le premier terminal 140 accède à la plateforme 100 et envoie une première requête d’accès REQ1 aux données de consentement d’au moins un patient. L’étape 210 peut comprendre au préalable l’identification/authentification de l’utilisateur du premier terminal 140 auprès de la plateforme 100, lui donnant accès à la plateforme via la première interface 130 dédiée aux terminaux requérants 140. La première requête d’accès REQ1 comprend un identifiant de groupe de patients, tel qu’un identifiant d’étude et/ou un identifiant de site médical. Sur réception de la première requête REQ1, la plateforme 211 détermine au moins un patient correspondant à l’identifiant de groupe de patients compris dans la première requête REQ1, par interrogation de la première base de données 110. A une étape 212, un premier ensemble de données de consentement d’au moins un patient correspondant à l’identifiant de groupe de patients, est obtenu par la plateforme 100 suite à l’interrogation de la première base de données 110. De manière préférentielle, le premier ensemble comprend toutes les données de consentement de tous les patients qui correspondent à l’identifiant du groupe de patients sont obtenus par la plateforme 100 à l’étape 110. A une étape 213, la plateforme 100 donne accès, via la première interface, à au moins certaines des données de consentement du premier ensemble obtenu. Ainsi, la présentation des données de consentement peut être partielle à ce stade : par exemple, seul le statut de consentement associé aux données personnelles du patient sont accessibles par le premier terminal 140 sur la première interface, les autres données de consentement telles que l’historique de mise à jour et le formulaire de consentement n’étant pas présentés au premier terminal 140 sur la première interface 130. En outre, les données de consentement présentées ne sont pas identifiées, puisque la deuxième base de données 111 n’a pas été consultée, ce qui rend impossible à l’utilisateur du premier terminal 140 de faire le lien entre les données de consentement et l’identité de patients. En variante, toutes les données de consentement du premier ensemble sont rendues accessibles à l’utilisateur du premier terminal 140 à l’étape 213, mais pas les informations d’identité des patients associés. La première interface 130 peut en outre rendre accessibles d’autres informations que les données de consentement partielles ou complètes : - au moins un identifiant du propriétaire. Si le propriétaire des données de consentement du groupe de patients est unique, alors un unique identifiant de propriétaire est affiché. Au contraire, les données de consentement du groupe de patients peuvent appartenir à plusieurs propriétaires, et plusieurs identifiants de propriétaires peuvent être rendus accessibles par la première interface 130. Dans ce qui suit, l’exemple d’un propriétaire unique est considéré à titre illustratif et pour simplifier l’exposé de l’invention ; et - un identifiant du groupe de patients, notamment l’identifiant de l’étude et/ou du site médical. Les données de consentement, l’identifiant du groupe de patients, et l’identifiant du propriétaire peuvent être rendus accessibles, pour chaque patient, dans un fichier unique, téléchargeable ou consultable sur la première interface 130. Il est ainsi permis à un tiers tel que l’utilisateur du premier terminal 140 d’accéder simplement à certaines données de consentement d’au moins un patient pour une étude donnée et/ou pour un site médical donné. Dans certains cas, l’utilisateur du premier terminal 140 doit recueillir plus d’informations pour mener à bien sa mission : - les informations d’identité du ou des patients pour lesquels il a obtenu des données de consentement à l’étape 213 ; et/ou - les données de consentement complémentaires aux données de consentement qui ont été rendus accessibles à l’étape 213, les données de consentement complémentaires pouvant comprendre l’historique de mise à jour du statut de consentement et/ou le formulaire de consentement. Pour ce faire, le premier terminal 140 peut transmettre une deuxième requête REQ2 à une étape 220 pour solliciter un accord avec le propriétaire des données du groupe de patients identifié dans la première requête REQ1, l’accord visant à permettre l’accès à des données de consentement complémentaires et/ou pour identifier les données de consentement avec les informations d’identité du ou des patients. A cet effet, la deuxième requête REQ2 peut comprendre les éléments suivants : - une identité de l’utilisateur du premier terminal 140 ou une identité de la première organisation ; - un identifiant du groupe de patients concerné, notamment un identifiant d’étude et/ou un identifiant de site médical ; - optionnellement, une explication concernant le motif pour lequel l’utilisateur du premier terminal 140 veut accéder aux données de consentement complémentaires et/ou aux données de consentement identifiées ; - optionnellement, mais de préférence, une durée d’accès aux données de consentement complémentaires et/ou aux données de consentement identifiées. Sur réception de la requête REQ2, la plateforme 100 détermine le propriétaire des données du groupe de patients identifié dans la deuxième requête REQ2 et génère à une étape 221 une proposition d’accord sur la base des éléments de la deuxième requête REQ2, la proposition d’accord comprenant ces éléments, et soumet la proposition d’accord au terminal propriétaire 160 à une étape 222, via la deuxième interface 150. En variante, l’identifiant du propriétaire est inclus dans la deuxième requête REQ2, puisque le premier terminal 140 a pu accéder à un tel identifiant à l’étape 213. Dans ce cas, la plateforme 100 détermine le propriétaire en fonction de l’identifiant de propriétaire inclus dans la deuxième requête REQ2. L’utilisateur du deuxième terminal 160 peut ainsi vérifier si les critères de la proposition d’accord lui conviennent, notamment si la première organisation identifiée est connue ou est un partenaire de la deuxième organisation, si la durée d’accès est acceptable, si l’étude concernée n’est pas confidentielle et/ou si le motif indiqué est acceptable. A une étape 223, l’utilisateur du deuxième terminal 160, accepte ou refuse la proposition d’accord sur le deuxième terminal 160, via la deuxième interface 150. Une réponse, comprenant une validation de l’accord ou un refus de l’accord, est reçue par la plateforme 100 de la part du deuxième terminal 160 à une étape 224. En cas d’accord, la plateforme 100 peut enregistrer localement, c’est à dire dans une mémoire non représentée sur la , l’accord entre la première organisation et la deuxième organisation, l’accord identifiant le groupe de patients concerné par l’accord, et optionnellement une durée d’accès maximale aux données de consentement complémentaires et aux informations d’identité des patients, qui peut être la durée d’accès spécifiée dans la deuxième requête REQ2 ou une durée d’accès issue d’une modification apportée par le deuxième terminal 160. En variante, ou de manière complémentaire, la plateforme 100 peut enregistrer l’accord sous forme de contrat intelligent, ou « Smart contract » en anglais, dans le registre distribué 120 à une étape 226. L’enregistrement d’un contrat intelligent dans le registre distribué 120 permet d’empêcher toute modification ultérieure de l’accord, assurant ainsi son intégrité, et permet en outre une exécution automatique de l’accord lorsque sa ou ses conditions d’exécution sont remplies. La condition d’exécution du contrat intelligent peut être la réception d’une requête d’exécution identifiant le groupe de patients objet de l’accord, et optionnellement comprenant une durée d’accès inférieure ou égale à la durée d’accès du contrat intelligent. En cas de refus de la deuxième organisation à l’étape 224, la plateforme 100 peut enregistrer le refus. En outre, le refus ainsi que la proposition d’offre peuvent être stockées dans le registre distribué 120 à l’étape 226. A une étape 227, la plateforme 100 indique, via la première interface 130 à laquelle accède le premier terminal 140, le refus ou la validation de l’accord entre la deuxième organisation et la première organisation du premier terminal 140. En cas de refus de l’accord, le procédé peut s’achever à l’étape 227. L’utilisateur du premier terminal 140 peut également solliciter un nouvel accord avec la deuxième organisation, par l’envoi d’une nouvelle deuxième requête REQ2 à une étape 220, la nouvelle deuxième requête REQ2 comprenant des éléments modifiés par rapport à la deuxième requête REQ2 précédemment décrite, par exemple : - la nouvelle deuxième requête REQ2 peut comprendre un motif différent de la deuxième requête REQ2, ce qui permet à l’utilisateur du premier terminal 140 de justifier davantage sa requête ; et/ou - la nouvelle deuxième requête REQ2 peut comprendre une nouvelle durée d’accès, inférieure à la durée d’accès de la deuxième requête REQ2 précédemment transmise. En cas de réception d’une validation de l’accord entre la deuxième organisation et la première organisation, le procédé peut comprendre une étape 230 durant laquelle le premier terminal 140 envoie une troisième requête REQ3 d’accès aux données de consentement complémentaires et/ou aux informations d’identité des patients. La troisième requête REQ3 peut comprendre l’un ou plusieurs des éléments suivants : - l’identité de l’utilisateur du premier terminal 140 ou l’identité de la première organisation ; - un identifiant du groupe de patients concerné, notamment un identifiant d’étude et/ou un identifiant de site médical. Le groupe de patients identifié est de préférence compris dans le groupe de patients identifié dans la deuxième requête REQ2 et pour lequel un accord a été obtenu. En particulier, le groupe de patients identifié dans la troisième requête REQ3 peut être identique au groupe de patients identifié dans la deuxième requête REQ2. Dans le cas où le groupe de patients identifié dans la troisième requête REQ3 diffère du groupe de patients identifié dans la deuxième requête REQ2, sans y être inclus, la plateforme 100 peut refuser l’accès au groupe de patient identifié dans REQ3, comme il sera mieux compris dans ce qui suit ; - optionnellement, mais de préférence, une durée requise d’accès aux données de consentement complémentaires et/ou aux données de consentement identifiées. La durée requise d’accès de la troisième requête REQ3 doit être inférieure ou égale à la durée d’accès de la deuxième requête REQ2 pour laquelle un accord a été obtenu, pour que la troisième requête REQ3 soit acceptée. A une étape 231, la plateforme 100 vérifie si la troisième requête REQ3 est conforme à l’accord passé entre la première organisation et la deuxième organisation. Une telle vérification peut comprendre, comme indiqué ci-dessus : - la comparaison de la durée requise d’accès de la requête REQ3, et la durée d’accès maximale autorisée par la deuxième organisation, qui peut être la durée d’accès identifiée dans la deuxième requête REQ2. Si la durée requise d’accès de la requête REQ3 est supérieure à la durée d’accès maximale autorisée, la plateforme 100 considère la troisième requête REQ3 comme non conforme ; - la comparaison du groupe de patients identifié dans la troisième requête REQ3 avec le groupe de patients identifié dans la deuxième requête REQ2. Si le groupe de patients identifié dans REQ3 est différent du groupe de patients identifié dans REQ2, sans y être inclus, la plateforme 100 considère la troisième requête REQ3 comme non conforme ; - la comparaison entre l’identité de l’utilisateur du premier terminal 140 ou l’identité de la première organisation, entre la deuxième requête REQ2 (soit celle mentionnée dans l’accord) et la troisième requête REQ3. En cas de différence dans l’identifié de l’utilisateur du premier terminal 140 ou de l’identité de la première organisation entre la troisième requête REQ3 et l’accord, la plateforme 100 considère la troisième requête REQ3 comme non conforme. En variante, la troisième requête REQ3 ne comprend qu’un identifiant de l’accord entre la première organisation et la deuxième organisation ainsi que l’identité de l’utilisateur du premier terminal 140 ou de la première organisation. Dans ce cas, la plateforme considère que la troisième requête REQ3 est conforme si l’accord identifié existe bien, et si cet accord implique l’utilisateur identifié ou la première organisation identifiée. Sinon, la plateforme 100 considère que la troisième requête REQ3 est non conforme. Si la troisième requête REQ3 est considérée comme conforme par la plateforme 100 et que l’accord est stocké localement par la plateforme 100, alors la plateforme exécute l’accord conformément à la troisième requête REQ3, c’est à dire que : - la plateforme 100 obtient les données complémentaires de consentement et/ou les informations d’identité des patients du groupe identifié par interrogation des première et deuxième bases de données 110 et 111, aux étapes respectives 234 et 235 ; - la plateforme 100 donne accès, à une étape 236, au premier terminal 140, aux données complémentaires de consentement et/ou aux informations d’identité des patients du groupe identifié dans la troisième requête REQ3, ou du groupe identifié dans l’accord si la troisième requête REQ3 n’identifie pas de groupe de patients à nouveau, via la première interface 130. En particulier, la plateforme 100 peut utiliser les associations entre informations d’identité et identifiants pseudonymes des patients obtenus de la deuxième base de données 111, pour identifier les données de consentement présentées au premier terminal 140 sur la première interface 130 ; - optionnellement, mais de manière préférentielle, si la troisième requête REQ3 comprend une durée requise d’accès, alors la plateforme 100 tient à jour un compteur à une étape 238, le compteur pouvant être initialisé à la durée requise d’accès et pouvant être mis à jour sur la base d’un signal d’horloge en étant décrémenté. Si la troisième requête REQ3 ne comprend pas de durée requise d’accès, le compteur peut être initialisé à la durée maximale d’accès spécifiée dans l’accord. Lorsque le compteur expire, c’est-à-dire lorsqu’il atteint la valeur nulle, un message de fin d’accès aux données complémentaires de consentement et/ou les informations d’identité des patients du groupe identifié, est transmis de la plateforme 100 au premier terminal 140 à une étape 239, et le premier terminal ne peut plus y accéder. L’utilisateur du premier terminal 140 peut ainsi accéder à l’ensemble des données de consentement identifiées, c’est-à-dire enrichies avec les informations d’identité des patients du groupe de patients identifié, à une étape 237 ayant la même durée que l’étape 238. L’utilisateur peut ainsi accéder à ces données de consentement enrichies pendant la durée d’accès inférieure ou égale à la durée d’accès maximale spécifiée dans l’accord établi avec la deuxième organisation. Si l’accord est stocké sous forme de contrat intelligent dans le registre distribué 120, alors la vérification de la conformité de la troisième requête peut comprendre l’extraction des éléments de la troisième requête REQ3 à l’étape 231 et la transmission des éléments de la troisième requête REQ3 au registre distribué à une étape 232. Le registre distribué 120 exécute le contrat intelligent en cas de conformité des éléments reçus avec les conditions du contrat intelligent, une telle conformité pouvant être basée sur les mêmes comparaisons que celles décrites précédemment pour la vérification de conformité mise en œuvre par la plateforme 100. L’exécution du contrat intelligent peut comprendre l’exécution à une étape 233 d’un logiciel sur la plateforme 100 permettant l’interrogation des bases de données 110 et 111 afin d’obtenir les données complémentaires de consentement et/ou les informations d’identité du groupe de patients identifié, conformément aux étapes 234 et 235 décrites précédemment. Les étapes 236 à 239 sont ensuite mises en œuvre de la même manière que décrit précédemment. Encore en variante, une double vérification est opérée : - une première vérification est mise en œuvre localement par la plateforme 100 à l’étape 231 précédemment décrite ; puis - les éléments de la troisième requête REQ3 sont transmis au registre distribué 120 pour une deuxième vérification par le registre distribué 120. Il est avantageux de procéder à une vérification de la conformité de la troisième requête REQ3 pour exécution de l’accord, dans le registre distribué 120, puisque l’accord stocké dans le registre distribué ne peut pas être modifié. Si la troisième requête REQ3 est déterminée comme non conforme par la plateforme à l’étape 230, un refus d’accès peut être indiqué au premier terminal 140 via la première interface 130. Un tel refus d’accès peut être stocké dans le registre distribué en association avec la troisième requête REQ3. Dans l’exemple de la , les deuxième et troisième requêtes REQ2 et REQ3 sont des requêtes distinctes. En variante, le premier terminal 140 peut accéder aux données de consentement complémentaires et/ou aux informations d’identité des patients dès l’étape 227, c’est-à-dire sur réception de l’accord de la deuxième organisation. Dans ce cas, il n’est nullement besoin de renvoyer une troisième requête REQ3. En cas de stockage de contrat intelligent dans le registre distribué 120, son exécution est immédiate, pour le groupe de patients spécifié dans la deuxième requête REQ2 et identifié dans le contrat et pour la durée d’accès maximale indiquée dans le contrat. Dans ce cas : - le stockage de l’accord dans le registre distribué 120 à l’étape 226 sous forme de contrat intelligent, lorsqu’il est mis en œuvre, est suivi de son exécution immédiate, et l’étape 233 peut ainsi immédiatement suivre l’étape 226 ; et - l’étape 227 est suivie des étapes 234 et 235 d’interrogation des deux bases de données 110 et 111, puis des étapes 236 à 239 précédemment décrites. La présente une structure d’une plateforme 100 selon un mode de réalisation de l’invention. La plateforme 100 comprend un processeur 301 configuré pour communiquer de manière unidirectionnelle ou bidirectionnelle, via un ou des bus ou via une connexion filaire directe, avec une mémoire 302 telle qu’une mémoire de type « Random Access Memory », RAM, ou une mémoire de type « Read Only Memory », ROM, ou tout autre type de mémoire (Flash, EEPROM, etc). En variante, la mémoire 302 comprend plusieurs mémoires des types précités. La mémoire 302 est apte à stocker, de manière permanente ou temporaire, au moins certaines des données utilisées et/ou issues de la mise en œuvre du procédé selon l’invention. En particulier, la mémoire 302 peut stocker, de manière temporaire ou permanente, des données relatives aux accords entre première organisation et deuxième organisation, lorsqu’elles sont stockées localement. Le processeur 301 est apte à exécuter des instructions, stockées dans la mémoire 302, pour la mise en œuvre des étapes de la , à l’exception des étapes 223, 233 et 237 qui sont exécutées en dehors de la plateforme 100. De manière alternative, le processeur 301 peut être remplacé par un microcontrôleur conçu et configuré pour réaliser les étapes de la , à l’exception des étapes 223, 233 et 237. La plateforme 100 comprend une première interface réseau 303 apte à communiquer avec la première interface 130. En variante, la première interface réseau 303 et la première interface 130 sont confondues. La plateforme 100 comprend une deuxième interface réseau 304 apte à communiquer avec la deuxième interface 150. En variante, la deuxième interface réseau 304 et la deuxième interface 150 sont confondues. La plateforme 100 peut comprendre en outre une troisième interface réseau 305 apte à communiquer avec la troisième interface 170. En variante, la troisième interface réseau 305 et la troisième interface 170 sont confondues. La plateforme 100 comprend en outre une quatrième interface 306 apte à communiquer avec la première base de données 110. La plateforme 100 comprend en outre une cinquième interface 307 apte à communiquer avec la deuxième base de données. En variante, la première base de données 110 et/ou la deuxième base de données 111 peuvent être intégrées à la plateforme 100, notamment dans la mémoire 302, auquel cas la plateforme 100 ne comprend pas la quatrième interface 306 et/ou la cinquième interface 307. La plateforme 100 comprend une sixième interface 308 agencée pour communiquer avec le registre distribué 120. La présente invention ne se limite pas aux formes de réalisation décrites ci-avant à titre d’exemples ; elle s’étend à d’autres variantes. Procédé de gestion de l’accès à des données de consentement de patients mis en œuvre par une plateforme informatique (100), et comprenant les opérations suivantes : disposer (200) d’une première base de données (110) comprenant des associations entre des données de consentement de patients et des identifiants pseudonymes de patients, et d’une deuxième base de données (111) comprenant des associations entre les identifiants pseudonymes de patients et des informations d’identité de patients ; sur réception (210) d’une première requête d’un premier terminal requérant (140) d’accéder à des données de consentement, la première requête comprenant un identifiant d’un groupe de patients, obtenir de la première base de données un premier ensemble de données de consentement associées à des identifiants pseudonymes de patients, en fonction de l’identifiant du groupe de patients, sans interroger la deuxième base de données ; donner accès (213) au premier terminal au premier ensemble de données de consentement obtenu de la première base de données ; sur réception (220) d’une deuxième requête du premier terminal pour obtenir des données de consentement complémentaires et/ou des informations d’identité du groupe de patients, demander (222) un accord à un deuxième terminal (160) d’un propriétaire des données de consentement du groupe de patients identifié ; en cas de réception (224) d’une validation de l’accord par le deuxième terminal, donner accès (236) au premier terminal aux données de consentement complémentaires et/ou aux informations d’identité d’au moins un patient du groupe de patients identifié. Procédé selon la revendication 1, dans lequel l’identifiant de groupe de patients comprend un identifiant d’étude et/ou un identifiant de site médical, et dans lequel l’identifiant de groupe de patients ne comprend aucune information personnelle individuelle de patients du groupe. Procédé selon l’une des revendications précédentes, dans lequel, en cas de validation de l’accord par le deuxième terminal (160), la plateforme (100) enregistre l’accord sous forme de contrat intelligent dans un registre distribué (120), et dans lequel une exécution (233) de l’accord par le registre distribué provoque une interrogation (234 ; 235) des première et deuxième bases de données (110;111) pour identifier les données de consentement des patients du groupe de patients identifié, avec les informations d’identité des patients du groupe de patients identifié, et dans lequel la plateforme donne accès (236) au premier terminal aux données de consentement identifiées d’au moins un patient du groupe de patients, avec les informations d’identité dudit au moins un patient. Procédé selon l’une des revendications 1 à 3, dans lequel l’accord comprend au moins certains des éléments suivants : - un identifiant d’une première organisation comprenant le premier terminal (140) et un identifiant d’une deuxième organisation comprenant le deuxième terminal (160) ; - l’identifiant du groupe de patients ; - une durée d’accès aux données de consentement complémentaires et/ou aux informations d’identité du groupe de patients Procédé selon l’une des revendications précédentes, dans lequel la deuxième requête est une requête d’obtention d’un accord pour accéder aux données de consentement complémentaires et/ou aux informations d’identité du groupe de patients , dans lequel, sur réception (224) de la validation de l’accord par le deuxième terminal (160), la plateforme (100) enregistre (225 ; 226) ledit accord localement et/ou dans un registre distribué (120), et dans lequel le procédé comprend en outre la réception (230) d’une troisième requête d’accès aux données de consentement complémentaires et/ou aux informations d’identité du groupe de patients, et dans lequel la plateforme et/ou le registre distribué vérifie (231 ; 232) une conformité de la troisième requête à l’accord enregistré, et dans lequel, uniquement en cas de conformité de la troisième requête à l’accord enregistré, la plateforme donne accès (236) au premier terminal aux données de consentement complémentaires et/ou aux informations d’identité dudit moins un patient du groupe de patients identifié. Procédé selon les revendications 4 et 5, dans lequel la vérification (231 ; 232) de conformité de la troisième requête avec l’accord comprend : - une comparaison d’un identifiant d’organisation de la troisième requête avec la première organisation identifiée dans l’accord ; - une comparaison d’une durée requise d’accès avec la durée d’accès ; et/ou - une comparaison entre un identifiant de groupe de patients de la troisième requête et l’identifiant de groupe de patients de l’accord. Procédé selon l’une des revendications précédentes, dans lequel, pour chaque patient, les données de consentement stockées dans la première base de données (110) comprennent un statut de consentement, une information relative à un historique de mise à jour du statut de consentement et un formulaire de consentement, dans lequel le premier ensemble de données de consentement comprend les statuts de consentement des patients du groupe identifié, et dans lequel les données de consentement complémentaires comprennent les historiques de mise à jour du statut de consentement et les formulaires de consentement des patients du groupe identifié. Procédé selon la revendication 7, dans lequel l’historique de mise à jour de statut de consentement, pour chaque patient, est stocké dans un registre distribué (120), et dans lequel l’information relative à l’historique de mise à jour du statut de consentement est un élément d’accès à l’historique de mise à jour du statut de consentement dans le registre distribué. Programme informatique comportant des instructions pour la mise en œuvre du procédé selon l’une quelconque des revendications précédentes, lorsque ces instructions sont exécutées par un processeur (301). Plateforme informatique (100) apte à accéder à une première base de données (110) comprenant des associations entre des données de consentement de patients et des identifiants pseudonymes de patients, et à une deuxième base de données (111) comprenant des associations entre les identifiants pseudonymes de patients et des informations d’identité de patients, la plateforme comprenant : une première interface (303) apte à recevoir une première requête d’un premier terminal requérant (140) d’accéder à des données de consentement, la première requête comprenant un identifiant d’un groupe de patients ; un processeur (301) apte à, sur réception de la première requête : - obtenir de la première base de données un premier ensemble de données de consentement associées à des identifiants pseudonymes, en fonction de l’identifiant du groupe de patients, sans interroger la deuxième base de données ; - donner accès au premier terminal au premier ensemble de données de consentement obtenu de la première base de données ; - sur réception d’une deuxième requête du premier terminal pour obtenir des données de consentement complémentaires et/ou des informations d’identité du groupe de patients, demander un accord à un deuxième terminal (160) d’un propriétaire des données de consentement du groupe de patients identifié, par une deuxième interface ; - en cas de réception d’une validation de l’accord par le deuxième terminal, donner accès au premier terminal aux données de consentement complémentaires et/ou aux informations d’identité d’au moins un patient du groupe de patients identifié.