Le temps de prendre connaissance des
RÉFÉRENTIEL RELATIF AUX TRAITEMENTS DE DONNÉES À CARACTÈRE PERSONNEL DESTINÉS À LA GESTION DES CABINETS MÉDICAUX ET PARAMÉDICAUX et
GUIDE PRATIQUE SUR LA PROTECTION DES DONNÉES PERSONNELLES je ne répond que maintenant. Je maitrise encore très mal le sujet et il me semble dans les faits assez complexe implémenter convenablement et dépasse le cadre de la simple intégration de MedshakeEHR car il faut prendre en considération le système d'information dans son ensembles.
En voulant répondre convenablement au sujet je me suis retrouvé à écrire un gros pavé très long... et encore j'ai essayer d'être bref (spoiler : j'ai pas réussi). Pour moi le sujet est un trop gros morceau pour être avalé et digéré d'un coup, je pense qu'il faut le découper en plusieurs problèmes distinct et travailler sur chacune d'entre individuellement, tout en conservant d'un autre coté une vision d'ensemble pour garder le tout cohérent. Je suis certainement pas en mesure de dire la ou doit aller impérativement MedshakeEHR, ce ne sont ici que mes piste de réflexion sur le sujet. J'ai conscience que certaines idée que j'évoque représente un gros travail qui va prendre du temps mais personnellement je me dit qu'il faut toujours mieux passer le temps nécessaire pour disposer de la fonctionnalité parfaitement étudié et adapté pour répondre au problème quitte à disposer des résultat dans plusieurs mois, voire un an s'il le faut, plutôt que ce céder à la tentation d'implémenter des solution rapide et facile mais qui seront bancal et poseront de pénibles soucis pour l'avenir. Du coup quitte à faire des truc autant les faire à fond (c'est partis, chuis un fous moi...) :
Pour ce qui est de MedhakeEHR je pense qu'il se dégage principalement 3 axes de travail :
- le contrôle d'accès aux données
- l'arrivage des données
- le chiffrement des données stockées
Le contrôle d'accès aux données
Bertrand a écrit : ↑01 sept. 2020, 15:55
Un premier point peut être discuté : la question des droits d'accès aux dossiers médicaux pour un utilisateur de type secrétaire. J'ai pour ma part une vision d'homme de terrain : une secrétaire n'est pas dans un cabinet médical uniquement là pour remplacer un système de prise de rendez-vous. Elle doit pouvoir accéder aux dossiers pour prendre des décisions humaines, dans le respect total du secret médical (elle voit de toute façon passer tous les courriers médicaux qui finissent dans les dossiers ...). Avoir l'idée de restreindre son accès n'a pour moi aucun sens.
Dans les fait je suis assez d'accord mais il faut pouvoir ensuite le justifier. Et si MedshakeEHR pouvait intégrer la notion de
"finalité de traitement de la donnée" et que l'on puisse lui en faire découler un système de droit d'accès. Je m'explique : chaque donnée saisie dans le logiciel doit l'être pour une raison particulière, ex : la tenus du dossier médical, le suivie administratif (facturation, contacte, etc..), la prise de rdv, etc... Puis on associe chaque "type" de données (au sens MedshakeEHR) à une ou plusieurs finalité de traitement, par exemple :
- Le nom du patient : il est saisie pour être utilisé lors de la tenus du dossier médical, la prise de rendez-vous et le suivie administratif.
- Le poids du patient : il est saisis uniquement pour la tenus du dossier médical.
Dans la partie sur les mesures que doit adopter le prestataire (p.9) le référentiel évoque la notion de
profils d’habilitation, nous pourrions implémenter cette notion aux utilisateurs en faisant correspondre chaque à chaque compte d'utilisateur des habilitations en fonction de leurs "mission" et en rapport avec la finalité des données à traité. Libre ensuite au responsable du traitement des données de gérer et de définir "la mission" (et donc les habilitations) de chacun des utilisateurs. Cela permettrais presque d'auto documenté le registre des activités de traitement et au minimum de définir explicitement qui traite les données et pourquoi dans la logique même du logiciel.
Bon ok, c'est un peut abstrait comme ça mais mon but est juste de poser une idée général pour ensuite la dégrossir si elle semble pertinente. Je pense qu'en fonctionnant comme ça on aurait plus une logique allant dans le sens "faire coller MedshakeEHR à la réglementation" plutôt que dans le sens "comment faire coller la réglementation à MedshakeEHR ?".
Bertrand a écrit : ↑01 sept. 2020, 15:55
Un second point m'a interrogé : la même question des droits d'accès, mais concernant le prestataire technique qui va mettre en œuvre le logiciel et le maintenir. On peut imaginer qu'avec un accès restreint, il ne puisse complètement assurer son rôle : savoir si le logiciel fonctionne pleinement et assurer le suivi de la configuration. Une piste d'amélioration en termes de secret médical serait de spécifier que cet utilisateur n'a exclusivement accès qu'aux dossiers patients étiquetés dossiers tests.
Bertrand a écrit : ↑02 sept. 2020, 12:02
Sur les techniciens, pas d'habilitation spécifique à ma connaissance, mais une responsabilité du donneur d'ordre de s'assurer que le sous-traitant respecte les règles.
Là il ne faut pas se faire d'illusion : le technicien a open-bar sur les données. Imaginer le contraire serait comme vouloir faire travailler un forgeron sans marteau ni enclume ... mais rien n’arrête jamais la folie administrative alors sait-on jamais ...
Alors oui, de toutes manière dans les fait le technicien a de toutes façon accès à toutes les données car il a un accès directe à la BD. De plus même si on imagine restreindre l'accès du technicien aux données de tests cela peut être handicapant pour le diagnostique de certain problèmes qui peuvent se produire dans des conditions bien particulières et pas évidentes à reproduire sur une fiche test.
A noter aussi que le prestataire doit avoir conclus avec le responsable de traitement un contrat de sous traitance qui doit entre autre spécifier que le prestataire n'accède aux données que sur instruction du responsable de traitement et avec des engagement de confidentialités (dans le respect du secret médical).
Deux autres point relatif que je voudrait brièvement aborder :
- L'authentification forte : Medshake possède déjà un système d'aurification, je ne l'ai jamais utilisé mais elle requiert l'utilisation d'un smart phone et d'un QR-Code. Si possible j'aimerai envisagé des alternative qui ne requière pas l'usage de smartphone et de QR-Code. L'authentification par carte CPS/CPE me semble le moyen le plus naturel, mais dans les fait l'obtention du kit de dévloppement semble lourde et compliqué. De plus certaines profession paramédical ne disposent pas de ces cartes. Je suggère l'utilisation d'une clé FIDO ? Est-ce considéré comme un dispositif d'authentification agrée par l'ASSIP (j'ai pas sur trouver d'informations claire sur le sujet) ?
- Travailler à une meilleur journalisation des accès : actuellement tout est géré dans les logs Apache. La responsabilité engagé en cas de fuite de données est lourde je pense qu'il faudrait envisager un système plus robuste pour monitorer toutes les traces fonctionnels. Chaque action métier dans Medshake pourrait à explicitement logué au saint d'un système de bloc chaîne garantissant son inaltérabilité et qui puisse être sauvegarder simplement et consulter au besoin. On ne logue pas de données spécifique mais seulement les identifiant des ressources accéder, l'action effectué, l'id utilisateur, la date et l'ip (aie je me rend compte que logé l'ip dans une bloc chaine est un pb : c'est un donnée personnel et on ne peut la conservé que pour une durée limité... arf !). On pourrai pas la suite en déduire des système d'audit de sécurité et implémenté des fonction de facilité l'identification et la nature d'une potentiel fuite de donnée (bien évidement que le serveur soit de son coté convenablement configuré).
l'archivage des données
Note rapide : il semble que pour la futur version 8 de php l’encryptions directe des fichier dans les archives zip soient prise en charge :
https://www.php.net/manual/fr/zip.constants.php.
Rappel :
- Les donnés actives sont conservées 5 ans
- Les données archivé sont conservées 20 ans
Bertrand a écrit : ↑02 sept. 2020, 12:02
Si on veut s'approcher le plus de la situation antérieure des dossiers papiers, l'idée pour moi c'est d'avoir à violer/dérober 2 systèmes (la serrure de la porte du grenier où sont entassés les dossiers) physiques, donc 2 ordinateurs distincts. En dessous de ça, c'est prêter le flanc aux interprétations ... et aux sanctions.
Dans un premier temps il me semblais évident que que l'archivage des données devais se faire sur un périphérique hors ligne chiffré (type clés USB ou disque dure externe) en plusieurs exemplaire car je considérai les archive comme des "données mortes" (déstockées de la base de données et conservées uniquement à des fin d'une éventuel restauration "au cas ou"). Dans les fait c'est plus compliqué, les archives sont des données vivantes amené à être modifier car il faut pouvoir "purger" les archives ayant dépassées leur date de péremption (de plus cette durée peut être variable en fonction de la finalité du traitement de la donnée). Il faut donc que Medshake, puisse accéder aux archives simplement pour y effectuer cette opération de suppression (à moins de passer par un outil externe, et de le faire sur toutes les copie des archives). La réglementation n'est pas très explicite : (p.7 "durées de conservation") "sur un support distinct ... dans des condition de sécurité équivalentes à celle des données enregistrés dans l'application.", c'est une peut vague.
Bon personnellement je voit ça comme ça : sur une autres machine du réseau (un praticien ou une secrétaire peut importe il faut juste que celui-ci soit chargé des sauvegardes) on met en place un partage réseau dédié au que les serveur Medshake (et lui seul) peut accéder. Pour type de partage réseau samba aurai été plus simple à mettre en place (surtout sur le postes Windows) mais pour ma part je serai partisan d'un truc plus costaud : un partage webdav avec une authentification via certificat X509 affin de garantir que seul Medshake, puisse y accéder (un simple mot de passe me semble pas suffisant, mais bon peut être que j'exagère que j'essaie "d'enculer les mouche" avec cette histoire). De toutes façon les archives sont chiffrées par Medshake dès leur écriture (du coup jamais stocké en claire). Comme c'est dangereux de conserver les données en un seul exemplaire, le fait que les archives soit redescendus sur une des postes d'un utilisateur permet leur sauvegarde aisé en les synchronisant (en répliquant la suppression des archives avec un outil adapté type rsync) sur un périphérique hors ligne que l'utilisateur emporte avec lui pour disposer d'un sauvegarde hors site.
Pour reprendre l'analogie du grenier :
- Le patage réseau et sa sécurisation représente le grenier et sa porte avec la serrure.
- Les fichier chiffré des archives sont le cassier fermé à clé ou elles sont stockés (sauf qu'ici en dispose d'un copie du casier au cas ou les locaux crament).
Coté Medshake pas de système qui archive automatiquement mais une alerte qui renvoie sur une page listant les données qu'il faut archivé. L'utilisateur voit les données qui seront archivées et valide lui même l'action de les archiver (ce qui permet aussi de notifier explicitement tout pb rencontré). Il faut aussi une page équivalente pour les données devant être purger de l'archive.
Maintenant il faut s'occuper de la manière dont les données sont représenté dans l'archive.
Bertrand a écrit : ↑02 sept. 2020, 12:02
Techniquement, on peut imaginer un zip par dossier patient, passé au chiffrement symétrique avec un process d'export automatique et de réimport à la demande. Et là, le plus drôle, c'est qu'on se heurte à une question métaphysique : faut-il dans le logiciel courant tenir une liste des dossiers archivés, c'est-à-dire une liste nominative ... et avec quelles données dans cette liste (nom, prénom, ddn, ins ... ?). Cette liste doit-elle être incluse dans le listing général, ou dans un listing séparé ... ?
Le point de se que l'on doit archiver et quand est pas très claire pour moi. Apparemment la durée à prendre en compte pour l'archivage des donnée est relative "a la date de dernière prise en charge du patient". Mais :
- Archive t'on d'un coup tout le dossier médical du patient dans son ensemble si nous n'avons pas eu de nouvelles de celui-ci au bout de 5 ans sans prendre en compte les données saisis pour une consultation plus ancienne (si les patient est venus récemment mais qu'il possède des données provenant d'un consultation effectués il y a plus de 5 ans celles-ci ne seront pas archivées car il est venus récemment) ?
- Ou faut t'il archiver les données seuls au fur et mesure en fonction de leur date de saisis/mise à jours (si le patient est venus récemment mais que nous disposons de données de consultations antérieurs aux 5 ans et donc les données de ses consultation doivent êtres archivés seuls a part du dossier patient) ?
Comment identifie t'on à quoi correspond une archive ? Si on tient un listing dans Medshake des données archivées en utilisant les informations d'une donnée elle même[ quote=Bertrand post_id=43 time=1599040974 user_id=52](nom, prénom, ddn, ins ... ?)[/quote] on se retrouve à conserver dans le logiciel une donnée antérieur aux 5 ans qui est non archivé... Du coup je verrai plus ça sous forme d'un fichier "index" (chiffré lui aussi) qui se trouve dans l'archive elle même (que seul Medshake possédant la clé de déchiffrement pourrait lire au besoins pour identifier une donnée et son emplacement).
Si on considère un fichier d'archive par dossier patient il ne faut pas que le nom du fichier permette d'identifier le contenus de l'archive. On peut imaginer que l'on nome ses fichier via un hash sha256 de donnée non informative comme l'id en base du dossier patient (qui normalement est unique) a la quel on ajoute son timestamp de création. Le fichier "index" serai utiliser pour identifier le contenus du fichier en faisant correspondre son nom et son contenus.
Faut aussi voire sous quel forme on encode les données elles même au sein de l'archive (pour leur export mais aussi pour leur import). MedshakeEHR semble pouvoir
produire des document au format XML CDA-R2, je ne l'ai jamais utilisé et je ne connaît pas la norme décrivant ce type de document, je sait juste qu'il s'agit d'un standard pour décrire des données médicale et standardisé leur échange et que son utilisation entre dans
le Cadre'd’Interopérabilité des Systèmes d’Information de Santé. Pourrait on utiliser ce format qui aurai le mérite de pouvoir réintégré les donnée dans dans un autres logiciel médical (15 ans c'est long et le système informatique peut évoluer entre temps). Ce format permettrait il l'ajout de données non prévus dans le standard et qui serai spécifique à Medshake (via des champs spéciaux, normalement avec XML pas de PB mais faudrait pas salopé un éventuel import dans une autre application) ?
le chiffrement des données
Deux opération de chiffrement sont à distingués :
- Le chiffrement des communication avec l'application : dans ce cas pas de problème c'est Apache et TLS qui gère.
- Le chiffrement des données stocké sur le serveur : la c'est déjà plus compliqués.
Pour chiffré les donnés stockés il faut concilier :
- Que les données soit chiffré (et donc aussi déchiffré) de manière transparente (l'utilisateur va par saisir un clé de chiffrement/déchiffrement à chaque saisis).
- Que la clés de chiffrement/déchiffrement ne soit pas stocké en claire sur le serveur (sinon sa sert à rien : si on vole le serveur, on vole la clé avec...).
On peut imaginer que la base de données et les fichier Medshake soit stocké dans une partition LUKs. Mais dans ce cas il faut un moyens au utilisateur de ressaisir la clé à démarrage de la machine (la machine va forcément redémarrer à un moment, pour appliquer une gros mise à jours ou bien lors d'une longue coupure de courant par exemple). En tous cas ça peut vite être compliqué s'il faut faire saisir une clé de déchiffrement du stockage à l'utilisateur au démarrage, j'imagine la situation le lundi matin avec toutes la patientel attend, le stress et la clé de déchiffrement oublié et dans le cas ou il se rappel de quoi on lui parle. Personnellement je pense pas que cette solution soit la meilleur. De plus dans ce cas le secret de chiffrement doit être partagé par tout les éventuels utilisateur.
Pour moi l'idéal serai que les données soient chiffrées lors de leur stockage (et déchiffré en accès) en base "à la volé" (ne pas oublier les documents PDF générés stockés hors base), mais sans que la clé ne soit jamais accessible en claire. Pour cela je propose ceci : on définit une "clé maitresse" qui va nous servir à chiffrer/déchiffrer toutes les données présentes en base mais cette dernière n'est jamais stocké en claire. Elle est elle même chiffré à l'aide du mot de passe du l'utilisateur lui même (pour cela elle doit être crée en même temps que le premier utilisateur). Puis pour chaque nouvelle utilisateur, on crée une nouvelle copie de la clé maitresse qui est a son tour chiffré avec le mot de passe de cette utilisateur (et aucun pb pour changer les mot de passe, il suffit de mettre à jour la "copie" de la clé maitresse). On se retrouve au final avec autant de copie de la clé maitresse qu'il y a d'utilisateur et chacune chiffré avec un mot de passe différent propre à chaque utilisateur. A aucun moment la clé maitresse est présente en claire sur le système. Lorsqu'il s'authentifie, l'utilisateur saisis son mot de passe et peut alors "déverrouiller" sa version de la clé maitresse, par contre pour le reste de la session il faudrait imaginer un cookie spécial qui puisse transmettre le mot passe (c'est possible de faire sans que le mot de passe ne soit jamais présent en claire mais c'est un problème à part entière que je vais pas traité ici) durant le reste de la session.
A noter aussi que dans ce cas, il n'y a pas besoin de partager "un secret" entre plusieurs utilisateurs, du coup un fois le compte d'un utilisateur supprimé celui-ci perd définitivement tout accès aux données.
Par contre cela pose aussi tout un tas de "sous problème" :
- On chiffre quoi et comment ?
- Il faut pouvoir effectuer des recherche en base, sur les données chiffrée et sans pourrir définitivement les temps de réponse. Comment on procède ?
- Comment on fait avec les donnée reçus par le logiciel quant elle son reçut hors connections d'un utilisateurs (par ex via la fonctionnalité "Dropbox" ou réception de courriel ou via n'importe quel autre tache cron) .
- A partir de quel volume de donnée ce fonctionnement est gérable ? Je pense notamment aux modules pour les société scientifique. Je pense que dans ce cas le problème peut être contourné. Ce genre d'installation est visible obligatoirement fait sur des serveur avec agrément HDS du coup je me pose la question de l'utilité du chiffrement des données sur ce genre d'installation.
Personnellement il me faut prendre le temps de me documenté beaucoup plus sur le sujet. Des solutions semblent exister au niveau de mariadb :
https://mariadb.com/resources/blog/tabl ... iadb-10-1/. Faut étudier ça au calme. Je vais pas trop m'étendre sur le sujet ici sinon sa va pas être gérable.
Sinon quelques réflexions :
Pour le point 1. : Sans prendre en compte les fichiers stockés en base, il me semble au doigt mouillé que seul le champ
value de la table
objets_data ai besoin d'être chiffré. Après à mois tout seul je pense pas être en mesure d'apprécier tout les cas de figure (il est peut être aussi utile de chiffré certain paramètres de configuration). MariaDB/Mysql dispose d'instruction
SQL adéquat pour le chiffrement.
Pour le point 2. : Ça me semble compliqué et je suis encore trop mal documenté sur le sujet. Il me semble que l'on peut utiliser les instruction SQL AES cité ci-dessus dans des requêtes de types SELECT, mais pour faire une recherche il faut que le SGDB parcourt tout les enregistrement et les déchiffrent un par un, sa va pas être gérable. Du coup deux piste de réflexion : la création d'index spéciaux comportent pour chaque motifs de recherche (par ex pour un nom quels enregistrements correspondent au motif chiffré sur deux lettres "AB", puis "ABC", etc..), que peut fait le systèmes d'index dans ce cas :
Perso je suis pas assez documenté sur le suget va falloir que je prenne le temps.
Si c'est OK au niveau du système d'index on pourrai s'en servir pour "pré filtrer" les résultats puis limiter le nombre de résultats a déchiffrer pour y trouver notre recheche (utilisation d'un discriminant) dans le cas de recherche complexe.
Et sans aller plus loin je place juste l'idée d'utilisation de cache de donnée en ram.
autres points
Un tout dernier truc, je pense qu'il serait important d'identifier, recenser et documenter clairement les point faibles de MedshakeEHR en ce qui concerne les problématique de respect de la réglementation et plus largement tout autres problème liée à la sécurisations des données peut être par le biais d'une page de Wiki dédié.