Quand un logiciel de santé devient-il un dispositif médical ?

Pour une équipe qui développe un logiciel de santé, la réponse à cette question change la durée et le coût du projet. Le même code peut porter une charge de conformité très différente selon la façon dont le produit est défini.

Imaginez deux applications. Toutes deux recueillent les symptômes saisis par l'utilisateur, exécutent un algorithme et renvoient une liste. Le code est presque identique. L'une relève de la réglementation relative aux dispositifs médicaux, l'autre non.

Ce qui fait la différence, c'est le texte descriptif dans la boutique d'applications. La première dit « informe sur les affections possibles selon vos symptômes ». La seconde dit « évalue vos symptômes et affiche le diagnostic probable ». Cette seconde phrase fait de ce produit un produit présenté à des fins de diagnostic, et cela déclenche la classification du risque, l'évaluation de la conformité, le dossier technique, l'évaluation clinique et les obligations de surveillance après mise sur le marché.

C'est l'erreur la plus coûteuse et la plus facilement évitable que je constate dans les projets de technologie de santé. La description du produit est rédigée par l'équipe marketing, personne ne réfléchit à sa conséquence juridique, et le produit se retrouve soumis à un régime de conformité qu'il n'avait jamais été prévu d'assumer.

La finalité d'usage est un texte juridique

La règle pratique qui en découle est la suivante. La description du produit doit être rédigée avec le même soin qu'une politique de confidentialité et faire l'objet d'un examen juridique avant sa publication.

Cet examen ne doit pas se limiter à la description de la boutique. Le titre sur le site web, la phrase dans la vidéo promotionnelle, l'affirmation dans la présentation commerciale et la formulation dans le document d'assistance peuvent produire le même résultat. Si vous avez écrit quelque part « pose un diagnostic », écrire ailleurs « à titre informatif uniquement » ne retire pas cette déclaration.

La décision doit être prise dès le départ. Si le produit doit être un dispositif médical, le processus exigé par ce régime est mis en place dès le début et intégré au plan comme un poste de coût. S'il ne doit pas l'être, le respect de cette limite dans chaque texte doit devenir une règle de développement du produit.

L'architecture d'accès aux données de santé

L'article 6 de la loi n° 6698 classe les données de santé parmi les catégories particulières de données personnelles et soumet leur traitement à des conditions plus restrictives. La traduction technique de cette qualification reste incomplète dans la plupart des projets.

Le tableau que je constate souvent est le suivant. L'application fonctionne, les données sont conservées, mais dans le système, tout le monde peut tout voir. Le développeur peut consulter la base de données de production, l'équipe d'assistance peut ouvrir le dossier du patient, la personne dirigeante peut voir des données brutes dans les rapports. Cela signifie que l'accès n'est pas limité, ce qui est difficile à défendre lors d'un audit.

La bonne conception commence par un contrôle d'accès fondé sur les rôles, mais ne s'arrête pas là. Chaque accès doit être consigné, cette trace doit indiquer qui l'a effectué et dans quel but, et un accès inhabituel doit pouvoir être repéré. Si quelqu'un ouvre le dossier d'un patient en pleine nuit, cela doit être visible dans le système.

L'environnement de test constitue une question à part. Tester avec de véritables données de patients est l'habitude la plus répandue et la plus risquée en technologie de santé. Travailler avec des données masquées ou synthétiques élimine en grande partie ce risque et n'est pas techniquement difficile à mettre en œuvre.

Aide à la décision clinique et responsabilité

Les systèmes d'aide à la décision assistés par l'intelligence artificielle soulèvent la question de savoir qui est responsable. En pratique, la configuration sûre consiste à ce que le système produise une recommandation et que la décision finale soit laissée au professionnel de santé compétent.

Pour que cette configuration ne reste pas seulement sur le papier, trois éléments doivent être conservés ensemble. La recommandation produite par le système, les données sur lesquelles cette recommandation repose, et la décision finale prise par le professionnel de santé. Si ces trois éléments sont conservés séparément, ils ne pourront plus être recoupés par la suite ; s'ils ne sont pas conservés du tout, il devient impossible de démontrer où se situe la responsabilité.

Il est utile d'y ajouter un indicateur. Il faut suivre la fréquence à laquelle le professionnel de santé rejette la recommandation du système. Si ce taux s'approche de zéro, la supervision humaine est devenue formelle, et à ce stade c'est en réalité le système qui prend la décision lui-même. Ce constat peut être déterminant dans un débat sur la responsabilité.

Les services de santé à distance

Les services de santé à distance sont régis par la réglementation du ministère de la Santé. Les services pouvant être fournis à distance, les obligations d'enregistrement et les limites du service sont fixés par la réglementation secondaire. Cette réglementation pouvant évoluer dans le temps, il faut, lors de la conception du produit, se référer au texte en vigueur.

Le principe qui ne change pas est le suivant. Les situations exigeant un examen en personne ne peuvent pas être prises en charge à distance. Une application de santé à distance doit pouvoir reconnaître une demande dépassant cette limite et la réorienter. Que le système puisse dire « pour cette situation, veuillez consulter un médecin » n'est pas une fonctionnalité d'ergonomie, mais une exigence juridique.

Au lancement d'un projet

Dans les projets de technologie de santé, la question à laquelle il faut répondre lors de la première réunion n'est pas ce que le produit va faire, mais ce qu'il va déclarer être. Chaque ligne de code écrite avant que cette question ait reçu une réponse peut avoir été écrite selon le mauvais régime.

La deuxième question concerne le modèle de données. Quelle donnée est réellement nécessaire, qui pourra la voir, où l'accès sera-t-il consigné et que se passera-t-il une fois la finalité atteinte. La réponse à ces quatre questions détermine directement la conception des tables, et la modifier ultérieurement, en exigeant la migration de données de patients déjà existantes, engendre un problème à la fois technique et juridique.