La FDA publie un projet de directives pour le logiciel de l’appareil dans les soumissions préalables à la commercialisation

La Food and Drug Administration (FDA) des États-Unis a publié un projet de directives à l’intention des sponsors, décrivant sa réflexion sur la documentation nécessaire pour soutenir l’évaluation par l’agence des fonctions logicielles de l’appareil pour les soumissions préalables à la commercialisation.

L’agence a déclaré que les directives reconnaissent la « nature en évolution rapide de la santé numérique et les récentes normes de consensus reconnues par la FDA concernant les logiciels » et, une fois finalisées, serviront de mise à jour de la Conseils pour le contenu des soumissions préalables à la commercialisation pour les logiciels contenus dans les dispositifs médicaux document publié en mai 2005.

Les modifications apportées à l’article 520 de la Loi fédérale sur les aliments, les médicaments et les cosmétiques (FD&C Act) en vertu de la Loi sur les cures du 21e siècle en décembre 2016, excluent certains types de logiciels, tels que les logiciels d’aide à la décision à faible risque comme certaines applications mobiles pour les consommateurs et les logiciels d’aide administrative aux laboratoires. (EN RELATION: La FDA explique que les applications mobiles ne sont plus des appareils, Orientation réglementaire 26 septembre 2019 ; La FDA renonce à réglementer certains types de logiciels de santé, Orientation réglementaire 07 décembre 2017)

En gardant à l’esprit ces modifications de l’article 520, le projet d’orientation décrit les logiciels des dispositifs qui relèvent de la compétence de la FDA lors de l’évaluation de la sécurité et de l’efficacité des dispositifs lors de la soumission préalable à la commercialisation. « Ce projet de directives décrit les informations qui seraient généralement générées et documentées lors du développement, de la vérification et de la validation de la conception du logiciel », a écrit l’agence.

Fonctions logicielles

La FDA a fait une distinction entre « Software in a Medical Device » (SiMD) – défini comme un logiciel faisant partie d’un dispositif médical ou le contrôlant – et « Software as a Medical Device » (SaMD), qui est un logiciel qui répond à la définition d’un appareil mais ne fait pas partie du matériel global de l’appareil. SaMD et SiMD sont tous deux des « fonctions logicielles de l’appareil », selon l’agence.

« Pour tout produit donné, le terme » fonction « est un objectif distinct du produit, qui pourrait être l’utilisation prévue ou un sous-ensemble de l’utilisation prévue du produit », a écrit la FDA. « Par exemple, un produit destiné à analyser des données a une fonction : l’analyse. Un produit destiné à stocker, transférer et analyser des données a trois fonctions : (1) le stockage, (2) le transfert et (3) l’analyse. »

Dans l’ensemble, le guide couvre les micrologiciels et autres logiciels qui contrôlent les appareils médicaux, les applications logicielles autonomes, les logiciels des plates-formes informatiques générales, les appareils dotés de matériel et de logiciels dédiés et les accessoires pour appareils médicaux qui incluent des logiciels. Les logiciels pour les systèmes automatisés de fabrication et de qualité et les logiciels qui ne correspondent pas à la définition de l’appareil étaient exclus du guide.

« En règle générale, les recommandations de ce guide s’appliquent à la partie constituante du dispositif d’un produit combiné (tel que les produits combinés médicament-dispositif et dispositif biologique-dispositif) lorsque la partie constituante du dispositif comprend une fonction logicielle du dispositif», a écrit la FDA.

Documentation de l’appareil logiciel

La FDA a mis à jour la documentation requise pour les sponsors avec des appareils qui incluent des logiciels répondant aux spécifications ci-dessus. L’agence examinera maintenant si le logiciel a besoin d’un niveau de documentation de base ou amélioré en fonction du risque du logiciel pour le patient, l’utilisateur de l’appareil, d’autres personnes et l’environnement dans lequel un appareil est utilisé. En général, une documentation améliorée doit être fournie par un promoteur si le dispositif est un dispositif de classe III, présente un risque de blessure grave ou de décès pour les parties prenantes, est « un élément constitutif d’un produit combiné » ou « (a) est destiné à tester les dons de sang pour les infections transmises par transfusion ; ou (b) est utilisé pour déterminer la compatibilité du donneur et du receveur ; ou (c) est un logiciel informatique d’établissement de sang.

Lorsqu’ils décrivent le logiciel d’un appareil, les sponsors doivent inclure un résumé de toutes les caractéristiques et fonctionnalités importantes du logiciel avec des détails tels que le langage de programmation et les versions du compilateur utilisées, les plates-formes matérielles, les systèmes d’exploitation, si l’appareil utilise un logiciel standard, et le version de sortie prévue. En outre, les sponsors doivent être prêts à documenter qui utilisera le logiciel de l’appareil, la population de patients visée, la méthodologie d’analyse de toute analyse effectuée par le logiciel, si le logiciel assiste ou remplace les actions du clinicien et, le cas échéant, des informations supplémentaires sur l’intelligence artificielle et des modèles d’apprentissage automatique.

Les promoteurs doivent également documenter le schéma du système et de l’architecture « pour faciliter une compréhension claire de 1) les modules et les couches qui composent le système et le logiciel, 2) les relations entre les modules et les couches, 3) les entrées/sorties de données et le flux de les données entre les modules et les couches, et 4) comment les utilisateurs ou les produits externes, y compris l’infrastructure informatique et les périphériques (par exemple, les appareils médicaux connectés sans fil) interagissent avec le système et les logiciels », a écrit la FDA.

En outre, le sponsor doit fournir une spécification des exigences logicielles (SRS) – « ce que la fonction logicielle fera » et une spécification de conception logicielle (SDS) – » comment les exigences du SRS sont mises en œuvre », a noté l’agence.

Gestion des risques logiciels, maintenance, tests

Une évaluation des risques qui inclut tous les « dangers logiciels et matériels raisonnablement prévisibles associés à l’appareil » et un plan de gestion des risques doivent être inclus dans toute soumission préalable à la commercialisation d’appareils dont le logiciel répond aux critères. « Il devrait être clair dans le plan de gestion des risques comment le fabricant prévoit d’évaluer le risque résiduel global par rapport aux avantages de l’utilisation prévue de l’appareil », a écrit l’agence.

Pour les logiciels des appareils nécessitant une documentation de base ou améliorée, les sponsors peuvent soit soumettre une déclaration de conformité à la version actuellement reconnue par la FDA de la norme ANSI/AAMI IEC 62304 Logiciel de dispositif médical – Processus du cycle de vie du logiciel ou fournir à l’agence une liste complète des processus et procédures qu’ils utilisent pour maintenir les pratiques de développement et de maintenance des logiciels.

Lors du test du logiciel pour vérification ou validation, la FDA a déclaré que le sponsor devrait documenter toutes les activités de test, y compris la version du logiciel utilisé, les résultats des tests de réussite/échec et les modifications apportées au logiciel en cas d’échec des résultats de test. Pour les logiciels nécessitant une documentation améliorée, « des protocoles et des rapports de test de niveau d’intégration doivent être fournis, y compris les résultats attendus dérivés des exigences et de la conception du logiciel, les résultats réels qui sont observés et enregistrés, la détermination objective de réussite/échec (c’est-à-dire que les résultats réels sont acceptablement équivalents à résultats attendus) et des rapports de tests unitaires et d’intégration », selon l’agence.

« Les rapports de test au niveau de l’unité et de l’intégration doivent démontrer que les protocoles ont été exécutés de manière acceptable avec des résultats de test satisfaisants et que toute anomalie non résolue a été différée de manière acceptable sur la base d’une évaluation des risques pour la version candidate », ont-ils déclaré.

La FDA a noté qu’elle est consciente que les informations contenues dans le projet de directives peuvent différer des directives finales qu’elle a publiées sur les logiciels prêts à l’emploi dans les dispositifs médicaux. L’agence a déclaré qu’elle prévoyait de mettre à jour les directives du logiciel OTS si les directives finales pour le logiciel du dispositif de soumission avant commercialisation étaient publiées afin de rendre les deux ensembles de directives cohérents.

Projet d’orientation : Contenu des soumissions préalables à la commercialisation pour les fonctions logicielles de l’appareil

Avis du Registre fédéral