Le poste informatique du médecin

C’est simple tant qu’il n’y a pas de grain de sable

Le poste informatique du médecin est devenu au cours du temps de plus en plus complexe en faisant appel à de nombreux logiciels qui ont parfois besoin des mêmes ressources qui peuvent inter réagir entre elles.

Certaines ressources logicielles travaillent en tâche de fond, comme les composants de lecture SESAM VITALE qui sont indispensables à la lecture des cartes (CPS médecin) et Sesam Vitale (patient) pour accéder :

  • à la facturation SV, signature des lots par CPS et télétransmission à l’Assurance Maladie.
  • aux services Améli Pro.
  • au DMP, via 1 navigateur web ou au travers du logiciel métier lorsqu’il le permet.

Ces composants de lecture de carte sont :

Je vais donc vous raconter une histoire personnelle pour illustrer ces propos :

Je travaille sur un MacBook Pro dernière génération à processeur 2,8 GHz intel Core i7 sous macOS Mojave 10.14.6, mon logiciel métier fait appel à la suite MédiStory et j’utilise FireFox version 75 (64 bits) et Chrome Version 81.0.4044.129 (64 bits) comme navigateurs internet.

Fin novembre début décembre 2019, brutalement, je n’arrivais plus à me connecter au DMP ni par un navigateur web ni par mon logiciel MédiStory version DMP avec affichage d’un message d’erreur « ERREUR GÉNÉRALE NON IDENTIFIÉE  » à la lecture de la CPS après avoir renseigné le code porteur ; mais la sécurisation des lots de FSE, leur télétransmission ainsi que l’accès à AMELI PRO ne posaient pas de problème (l’authentification par CPS se déroulait normalement).

Pensant à un problème de mise à niveau de la sécurisation du DMP devenu incompatible avec les composants SESAM VITALE de mon poste, je l’ai testé avec l’outil CNAM DIAGAM et j’ai remarqué que je n’avais pas les derniers composants installés sur ce poste : j’ai donc procédé à la MAJ via la dernière version de l’ATSAM : 4.50

Au redémarrage même problème pour le DMP mais en plus facturation et télétransmission SV défaillante ! La MAJ avait apparemment corrompu le galss ou le io_comm.prokov…
J’ai réinstallé la suite MEDISTORY et ainsi récupéré la télétransmission mais toujours pas l’accès au DMP

– Le 14 décembre 2019 le message d’erreur était toujours le même « ERREUR GÉNÉRALE NON IDENTIFIÉE ». Dans ce genre de situatin,  une alerte sur la page web à propos du dysfonctionnement de l’accès par les responsables de l’hébergement du DMP aurait été bienvenue !

En effet face à un tel problème le médecin peut se demander s’il ne provient pas de son poste ?

– Chez moi la télétransmission et l’accès à AMELI PRO se faisaient sans problème avec lecture de la CPS et des cartes vitales patients.
– Au niveau de mon logiciel métier, la lecture des cartes vitales était opérationnelle mais l’accès au DMP en erreur !
– Essai d’accès au DMP via le web par CHROME et SAFARI idem
– Contrôle des compatibilités OS, navigateur, versions du GALSS, SrvSVCBAM, Cryptolib CPS : OK les versions sont les bonnes.
– Contrôle du poste avec l’outil DIAGAM : OK
– Appel de l’assistance DMP mi décembre au 0810 331 133 qui me conseille de contacter le Conseiller Informatique Service (CIS) de ma caisse.
– Appel du CIS, son n° est sur répondeur, il est en vacances jusqu’au 06/01/2020 ; je laisse un message et préfère attendre son retour, ayant une relation de confiance avec lui.
– 08/01/2020 le CIS me rappelle et on fixe un RDV au 10 janvier.
-10/01 il constate l’anomalie et me signale qu’il a reçu le matin même un message du national confirmant l’anomalie. Il appelle la hotline DMP et laisse mes coordonnées.
-10/01 j’appelle mon installateur informatique sur le Rhône (BIMP/LDLC), il me donne un RDV tél pour le 14/01.
– 14/01, 11h je lui laisse la main sur mon poste via TeamViewer, il constate l’anomalie et me demande si mon lecteur bifentes a été vérifié ? Il me propose de passer au siège.
– 14/01, 14h je me rends à Limonest chez BIMP/LDLC ; mise à jour du lecteur, test de mon poste avec un autre lecteur… Accès toujours impossible et impossibilité d’associer la CPS.
– 14/01, 17h BIMP/LDLC me rappelle au téléphone me demandant d’essayer de vider les « caches » : je mets à la corbeille le contenu des caches des dossiers CPS et pref CPS sans plus de succès.
-15/01 dans l’après midi je rappelle la hotline DMP qui vérifie mes coordonnées me confirme que le problème vient du DMP et qu’ils y travaillent… L’appel du CIS est noté dans « mon dossier » Je propose de tester le patch correctif dès que les développeurs auront trouvé une solution à ce problème !
– 23/01mail au responsable DMP (Yvon MERLIERE) avec qui j’ai l’habitude d’échanger pour l’informer du problème.
– 26/01 réponse d’YM qui signale le problème à la CNAM et à l’hébergeur WORLDLINE.
– 28/01 échange avec le CIS Rhône, qui n’a pas de nouvelle info.
– 29/01 : par mail d’YM me signale que le correctif serait mis en production sous 1 semaine.
– 08/02 : le correctif n’a pas résolu le problème
– 08/02 YM me répond Argh !! je tiens informé le CIS du Rhône.
– 11/02 je suis rappelé par l’assistance du DMP (une ancienne du GCS SIMPA) qui m’apprend que la BDD de l’ASIP a été étendue à l’ensemble des professionnels de santé et que cela semble poser problème avec certains médecins…
– 12 et 13/02 j’échange avec le CIS du Rhône.
– 13/02 16h je suis rappelé par les informaticiens de WORLDLINE ; RDV pour le lendemain pour tests en ligne.
– 14/02 test de 10h30 à 10h40 avec horodatage et repérage de l’IP de connexion ; constatation de l’erreur à la connexion.
– 18/02 mail de WORLDLINE, RDV pour le 19 pour de nouveaux essais avant et après correctif.
– 19/02 15h 1er essai, adresse toujours en erreur, application du correctif, je relance le navigateur, miracle je peux me connecter via le web !
Merci aux informaticiens de Worlline (notamment Constant) qui ont pu régler ce problème.

J’avais donc récupéré la TLT, l’accès web au DMP mais pas depuis MédiStory avec impossibilité d’associer la CPS et erreur 777.
C’est à ce moment que j’ai contacté par 2 fois l’assistance de mon éditeur, Prokov :
– Le premier intervenant n’a pas appréhendé sérieusement le problème, m’a fait supprimer des préférences notamment de lecteur et était étonné qu’elles réapparaissent au redémarrage du poste ! C’est le 2è (plus ancien chez Prokov) qui m’a mis sur la voie de la Cryptolib CPS en raison de cette erreur 777 !

Avec la crise du Covid j’ai tout laissé en stand-by, je pouvais travailler et j’ai repris la traque de cette erreur le 28 avril 2020 :

Avec l’outil ATSAM de l’assurance maladie, il y a un outil de désinstallation qui fonctionne sous le Terminal.
Entre temps, l’assurance maladie s’est apparemment rendue compte que leur dernière version de l’ATSM (4.5) n’est pas compatible au niveau de la Cryptolib CPS avec l’OS MOJAVE et qu’il ne faut l’installer que pour CATALINA. MOJAVE nécessite la version 4.41 de la Cryptolib CPS.

L’outil ne permet pas de désinstaller les composants séparément mais en bloc, le Galss, le SrvSCCNAM et la Cryptolib CPS : j’ai tout désinstallé, puis réinstallé via l’ATSAM 4.41 et tout fonctionne à nouveau, j’ai pu re associer ma CPS via l’administation du poste et me reconnecter au DMP depuis MédiStory !

En résumé :


Pour MOJAVE il faut utiliser ATSAM 4.41
la bonne version des composants est :
Galss : 3.42.03
SrvSVCNAM : 3.40.02 (que j’ai mis-à-jour en 3.42.02)
Cryptolib : 5.1.5

Pour CATALINA il faut utiliser ATSAM 4.5
la bonne version des composants est :
Galss : 3.43.02
SrvSVCNAM : 3.43
Cryptolib : 5.1.8
Il serait simple d’insérer dans le script d’installation une identification de l’OS avec message d’info en cas de tentative d’installation sur un OS inférieur à CATALINA !

Ressources utiles :
Au bas de la page d’accueil d’AMELI PRO (authentification) vous avez en bas à droite le lien « Configuration » qui pointe vers les les liens de téléchargement des ressources nécessaires :

  • Au diagnostic : DIAGAM, en version windows et MacOS.
  • A l’installation des composants CPS : ATSAM, en version windows et MacOS (attention version pour OS inférieur à Catalina et pour OS Catalina).

Dr Marcel GARRIGOU-GRANDCHAMP, Lyon 3è, CELLULE JURIDIQUE FMF