CHAPITRE 4. GESTION DU PATIENT ET DES DONNEES MEDICALES POUR RSCA
4.3. M ODELE D ’ IDENTIFICATION DYNAMIQUE ET DISTRIBUE DU PATIENT
4.3.2. Description des scénarios d’identification
4.3.2.1. Choix de l’identifiant
La solution proposée doit s’appuyer sur un identifiant complètement anonyme et généré aléatoirement, sans aucun rapport avec le patient. Une des manières les plus simples de générer ce type de numéro est d’utiliser le système uuid1, proposé par P.Leach [177] et présenté sous la norme RFC4122. Ce système génère un nombre aléatoire sur 128bits avec 122bits aléatoires, soit
possibilités. Les probabilités de collision sont extrêmement faibles et l’entropie de l’algorithme en fait un identifiant statistiquement unique.
L’implémentation de l’algorithme au sein des plateformes informatiques est très répandue, que ce soit dans les systèmes, langages de programmation ou même bases de données. Il est disponible nativement sous tout système unix/linux/osx via la commande uuidgen, implémenté dans java sous le paquetage java.util.UUID ou intégré de façon native dans la base de données mysql par la fonction UUID().
1
Universal Unique Identifier Structure 1 ID_struct=s1 Patient_id=1292761 Structure 3 ID_struct=s3 Patient_id=p_83321 Id=c1df98 Id=44bd22 Id=fd1ea9 Patient Master ID=9a33c7 Structure 2 ID_struct=s2 Patient_id=s32av48
4.3. Modèle d’identification dynamique et distribué du patient 155
4.3.2.2. Scénarios d’identification
Ces différents scénarios sont au nombre de cinq : 1. Ajout des données au réseau par un fournisseur 2. Requête de type nominative
3. Requête de type statistique (anonyme)
4. Comportement du service central d’identification 5. Réponse aux requêtes par le service central
1ère phase : Ajout de données dans le réseau sentinelle par un fournisseur de données
Synopsis Un utilisateur souhaite intégrer des données au réseau sentinelle
Il s’identifie sur le serveur grille de son établissement relié au réseau sentinelle
Il « pousse » ses données sur ce serveur
Le serveur grille reçoit les données : Pour chaque entrée reçue, il vérifie auprès du serveur d’identification central l’existence du patient concerné : 3 cas sont à distinguer :
Cas 1 Le patient n’existe pas : taux de rapprochement < limite_bas :
Il insère ce patient dans la base de données en créant un nouvel identifiant
Cas 2 Si ce patient existe déjà (i.e. il est possible de rapprocher l’identité à un autre patient avec un taux de confiance suffisant) -> taux > limite_haut
Alors il récupère l’identifiant de ce patient sur le réseau et l’attribue au patient dans la base Cas 3 Sinon (le taux de confiance est insuffisant) limite_bas < taux < limite_haut
Le serveur place le patient en attente d’une validation manuelle d’un opérateur en comparant visuellement les fiches patient
Cette première phase fait appel à une notion de taux de rapprochement et de seuils limites qui seront discutés au cours de la partie suivante [4.4].
L’insertion de l’identifiant du patient dans le réseau sentinelle se fait en chiffrant les données à l’aide de sa clé publique. Ainsi il n’est pas possible de récupérer l’identifiant « clair » sans posséder la clé privée du serveur concerné.
2ème phase : Requête des données sur le réseau par les associations (type nominatif)
Synopsis Une association souhaite récupérer les données sur un patient
L’utilisateur s’identifie sur le serveur grille de son établissement relié au réseau sentinelle
Il recherche le patient dans son logiciel métier local et effectue une mise en correspondance avec celui stocké dans la base de son serveur grille
Si le patient n’existe pas il faut insérer le patient en procédant de la même façon qu’en phase 1
Une fois l’identifiant récupéré depuis le serveur de grille:
Il est maintenant déchiffré via la clé privée de l’association
Il est de nouveau chiffré avec la clé publique du serveur central d’identification
La requête est maintenant envoyée au serveur d’identification (voir phase 4) Une fois la requête transmise, à chaque nouveau message :
156 Chapitre 4 : Gestion du patient et des données médicales pour RSCA
Il récupère les résultats préalablement chiffrés par sa clé publique
Il déchiffre le contenu du message au moyen de sa clé privée
Il insère les données dans la base de données en prenant soin de chiffrer à nouveau l’identifiant au moyen de sa clé publique.
Une fois les données insérées, le logiciel métier de l’association peut alors requêter son serveur de grille local pour récupérer les informations.
Passé un délai ou une fois les informations récupérées par le logiciel métier, toutes les données (mises à part l’identifiant) sont supprimées du serveur de grille car elles sont en doublon (par respect des contraintes des fournisseurs)
3ème phase : Requête des données sur le réseau par la santé publique
Synopsis Un utilisateur souhaite récupérer des données statistiques
Il s’identifie sur le serveur grille de son établissement relié au réseau sentinelle
Il transmet une requête au serveur central avec ses paramètres (voir phase 4)
Il attend la réponse et récupère les résultats une fois disponibles
4ème phase : Serveur d’identification
Synopsis Le serveur d’identification central reçoit une demande de données
Il reçoit le message
Il déchiffre son contenu grâce à sa clé privée Suivant le contenu du message deux cas sont à distinguer : Soit c’est une requête statistique :
Il requête alors les différents serveurs de données concernés auxquels a accès l’émetteur de la requête
Pendant un temps défini il attend les résultats
A la réception d’un message, il enregistre les résultats dans une liste
Une fois que les serveurs ont tous répondu ou que le temps a expiré, le message est envoyé à l’expéditeur préalablement chiffré avec sa clé privée
Soit c’est une requête de données nominatives
Il récupère l’identifiant du patient (préalablement déchiffré)
Pour chaque serveur de données « X » disponible et concerné par la requête : o Il chiffre l’identifiant avec la clé publique du serveur « X »
o Il transmet la demande à ce serveur (phase5)
o Pendant un temps défini, le serveur attend les résultats des différents serveurs (voir phase 4)
A la réception d’une réponse :
o Il déchiffre le message avec sa clé privée
o Il transmet ce message à l’expéditeur en prenant soin de le re-chiffrer avec la clé publique de l’expéditeur
4.3. Modèle d’identification dynamique et distribué du patient 157
5ème phase : Réponse aux requêtes par un fournisseur
Synopsis Le serveur de données reçoit une requête
Il reçoit le message
Il déchiffre son contenu grâce à sa clé privée
Il vérifie les droits d’accès de l’émetteur de la requête Suivant le contenu du message deux cas sont à distinguer :
Soit c’est une requête statistique :
Il exécute la requête et renvoie un résultat chiffré au serveur central Soit c’est une requête de données nominatives
Il récupère l’identifiant chiffré et le compare à sa base de données locale
Il renvoie les données demandées si le patient existe en prenant soin de chiffrer la réponse avec la clé publique du serveur central
Avantages et inconvénients de la méthode
Cet ensemble de scénarios a le principal avantage d’amener un haut niveau de sécurité : les données ne sont jamais transférées sans chiffrement. De plus, jamais l’identifiant du patient n’est « en clair » dans le réseau sentinelle. Cette mesure assure en outre que l’identifiant ne peut être mis en relation sans avoir accès à une clé privée d’un site du réseau.
Le rôle central du serveur d’authentification permet d’en faire un nœud centralisé de contrôle de l’accès et le traçage des utilisations, ce qui est une recommandation de l’ASIP-Santé.
Cette agrégation d’identifiant a aussi la possibilité d’intégrer d’autres identifiants ou sources d’identification, comme l’INS-A une fois qu’il sera disponible. De plus, en cas de double ou fausse identification, une modification de la liste des identifiants associés au patient permet de résoudre le problème.
Enfin, le dernier avantage est de créer un réseau où toutes les données sont clairement identifiées, ce n’est pas un simple dépôt non structuré de l’information.
Cependant, cette méthode a des inconvénients non négligeables : le système par chiffrement/déchiffrement peut devenir conséquent lors de la montée en puissance du réseau sentinelle. De plus, la première phase nécessite, par patient, une comparaison systématique avec l’ensemble des patients déjà existants. Des méthodes d’optimisation seront nécessaires.
Enfin, la première phase de rapprochement nécessite une véritable recherche sur la méthode de comparaison de patient, à savoir qu’est ce qui définit une relation entre deux dossiers du même patient ? Comment mesurer cette similarité ? Et aussi quelles sont les valeurs des seuils à fixer limite_bas et limite_haut ?
La [Figure 56] résume les différentes étapes du système d’identification, à partir de plusieurs sources des données concernant un même patient. Les identifiants colorés indiquent les doubles chiffrés de l’identifiant nominal du patient qui ne sont pas visibles « en clair » sans déchiffrement au préalable.
158 Chapitre 4 : Gestion du patient et des données médicales pour RSCA
Figure 56 - Fonctionnement du système d'identification
Cette méthode a aussi l’avantage de séparer en deux couches bien distinctes l’identification des patients et l’utilisation du réseau.
De cette manière la sécurité des informations est un peu plus protégée : une requête en identification ne comporte aucune donnée médicale et une requête en données médicales n’a pas besoin des traits d’identification du patient mais seulement de l’identifiant anonyme et chiffré du réseau.