HackingHealth de Besancon

Comme tous les ans, s’est tenu cette année le HackingHealth à Besancon, du 14 au 16 octobre, en collaboration avec le CHU de Besançon et l’université de Besançon.

Le Hacking Health est un événement qui présente des défis techniques / technologiques liés au vaste sujet qu’est la santé. Cela peut aller de l’amélioration d’un système avancé de mécanique, au développement d’une application web ou bien encore, une solution au décor des chambres d’enfants hospitalisés, effrayés par les poches de sang.

Suite à l’expérience des porteurs de projets, ils ressentent un problème particulier et proposent aux participants du Hacking Health de tenter de résoudre celui-ci, en apportant un regard neuf, une approche différente et des techniques nouvelles.

Les participants sont des étudiants ou des professionnels qui vont donner leur temps pour résoudre ces défis, près de 300 depuis la première édition du HackingHealth.

L’une des équipes qui nous intéresse, était contituée de collaborateurs de Cadoles, qui ont choisi le projet de l’Etablissement français du Sang, autour de la collecte de l’étiquetage des poches de sang collectées auprès des donneurs.

Dans le cycle de vie de la collecte et distribution des poches de sang, l’identification de celles-ci est très importante pour la sécurité des receveurs. Dans la réalité de tous les jours, des erreurs peuvent être commises. Le challenge était donc de trouver une solution afin de limiter au maximum l’erreur humaine. La perte en temps et en ressource est considérable et étant donné l’importance de la disponibilité du sang dans le domaine de la santé, il est intéressant de chercher à améliorer ce système si cela est possible.

Une fois le groupe formé, le vendredi soir, départ pour le Hacking Health à 17h00.

Les porteurs de projets sont là, 7 étudiants et 3 professionnels aussi. Début du brainStorming qui va durer jusqu’à 1h du matin. C’est une partie très intéressante où les porteurs de projets vont devoir expliquer les processus à des béotiens en ne faisant aucun raccourci et répondre à des questions pouvant pourtant être triviales. Après quelques heures, l’équipe a réussi à identifier un problème central, et après diverses propositions, elle s’est arrêtée sur un début de solution qui sera affinée au cours du weekend.

La solution était la mise en place d’une combinaison entre un lecteur de code barre et une application web qui affiche dynamiquement l’évolution de l’étiquetage, établit des étapes de scans et recueille les informations au préalable pour assurer la corrélation entre les informations médicales et le nombre de poches à collecter ainsi que les tubes qui serviront aux analyses.

À partir de là, plusieurs groupes se sont formés pour pouvoir réaliser cette solution:

• Un groupe « développement » chargé de développer une application qui soit fonctionnelle.

• Un groupe de « design » chargé de créer les visuels et de respecter une expérience utilisateur optimale dans le parcours utilisateur.

• Une équipe « matériel » chargée de récupérer un lecteur code barre et de créer les code barre définis.

• Une équipe « pitch » chargée du film de promotion du projet et de la solution pour la présentation à la fin du Hacking Health.

Après 8 heures de sommeil chacun sur le weekend et beaucoup de cafés, l’équipe est parvenu à réaliser un prototype fonctionnel.

L’autre équipe était sur une autre problématique, celle du sport. Les deux porteurs de projets étaient à la recherche de données leur permettant d’annalyser la posture d’un courreur afin d’identifier un potentiel déséquilibre pendant sa course.

Pour arriver à cela, nous avions à disposition des données brutes issues de capteurs (gyroscope, accéléromètre). Notre groupe était consituté de 3 professionels et d’un étudiant. La première soirée a été consacrée à l’identification des besoins, les pistes pour y arriver, l’explication de ce qui avait déjà été fait auparavant par d’autres intervenants mais qui n’avait mené à aucun résultat.

À la fin de cette première soirée, les besoins ont été identifiés, à savoir: ressortir des temps de contact, temps de vol ainsi que la longueur de foulée cycle à cycle lors d’une course.

Le deuxième jour, trois groupes se sont formés:

• un sur l’annalyse des capteurs utilisés afin d’identifier si il y avait un quelconque moyen de récupérer les données sans passer par l’application du constructeur.
• un sur l’annalyse des données brutes issues des différents capteurs afin de ressortir les temps de contact, temps de vol, longeur de foulée
• un sur la création de l’interface permettant la gestion des capteurs ainsi que le relevé de données pour un “patient”

Nous avons identifié que les capteurs utilisés par les porteurs de projets n’étaient pas sous licence libre, leur utilisation dans un but commerciale est interdit. Un des membres du groupe avait une autre solution: un capteur sous licence libre qu’il utilise au quotidien. La suite s’est donc faite uniquement avec l’annalyse des données de ce dernier capteur.

À la fin du weekend, l’équipe a été capable de ressortir les données recherchées par les porteurs de projet, et de rendre des informations pertinentes. Le projet, qui n’était au départ qu’une question de faisabilité/utilité, a obtenu une réponse concrète et favorable.