4 min lire
Avec l'évolution de la technologie, le secteur de la santé s'est montré très intéressé par l'intégration de logiciels aux dispositifs médicaux afin d'automatiser et d'améliorer la précision des prévisions, des diagnostics, de la prévention, des traitements et de la gestion des problèmes de santé. LaFDA US FDA longtemps le rôle que les logiciels pouvaient jouer pour améliorer le fonctionnement des dispositifs médicaux, mais n'avait pas encore publié de directives ou de règles concrètes qui auraient pu aider les chercheurs du secteur à progresser vers la santé numérique.
Le 4 novembre 2021, laFDA US FDA un projet de lignes directrices sur «le contenu des demandes d'autorisation préalable à la mise sur le marché pour les fonctions logicielles des dispositifs », donnant une idée précise aux promoteurs chargés de préparer le document et aux informations à inclure. Ces informations fournies par les promoteurs sont importantes pour FDA évaluer le logiciel du dispositif exécutant une ou plusieurs fonctions et de 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 engagée à publier en remplacement du guide vieux de 15 ans intitulé « Guidance for the content of pre-market submission for the software contained in Medical device » (Guide sur le contenu des demandes d'autorisation préalable à la mise sur le marché pour les logiciels contenus dans les dispositifs médicaux) publié en mai 2005. La FDA a laissé ouverte la possibilité de faire part de commentaires et toute discussion à ce sujet est ouverte jusqu'au 2 février 2022.
Dans cette nouvelle version, la FDA le mode d'association des logiciels avec les dispositifs médicaux et les a différenciés en SaMD Software as a medical device SaMD Software as a medical device SiMD (Software in a Medical Device, logiciel dans un dispositif médical), en tant que subdivisions des fonctions logicielles des dispositifs. Software as a medical device SaMD 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) de la loi FD&C, mais qui ne fait pas partie intégrante du dispositif. D'autre part, le logiciel dans 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 la préparation des documents requis pour les soumissions préalables à la mise sur le marché des fonctions logicielles des dispositifs. Elle a clairement défini ce qu'elle attend des documents qui établissent de manière rigoureuse les spécifications des exigences logicielles (SRS) et les spécifications de conception du logiciel ou du système (SDS). La FDA une approche fondée sur les risques lors de la documentation des soumissions préalables à la mise sur le marché des fonctions logicielles des dispositifs. En fonction du niveau de préoccupation ou du risque associé à l'utilisation prévue du dispositif, le niveau de documentation doit également varier entre une documentation de base et une 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) couvrant 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 les SRS décrivent la fonction prévue du logiciel, les SDS fournissent des informations détaillées sur la méthodologie de mise en œuvre des exigences mentionnées dans les SRS. Les SDS doivent inclure des détails techniques complets sur la conception, avec des informations adéquates sur l'utilité, le fonctionnement en lien avec les SRS, la nécessité ou non d'une assistance pour utiliser le logiciel ou s'il s'agit d'un système de CAO formé basé surML
- Le respect des 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 une documentation améliorée doivent tous deux être conformes à la version FDA de la norme ANSI/AAMI IEC 62304 Logiciels pour dispositifs médicaux - Processus du cycle de vie des logiciels. Les documents améliorés nécessitent une description supplémentaire de la configuration complète, avec des détails encore plus précis sur le développement de la conception et le plan de maintenance dans le cycle de vie du logiciel, afin d'assurer une meilleure clarté lors de l'examen.
- Sur la base de l'analyse des risques conformément aux exigences du règlement 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 de fonctionnement, ainsi que toute valeur de base ou seuil dont le logiciel a besoin pour fonctionner, doivent également être incluses. La mise en place d'un système de vigilance permettant de suivre les données enregistrées à l'aide de la mémoire ou du système de stockage de l'appareil doit être mentionnée.
- 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 pris dans le cadre du MDUFA IV, l'Agence est censée publier les recommandations finales dans les 12 mois suivant la fin de la période de consultation sur le projet. La FDA annoncé qu'elle organiserait un webinaire le 16 décembre 2021 à l'intention des fabricants de dispositifs médicaux, des chercheurs du secteur de la santé numérique et des professionnels afin de discuter de ce projet de recommandations.
Pour en savoir plus sur la soumission préalable à la mise sur le marché des fonctions logicielles des dispositifs, reach un expert régional en réglementation tel que Freyr. Restez informé. Restez en conformité.
