Combler l'écart entre la théorie et la pratique pour un logiciel en tant que dispositif médical alimenté par l'intelligence artificielle
par Inès D'Heygère
Toute entreprise qui envisage de lancer un Software as Medical Device (SaMD) est confrontée à l'obligation de se conformer à la réglementation applicable dans son pays de commercialisation. Si vous souhaitez commercialiser votre dispositif médical en Europe, vous devrez vous intéresser au marquage CE.
La réglementation en place s'applique à tous les types de SaMD, qu'ils s'appuient ou non sur l'intelligence artificielle (IA), et vous oblige à constituer un dossier technique, c'est-à-dire un ensemble de documents qui démontrent la conformité de votre produit à la législation sur le marquage CE.
Cependant, les spécificités de l'IA sont nombreuses, et l'IA étant une technologie relativement nouvelle dans les laboratoires médicaux, il n'y a pas aujourd'hui d'explications claires sur la manière de les refléter dans votre dossier technique.
Chez ImVitro, nous avons entamé le processus de marquage CE dès la phase de conception du produit et nous avons pu soumettre notre dossier après seulement 4 mois de travail. En tant que directeur des opérations, j'étais chargé de constituer notre dossier technique avec l'aide de consultants spécialisés. Malgré leur aide, nous avons consacré beaucoup de temps à la réalisation du dossier car personne n'était mieux placé que nous pour comprendre en détail notre dispositif médical.
Cet article porte sur les 5 exigences de marquage CE pour les logiciels de dispositifs médicaux alimentés par l'IA qui ont été les plus difficiles pour nous et sur la façon dont nous avons comblé le fossé entre la théorie et la pratique chez ImVitro.
1. Classification de notre dispositif médical
En essayant de définir la classe de notre dispositif médical conformément au nouveau règlement de l'UE sur les dispositifs médicaux (MDR), nous avons été confrontés à une question assez unique : fournissons-nous des informations qui sont utilisées pour diagnostiquer une maladie ou influencer un traitement thérapeutique ?
Notre logiciel, destiné aux experts en fécondation in vitro (FIV), analyse les vidéos d'embryons et les données cliniques des patients pour évaluer le potentiel de chaque embryon à mener à une grossesse.
Un diagnostic est l'identification d'une maladie ou d'un état en fonction des symptômes. Notre évaluation des embryons ne permet pas d'identifier des maladies chez les embryons ni chez les patients qui ont déjà reçu un diagnostic d'infertilité.
D'autre part, un traitement thérapeutique consiste à guérir une maladie, le plus souvent à l'aide de médicaments. Quelle que soit la manière dont il est utilisé, notre logiciel ne guérit pas l'infertilité.
Au regard de ces définitions, il apparaît que notre dispositif médical n'est ni destiné au diagnostic ni à des fins thérapeutiques, et parce qu'aucun dommage ne peut résulter de son utilisation autre que ceux habituels liés à la sélection des embryons, il appartient aux dispositifs de classe I. Ceci a été confirmé par l'ANSM par écrit.
La classification est une étape cruciale, car elle affecte non seulement le calendrier réglementaire pour l'obtention du marquage CE, mais détermine également le rythme des améliorations et des modifications continues après l'obtention du marquage CE. Rétrospectivement, le fait d'être dans la classe I est un atout majeur car il supprime la nécessité de procéder à des audits réguliers ; vous devez cependant être prêt à tout moment pour un audit, et devez donc vous assurer de documenter minutieusement votre produit et toute son évolution.
2. Champ d'application du marquage CE
L'une des premières questions que nous nous sommes posées est celle de la portée de notre futur dispositif médical. Notre produit est composé d'une plateforme SaaS et d'algorithmes d'IA. Même si l'ensemble de notre logiciel est destiné aux soins de santé, seuls nos algorithmes d'IA au sein de notre logiciel ont une utilisation médicale prévue qui répond à la définition d 'un dispositif médical selon le RIM.
Par conséquent, devrions-nous seulement apposer le marquage CE sur nos algorithmes, ou sur l'ensemble de notre logiciel qui contient également d'autres modules (par exemple, l'inventaire des patients, la page de profil, etc.)
Le marquage CE de l'ensemble du logiciel exige davantage de documentation de la part des équipes chargées de la réglementation, de la recherche et du développement au jour le jour, ce qui nécessite davantage de ressources. Parce que chaque fonctionnalité doit être spécifiée, analysée et testée, il y a finalement une perte de flexibilité en termes de sorties de produits.
Le marquage CE d'un algorithme seul n'est pas l'approche standard mais elle est devenue plus courante ces dernières années, et aujourd'hui les algorithmes médicaux sont marqués CE et approuvés par la FDA. Pour ce faire, il faut d'abord pouvoir justifier que l'algorithme est entièrement indépendant du reste du logiciel et que l'intention médicale décrite dans le dossier technique est remplie uniquement par l'algorithme en question.
Par conséquent, si la majorité du logiciel ne répond pas à la définition d'un dispositif médical, il peut être plus judicieux de procéder au marquage CE de l'algorithme uniquement.
3. Spécifications des performances
Le RIM exige que les performances du dispositif médical soient incluses dans le dossier technique. La performance du dispositif est définie comme sa capacité à atteindre l'objectif prévu. Pour les algorithmes d'IA, il existe une multitude de métriques qui peuvent être utilisées pour rendre compte de la performance technique. Nous nous sommes donc demandé : quelle métrique devons-nous déclarer ?
Premièrement, il n'y a pas une seule bonne réponse. Deuxièmement, cette mesure peut être différente de celle que vous communiquez à vos clients si nécessaire.
Chez Imvitro, un premier choix aurait pu être de rapporter uniquement la précision. Mais cette simplification excessive présente des inconvénients, car le fait de ne rapporter qu'une seule métrique ne fournit pas suffisamment d'informations pour décrire le comportement et l'évolution d'un algorithme. Il y a généralement un compromis à faire entre les métriques pour atteindre les améliorations visées.
Nous avons décidé de rendre compte des trois paramètres suivants, qui semblaient également être une pratique courante dans d'autres start-ups de santé basées sur l'IA que nous avons contactées : précision, sensibilité et spécificité.
Nos mesures sont calculées sur un ensemble de données de test, comme il est courant dans l'apprentissage automatique. Contrairement à l'approbation de la FDA, il ne semble pas y avoir, à ce jour, d'exigences réglementaires sur le rapport des performances des algorithmes d'apprentissage profond ni sur les ensembles de données utilisés pour former, valider et tester.
Nous avons fait l'effort de sélectionner et de documenter notre ensemble de données de test initial dès le début du processus et nous nous sommes assurés qu'il comprenait un large éventail de situations cliniques pour prouver nos performances. Nous gardons trace de tout changement et fournissons systématiquement des justifications pour expliquer pourquoi les corrections étaient nécessaires (par exemple pour modifier la distribution des patients afin de mieux démontrer nos affirmations, pour supprimer les biais ou pour augmenter la taille de l'ensemble). Apporter des changements à l'ensemble de tests n'est pas trivial et vous devez en tout cas être en mesure de calculer les performances sur le même ensemble de tests pour toujours démontrer la non-infériorité au fil du temps et des versions.
4. Analyse de risque sur les algorithmes
L'analyse des risques liés à la sécurité du produit est un autre exercice difficile que nous avons mené au début du processus de conception. Alors que de nombreux risques liés aux logiciels sont facilement identifiables et atténuables (ceux découlant d'un problème de réseau, d'une défaillance du système, d'une faille de sécurité), ceux propres à l'intelligence artificielle sont plus difficiles à identifier par anticipation.
Les risques classiques connus pour les algorithmes de Deep Learning concernent les données d'entrée, qui sont vulnérables aux biais, le développement lui-même, qui est sujet à des erreurs humaines ou à des choix non optimaux, et les résultats, qui peuvent être interprétés ou utilisés de manière inexacte(1).
Dans la mesure du possible, l'entreprise doit mettre en œuvre des mesures de protection "dès la conception" pour atténuer ces risques. S'assurer que les résultats sont correctement interprétés ou utilisés peut être résolu par des mesures d'atténuation de la convivialité, c'est-à-dire en optimisant l'interface utilisateur pour éviter les erreurs humaines. Cependant, s'assurer que le développement et les résultats ne contiennent pas de biais ou d'erreurs humaines est plus complexe en raison de l'aspect "boîte noire".
Mais quel préjudice relatif le patient ou l'utilisateur peut-il subir dans ces dernières situations si l'algorithme s'est avéré plus performant que le médecin seul ? Est-ce un risque pour le patient, si l'utilisation d'un tel algorithme peut encore améliorer son traitement ? Faire des faux positifs est-il un risque, si l'algorithme est moins performant que le médecin ? Rappelez-vous que tout dépend de l'utilisation prévue de votre dispositif médical et de ses revendications : c'est-à-dire que si vous revendiquez une non-infériorité ou une supériorité clinique, ou si vous ne garantissez que des performances absolues, les risques associés peuvent changer.
Dans tous les cas, même si tous les risques n'ont pas pu être identifiés efficacement ou en temps voulu, les risques liés aux algorithmes doivent être traités dans le cadre d'un effort à l'échelle de l'entreprise, avec une organisation appropriée et des processus bien pensés. La conception et le développement doivent mettre l'accent sur la gestion des données, le test des algorithmes, la validation et le suivi une fois que le produit est utilisé.
5. Modifications majeures ou mineures
Une start-up évolue généralement à un rythme rapide et doit s'adapter de manière très agile. Il peut être nécessaire d'apporter des modifications au produit pour plusieurs raisons : nouveaux besoins des utilisateurs, données supplémentaires disponibles, optimisation des paramètres, développements technologiques, etc.
La réglementation sur les dispositifs médicaux impose un contrôle strict des modifications, et notamment des modifications importantes. Pour les dispositifs médicaux de classe II et III, un changement significatif nécessite l'approbation d'un organisme notifié. Pour une classe I, c'est plus permissif, mais un changement significatif a au moins un impact sur son identification (UDI-DI), la déclaration de conformité et le dossier technique, il est donc important de l'identifier afin de modifier l'enregistrement, et d'être préparé en cas d'audit inattendu.
Cependant, la définition des changements significatifs est plutôt vague. Dans le guide MDCG 2020-3, tout "changement d'algorithme" est considéré comme significatif, mais pour nous, certains changements sont sans aucun doute mineurs.
Nous avons discuté avec des consultants et avec des pairs de start-ups plus avancées et avons appris que leurs organismes notifiés avaient accepté de classer certaines modifications de l'algorithme comme mineures, à condition que les performances résultantes n'aient pas diminué suite à la modification.
En pratique, chez ImVitro, nous discutons d'abord des changements souhaités lors d'une revue de conception afin de nous aligner sur leur niveau d'importance. Ensuite, les demandes de changement sont créées par les développeurs principaux de manière à ce que leur description soit compréhensible pour l'équipe réglementaire. Troisièmement, l'équipe de réglementation documente les impacts à l'aide du guide MDCG 2020-3 sur les changements importants et les approuve. Quatrièmement, l'équipe de recherche et développement fournit une analyse et une conclusion sur les nouvelles performances après le développement. Enfin, la demande de changement est clôturée après le lancement, et chaque étape est tracée sur des documents signés par au moins trois membres de l'équipe.
Si vous cherchez d'autres exemples de modifications qui peuvent être justifiées comme mineures, je vous suggère de vous référer au cadre réglementaire proposé par la FDA pour les modifications des logiciels basés sur l'IA/ML en tant que dispositif médical.
Conclusion
Les normes et réglementations sont encore en train de rattraper l'IA, vous devez donc être attentif aux changements d'exigences et être prêt à agir. Les nouvelles lois, notamment la loi sur l'intelligence artificielle, devraient répondre à certaines de nos questions les plus pressantes.
Si vous avez des doutes lors de la constitution de votre dossier technique, je vous recommande de vous rapprocher d'autres start-ups d'IA dans le domaine médical.
Ne sous-estimez pas la dette technique que vous pouvez accumuler si vous n'imposez pas de bonnes habitudes dès le départ à l'ensemble de l'entreprise. Ne sous-estimez pas non plus les efforts nécessaires pour maintenir votre dossier technique au fil des versions du produit. Nous avons récemment engagé un responsable QARA qui assure notre conformité au quotidien et travaille de temps en temps avec des consultants.
Outre le marquage CE, nous avons décidé chez ImVitro de passer également la certification ISO 13485 sur notre système de gestion de la qualité (SGQ), qui nécessite plusieurs audits externes, afin de consolider nos processus internes et de rassurer les parties prenantes externes sur le fait que nous prenons très au sérieux la conformité réglementaire.
Même si cela peut sembler lourd, le respect de toutes ces exigences réglementaires a rendu notre entreprise plus forte et garantit que nous travaillons en toute sécurité pour mieux aider les patients, qui sont au cœur de notre mission.