Avec l'évolution des technologies, le secteur de la santé s'est mis à privilégier l'intégration de logiciels aux dispositifs médicaux afin d'apporter automatisation et précision dans la prévision, le diagnostic, la prévention, le traitement et la prise en charge des pathologies. LaFDA US FDA longtemps le rôle que les logiciels peuvent jouer pour améliorer le fonctionnement des dispositifs médicaux, mais n'avait pas encore publié de directives ou de règles concrètes susceptibles d'aider les chercheurs du secteur à progresser vers la santé numérique.
Le 4 novembre 2021, laFDA US FDA un projet de lignes directrices intitulé «Contenu des dossiers de demande d'autorisation de mise sur le marché concernant les fonctions logicielles des dispositifs médicaux », qui donne aux promoteurs chargés de préparer ces dossiers une idée précise de la marche à suivre et des informations à inclure. Ces informations fournies par les promoteurs sont essentielles pour FDA la FDA évaluer le logiciel du dispositif exécutant une ou plusieurs fonctions et de garantir la sécurité et l'efficacité de celui-ci tout au long de son cycle de vie. Ces nouvelles lignes directrices constituent une recommandation et un projet concernant les fonctions logicielles des dispositifs médicaux que la FDA engagée à publier en remplacement du document datant de 15 ans intitulé « Guidance for the content of pre-market submission for the software contained in Medical device » (Lignes directrices relatives au contenu des demandes d'autorisation de mise sur le marché pour les logiciels contenus dans les dispositifs médicaux), publié en mai 2005. La période de consultation est maintenue, et toute discussion à ce sujet est ouverte jusqu'au 2 février 2022.
Dans cette nouvelle version, la FDA le mode d'association d'un logiciel à un dispositif médical et les a classés en deux catégories distinctes SaMD Software as a Medical Device SaMD ou « logiciel en tant que dispositif médical » SaMD et les SiMD (Software in a Medical Device, ou « logiciel intégré à un dispositif médical »), qui constituent des sous-catégories des fonctions logicielles des dispositifs. Un logiciel en tant que dispositif médical, ou SaMD un logiciel qui remplit lui-même la fonction 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. En revanche, le logiciel dans un SiMD, comme son nom l'indique, fait partie intégrante 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 met davantage l'accent sur les attentes de la FDA la préparation des documents requis pour les demandes d'autorisation de mise sur le marché relatives aux fonctions logicielles des dispositifs médicaux. L'agence a clairement défini ce qu'elle attend de ces documents, qui doivent établir de manière rigoureuse le cahier des charges logiciel (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 demandes de mise sur le marché des fonctions logicielles des dispositifs. En fonction du niveau de préoccupation ou du risque associé à l'usage prévu du dispositif, le niveau de documentation est également censé varier entre une documentation de base et une documentation approfondie. 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.
- Spécifications des exigences logicielles (SRS), qui incluent les détails de l'architecture logicielle avec un schéma de tous les modules, périphériques, langages de programmation, système d'exploitation, version du compilateur, l'utilisation de tout logiciel shell et tout détail d'interface utilisateur/expérience utilisateur (UI/UX)
- Les spécifications de conception de logiciel ou de système (SDS) couvrant les informations du logiciel dès la phase de conception sont requises pour les promoteurs soumettant 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 de conception complets avec des informations adéquates sur l'utilité et le fonctionnement qui se rapportent aux SRS, et préciser si une assistance est nécessaire pour faire fonctionner le logiciel ou s'il s'agit d'un système CAD entraîné basé sur des modèles d'IA/ML.
- Selon ce nouveau projet de lignes directrices, le respect des normes consensuelles volontaires reconnues par le secteur pour les demandes d'autorisation réglementaire deviendrait plus aisé et serait davantage en phase avec les tendances, les pratiques et les innovations actuelles du marché de la santé numérique. Les dispositifs nécessitant une documentation de base ou une documentation approfondie doivent tous se conformer à la version de la norme ANSI/AAMI IEC 62304 « Logiciels pour dispositifs médicaux – Processus du cycle de vie des logiciels » FDA. Les documents approfondis exigent une description supplémentaire de la configuration complète, avec des détails encore plus précis sur le plan de conception, de développement et de maintenance dans le cycle de vie du logiciel, afin d'assurer une plus grande clarté lors de l'examen.
- Selon l'analyse des risques et conformément aux exigences du Règlement sur les systèmes qualité (21 CFR 820), des informations relatives à la sécurité, telles que l'environnement d'exploitation, l'efficacité, la précision, le temps de réponse, le temps de latence, la cohérence, les limites et la plage de fonctionnement, ainsi que toute valeur de base ou de seuil requise par le logiciel pour fonctionner, doivent également être incluses. La mise en place de tout système de vigilance pour 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 du logiciel, la vérification et la validation du logiciel sont essentielles, réalisées en testant les composants logiciels au niveau du système ou de l'intégration. Ceci est obligatoire pour une documentation améliorée. En outre, la description des protocoles de test ainsi que les résultats attendus ou observés pour établir le statut de réussite/échec du système devraient également être abordés.
- Toute implication d'anomalies non résolues telles que des bogues, des défauts pouvant affecter la performance de la fonction logicielle doit être identifiée et classifiée selon 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 un produit combiné, soit classés comme un dispositif de classe III à haut risque, soit une fonction logicielle destinée à être utilisée dans des applications de don et de transfusion sanguine qui effectue l'évaluation de la compatibilité entre le donneur et le receveur. Les dispositifs nécessitant une documentation spéciale doivent respecter les exigences de documentation renforcée. La documentation de base doit inclure un résumé des analyses des dangers, des mesures d'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 tenue de publier la version finale des lignes directrices 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 du secteur afin de discuter de ce projet de lignes directrices.
Pour en savoir plus sur la soumission avant commercialisation des fonctions logicielles des dispositifs, contactez un expert en réglementation régional comme Freyr. Restez informé. Restez conforme.