Validation du logiciel en tant que dispositif médical (SaMD)

Les logiciels dans le secteur de la santé ont parcouru un long chemin au cours des 20 dernières années. Les entreprises de dispositifs médicaux, comme la plupart des entreprises des sciences de la vie, hésitaient un peu à intégrer des logiciels et l’automatisation dans leurs processus. Cependant, les logiciels sont désormais omniprésents à des degrés divers dans toutes les entreprises de dispositifs médicaux. Pendant des années, les pompes à insuline et les stimulateurs cardiaques se sont appuyés sur des appareils physiques avec un logiciel intégré pour fonctionner correctement. Désormais, les utilisateurs peuvent les contrôler via Bluetooth. Même les implants cochléaires peuvent se connecter aux smartphones directement via Bluetooth. Nous avons maintenant atteint le point où le logiciel est le dispositif médical. Alors que cela ressemblait à de la science-fiction il y a 20 ans, les progrès de l’intelligence artificielle (IA) ont ouvert la voie au logiciel en tant que dispositif médical (SaMD).

La validation appropriée du logiciel est un élément important pour garantir la conformité, la sécurité des patients et la qualité du produit. SaMD ne fait pas exception. C’est suffisamment nouveau pour que les agences gouvernementales déterminent encore comment cela devrait être réglementé. Au début de l’année, la Food and Drug Administration (FDA) des États-Unis a publié son « Plan d’action basé sur l’intelligence artificielle/l’apprentissage automatique (IA/ML) en tant que dispositif médical (SaMD) », mais sa validation est faible. En examinant l’attitude de l’agence envers la validation en général, les entreprises SaMD peuvent valider efficacement leurs logiciels et assurer une amélioration continue.

L’approche basée sur les risques du logiciel en tant que dispositif médical

La FDA a publié ses dernières directives finales pour la validation des logiciels informatiques (CSV) en 2002. Au cours des dernières années, le Center for Devices and Radiological Health (CDRH) de la FDA a décidé qu’une mise à jour était nécessaire et a basculé la conversation sur l’assurance des logiciels informatiques (CSA ). CSA met davantage l’accent sur la pensée critique et l’évaluation appropriée des risques et vise à alléger le fardeau que les CSV traditionnels font peser sur les entreprises des sciences de la vie. Bien que les directives finales ne soient pas encore publiées, la FDA a suffisamment parlé des concepts impliqués pour fournir une image claire de ce qu’elle inclura. Et, étant donné que le CDRH réglemente les dispositifs médicaux, leur attitude envers la validation se répercutera probablement sur le SaMD.

Au lieu de valider toutes les fonctionnalités d’un logiciel, les entreprises de dispositifs médicaux devraient se concentrer sur les domaines qui présentent le plus grand risque. Du point de vue de la FDA, les composants les plus risqués sont ceux qui pourraient affecter la sécurité des patients ou la qualité du produit. Cela a toujours été des problèmes avec les logiciels, mais avec SaMD, il est encore plus important de savoir que le logiciel fonctionne comme prévu. L’un des moyens de garantir cela est d’utiliser une approche d’intégration continue/déploiement continu (CI/CD) pour le développement de logiciels. Cela vous permet de corriger plus rapidement les zones fragiles de votre code et fonctionne mieux lorsqu’il est amélioré par l’IA.

Développement CI/CD

Le but de la validation n’est pas de prouver que le logiciel fonctionne parfaitement. Aucun logiciel ne fonctionne parfaitement. Le but est de s’assurer que les défauts du logiciel ne changeront pas radicalement la qualité globale ou ne compromettront pas la sécurité. À l’aide de l’IA, vous pouvez jeter les bases de la validation intégrée CI/CD en identifiant les chemins d’utilisation et en les automatisant dans votre cycle de validation. Ces chemins d’utilisation sont basés sur la manière dont vos utilisateurs finaux, patients ou médecins, utilisent le SaMD, et non sur la manière dont vous pensez qu’il devrait être utilisé. Vous pouvez les déterminer en suivant l’utilisation du logiciel par les clients. Ces modèles d’utilisation des clients peuvent être optimisés pour détecter ces défauts d’utilisation des cas extrêmes avant la publication de la mise à jour logicielle. Il est essentiel de savoir comment le SaMD est utilisé pour corriger tout défaut avant qu’il n’atteigne les mains des patients.

Une fois que vous avez connaissance d’un défaut, vous pouvez écrire du code pour le corriger. Afin de s’assurer que le remède n’est pas pire que le mal, le correctif doit être testé avant d’être déployé. Et il doit être testé par rapport à tous les flux d’utilisation, pas seulement ceux directement liés au défaut. Après l’avoir testé dans votre pipeline, s’il ne casse rien d’autre et corrige le défaut comme prévu, il peut être déployé. Cela peut sembler une simplification excessive, mais la partie la plus compliquée du processus consiste à capturer chaque cas d’utilisation et à prendre en compte tous les patients impliqués. Si cela n’est pas fait correctement, vos données peuvent introduire un biais dans le processus, ce qui invalide les résultats. Pour éviter les biais, vous devez regarder au-delà du cas d’utilisation spécifique du défaut et envisager plusieurs scénarios qui l’impliquent. L’intégration de tests pour le pipeline de déploiement empêche l’introduction de biais dans les données validées.

L’intégration de l’IA dans CI/CD signifie que l’algorithme de test de validation peut modifier automatiquement le plan de validation ou suggérer des domaines nécessitant plus d’attention en fonction de la régression et des données prévisionnelles. Mais le biais est un problème bien connu dans l’IA et les soins de santé. Ainsi, si les tests de validation SaMD sont entraînés sur des données biaisées, ils feront des hypothèses incorrectes et fonctionneront mal. C’est pourquoi il est si important de s’assurer que vos chemins d’utilisation sont basés sur un large échantillon représentatif de patients et de scénarios d’utilisateurs finaux. Lorsque le produit sera lancé, les données réelles des patients entraîneront l’IA à être plus précise et à s’améliorer au fil du temps. Cela augmente rapidement la maturité de votre processus de validation. L’utilisation par les patients met en évidence les zones fragiles du code qui nécessitent davantage de tests du point de vue de la validation, mais il existe d’autres sources de données pour les problèmes SaMD courants.

Formulaire FDA 483

Le terme « formulaire 483 » est suffisant pour faire frémir n’importe qui dans l’industrie des dispositifs médicaux. Les inspections de la FDA sont stressantes, mais recevoir un formulaire 483 après coup ne fait qu’empirer les choses. L’examen des données des formulaires 483 dans leur ensemble donne à l’industrie une idée des priorités de la FDA et des problèmes historiques rencontrés par les autres entreprises. Deux de ces problèmes dans l’industrie des dispositifs médicaux ont été la gestion du changement et les évaluations des risques, qui sont toutes deux essentielles en matière de logiciels et de validation.

La gestion des risques est presque toujours subjective. Il s’agit de savoir ce que vous ou votre entreprise considérez être les risques les plus importants en fonction de votre propre tolérance au risque. Différentes entreprises auront des points de vue différents sur la criticité des différentes fonctionnalités logicielles en fonction de leur expérience professionnelle et industrielle. Ces expériences subjectives colorent le niveau de risque attribué aux différents usages, même en essayant de supprimer le biais subjectif en utilisant des matrices de risque formalisées. L’apprentissage automatique (ML), un sous-ensemble de l’IA, peut supprimer une partie de cette subjectivité (bien que, encore une fois, votre biais soit présent dans les données sur lesquelles il est formé). Si les données sont incorporées à partir de plusieurs sources, l’évaluation des risques tend à devenir objective avec des preuves étayant le score de risque au lieu d’être simplement instinctif.

Le contrôle des modifications est vital dans le logiciel car il est destiné à être modifié et mis à jour au fil du temps, et c’est également le cas avec SaMD. SaMD qui implique AI/ML changera naturellement d’une manière différente. L’intérêt de l’utilisation de l’IA/ML est que plus le programme est exposé à des données, plus il apprend et plus il devient précis. Le plan d’action de la FDA décrit un « plan de contrôle des changements prédéterminés », qui inclurait quels aspects du SaMD seront modifiés via l’IA/ML et comment cela sera fait pour maintenir la sécurité et l’efficacité du dispositif.

Plan d’action de la FDA

Le plan d’action de la FDA n’est que cela. Il ne s’agit pas d’un règlement et il n’a pas évolué vers une orientation. C’est un plan basé sur les commentaires de l’industrie. La validation est à peine mentionnée dans le plan, mais il existe quelques indications sur les priorités et les facteurs de la FDA que les entreprises SaMD devraient prendre en compte lors de la validation. L’un d’eux est le plan de contrôle des changements prédéterminé mentionné ci-dessus. L’agence espère publier des directives connexes cette année.

Un autre facteur important mentionné dans le plan est le biais mentionné précédemment. Comme il s’agit d’un risque si important en ce qui concerne les données, les plans de validation doivent se concentrer sur l’atténuation du problème. Des tests supplémentaires doivent être effectués pour tester le dispositif pour le biais. Le plan d’action de la FDA mentionne la race, l’origine ethnique et le statut socio-économique. Veillez donc à ce que ces facteurs n’affectent pas les performances du SaMD.

Le dernier point mentionné par la FDA est le concept de performance du monde réel ou de données du monde réel. Cela renvoie aux chemins d’utilisation qui informent les tests de validation. L’utilisation de données réelles garantit la précision de la détermination des principaux risques dans le logiciel. Bien que le plan n’indique pas que la collecte et la surveillance de données dans le monde réel seront une exigence réglementaire, cela implique qu’on s’y attendra dans une certaine mesure.

Conclusion

L’IA/ML est en train de remodeler le secteur de la santé, et SaMD n’est qu’un exemple de la façon dont cela se produit. Ces technologies ont un grand potentiel, mais cela ne sera réalisé que si elles tiennent leurs promesses. Comme pour tout autre logiciel, la validation basée sur les risques est la clé pour garantir que le produit fonctionne correctement sans surcharger le fabricant. Avec la bonne approche de développement logiciel et en utilisant l’IA/ML pour trouver et corriger les défauts, les entreprises SaMD peuvent s’assurer que leurs produits fonctionnent avec précision et s’améliorent continuellement à mesure qu’ils apprennent à partir de plus de données.