4 min de lecture
Avec l'évolution technologique, le secteur de la santé cherche de plus en plus à intégrer des logiciels aux dispositifs médicaux pour apporter plus d'automatisation et de précision dans la prédiction, le diagnostic, la prévention, le traitement et la gestion des problèmes de santé. La US FDA a depuis longtemps reconnu le rôle bénéfique que les logiciels peuvent jouer dans le fonctionnement des dispositifs médicaux, mais elle n'avait pas encore établi de directives ou de règles concrètes pour aider les chercheurs du secteur à progresser vers la santé numérique.
Le 4 novembre 2021, la US FDA a publié un projet de guide sur le « contenu des soumissions avant commercialisation pour les fonctions logicielles des dispositifs », donnant une idée précise aux promoteurs responsables de la préparation du document sur les informations à inclure. Ces informations fournies par les promoteurs sont importantes pour que la FDA puisse évaluer le logiciel du dispositif exécutant une ou plusieurs fonctions et garantir sa sécurité et son efficacité tout au long de son cycle de vie. Ce nouveau guide est une recommandation et une version préliminaire concernant les fonctions logicielles des dispositifs médicaux que la FDA s'est engagée à publier en remplacement du document d'orientation vieux de 15 ans intitulé « Guide pour le contenu de la soumission avant commercialisation pour le logiciel contenu dans un dispositif médical », publié en mai 2005. La période de consultation et de discussion est ouverte jusqu'au 2 février 2022.
Dans cette nouvelle version, la FDA a reconnu le mode d'association d'un logiciel à un dispositif médical et les a ensuite différenciés en SaMD (Software as a Medical Device - Logiciel en tant que dispositif médical) et SiMD (Software in a Medical Device - Logiciel dans un dispositif médical), en tant que sous-catégories des fonctions logicielles des dispositifs. Un logiciel en tant que dispositif médical, ou SaMD, est un logiciel qui exécute lui-même la tâche d'un dispositif médical selon la définition du dispositif médical mentionnée à la section 201(h) de la loi FD&C, mais qui ne fait pas partie d'un composant du dispositif. D'autre part, le logiciel SiMD, comme son nom l'indique, fait partie du composant ou du matériel du dispositif médical utilisé pour enregistrer, contrôler ou afficher des informations médicales ou non médicales.
Ce projet se concentre principalement sur les attentes de la FDA concernant la préparation des documents requis pour les soumissions avant commercialisation des fonctions logicielles des dispositifs. Elle définit clairement ce qu'elle s'attend à trouver dans les documents qui établissent de manière solide les spécifications des exigences logicielles (SRS) et les spécifications de conception du logiciel ou du système (SDS). La FDA met l'accent sur une approche fondée sur les risques lors de la rédaction des documents pour les soumissions avant commercialisation des fonctions logicielles des dispositifs. Selon ce niveau de préoccupation ou le risque associé à l'utilisation prévue du dispositif, le niveau de documentation peut également varier entre une documentation de base et une documentation renforcée. Les points clés que chaque niveau de documentation doit mettre en avant pour identifier le niveau de préoccupation du logiciel associé au dispositif médical sont les suivants :
- La vue d'ensemble du logiciel donnant une idée des entrées et des sorties
- Les spécifications des exigences logicielles (SRS), qui comprennent des détails sur l'architecture du logiciel avec un diagramme schématique de tous les modules, périphériques, langages de programmation, système d'exploitation, version du compilateur, utilisation éventuelle d'un logiciel hôte, et tous les détails d'interface utilisateur (UI/UX)
- Les spécifications de conception du logiciel ou du système (SDS) couvrant les informations sur le logiciel dès la phase de conception sont requises pour les promoteurs soumettant une documentation renforcée. Alors que la SRS décrit la fonction prévue du logiciel, la SDS fournit des informations détaillées sur la méthodologie de mise en œuvre des exigences mentionnées dans la SRS. La SDS doit inclure des détails de conception technique complets avec des informations adéquates sur l'utilité et le fonctionnement liés à la SRS, en indiquant si une assistance est nécessaire pour faire fonctionner le logiciel ou s'il s'agit d'un système de CAO entraîné basé sur des modèles d'intelligence artificielle ou d'apprentissage automatique (AI/ML)
- Selon ce nouveau projet de directive, il deviendra plus facile et plus conforme aux tendances, pratiques et innovations actuelles du marché de la santé numérique de se conformer aux normes de consensus volontaires reconnues par l'industrie pour les soumissions réglementaires. Les dispositifs nécessitant une documentation de base ou renforcée doivent tous deux respecter la version reconnue par la FDA de la norme ANSI/AAMI IEC 62304 concernant les logiciels de dispositifs médicaux et les processus du cycle de vie du logiciel. Les documents renforcés nécessitent une description supplémentaire de la configuration complète avec des détails encore plus précis sur le plan de développement de la conception et de maintenance dans le cycle de vie du logiciel pour une meilleure clarté lors de l'examen
- Sur la base de l'analyse des risques conformément aux exigences de la réglementation sur les systèmes qualité (21 CFR 820), les informations relatives à la sécurité telles que l'environnement d'exploitation, l'efficacité, la précision, le temps de réponse, le temps de retard, la cohérence, les limites et la plage d'utilisation, ainsi que toute valeur de base ou seuil requise pour le fonctionnement du logiciel, doivent également être incluses. La disposition de tout système de suivi pour consigner les données enregistrées à l'aide de la mémoire du dispositif ou du système de stockage doit être mentionnée
- Dans le cadre du cycle de vie du logiciel, la vérification et la validation du logiciel sont essentielles et sont réalisées en testant les composants du logiciel au niveau du système ou de l'intégration. Cette étape est obligatoire pour la documentation renforcée. En outre, la description des protocoles de test ainsi que les résultats attendus ou observés permettant d'établir le statut de réussite ou d'échec du système doit également être abordée
- Toute présence d'anomalies non résolues, telles que des bugs ou des défauts susceptibles d'affecter les performances de la fonction logicielle, doit être identifiée et classée selon la taxonomie des défauts de la norme ANSI/AAMI SW91 relative à la classification des défauts dans les logiciels de santé
Une documentation renforcée doit être soumise pour les dispositifs qui constituent un produit combiné, qui sont classés comme dispositifs à haut risque de classe III, ou qui intègrent une fonction logicielle destinée à être utilisée dans le cadre du don et de la transfusion de sang pour réaliser l'évaluation de la compatibilité entre le donneur et le receveur. Les dispositifs nécessitant une documentation spécifique doivent respecter les exigences de documentation renforcée. La documentation de base doit résumer l'analyse des risques, les mesures d'atténuation des risques et les rapports de justification des risques.
Conformément aux engagements du dispositif MDUFA IV, l'Agence est tenue de publier le guide définitif dans les 12 mois suivant la fin de la période de consultation publique. La FDA a annoncé l'organisation d'un webinaire le 16 décembre 2021 à l'intention des fabricants de dispositifs médicaux, des chercheurs et des professionnels du secteur de la santé numérique afin de discuter de ce projet de guide.
Pour en savoir plus sur la soumission avant commercialisation des fonctions logicielles de dispositifs, contactez un expert réglementaire régional comme Freyr. Restez informé. Restez conforme.
