Là où il faut aller (impérativement)

Les sujets de cette catégorie concernent le développement du logiciel MedshakeEHR.
Avatar de l’utilisateur
Bertrand
Messages : 177
Inscription : 21 juil. 2020, 18:08
Localisation : Dans le grand bain
Contact :

Là où il faut aller (impérativement)

Message non lu par Bertrand »

Ce message pour indiquer cette ressource :
https://t.co/7ZeW88jJmi?amp=1

C'est le "RÉFÉRENTIEL RELATIF AUX TRAITEMENTS DE DONNÉES À CARACTÈRE PERSONNEL DESTINÉS À LA GESTION DES CABINETS MÉDICAUX ET PARAMÉDICAUX"

Comme vous le constaterez, MedShakeEHR valide à mon sens une très grande majorité des exigences.

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.

Un second point m'a interrogé : la même question des droits d'accès, mais concernant le prestataire technique qui va mettre en oeuvre 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.

Enfin, une vraie interrogation existe sur le chapitre 7 de ce document :
Au regard des finalités de gestion du cabinet médical ou paramédical, les données enregistrées dans l’application peuvent être conservées pendant une durée de vingt ans à compter de la date de la dernière prise en charge du patient: en base active, pendant une durée de cinq ans à compter de la dernière intervention sur le dossier du patient, puis, à l’issue de cette période, sous la forme archivée sur un support distinct pendant quinze ans, dans des conditions de sécurité équivalentes à celles des autres données enregistrées dans l’application.
Je ne connais aucun système qui effectue cela, mais cela existe surement. Comme l'indiquait un twittos : ce qui se conçoit pour un dossier papier, c'est-à-dire le monter au grenier dans une armoire fermée à clef, prend ici une toute autre dimension avec des enjeux techniques importants :
- quid du désarchivage simple au retour du patient à 5 ans et 1 mois (certaines disciplines voient les mêmes patients très rarement)
- quid du désarchivage au bout de 10 ou 15 ans, par exemple à la demande de la justice, ou dans le cadre d'une alerte médic tardive (rechercher dans ses patients qui a pris la molécule tartanpion par le passé) ?
- quid de la pérennité du support qui contient les archives : quid de sa durée de vie physique, quid de son format technique (qui peut lire aujourd'hui une disquette ...), quid de la lecture ultérieure de fichiers au format ancien ?

Bref, ce document est à consulter par chacun pour bon nombre de raison et pour ceux qui s'intéressent au développement de MedShakeEHR, car il gouverne en quelque sorte les priorités que doit suivre la vie de ce soft.

B.

MedShakeEHR : Le Logiciel Médical Modulaire Libre
http://www.medshake.app/

MedShake : communauté médicale bien fraîche (et un peu secouée) !
https://www.medshake.net/

marsante
Messages : 175
Inscription : 25 juil. 2020, 18:42

Re: Là où il faut aller (impérativement)

Message non lu par marsante »

J'ai vu passer la note il y quelques semaines et je m'étais fait la réflexion qu'en effet je ne connais pas de logiciel procédant ainsi. Je m'étais aussi fait la réflexion qu'avec MedShakeEHR et Linux sous le capot, il y aurait bien tôt ou tard moyen d'automatiser la chose. Ce qui me pose question c'est : est ce que chaque temporalité doit être sur un appareil différent (support distinct, mais est-ce qu'un deuxième DD dans un ordi est considéré comme un support distinct ?) ? Sinon s'il y a la possibilité de maintenir toutes les temporalités sur la même machine à priori ça sera l'affaire de script pour exporter/importer la base de données si telle ou telle condition. Et comme une personne ici c'est déjà un jour pris pour Dieu en créant Village People, et vu le nombre de conditions à prendre en compte, je suis confiant :D . Sinon ça sera plus compliqué en effet.

Concernant les contrôles d'accès, je ne connais pas suffisamment le statut d'une secrétaire médicale, je pensais naïvement que le secret médical s'appliquait et qu'il suffisait juste de signaler dans sa déclaration RGPD qu'elle avait accès aux données dans le cadre de son travail. Concernant la possibilité d’étiqueter des patients tests bonne idée. Est-ce qu'il existe des techniciens habilités à traiter des données de santé ? Par exemple si un médecin demande à un technicien d'exporter son ancienne bdd et de l'importer dans MedShakeEHR il y aura forcément un moment où le fichier sera en clair ?
Avatar de l’utilisateur
Bertrand
Messages : 177
Inscription : 21 juil. 2020, 18:08
Localisation : Dans le grand bain
Contact :

Re: Là où il faut aller (impérativement)

Message non lu par Bertrand »

Concernant l'archivage, je pense qu'il serait difficile à vendre que 2 ssd / hdd dans une même machine soient un fonctionnement respectueux de la consigne donnée ...
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.
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é ... ?

Sur les dossiers tests, c'est déjà existant. Il y a un champ en zone de config où on peut rentrer les id des dossiers tests, séparés par une virgule. Les pièces de ces dossiers n'entrent pas dans les stats.

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 ...

B.

MedShakeEHR : Le Logiciel Médical Modulaire Libre
http://www.medshake.app/

MedShake : communauté médicale bien fraîche (et un peu secouée) !
https://www.medshake.net/

Avatar de l’utilisateur
Indelog
Administrateur
Messages : 71
Inscription : 10 juil. 2020, 10:06

Re: Là où il faut aller (impérativement)

Message non lu par Indelog »

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é.
DEMAREST Maxime (Indelog)
Avatar de l’utilisateur
Bertrand
Messages : 177
Inscription : 21 juil. 2020, 18:08
Localisation : Dans le grand bain
Contact :

Re: Là où il faut aller (impérativement)

Message non lu par Bertrand »

le contrôle d'accès aux données
- Effectivement considérer de façon unitaire chaque type de donnée est sûrement la solution ultime. La solution intermédiaire peut être aussi de se baser sur les catégories ou les groupes de données. Si on considère 2 droits, lecture et écriture, cela fait mettre en place un système très conséquent.
- l'authentification forte CPS : elle doit se faire au niveau du navigateur et du serveur apache, tout est prévu. Et oh surprise : c'est déjà discuté sur le repositorie https://github.com/MedShake/MedShakeEHR-base/issues/31
- la journalisation des accès : pourquoi pas améliorer les choses. L'intérêt du log Apache c'est que tout est déjà fait et qu'en plus c'est dans une couche sous-jacente, ce qui au niveau sécurité me semble pas mal.

l'arrivage des données

À mon avis tu vas trop loin en imaginant que dans l'archive d'un dossier patient spécifique il faille intervenir pour purger certaines données. L'archivage d'un dossier patient, c'est tout ou rien. D'ailleurs on ne doit pas pouvoir intervenir pour ne pas altérer les données. En gros ne pas pouvoir tricher en cas de mise en cause par exemple. Le processus doit donc être un simple archivage intégral, une fonction de réimport sans destruction de l'archive et une fonction de consultation du dossier archivé.
Ce dernier point est sûrement le plus problématique, sauf si à l'archivage, tous les documents sont convertis aussi vers un format standard consultable de façon autonome. Pourquoi pas du XML CDA-R2 ... mais ce format n'est pour le moment pas grand-chose de plus que de l'encapsulation de PDF dans une trame XML. En tout cas, ce serait un choix d'avenir.

le chiffrement des données

Je pense qu'il ne faut pas chercher trop compliqué : ce que j'ai fait moi, c'est le chiffrement de la partition. En cas de vol, comme il y aura coupure électrique, c'est réglé. Pour l'utilisation quotidienne, les coupures réseau longues sont quand même très rares et il faut de toute façon prévoir un onduleur.
Chiffrer en base me semble impossible : on perd toutes les possibilités de recherche sur les données.

B.

MedShakeEHR : Le Logiciel Médical Modulaire Libre
http://www.medshake.app/

MedShake : communauté médicale bien fraîche (et un peu secouée) !
https://www.medshake.net/

Répondre