Ouvrir son DPI aux patients, oui, mais comment ?

Ouvrir le DPI d’un GHT peut se faire de trois façons. Soit chaque établissement de GHT déploie une brique logicielle (dans sa DMZ et en mode reverse proxy pour les intimes) pour son propre DPI (si la convergence n’est pas encore atteinte), ce qui suppose que chacun peut se l’offrir, dispose des infrastructures techniques adéquates, saura la maintenir, etc. Soit, deuxième méthode : les DPI n’ont pas encore convergé, mais le GHT monte une brique de type « repository » (un DPI de territoire alimenté par les DPI locaux et accessible uniquement en lecture) qu’il met à disposition des patients. C’est l’approche typique des vendeurs de solutions d’interopérabilité, qui a ses avantages et ses inconvénients. Soit, enfin, les DPI ont convergé, et l’on met à disposition la même brique que dans le premier cas, selon le même protocole technique de déploiement : c’est juste plus gros que le cas 1.

Tout cela se résume à de la technique. Ça finira par marcher un jour, parce qu’il n’y a pas de raison que j’aie accès à mes résultats de laboratoire quand je vais faire mes analyses au labo en face de chez moi, et pas à mon dossier patient quand je vais à l’hôpital. Mais quid des aspects réglementaires, et surtout de la gestion des accès patients, qui est de loin la question la plus compliquée ? 

La gestion des accès patient a pourtant l’air simple a priori : il faut juste donner un identifiant/mot de passe à chaque patient (avec un mot de passe temporaire à changer à la première connexion, on n’est pas tout à fait stupide). Mais où donne-t-on le précieux sésame au patient ? Forcément au seul endroit où on le voit passer en face à face et où sa pièce d’identité est contrôlée : les admissions. Ça ne va pas plaire à tout le monde, quand on sait déjà la surcharge de ces équipes à qui on va en rajouter une louche. Et qui va expliquer au patient comment on se connecte ? Qui va lui répondre quand il ne pourra pas se connecter de son PC personnel ? Qui va faire la hotline quand il aura perdu son mot de passe ou son identifiant ? Certes, on sait renvoyer des mots de passe sur des portables par SMS, on sait mettre en place des jeux de questions secrètes pour recouvrer son identifiant, etc. Mais il va tout de même y avoir le cas du patient qui devra forcément faire appel à une assistance humaine, sans parler des cas où il faudra demander au patient de repasser au CHU (si, par exemple, son adresse postale a changé et que l’on ne peut pas lui envoyer un mot de passe par courrier papier). Un CHU médian compte entre deux et trois millions de patients dans sa base : même avec un taux de perte des accès infinitésimal, on se retrouve vite avec des centaines de personnes qui appellent pour avoir perdu leur accès.

En ce qui concerne la conformité normative, elle tourne autour de deux textes : le RGS (référentiel général de sécurité), qui s’applique à tous les téléservices que les administrations mettent à disposition des usagers, et la réglementation Informatique et Libertés – on ne parle de toute manière plus que de sa mouture de mai 2018, à savoir le RGPD. La bonne nouvelle, c’est qu’en substance ces deux textes disent la même chose : il faut évaluer les risques du téléservice, déterminer les risques non admissibles, mettre en place des mesures de traitement, évaluer les risques résiduels, les accepter formellement et faire un beau dossier tout ficelé qui résume le bazar. Le RGPD a deux ou trois trucs en plus, l’information des usagers, l’accès aux données, etc. (pour ceux qui ne le savent pas déjà, la minimisation, le droit à la rectification et à l’effacement, l’opposition à la collecte des données ne s’appliquent que partiellement ou pas du tout à la santé). La mise à disposition d’une brique DPI pour les accès externes des patients n’est qu’un projet de plus ; le premier qui aura fait le job normatif filera sa copie aux copains, et on pourra factoriser le temps passé.