Évaluation clinique d'un logiciel de santé : les trois preuves

L’évaluation clinique est le chantier qui décide le plus souvent du calendrier réel d’un projet de logiciel médical — et celui que les équipes techniques comprennent le moins bien, parce qu’il ne relève pas de leur métier.

Les trois composantes du MDCG 2020-1

Le guide MDCG 2020-1 propose un cadre en trois composantes, à établir successivement.

1. L’association clinique valide

Dans quelle mesure la sortie de votre logiciel est-elle associée à l’état physiologique ou à la condition clinique que vous visez ? Cette association doit être bien fondée ou cliniquement acceptée, ce qui s’établit par une analyse de l’état de l’art.

C’est la brique fondatrice : si le lien entre ce que vous mesurez et ce qui compte cliniquement n’est pas établi, la qualité de votre implémentation n’a aucune importance.

C’est aussi celle qu’on peut instruire avant d’écrire une ligne de code, par une revue de littérature — et c’est pourquoi il est absurde de la traiter en dernier.

2. La performance technique

Votre logiciel produit-il correctement et de façon fiable la sortie annoncée, à partir des entrées attendues ? Précision, répétabilité, robustesse aux données dégradées, comportement aux limites.

C’est la composante la plus proche du travail habituel d’une équipe logicielle, et généralement la mieux traitée.

3. La performance clinique

La sortie, correctement produite, est-elle cliniquement pertinente dans le contexte d’usage réel ? C’est la démonstration que votre logiciel produit l’effet attendu chez les utilisateurs visés, dans les conditions visées.

C’est la composante qui coûte le plus cher et prend le plus de temps.

Ce que ce découpage change en pratique

Il permet de séquencer l’effort et d’identifier tôt ce qui bloque.

Un logiciel dont l’association clinique est solidement établie dans la littérature — parce qu’il automatise une mesure cliniquement reconnue — aura une évaluation clinique nettement plus légère qu’un logiciel qui propose un nouveau marqueur. Dans le second cas, c’est l’association elle-même qu’il faut démontrer, et cela relève de la recherche clinique.

Beaucoup d’équipes découvrent trop tard qu’elles sont dans le second cas. Le symptôme est reconnaissable : une promesse produit formulée en termes nouveaux, sans littérature à laquelle s’adosser.

Le lien avec la conception du produit

L’évaluation clinique n’est pas seulement un exercice documentaire : elle impose des choix produit.

La destination revendiquée doit être précise. « Aider au suivi des patients diabétiques » n’est pas évaluable. Une indication, une population, un contexte d’usage et un critère le sont.

La collecte de données doit être prévue. L’évaluation clinique doit être maintenue à jour par les données recueillies après la mise sur le marché. Un produit qui ne collecte rien d’exploitable ne pourra pas alimenter ce suivi — et cela se prépare dans l’architecture, pas dans un tableur.

Le périmètre fonctionnel doit être arbitré. Chaque indication supplémentaire élargit le champ à démontrer. Un produit qui promet trop devient inévaluable.

L’erreur qui coûte le plus cher

Conduire une étude longue et onéreuse sans avoir défini à l’avance la question, le comparateur et le critère de jugement. On obtient alors des données abondantes qui ne répondent à rien.

C’est aussi la raison pour laquelle un cadrage extérieur en amont — y compris auprès des autorités, qui proposent des dispositifs d’accompagnement — est l’investissement au meilleur rendement de tout le parcours réglementaire.