4 min lire
Avec l'évolution de la technologie, le secteur des soins de santé a pris l'habitude d'intégrer des logiciels aux dispositifs médicaux afin d'automatiser et d'améliorer la prédiction, le diagnostic, la prévention, le traitement et la gestion des problèmes de santé. La FDA américaine a depuis longtemps reconnu le rôle que peuvent jouer les logiciels dans le fonctionnement des dispositifs médicaux, mais elle n'a pas encore formulé d'orientations ou de règles concrètes qui auraient pu aider les chercheurs de l'industrie à progresser vers la santé numérique.
Le 4 novembre 2021, la FDA américaine a publié un projet de lignes directrices sur le "contenu des soumissions préalables à la mise sur le marché pour les fonctions logicielles des dispositifs", donnant ainsi une idée précise aux promoteurs responsables de la préparation du document et des 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 la sécurité et l'efficacité tout au long de son cycle de vie. Le nouveau guide est une recommandation et une version préliminaire sur les fonctions logicielles des dispositifs médicaux que la FDA s'est engagée à publier pour remplacer le document d'orientation "Guidance for the content of pre-market submission for the software contained in Medical device", publié en mai 2005 et vieux de 15 ans. La FDA a gardé la possibilité de recueillir des commentaires et toute discussion à ce sujet est ouverte jusqu'au 2 février 2022.
Dans cette nouvelle version, la FDA a reconnu le mode d'association des logiciels avec un dispositif médical et les a différenciés en SaMD (Software as a medical device) et SiMD (Software in a Medical Device), en tant que subdivisions des fonctions logicielles du dispositif. 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 conformément à la définition du dispositif médical mentionnée à la section 201 (h) du FD&C Act, mais qui ne fait pas partie d'un composant du dispositif. En revanche, le logiciel d'un 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.
Le projet se concentre davantage sur les attentes de la FDA concernant la préparation des documents requis pour les soumissions préalables à la mise sur le marché des fonctions logicielles des dispositifs. La FDA a clairement défini ce qu'elle attend des documents qui établissent solidement la spécification des exigences logicielles (SRS) et les spécifications de conception des logiciels ou des systèmes (SDS). La FDA met l'accent sur une approche basée sur le risque lors de la documentation des fonctions logicielles des dispositifs dans le cadre des soumissions préalables à la mise sur le marché. En fonction de ce niveau de préoccupation ou du risque associé à l'utilisation prévue du dispositif, le niveau de documentation est également censé varier en tant que documentation de base et documentation améliorée. Les points clés que chaque niveau de documentation doit mettre en évidence pour identifier le niveau de préoccupation du logiciel associé au dispositif médical sont les suivants :
- L'aperçu du logiciel donnant une idée des entrées et des sorties
- le cahier des charges du logiciel (SRS), qui comprend les détails de l'architecture du logiciel avec un schéma de tous les modules, les périphériques, les langages de programmation, le système d'exploitation, la version du compilateur, l'utilisation de tout logiciel de base et tous les détails de l'interface utilisateur/utilisateur.
- Les spécifications de conception du logiciel ou du système (SDS), qui couvrent les informations relatives au logiciel dès la phase de conception, sont requises pour les promoteurs qui soumettent une documentation améliorée. Alors que le SRS décrit la fonction prévue du logiciel, le SDS est une information approfondie sur la méthodologie de mise en œuvre des exigences mentionnées dans le SRS. La FDS doit comprendre une description détaillée de la conception technique avec des informations adéquates sur l'utilité, le fonctionnement qui correspond à la FDS, si une assistance est nécessaire pour faire fonctionner le logiciel ou s'il s'agit d'un système de CAO formé construit sur des modèles AI/ML.
- L'adhésion aux normes consensuelles volontaires reconnues par l'industrie pour les soumissions réglementaires deviendrait facile et plus en phase avec les tendances, les pratiques et les innovations actuelles du marché de la santé numérique selon ce nouveau projet de ligne directrice. Les dispositifs nécessitant une documentation de base et améliorée doivent tous deux être conformes à la version reconnue par la FDA de la norme ANSI/AAMI IEC 62304 Medical device software- Software lifecycle process. Les documents améliorés exigent une description supplémentaire de la configuration complète avec encore plus de détails sur le développement de la conception et le plan 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 de qualité (21 CFR 820), les informations relatives à la sécurité telles que l'environnement opérationnel, l'efficacité, la précision, le temps de réponse, le délai, la cohérence, les limites de fonctionnement et la plage, ainsi que toute valeur de base ou de seuil sur laquelle le logiciel doit fonctionner, doivent également être incluses. Il convient de mentionner l'existence d'un système de vigilance permettant de suivre les données enregistrées à l'aide de la mémoire de l'appareil ou du système de stockage.
- Dans le cadre du cycle de vie des logiciels, la vérification et la validation des logiciels sont essentielles. Elles sont réalisées en testant les constituants des logiciels au niveau du système ou de l'intégration. Cela est obligatoire pour améliorer la documentation. En outre, la description des protocoles de test ainsi que les résultats attendus ou observés pour établir l'état de réussite ou d'échec du système doivent également être discutés
- Toute implication d'anomalies non résolues telles que des bogues ou des défauts susceptibles d'affecter la performance de la fonction logicielle doit être identifiée et classée sur la base de la taxonomie des défauts conformément à la classification des défauts dans les logiciels de santé de l'ANSI/AAMI SW91.
Une documentation renforcée doit être soumise pour les dispositifs qui sont soit des produits combinés, soit des dispositifs à haut risque de classe III, soit une fonction logicielle destinée à être utilisée dans des applications de don de sang et de transfusion sanguine qui évalue la compatibilité entre le donneur et le receveur. Les dispositifs qui requièrent une documentation spéciale doivent respecter les exigences de documentation renforcées. La documentation de base doit comprendre une analyse des dangers, une atténuation des dangers et des rapports de justification des risques.
Conformément aux engagements de la MDUFA IV, l'Agence est censée publier les orientations finales dans les 12 mois suivant la fin de la période de consultation du projet. La FDA a déclaré qu'elle organiserait un webinaire le 16 décembre 2021 à l'intention des fabricants de dispositifs médicaux, des chercheurs de l'industrie de la santé numérique et des professionnels afin de discuter de ce projet de directive.
Pour en savoir plus sur la soumission avant commercialisation des fonctions logicielles des appareils, contactez un expert régional en réglementation comme Freyr. Restez informé. Restez conforme.
