Documentation logicielle de la FDA pour les dispositifs médicaux

Freelance rédacteur réglementaire Shreya Chenni fournit un guide de la documentation logicielle de la FDA pour les dispositifs médicaux, y compris une ventilation des exigences en fonction de la classification. 

Le site dispositif médical industry is seeing rapid technological advancement and a high rate of innovation.  Nowadays, many devices are AI-enabled, which allows early detection of disease, identification of different patterns of a biological activity, and improved diagnostic accuracy. Some examples of AI-enabled applications or devices include Arterys Application, Philips WSI and QuantX by Quantitative Insights. The software has to be verified and validated, to ensure its safety and effectiveness. 

Pour tout appareil qui contient un logiciel passant par le Route 510(k)Dans ce cas, des documents spécifiques relatifs aux logiciels doivent être soumis. Dans cet article, nous abordons les documents requis pour Soumissions 510(k) et comprendre comment les rédiger en fonction de la classification de votre logiciel.  

Comment classer votre logiciel de dispositif médical ? 

Identifier le niveau de préoccupation (NdP) applicable. Il existe trois niveaux : 

• Majeur : une défaillance ou un vice caché peut entraîner directement la mort ou des blessures graves pour le patient ou l'opérateur. 

OU 

 une défaillance ou un vice caché pourrait indirectement entraîner la mort ou des blessures graves du patient ou de l'opérateur par le biais d'informations incorrectes ou tardives ou par l'action d'un prestataire de soins.

• Modérée : une défaillance ou un défaut de conception latent pourrait entraîner directement des blessures mineures pour le patient ou l'opérateur.

 OU 

une défaillance ou un vice caché pourrait indirectement entraîner des blessures mineures pour le patient ou l'opérateur par le biais d'informations incorrectes ou tardives ou par l'action d'un prestataire de soins. 

• Mineure : si les défaillances ou les défauts de conception latents sont peu susceptibles de causer des blessures au patient ou à l'opérateur. 

Utilisez le tableau 1 et le tableau 2 de la Guide de la FDA sur le contenu des soumissions de précommercialisation pour les logiciels contenus dans les dispositifs médicaux pour répondre aux questions et déterminer le niveau de préoccupation de votre logiciel. 

Documents logiciels de la FDA pour les dispositifs médicaux

Quels sont les documents à présenter ?

Les logiciels de niveau de préoccupation modéré et majeur doivent être soumis avec 11 documents différents. Alors que les logiciels de niveau de préoccupation mineur nécessitent sept documents différents. La portée et l'étendue des détails dans ces documents varient en fonction de leur niveau de préoccupation.

Le tableau suivant identifie les documents requis pour chacun des niveaux de préoccupation : 

Mineur	Modéré	Major
Niveau de préoccupation	Niveau de préoccupation	Niveau de préoccupation
Description du logiciel	Description du logiciel	Description du logiciel
Analyse des risques liés aux dispositifs	Analyse des risques liés aux dispositifs	Analyse des risques liés aux dispositifs
Spécification des exigences logicielles (SRS)	Spécification des exigences logicielles (SRS)	Spécification des exigences logicielles (SRS)
Analyse de la traçabilité	Analyse de la traçabilité	Analyse de la traçabilité
Documentation de vérification et de validation	Documentation de vérification et de validation	Documentation de vérification et de validation
Historique des niveaux de révision	Historique des niveaux de révision	Historique des niveaux de révision
----	Charte de conception architecturale	Charte de conception architecturale
----	Document de spécification de la conception du logiciel	Document de spécification de la conception du logiciel
----	Software Development Environment Description	Description de l'environnement de développement logiciel
----	Anomalies non résolues (bogues ou défauts)	Anomalies non résolues (bogues ou défauts)

 

Description des documents 

1. Niveau de préoccupation 

Enregistrez les réponses aux questions du Tableau 1 et du Tableau 2 du Guide de la FDA sur le contenu des soumissions de précommercialisation pour les logiciels contenus dans les dispositifs médicaux  dans ce document. Inclure une justification du niveau de préoccupation déterminé. 

2. Description du logiciel

Ce document présente le logiciel du dispositif et doit donc fournir un aperçu complet des caractéristiques, des fonctionnalités et de l'utilisation prévue. Il doit inclure le langage de programmation, la plate-forme matérielle, le système d'exploitation et l'utilisation de logiciels disponibles sur le marché, le cas échéant. Des figures et des diagrammes doivent être inclus, le cas échéant. 

Dans le cas où le dispositif utilise un logiciel sur étagère, veuillez vous référer au document d'orientation de la FDA "Guide pour l'utilisation de logiciels sur étagère dans les dispositifs médicaux." 

3. Analyse des risques liés aux dispositifs 

 Une analyse des risques liés au dispositif est indispensable. Tous les dangers prévisibles associés à l'utilisation prévue de l'appareil (logiciel et matériel) doivent être saisis. L'analyse des risques doit être réalisée en conformité avec la norme ISO 14971. L'analyse des dangers doit identifier le danger, le risque, la gravité du danger, la cause du danger, la mesure de contrôle du risque et la vérification de la mesure de contrôle. 

4. Spécification des exigences du logiciel

La spécification des exigences du logiciel (SRS) documente toutes les exigences du logiciel. Fondamentalement, les exigences décrivent ce que le logiciel doit faire. Les exigences peuvent être classées dans différentes catégories, telles que les exigences fonctionnelles, de performance, d'interface utilisateur et réglementaires. 

Pour les LdC mineures, le SRS peut être un résumé des exigences fonctionnelles, mais pour les LdC modérées et majeures, les exigences doivent être détaillées et typiquement listées. Assurez-vous que chaque exigence listée a un ID d'exigence qui lui est attribué, comme SRS-01, SRS-02, etc. 

Voici quelques exemples du SRS : 

Exigences matérielles : Incluez les exigences concernant -  

• microprocesseurs 
• les dispositifs de mémoire
• capteurs 
• les sources d'énergie 
• caractéristiques de sécurité
• communications

Exigences de programmation : Inclure les exigences relatives à la taille du programme, les restrictions, etc. 

Exigences d'interface : Comprend les exigences qui décrivent la communication entre le logiciel et les périphériques matériels tels que les imprimantes, les moniteurs. D'autres exigences telles que le système d'exploitation avec lequel le logiciel est compatible et ainsi de suite. 

Software Performance and Functional Requirements Software performance and functional requirements include algorithms or control characteristics for therapy, diagnosis, monitoring, alarms, analysis, and interpretation with full text references or supporting clinical data, if necessary. 

Les performances du logiciel et les exigences fonctionnelles peuvent également inclure :

• Limitations du dispositif dues au logiciel 
• Tests et contrôles internes des logiciels
• Traitement des erreurs et des interruptions 
• Caractéristiques de détection, de tolérance et de récupération des fautes 12 Contient des recommandations non contraignantes 
• Exigences de sécurité
• Besoins en temps et en mémoire 
• Identification des logiciels disponibles sur étagère, le cas échéant. 

5. Tableau de conception de l'architecture

 Ce document présente clairement la relation, le flux de données et l'interaction entre les principaux composants ou blocs fonctionnels du logiciel. Il est généralement représenté sous forme d'organigramme, de diagrammes de blocs et d'autres formes, selon le cas. Pour les logiciels de niveau de préoccupation modéré et majeur, le diagramme de conception peut inclure des diagrammes d'état. 

6. Spécifications de conception logicielle (SDS)

La mise en œuvre de ces exigences est détaillée dans ce document. Chaque SDD doit être numérotée, par exemple SDD-01, comme le SRS. Chaque exigence incluse dans le SRS doit avoir une spécification de conception correspondante. Cependant, il est également possible qu'une seule spécification de conception corresponde à un groupe d'exigences. 

7. Analyse de la traçabilité

Ce document relie les exigences, la spécification de la conception, les dangers et les tests V&V. La matrice de traçabilité peut être rédigée comme ci-dessous, les détails peuvent être ajoutés si nécessaire : 

Besoin de l'utilisateur (facultatif)	SRS	SDS	Dangers	Cas de test V&V
UND-001	SRS-001 SRS-002	SDS-001	Haz-001	TC-001
UND-002	SRS-002	SDS-001 SDS-002	Haz-002	TC-002 TC-004

 

8. Description de l'environnement de développement logiciel (SDED)

Les logiciels de niveau de préoccupation modéré et majeur doivent soumettre un SDED qui décrit le plan du cycle de vie du développement du logiciel, la maintenance et les activités du logiciel. Le niveau de détail diffère pour les niveaux modéré et majeur. Reportez-vous au tableau 1 de la norme EN 62304 : Tableau A.1 - Résumé des exigences par classe de sécurité logicielle. Il peut être utilisé pour identifier les éléments à inclure et les activités qui doivent être documentées par classe. Les trois classes A, B et C correspondent au niveau de préoccupation de la FDA.  

9. Documentation de vérification et de validation

BdC mineur : Documenter les tests au niveau du dispositif et les tests d'intégration (le cas échéant). S'assurer que les cas de test ont un critère d'acceptation et un résumé des résultats du test. 

LoC modérée : Documenter la liste sommaire des activités de validation et de vérification et leurs résultats. Inclure les critères d'acceptation. S'assurer que l'analyse de traçabilité fait référence aux ID des cas de test. 

BdC majeure : En plus de l'information ci-dessus (BdC modérée), la description de tous les tests échoués et les changements effectués en réponse à ceux-ci doivent être documentés. 

10. Historique des niveaux de révision

Documentez les principales modifications apportées au logiciel en veillant à ce que la dernière ligne de temps/entrée soit la dernière version du logiciel. Identifiez le numéro de version, la date et décrivez les changements par rapport à la version précédente. 

11. Anomalies non résolues 

Documenter les bogues non résolus existant dans le logiciel en cours de publication. Saisissez les éléments suivants pour chaque bogue : 

• Le problème
• Impact sur les performances du dispositif 
• Délais prévus pour corriger ces bogues (le cas échéant) 

The above eleven documents cover the entire documentation necessary for the device software. Additionally, FDA requires Cybersécurité Documentation such as cybersecurity plan, risk management and V&V tests and their results. For more information on this FDA guidelines on Cybersecurity requirements refer to: Contenu des demandes de précommercialisation pour la gestion de la cybersécurité des dispositifs médicaux. 

Références : 

• Directives sur le contenu des soumissions de précommercialisation pour les logiciels contenus dans les dispositifs médicaux

Vous avez besoin d'aide pour la documentation des logiciels de la FDA pour les dispositifs médicaux ? Prenez contact avec des rédacteurs indépendants spécialisés dans la réglementation et Experts en soumission à la FDA sur Kolabtree.