Alors qu'un grand nombre de sociétés s'excitent pour réinventer la roue autour de la communication interprofessionnelle santé en imaginant tout et n'importe quoi pour pouvoir prendre une marge en passant, il semble que personne ne s’intéresse à la communication électronique médecin (ou pro de santé) vers patient.
À l'heure du RGPD, il est assez étonnant de constater qu'il semble n'ennuyer personne d'envoyer des données médicales, ou même un simple rappel de rendez-vous, sur le mail d'un patient. Ce genre d'échange doit se compter par centaine de milliers chaque jour. J'avoue être surpris de ne voir quasi personne s'intéresser au sujet.
Pour ce qui me concerne, la chose tourne en boucle régulièrement, même si n’exerçant plus depuis en moment le problème ne me concerne pas directement. J'avoue qu'avec mon seul domaine de compétence qui est celui des technos web, je suis assez mal placé pour élaborer une solution de toute pièce. N'étant pas non plus un expert en chiffrage de données et méthodes d'accès protégées, j'ai tout de même essayé d'imaginer une solution simple reposant sur des applications standards pluridécennales. La voici exposée.
Préambule important : la solution proposée ici part du principe que la communication est unidirectionnelle, médecin vers patient. Imaginer une solution bidirectionnelle serait prouver une méconnaissance franche de l'exercice libéral. À l'heure de la pénurie médicale, il me semble parfaitement inenvisageable de laisser penser qu'un médecin pourrait être, tel un employé de centre d'appel, assis derrière son bureau prêt à répondre dans la minute au moindre email ou appel téléphonique. La réalité du terrain est que le burn-out guette chacun et qu'il ne faut surtout pas amplifier la charge mentale des praticiens avec de nouveaux canaux de communication non maîtrisés (sans compter d'ailleurs les risques juridiques liés à faire de la médecine par email) ...
La solution envisagée tourne autour de 3 composants :
- GnuPG pour le chiffrement des données
- Serveur mail pour leur distribution
- Application smartphone pour le patient.
Le point de complexité pour une adoption grand-publique dans le chiffrage des communications électroniques de type mail, c'est l’installation et la mise en service du chiffrage. L'idée est donc d'empaqueter toute cette partie dans une application smartphone, outil devenu synonyme d'informatique personnelle quotidienne pour la majorité.
L'application est téléchargée. L'utilisateur crée un compte local ce qui provoque en arrière-plan la génération d'une paire de clefs GnuPG. La clef privée est protégée par le mot de passe de l'application et/ou l’identification biométrique.
Quand le patient se présente chez un praticien, il ouvre son application et affiche à l'écran un QR code représentant la clef publique.
Le praticien flashe la clef qui s'insère dans les données administratives du dossier patient (c'est déjà possible avec MedShakeEHR v5.10.0 !).
En échange, le praticien communique au patient son adresse de serveur de messagerie (on peut imaginer là aussi un flash code, mais une simple ligne de texte sur l'ordonnance fonctionne ...)
Au quotidien, l'application n'est autre qu'un releveur de comptes POP qui déchiffre du GPG et notifie des nouveaux messages.
Le praticien émet vers son serveur de messagerie sur le compte identifié à partir des données de la clef publique du patient (fingerprint, hash de la clef ?) tout ce qu'il souhaite : rappel de RDV, documents médicaux ...
Je dois avouer que si j'avais une quelconque compétence en programmation d'application mobile, je m'y mettrais de suite (en mode GPL bien évidemment !), mais malheureusement, cela n'est pas le cas. Pour le reste, la solution présentée me semble être ce qu'on peut faire de plus simple, de plus robuste et surtout de plus ouvert. Avis à ceux qui souhaiteraient en discuter ou faire des tests de mise en place avec moi !
Pour ce qui me concerne, la chose tourne en boucle régulièrement, même si n’exerçant plus depuis en moment le problème ne me concerne pas directement. J'avoue qu'avec mon seul domaine de compétence qui est celui des technos web, je suis assez mal placé pour élaborer une solution de toute pièce. N'étant pas non plus un expert en chiffrage de données et méthodes d'accès protégées, j'ai tout de même essayé d'imaginer une solution simple reposant sur des applications standards pluridécennales. La voici exposée.
Préambule important : la solution proposée ici part du principe que la communication est unidirectionnelle, médecin vers patient. Imaginer une solution bidirectionnelle serait prouver une méconnaissance franche de l'exercice libéral. À l'heure de la pénurie médicale, il me semble parfaitement inenvisageable de laisser penser qu'un médecin pourrait être, tel un employé de centre d'appel, assis derrière son bureau prêt à répondre dans la minute au moindre email ou appel téléphonique. La réalité du terrain est que le burn-out guette chacun et qu'il ne faut surtout pas amplifier la charge mentale des praticiens avec de nouveaux canaux de communication non maîtrisés (sans compter d'ailleurs les risques juridiques liés à faire de la médecine par email) ...
La solution envisagée tourne autour de 3 composants :
- GnuPG pour le chiffrement des données
- Serveur mail pour leur distribution
- Application smartphone pour le patient.
Le point de complexité pour une adoption grand-publique dans le chiffrage des communications électroniques de type mail, c'est l’installation et la mise en service du chiffrage. L'idée est donc d'empaqueter toute cette partie dans une application smartphone, outil devenu synonyme d'informatique personnelle quotidienne pour la majorité.
L'application est téléchargée. L'utilisateur crée un compte local ce qui provoque en arrière-plan la génération d'une paire de clefs GnuPG. La clef privée est protégée par le mot de passe de l'application et/ou l’identification biométrique.
Quand le patient se présente chez un praticien, il ouvre son application et affiche à l'écran un QR code représentant la clef publique.
Le praticien flashe la clef qui s'insère dans les données administratives du dossier patient (c'est déjà possible avec MedShakeEHR v5.10.0 !).
En échange, le praticien communique au patient son adresse de serveur de messagerie (on peut imaginer là aussi un flash code, mais une simple ligne de texte sur l'ordonnance fonctionne ...)
Au quotidien, l'application n'est autre qu'un releveur de comptes POP qui déchiffre du GPG et notifie des nouveaux messages.
Le praticien émet vers son serveur de messagerie sur le compte identifié à partir des données de la clef publique du patient (fingerprint, hash de la clef ?) tout ce qu'il souhaite : rappel de RDV, documents médicaux ...
Je dois avouer que si j'avais une quelconque compétence en programmation d'application mobile, je m'y mettrais de suite (en mode GPL bien évidemment !), mais malheureusement, cela n'est pas le cas. Pour le reste, la solution présentée me semble être ce qu'on peut faire de plus simple, de plus robuste et surtout de plus ouvert. Avis à ceux qui souhaiteraient en discuter ou faire des tests de mise en place avec moi !