Peut-être l’un des projets les plus aboutis et novateurs de notre institut, avec des collaborations prestigieuses et des moyens intéressants, ce projet eût pu constituer un bel exemple de collaboration entre le milieu hospitalier et le milieu de l’ingénierie. Des considérations tout à fait annexes (sans aucun rapport avec l’argumentaire médical ou technique) en décidèrent autrement. La documentation technique est accessible depuis cette page.
SAVER (Smart Access to Versatile Emergency Resources) était un projet dont l’idée de base provenait d’un grand hôpital universitaire de Suisse Romande, de son service des urgences plus précisément. En bref, le problème était de gérer les patients au service des urgences : il était (et il est toujours) difficile de suivre l’état d’un patient, de documenter les traitements qu’on lui administrait, etc… Le service des urgences est caractérisé par un fonctionnement chaotique et imprévisible, et disposer de la bonne information au bon moment (Une information adaptée au patient que l’on a devant soi, et concernant les responsabilités du thérapeute concerné) est une gageure. SAVER constitue une interface mobile (basée sur des smartphones) qui permet au personnel soignant de disposer d’une information à jour sur la patient, et au besoin se pose comme un outil de rappel sur des soins urgents à dispenser.
SAVER introduisait pour la première fois l’authentification mutuelle implicite (un thérapeute et un patient sont immédiatement identifiés par le simple fait qu’ils sont en présence l’un de l’autre, et un extrait pertinent de leur dossier médical est immédiatement mis à disposition du thérapeute sur son smartphone ou sa tablette numérique). Il permettait aussi l’introduction rapide (et dans certains cas implicite) d’informations, permettant ainsi au soignant de gagner énormément de temps en lui évitant l’introduction de ces mêmes renseignements par le biais de terminaux requérant une authentification explicite mille fois répétée.
Le prototype étant opérationnel, nous pensions, avec l’équipe des urgences, que nous pourrions opérer un déploiement pilote (il faut noter que l’hôpital n’avait jusqu’ici dépensé aucun centime pour ce développement financé par des fonds publics et privés; seul le service des urgences avait dépensé pas mal d’efforts et de bonne volonté). C’est là que nous nous heurtâmes à un problème que nous n’avions pas anticipé. Le service informatique de cet hôpital était impliqué dans le déploiement d’un outil informatique monumental (un de ces exemples de logiciels monstrueux des années 1980 que l’on appelle communément « usine à gaz »); cet outil avait coûté fort cher, et de ce fait, il devait forcément être parfait, sous peine de s’exposer à des questions politiques embarrassantes. Or, nous arrivions avec une proposition d’amélioration dans notre besace ! On commença par nous féliciter de nos initiatives constructives, mais très vite on nous objecta que le système déployé (l' »usine à gaz », donc) pouvait réaliser la même chose pour peu que l’on installe un tout petit module complémentaire. C’était une affirmation gratuite, car le système en question ne disposait du fait de sa conception tout simplement PAS de la logique nécessaire; mais bon… Nous multipliâmes les efforts pour convaincre, mais nous nous heurtions à l’usine à gaz existante et la crainte des responsables informatiques de se voir confrontés à un outil (le nôtre) qui pourrait faire croire que ce qu’ils déployaient n’était peut-être pas aussi parfait qu’ils l’avaient affirmé. Le manque d’argent, mais aussi une certaine lassitude, finirent par avoir raison de SAVER; mais il n’y a (à l’heure actuelle, fin 2014) toujours pas de système mobile déployé dans l’hôpital en question.
Mais l’histoire ne s’arrête pas là, malheureusement. L’éditeur du logiciel « usine à gaz » a décidé de vendre sa division « systèmes d’informations médicaux » à un concurrent, pour la coquette somme de 1.3 milliards de dollars. Le concurrent ne va pas continuer longtemps à maintenir ladite usine à gaz et proposera un arrangement de reprise à ses clients (surtout que ceux-ci ne sont pas très nombreux, à travers le monde…). Une modification qui va coûter très cher en termes d’adaptation de l’information…
Plutôt que de dépenser des sommes astronomiques pour acquérir un logiciel sur lequel on n’a aucun contrôle, ne serait-il pas plus judicieux de dépenser ce même argent sur des fonctionnalités maintenues par des ingénieurs locaux, que l’on peut contrôler et dont on peut influencer le développement, en collaboration avec des institutions académiques nombreuses dans la région ? De plus, cela créerait des emplois locaux, donc des revenus fiscaux… Peu importe finalement que le logiciel soit d’origine étrangère ou locale, mais on devrait au moins s’assurer de sa pérennité grâce à des équipes locales. Au vu du résultat décrit ici, cela ne coûterait certainement rien de plus, probablement plutôt le contraire. C’est cela aussi, le coût de la Santé…