DPI de GHT : habilitations et contrôles, partie III

Concernant ces dernières, justement, une réflexion s’impose. Certes, tous les DPI de bon aloi stockent les traces (au sens technique du terme) des accès aux données (qui ouvre quel écran, pour voir quoi, pour écrire quoi, pour modifier quoi, à quelle heure, etc.), mais cela ne suffit pas : il faut analyser les traces, et la stratégie à mettre en place comporte plusieurs couches

Première couche, le service en charge d’analyser les traces doit être capable de lancer une requête d’analyse (s’entend au travers d’une IHM normale, et pas en mode grep sur des fichiers texte) sur suspicion ou dénonciation. Ne pas être taillé pour ce faire, c’est être très clairement en faute vis-à-vis de toutes les réglementations habituelles dans ce domaine (RGPD entre autres). L’outil d’analyse doit être en mesure de partir soit d’un patient donné (qui a eu accès à son dossier entre telle et telle date), soit d’un praticien donné (à quoi il a accédé). Attention, les traces sont très verbeuses, et rien que les personnels des admissions ou de la facturation en génèrent des quantités astronomiques. Même avec un bon outil, c’est souvent l’histoire de l’aiguille dans la meule de foin. 

Deuxième couche : le DIM doit pouvoir lancer, à intervalle régulier (tous les mois) des requêtes dont il a défini les aspects fonctionnels mais qui ont pu être fabriquées par la DSI, et pour des cas que l’on sait être des anomalies. Par exemple, un accès à un dossier patient décédé depuis plus d’un an (c’est un exemple) est une anomalie, tout comme l’accès à un dossier patient d’une unité par un personnel soignant d’une autre unité. Etc., etc., etc. Au fur et à mesure de la découverte de nouvelles familles de cas d’anomalies (pas d’inquiétude, la nature humaine est riche en inventivité, il y en aura à la pelle), il faut étoffer la bibliothèque de requêtes mise à disposition du DIM. 

Troisième couche, la bonne vieille technique des pots de miel, qui consiste à créer un dossier patient bien visible (par exemple, celui du directeur général mais avec une légère faute d’orthographe dans le nom de famille) et de positionner des alertes dès qu’un gugusse tente d’y accéder. Je connais un DIM qui procède de la sorte : effet garanti. 

À ce sujet justement, d’aucuns prônent un contrôle accru des dossiers médicaux des patients que sont aussi les agents, au motif que les cas d’indiscrétion les plus courants les concernent. Si le besoin est réel et indiscutable, il pose problème au regard de la réglementation Informatique et Libertés : il implique d’interconnecter les fichiers des agents et celui des patients, et là se pose un souci. Quelle garantie offrir aux agents qu’aucune requête dans la base ne sera passée pour vérifier qui a consulté ou pas ? Le RGPD va peut-être permettre de traiter cela en mode risque, mais avec des conséquences en termes de contrôles additionnels. Je ne suis cependant pas persuadé que le dispositif d’interconnexion soit efficace. Soit l’accès au DP est réalisé par un personnel appartenant à l’unité d’hospitalisation et le caractère indu sera difficile à prouver, soit le personnel qui a accédé au DPI n’appartient pas à la même unité d’hospitalisation et cet accès indu est supposé avoir été repéré par les requêtes génériques. Et surtout, je ne suis pas certain que le risque induit par l’interconnexion des fichiers RH et DPI pour l’agent ne soit pas supérieur au gain hypothétique généré par les contrôles.

Si vous pensez que je délire en matière d’exploitation des traces, sachez que les commissaires aux comptes commencent à demander des preuves d’analyse des traces dans tous les logiciels qui manipulent des flux financiers : GEF, RH bien entendu, mais aussi GAM puisque les actes y sont cotés. Les établissements ne resteront pas longtemps à l’écart des contraintes de l’analyse régulière de ce genre de traces et de rapports écrits traçant ces analyses. Et au sein d’un GHT, il y a aussi fort à parier que dans un DPI de GHT convergé, le RGPD imposera rapidement le même type de dispositif. À bon entendeur…

À suivre.

(1) /article/2834/dpi-de-ght-habilitations-et-controles-partie-i.html 

(2) /article/2844/dpi-de-ght-habilitations-et-controles-partie-ii.html