Santé numérique entre Ptolémée, Copernic et Ulysse

Alors que les technologies évoluent rapidement, la manière de créer des applications de santé reste la même, au bénéfice exclusif de ceux qui les produisent.

Le système géocentrique a été la théorie astronomique dominante pendant environ deux millénaires avant d’être remplacé par le système héliocentrique de Nicolas Copernic. Mais qu’est-ce que tout cela a à voir avec la santé numérique ? La réflexion m’est venue spontanément en réfléchissant à la comparaison entre la vision « app-centric » et « data-centric » dont j’évoquais dans ce post.

Jusqu’à présent, les applications ont été et sont toujours au centre des soins de santé numériques. Tout tourne autour d’eux, y compris les données qui en font partie intégrante. Les entreprises qui développent des logiciels investissent du temps et de l’argent pour créer des applications technologiquement mises à jour et présentant un haut niveau de configurabilité au niveau des processus, des formulaires et des données. Le fait que ceux-ci se trouvent à l’intérieur des applications et soient gérés dans le code ou dans la structure de la base de données détermine une complexité considérable qui se répercute sur une série de problèmes critiques : difficulté à préserver la notion de « produit » par rapport à la « solution personnalisée ». ” ; l’effort pour maintenir et faire évoluer le produit ; la fragilité de certains mécanismes qui, s’ils sont modifiés en fonction d’un besoin, peuvent avoir un impact négatif sur les clients.

Le recours à des architectures de services ou de microservices ne résout pas le problème même si cela l’atténue quelque peu. Le problème réside précisément dans l’approche qui, dans un système de santé de plus en plus complexe et numérique, est limitée par sa nature même.

En me comparant aux éditeurs de logiciels sur ce sujet, je constate combien il leur est difficile de changer de paradigme, c’est-à-dire de point de vue avec lequel concevoir une solution numérique de santé. L’idée de se “séparer” des données est source de scepticisme quant à la faisabilité réelle d’une telle chose et d’inquiétude quant à la possible perte de contrôle sur un aspect fondamental de chaque application.

Les services ou microservices ne sont bons que s’ils fonctionnent avec leur propre base de données, ce que je contrôle entièrement. Séparer logiquement et physiquement les données des applications est un concept compréhensible mais difficile à accepter.

Cependant, à y regarder de plus près, les résistances qui existent ne concernent pas seulement les aspects techniques mais sont également de nature commerciale. Le fait de garder le tout ensemble, avec une logique propriétaire, assure un fort verrouillage de la part du fournisseur qui n’est affecté ni par le transfert de la licence d’utilisation, ni même par celui des codes sources.

Ici donc – vous comprendrez ici ce qu’Ulysse a à voir là-dedans – que placer un système chez un client garantit beaucoup de travail sur un marché captif pour les années à venir. Un sacrifice financier initial, dans la réponse à l’appel d’offres, permet non seulement de récupérer le chiffre d’affaires perdu au fil du temps, mais aussi de défendre sa position auprès du client pendant de nombreuses années. Si l’entreprise de santé souhaite ensuite changer de fournisseur, les coûts et les difficultés de la migration seront à sa charge.

Mais le passage d’une vision « app-centric » à une vision « data-centric » n’est pas le seul aspect à considérer. Certaines réflexions doivent également être menées sur la manière dont les applications sont développées. Nous en parlerons dans le prochain post.