Développement d'un backend FHIR pour MyGus
Contexte
MyRobotics est une startup française qui commercialise des dispositifs à visée médicale. Leur premier produit, MyGus, est un capteur de goût.
Cette offre est composée d’un capteur physique, d’une application sur smartphone et d’une base de données qui centralise les mesures de goût et les données des patients (figure 1).
Si MyGus est voué à devenir un dispositif de soins, il s’adresse dans un premier temps aux chercheurs intéressés par intégrer la mesure du goût dans leurs protocoles de recherche. Cette stratégie permettra, à travers la mutualisation des données patients, de générer des preuves qui seront utilisées pour justifier d’une mise sur le marché médical.
MyRobotics s’inscrit dans une logique de développement de dispositifs médicaux en général. MyGus ne sera que le premier produit. Dans cette optique, les briques logicielles développées dans le cadre de cette offre pourront être amenées à être réutilisées et étendues.
Mission
MyRobotics a confié à Akimed la conception et l’implémentation d’une plateforme logicielle de mutualisation des données patient, récoltées à partir de l’application mobile, afin de générer des preuves sur l’efficacité de la mesure du goût.
La solution retenue est un serveur FHIR complété par un microservice d’authentification
FHIR
FHIR est un standard émergent de structuration de la donnée médicale. Utiliser FHIR vous permet non seulement de rendre vos logiciels plus interopérables, mais également de gagner en temps de développement et en rigueur (les concepts, les ontologies et les terminologies médicales n’ont pas à être repensés puisqu’ils existent dans FHIR). Utiliser FHIR, c’est également un gage de qualité que vous pouvez facilement communiquer à vos clients, utilisateurs et actionnaires.
Méthodologie
Nous avons découpé notre travail en sprints de deux semaines chacun. Les sprints ne démarrent que lorsqu’un cahier des charges et une liste de livrables ont été établis et se concluent par la transmission d’un rapport écrit qui rapproche le travail transmis du cahier des charges et des livrables. Le premier sprint était un sprint de conception, les deux sprints suivants étaient des sprints d’implémentation.
Lors du sprint de conception, nous nous sommes attachés à préciser les besoins du client à partir des maquettes de l’interface utilisateur qui nous ont été transmises sur InVision. Nous avons ensuite précisé les ressources FHIR à mettre à contribution, écrit des profils pour ces ressources FHIR qui rendent compte des contraintes sur le contenu de ces ressources (pour préciser, par exemple, ce qu’est une mesure de goût), spécifié les API REST correspondantes et les scénarios d’utilisation de ces API REST (par exemple, quels appels d’API sont à effectuer pour créer un patient, l’associer à un protocole de soin, …). Cette phase de conception a été supportée par un validateur de conformance FHIR que nous avons écrit et qui nous permet, en intégration continue de notre spécification, d’en vérifier la cohérence interne. Ce validateur, en produit dérivé, génère une documentation de l’API qui est consultable en ligne, sur un site Web, pour faciliter la communication avec les développeurs frontend (figure 3).
Cette phase de conception a été également l’occasion d’investiguer et de s’aligner sur un certain nombre de choix techniques. C’est ainsi que nous avons décidé de partir sur un framework unifié d’API, basé sur du Kotlin, HAPIFHIR pour le serveur FHIR et vertx.io pour les microservices REST non-FHIR (figure 4).
Les sprints d’implémentation se déroulaient sur un thème précis. Les livrables étaient des images Docker, un docker-compose, des dictionnaires de terminologie médicale, une documentation technique détaillée et une intégration continue sur Github qui lance les tests unitaires, d’intégration et d’acceptance à chaque commit.
Impact
En six semaines seulement, Akimed a fourni à My Robotics une solution complète de gestion des données patient, basé sur FHIR, une norme largement utilisée en informatique médicale.
Le « plus » Akimed
Nous avons une fine compréhension de la structuration des données médicales et de la norme FHIR en particulier qui nous permettent d’avancer vite et de vous assurer une maîtrise du budget.
Nous avons développé une méthodologie basée sur une génération automatique de documentation pour lier, d’une part, la conception de l’ontologie médicale et des API non FHIR et, d’autre part, l’implémentation du backend proprement dite.
