Couverture de l’atelier de la FDA sur les dispositifs médicaux AI/ML – Partie 1 : L’histoire de la réglementation des logiciels de la FDA

En prévision de l’atelier public virtuel de la FDA sur la transparence des dispositifs médicaux compatibles avec l’intelligence artificielle/l’apprentissage automatique (IA/ML) prévu pour le 14 octobre 2021, nous publierons une série détaillant l’historique de la réglementation des logiciels par la FDA, puis nous rapporterons nos impressions. des présentations de la FDA et des déclarations de diverses parties prenantes présentes à la suite de la réunion. Selon la FDA, le but du prochain atelier est de :

• Identifier des considérations uniques pour parvenir à la transparence pour les utilisateurs de dispositifs médicaux compatibles avec l’IA/ML et les moyens par lesquels la transparence pourrait améliorer la sécurité et l’efficacité de ces dispositifs ; et
• Recueillez les commentaires de diverses parties prenantes sur les types d’informations qu’il serait utile pour un fabricant d’inclure dans l’étiquetage et les informations destinées au public des dispositifs médicaux compatibles avec l’IA/ML, ainsi que d’autres mécanismes potentiels de partage d’informations.

Avant la réunion, nous explorerons l’historique de la réglementation de la FDA sur les dispositifs médicaux et les logiciels autonomes activés par logiciel et les progrès les plus récents de l’agence en matière de politiques de santé numérique. Dans cette partie, nous résumons brièvement l’approche traditionnelle de la FDA en matière de réglementation des logiciels et la manière dont le développement de logiciels a rapidement révélé les limites du cadre réglementaire d’origine établi dans les modifications apportées aux dispositifs médicaux de 1976 à la loi fédérale sur les aliments, les médicaments et les cosmétiques (Loi FD&C).

L’approche traditionnelle de la FDA en matière de réglementation des logiciels

Le développement, l’utilisation et la réglementation des dispositifs médicaux ont une longue histoire aux États-Unis. Reconnaissant qu’un cadre de réglementation des dispositifs médicaux séparé et distinct du cadre des produits pharmaceutiques était nécessaire, le Congrès a adopté les modifications apportées aux dispositifs médicaux de 1976, qui ont établi les trois classifications des dispositifs fondées sur les risques (classes I, II et III), le processus de la création de normes de performance pour les appareils de classe II et les exigences d’approbation préalable à la commercialisation pour les appareils de classe III.

Dans les années 1970, les logiciels ont commencé à faire partie intégrante de certains dispositifs médicaux (auparavant, les dispositifs étaient en grande partie du matériel médical). En particulier, des systèmes d’imagerie par résonance magnétique et des systèmes de programmation de stimulateurs cardiaques ont été développés dans les années 1970, obligeant la FDA à examiner le logiciel ainsi que les composants matériels dans le cadre du processus d’approbation préalable à la commercialisation. De plus, la base de données 510(k) de la FDA montre que des notifications préalables à la mise sur le marché en vertu de la section 510(k) de la loi FD&C ont été soumises pour les dispositifs logiciels en 1980.

Bien que la FDA ait fait quelques tentatives pour développer des règles complètes pour les logiciels de dispositifs médicaux, l’agence n’a finalement jamais publié de cadre proposé pour réglementer les logiciels. En 1997, la FDA a finalisé le Quality System Regulation (QSR) pour les dispositifs médicaux (21 CFR partie 820), qui répond aux attentes de qualité spécifiques relatives au développement de logiciels de dispositifs médicaux et à l’utilisation de logiciels dans des processus automatisés pour concevoir, développer et fabriquer Équipement médical. Dans le commentaire réglementaire avant la finalisation du QSR, la FDA a déclaré que les normes du système qualité étaient nécessaires en partie à cause des défaillances des appareils associées à des problèmes de qualité logicielle :

En ce qui concerne les logiciels utilisés pour faire fonctionner les dispositifs médicaux, les données étaient encore plus frappantes. Une étude ultérieure des rappels liés aux logiciels pour la période de l’exercice (AF) 1983 à l’exercice 1991 a indiqué que plus de 90 pour cent de toutes les défaillances d’appareils liées au logiciel étaient dues à des erreurs liées à la conception, en général, la non-validation du logiciel avant fabrication courante. (61 Règl. féd. 52 602 (7 oct. 1996))

Depuis lors, la FDA a publié de nombreux documents d’orientation non contraignants sur diverses questions liées aux logiciels, y compris des dizaines de directives de contrôles spéciaux pour certains dispositifs logiciels de classe II. En effet, le courant Politique relative aux fonctions logicielles de l’appareil et aux applications médicales mobiles Le guide fournit un historique des tentatives de la FDA pour développer une politique générale de réglementation des logiciels et explique que l’agence a abandonné ces efforts parce que « l’utilisation de produits informatiques et logiciels en tant que dispositifs médicaux a augmenté de manière exponentielle et les types de produits se sont diversifiés et sont devenus plus complexes ». (Voir page 3.)

Les problèmes de l’approche logicielle de la FDA

L’absence d’un cadre réglementaire, de classifications ou de méthodes d’examen préalable à la commercialisation distincts pour les dispositifs logiciels a conduit la FDA à traiter en grande partie les dispositifs logiciels de la même manière que les dispositifs matériels traditionnels. Les dispositifs logiciels et matériels ont des processus de conception, de développement et de qualité radicalement différents, et bien que certaines normes générales de haut niveau puissent s’appliquer aux deux, les différences fondamentales entre ces types de dispositifs rendent la réglementation des logiciels selon les règles actuelles comme forcer une cheville ronde dans un trou carré. Les difficultés sont atténuées lorsque le logiciel est un composant d’un dispositif matériel (par exemple, un système d’IRM ou un robot chirurgical), mais les dispositifs logiciels autonomes (également appelés logiciels en tant que dispositif médical, ou SaMD) présentent des défis de développement et de qualité qui ne sont pas suffisamment abordés dans la réglementation en vigueur.

Certains de ces défis comprennent :

• Modifications post-commercialisation – Le cadre réglementaire de la FDA exige que les fabricants de dispositifs obtiennent une nouvelle autorisation ou une nouvelle approbation pour les modifications importantes apportées aux dispositifs de classe II ou III commercialisés légalement, ce qui signifie que chaque modification apportée à un dispositif autorisé ou approuvé doit être évaluée pour déterminer si une nouvelle soumission préalable à la commercialisation est nécessaire. Ce processus est logique pour les périphériques matériels, car les modifications nécessitent généralement des efforts d’ingénierie substantiels pour concevoir, développer et tester, et les fabricants publieront souvent de nouvelles versions d’un périphérique matériel avec de multiples améliorations. Les dispositifs logiciels, d’autre part, peuvent être modifiés (par exemple, pour ajouter des fonctionnalités ou des types supplémentaires d’entrées et de sorties de données) relativement facilement et individuellement, mais des modifications importantes peuvent être rapidement développées et publiées. À mesure que la technologie progresse, de plus en plus de fonctionnalités peuvent être ajoutées à un dispositif logiciel simplement en codant et en validant le nouveau code, et chaque modification doit potentiellement être examinée par la FDA avant sa publication, ce qui constitue une lourde charge pour les développeurs de dispositifs logiciels et les ressources de l’agence.
• De multiples fonctionnalités – De nombreux dispositifs matériels ont une seule utilisation prévue qui peut être définie en quelques phrases ou moins (par exemple, un brassard de tensiomètre, un flacon de prélèvement d’échantillons ou un stéthoscope). D’autres périphériques matériels (en particulier ceux qui intègrent des composants logiciels) peuvent avoir plus d’une utilisation prévue, mais ces utilisations correspondent parfaitement à un type de périphérique établi ou sont de nouvelles fonctions de périphérique qui peuvent être définies via l’approbation préalable à la commercialisation ou le processus de novo. SaMD, cependant, peut incorporer des dizaines d’utilisations prévues dans une suite logicielle complète et peut combiner des fonctions logicielles de l’appareil et des fonctions logicielles non liées à l’appareil.
• Équivalence substantielle – Un dispositif médical de classe II doit passer par le processus de notification préalable à la commercialisation (ou 510(k)) avant la commercialisation, et ce processus nécessite la détermination de la FDA que le nouveau dispositif est substantiellement équivalent à un dispositif commercialisé légalement. Comme indiqué ci-dessus, de nombreux appareils ont une seule utilisation prévue, et leurs technologies respectives peuvent être facilement comparées à d’autres appareils de la même catégorie. Cependant, lorsque SaMD a été introduit, l’industrie des appareils et la FDA ont été obligées de comparer les logiciels autonomes aux appareils commercialisés légalement avec des composants matériels. De plus, les SaMD avec de nombreuses fonctionnalités périphériques et non périphériques, dont certaines peuvent être interdépendantes pour l’entrée, le calcul et la sortie, ou celles qui intègrent des algorithmes AI/ML uniques, mais ne présentent néanmoins qu’un risque modéré, sont difficiles à comparer et trouver une équivalence substantielle avec d’autres dispositifs commercialisés légalement.
• La cyber-sécurité – Les progrès de la technologie logicielle ont conduit à des capacités étonnantes qui peuvent être appliquées aux soins des patients, mais cela a également conduit à une augmentation terrifiante des cyber-vulnérabilités qui peuvent être exploitées par des pirates informatiques ou peuvent entraîner des pannes imprévues des appareils. La FDA a consacré beaucoup de temps et d’efforts à l’élaboration de directives et de politiques relatives à la cybersécurité des appareils et a publié plusieurs documents d’orientation sur le sujet. Cependant, tout comme les progrès rapides de la technologie et des logiciels ont entravé les efforts de la FDA pour développer une politique logicielle globale, les mêmes progrès, ainsi que l’évolution parallèle des cyber-vulnérabilités et des techniques de piratage, peuvent dépasser les tentatives de l’agence pour atténuer considérablement les risques associés.
• Contrôles de qualité, en général – Comme indiqué ci-dessus, le cadre réglementaire actuel des appareils, y compris le QSR, est largement basé sur les appareils matériels et ne s’applique pas pleinement à la conception, au développement et au contrôle qualité des logiciels. Par exemple, certaines des dispositions QSR s’appliquent certainement au SaMD, telles que les actions correctives et préventives, le traitement des plaintes et les contrôles des documents, mais de nombreuses autres sont inapplicables, par exemple, les contrôles de production et de processus ; contrôles d’étiquetage et d’emballage; manutention, stockage, distribution et installation; entretien; et produit non conforme. Les différences significatives dans les processus et l’environnement entre les développeurs SaMD et les fabricants de périphériques matériels traditionnels affectent les activités de conformité post-commercialisation et les inspections réglementaires pour les produits SaMD et leurs développeurs.

Il est important de noter que toute mesure prise par la FDA à la suite du prochain atelier AI/ML ne changera probablement pas fondamentalement le cadre réglementaire actuel pour les appareils. Cependant, l’agence créera presque certainement diverses politiques et outils qui rationaliseront le processus de soumission et d’examen pour certains dispositifs logiciels basés sur l’IA/ML.

Conclusion

Dans cet article, nous avons brièvement exploré l’histoire de la FDA en matière de réglementation des dispositifs médicaux logiciels en vertu de règles conçues principalement pour les dispositifs matériels et les problèmes liés à une telle réglementation. La semaine prochaine, nous donnerons un bref aperçu des actions récentes de l’agence pour créer des politiques et des processus qui s’adaptent mieux aux technologies logicielles avancées telles que les dispositifs médicaux, ainsi qu’à leurs développeurs.