Dans les coulisses de FarmaFlux

Il y a cinq ans, nous sommes passés d’un reporting des erreurs postérieur aux faits à un suivi en temps réel des systèmes soutenant FarmaFlux. Nous nous sommes entretenus avec Marc Buckens et Jan Lenie, qui nous expliquent ce qui se passe en coulisse.

Routine journalière

Lorsque vous démarrez votre ordinateur à la pharmacie le matin et que vous commencez votre journée tout comme vos quelque 5000 collègues, vous n’espérez qu’une chose : que tout fonctionne. En toute franchise, nous aussi, car nous savons tous les problèmes qui peuvent survenir.

Chaque fois qu’un pharmacien souhaite enregistrer des informations dans le DPP, demander l’historique des médicaments via le PCDH (Pharmaceutical Care Data Hub) ou extraire une ordonnance, il effectue une action (un « call »). Il en résulte toute une série d’actions par seconde depuis – désormais – le corps pharmaceutique dans son ensemble. On peut facilement comparer la chose à la quantité de paiements électroniques d’un samedi de shopping.

L’équipe FarmaFlux suit tous ces calls au moyen de graphiques sur son PC ou smartphone. Jan Lenie : « Il y a actuellement 6000 points de mesure ou RRD (Round-Robin Database)* pour FarmaFlux, où l’on vérifie notamment l’enregistrement des demandes de pharmaciens, le fonctionnement correct des serveurs, etc. Lorsque les graphiques ne présentent pas de pics, c’est une bonne nouvelle. En cas d’anomalie, l’historique nous permet de comparer le graphique du moment à celui du mois précédent ou de la même période l’an dernier, afin de voir s’il s’agit d’un problème temporaire ou non. »

Marc : « Les graphiques montrent aussi le rythme quotidien du pharmacien, comme les pics du matin et la baisse d’activité le midi. Nous veillons à ce que toute l’équipe de FarmaFlux ne soit pas sur la route lors de ces moments de pointe, garantissant ainsi une intervention immédiate en cas de problème. Il est capital d’intervenir rapidement. Nous parvenons même régulièrement à régler les problèmes avant même leur détection sur le terrain. »

Soldes

Jan Lenie : « Il arrive que l’on remarque un problème dans le système nécessitant le redémarrage de celui-ci. Cependant, nous essayons d’éviter une telle situation en journée, car au redémarrage du système, un grand nombre de calls/messages arrivent en même temps, mettant ainsi le système à rude épreuve. Un peu comme une foule de personnes qui se ruent dans un magasin pendant les soldes : ce n’est pas très heureux. En particulier pour les services FarmaFlux, nous pouvons remettre le redémarrage au soir. En journée, tous les messages s’accumulent – leur nombre atteignant très vite plusieurs centaines de milliers – pour être traités soigneusement après le redémarrage. L’idée est une fois encore d’éviter d’impacter la pharmacie proprement dite. »

Travail d’équipe

eHealth a également un droit d’accès et de consultation sur notre suivi. S’ils détectent un problème de notre côté, ils nous envoient un rapport par e-mail. En cas de problème de leur côté, une fenêtre pop-up s’affiche sur le PC de Marc, et les graphiques illustrent une paralysie du nombre de calls et un blocage d’accès des pharmaciens au système. Où que l’erreur se situe, nous sommes généralement en mesure de la détecter en trois minutes. Le moment venu, l’équipe est avertie et tout le monde est paré devant son écran. Si l’erreur a un impact sur le terrain, la communication est lancée. (Découvrez ici qui fait quoi.)

Marc : « Pendant la période estivale, aucune modification n’est apportée aux systèmes pour que l’on puisse (la plupart du temps) partir en vacances l’esprit serein, tandis que la maintenance régulière se poursuit. Un jour, on m’a appelé en vacances et j’ai dû travailler depuis la voiture parce que c’était le seul endroit avec une connexion Wi-Fi. » (Rassurez-vous, un code interne a été convenu pour les urgences.)

Sécurité supplémentaire

Les serveurs se trouvent dans un environnement très sécurisé chez Proximus et comme la connexion à ces serveurs ne peut rester ouverte en permanence, on utilise un système ingénieux pour savoir que tout fonctionne. Un système de journalisation, d’observateurs (logwatchers) et d’alertes nous permet de vérifier le fonctionnement du système et nous informe des erreurs. Toutes les heures, des dizaines de fichiers sont générés avec des valeurs techniques du système – comme on peut le voir sur l’image et la vidéo ci-dessous – et près de 2 millions de lignes défilent sur les écrans, ceci pour le DPP, RaOTD, AssurPharma, etc.

L’ordinateur lit toutes ces lignes à partir d’un système externe et les convertit en graphique, ce qui nous permet de localiser un problème et de le relier à un éditeur de logiciels ou à un pharmacien particulier. Il nous arrive de constater une surcharge des systèmes par une personne, comme un pharmacien consultant 1000 patients toutes les heures, ou de détecter des codes d’erreur qui font référence à des pharmaciens utilisant les services FarmaFlux sans contrat.

Objectif

Marc : « Alors qu’autrefois il fallait des jours pour localiser la pharmacie qui posait problème, on arrive maintenant à la détecter en une dizaine de minutes. L’objectif est de travailler de plus en plus à isoler chaque problème et à y apporter une solution. Nous aspirons à la visibilité et à la stabilité. Les erreurs sont corrigées sur la base d’une compréhension concrète des problèmes. Même si la cause ne vient pas de notre côté, les mesures nécessaires sont prises pour y remédier. Il est également fait appel aux personnes de la plate-forme eHealth, aux éditeurs de logiciels, voire au pharmacien individuel au besoin. Nous voulons aussi, à partir d’un certain nombre de paramètres, créer un graphique synthétisant la situation et le publier sur le site web, comme tel est déjà le cas avec Recip-e via le bouton de statut au bas de la page d’accueil. Pour l’heure, il nous manque cependant les ressources humaines nécessaires : cela fait donc pas mal de temps que nous sommes à la recherche de geeks enthousiastes. »

• ‘RRD tool’ est un outil de gestion de base de données RRD (Round-Robin database) créé pour superviser des données serveur et inclut également un outil permettant de représenter graphiquement les données contenues dans la base. (Wikipedia)