Conception de l’application mobile Prevent Connect d’aide à la prévention personnalisée du
risque cardio-vasculaire

Conception de l’application mobile Prevent Connect pour le choix d’interventions numériques de santé 4.1 Conception de l’application Prevent Connect Lors de ma deuxième année de thèse j’ai supervisé le travail de deux stagiaires au LIMICS. Le premier étudiant Marc Fouque a effectué du 8 avril au 14 juin 2019 « une modélisation UML41 du processus de choix de recommandations personnalisées pour la prévention de risques cardiovasculaires » lors de son stage de première année du Master Sciences Technologies Santé Mention Santé publique, université de Bordeaux, ISPED (Institut de Santé Publique d’épidémiologie et de Développement). Le second étudiant Matteo Brandi a effectué du 3 juin au 26 juillet 2019 « la réalisation de l’application mobile et de son serveur web sur la prévention des risques cardiovasculaires », lors de son stage de première année de cycle ingénieur l’ENSIIE (l’École Nationale Supérieure d’Informatique pour l’Industrie et l’Entreprise). Une synthèse des documents ayant servi à la conception de l’application Prevent Connect se trouve dans ce chapitre, en annexe C (Fouque M, 2019) et (Brandi M, 2019). 4.1.1 Spécifications fonctionnelles42 et scénario d’usage43 La Figure 32 représente le processus de choix des interventions numériques de santé qui est constitué d’une chaîne de décision automatisée intégrant 4 étapes (classification des groupes de comportements, associations des recommandations, association d’une liste des interventions numériques de santé, sélection d’une liste d’INS adaptées).

Étape 1 : Associer le comportement de l’utilisateur à une liste de recommandations générale

. À cette étape, la liste exhaustive des recommandations générales extraites de source officielle est attribuée au quadruplet de l’utilisateur. Par exemple, les recommandations pour un sujet présentant un comportement [0-1-0-1] seront « cesser de fumer en consultant un professionnel de santé, car il est difficile d’arrêter de fumer seul » et b) « pratiquer une activité physique quotidienne et régulière, équivalente ou supérieure à 30 min ». Étape 2 : Affiner l’ensemble des recommandations en fonction des facteurs de risque cliniques que présente l’utilisateur. Bien que ce ne soit pas toujours le cas, les facteurs de risques cliniques peuvent être liés aux comportements. Dans ce cas, il est admis qu’un changement de comportement positif peut réduire le facteur de risque et prévenir l’installation ou la survenue de certains événements cardio-vasculaires. Par exemple, une alimentation équilibrée peut avoir un impact positif sur l’obésité ou le diabète d’un sujet, et une réduction de la dépendance à l’alcool peut permettre de réduire les troubles du sommeil. L’objectif de cette étape est donc de sélectionner la liste des actions correspondant aux recommandations en tenant compte de la situation clinique afin de cibler les comportements à changer chez un utilisateur. L’ensemble des actions utilisées dans notre protocole de recommandations est extrait des sources précédemment citées. Ainsi, si l’on reprend notre exemple de l’étape 1 dans lequel le comportement de l’utilisateur était [0-1-0-1] en association avec la présence d’un diabète, la liste d’actions résultante sera un lien vers « tabac info service » et « Bouger plus ». Étape 3 : Sélectionner une liste d’interventions numériques de santé. Nous avons identifié une liste de leviers de e-santé issue de la littérature. L’élaboration de cette liste de services connectés tels que les services de messagerie SMS, et les applications sur smartphones, nous a servi d’exemples. Puis nous avons réalisé une revue systématique relative aux tendances en fonction du type de comportements ou de facteur de risque associées au risque cardiovasculaire. Dans le cadre de notre protocole, un levier de e-santé est affecté à un utilisateur si, et seulement si, ce dernier prend en compte un facteur de risque que l’utilisateur indique comme présent.

Ces leviers sont donc en théorie adaptés à l’utilisateur car répondant à ses besoins spécifiques. Tous les leviers qui ne correspondent pas aux critères de l’utilisateur sont exclus. Pour revenir à notre exemple, pour notre utilisateur [0-1-0-1] souffrant de diabète, le premier résultat par filtrage présente une liste des types de services de levier e-santé actuel et émergeant, à lire, ou à connecter ; et des appareils connectés spécifiques à son profil clinique comme un « glucomètre connecté ». Étape 4 : Sélectionner une liste de dispositifs de santé connectés appropriés pour réaliser les actions parmi lesquelles sont identifiés des leviers personnalisés considérés plus efficaces par rapport à leur sexe, leurs critères sociaux ou leur âge. L’informatisation d’un tel système d’aide à la décision nécessite préalablement une préparation, une modélisation et une vérification à l’aide du Langage de Modélisation Unifié (UML) (Fouque M, 2019), puis la mise en œuvre du système.

Spécification technique

L’application réalisée est divisée en plusieurs programmes fonctionnant séparément. Java FX est un cadre d’application et une bibliothèque d’interface utilisateur permettant aux développeurs Java de créer une interface graphique pour des applications de bureau, des applications Internet riches et des applications smartphones et tablettes tactiles. Cet environnement permet de réaliser plus facilement et donc plus rapidement une interface graphique pour téléphone mobile et tablette. (Brandi M, 2019). Gluon mobile est un outil permettant de compiler et de déployer une application Java sur PC ou Mac ; et de produire plusieurs versions de l’application pour ses différents supports depuis le même code source. Au vu du besoin potentiel de fournir l’API à des industriels, il a été assez naturel de choisir une structure Modèle-Vue-Contrôleur. En effet, en plus de tous les avantages de ce choix de structure, cela permet très facilement le développement d’une nouvelle application en incluant le Modèle tel quel, contenant le modèle, les traitements des informations et la préparation des requêtes HTTP vers le serveur, et en remplaçant la vue et le contrôleur en fonction de l’application développée. Cela assure donc que le traitement des données de santé demeure inchangé en plus de faciliter le travail d’un futur développement. Les différents utilisateurs ayant accès à l’application développée dans le cadre de cette thèse peuvent être soit : des utilisateurs de l’application, soit des opérateurs ou des administrateurs possédant des droits propres à leurs responsabilités et missions. L’opérateur et administrateur possèdent deux tables différentes, car il est probable dans le futur que ces deux groupes se voient ajouter des attributs différents.