La toute première chose qu'on remarque en parcourant les nouvelles orientations est que la terminologie et la différenciation de la documentation à fournir en fonction du "niveau de préoccupation" n'apparaissent plus.
Ce concept a été remplacé par le Niveau de documentation : documentation level
L'objectif du niveau de documentation est d'aider à identifier la quantité minimale d'informations qui soutiendraient une demande d'autorisation de mise sur le marché comprenant des fonctions logicielles de dispositifs.
Une approche basée sur le risque a été introduite pour déterminer le niveau de documentation (documentation level) de l'appareil, qui peut être Basic ou Enhanced.
Lors de la détermination du niveau de documentation, les sponsors doivent prendre en compte tous les risques logiciels connus ou prévisibles et les situations dangereuses associées au dispositif, y compris ceux résultant d'une mauvaise utilisation raisonnablement prévisible, qu'elle soit intentionnelle ou non, avant la mise en œuvre des mesures de maîtrise des risques. Cela inclut également la probabilité que la fonctionnalité du dispositif soit intentionnellement ou non compromise par une cyber sécurité inadéquate du dispositif.
Une approche basée sur le risque a été introduite pour déterminer le niveau de documentation du dispositif, qui peut être basique ou amélioré.
Lors de la détermination du niveau de documentation, les promoteurs doivent prendre en compte tous les risques logiciels connus ou prévisibles et les situations dangereuses associées au dispositif, y compris ceux résultant d'une mauvaise utilisation raisonnablement prévisible, qu'elle soit intentionnelle ou non, avant la mise en œuvre des mesures de maîtrise des risques. Cela inclut également la probabilité que la fonctionnalité du dispositif soit intentionnellement ou non compromise par une cyber sécurité inadéquate du dispositif.
|
Software Documentation Elements |
Basic Documentation Level |
Enhanced Documentation Level |
|
Documentation Level Evaluation |
Une déclaration indiquant le niveau de documentation et une description de la raison d'être de ce niveau. |
|
|
Software Description* |
Description du logiciel, y compris une vue d'ensemble des caractéristiques, fonctions, analyses, inputs, outputs et plates-formes hardware importantes du logiciel. |
|
|
Risk Management File |
Plan de gestion des risques, évaluation des risques démontrant que les risques ont été atténués de manière appropriée, et rapport de gestion des risques. |
|
|
Software Requirements Specification (SRS)* |
La documentation SRS, qui décrit les besoins ou les attentes concernant un système ou un logiciel, est présentée dans un format organisé, au niveau du système logiciel ou du sous-système, selon le cas, et contient suffisamment d'informations pour comprendre la traçabilité de l'information par rapport aux autres éléments de la documentation du logiciel (par exemple, le risk management file, software design specification, system and software architecture design chart, software testing) |
|
|
System and Software Architecture Design |
Diagrammes détaillés des modules, couches et interfaces qui composent le dispositif, de leurs relations, des entrées/sorties et du flux de données, et de la manière dont les utilisateurs ou les produits externes (y compris l'infrastructure informatique et les périphériques) interagissent avec le système et le logiciel. |
|
|
Software Design Specification (SDS)* |
La FDA ne recommande pas que la fiche SDS fasse partie de la demande d'autorisation de mise sur le marché. Le fabricant doit documenter ces informations sur la conception par le biais du DHF pour le dispositif. Au cours de l'examen préalable à la mise sur le marché, la FDA peut demander des informations supplémentaires, si nécessaire, pour évaluer la sécurité et l'efficacité du dispositif. |
La Documentation SDS, comprenant des informations suffisantes pour permettre à la FDA de comprendre les détails de la conception technique du fonctionnement du logiciel, la manière dont la conception du logiciel met en œuvre complètement et correctement toutes les exigences du SRS, et la manière dont la conception du logiciel correspond au SRS en termes d'utilisation prévue, fonctionnalité, sécurité et efficacité. |
|
Software Development, Configuration Management, and Maintenance Practices |
Un résumé du plan de développement du cycle de vie et un résumé des activités de gestion de la configuration et de maintenance ; OU Une déclaration de conformité à la version de la IEC 62304 reconnue par la FDA, y compris les sous-classes 5.1.1-5.1.3, 5.1.6-5.1.9, la clause 6 et la clause 8, entre autres, le cas échéant. |
Niveau de documentation de base, PLUS document(s) complet(s) de gestion de la configuration et de plan de maintenance ; OU une déclaration de conformité à la version de la IEC 62304 reconnue par la FDA, y compris les sous-classes 5.1, la clause 6 et la clause 8, entre autres, le cas échéant. |
|
Software Testing as Part of Verification and Validation |
Une description sommaire des activités d'essai aux niveaux de l'unité, de l'intégration et du système ; ET un protocole d'essai au niveau du système comprenant les résultats attendus, les résultats observés, la détermination de la réussite ou de l'échec et le rapport d'essai au niveau du système. |
Basic Documentation Level, PLUS protocoles d'essai au niveau de l'unité et de l'intégration, y compris les résultats attendus, les résultats observés, la détermination de la réussite ou de l'échec, et les rapports d'essai au niveau de l'unité et de l'intégration. |
|
Software Version History* |
Un historique des versions testées du logiciel comprenant la date, le numéro de version et une brève description de tous les changements par rapport à la version précédente du logiciel testé. |
|
|
Unsolved Software Anomalies * |
Liste des anomalies logicielles non résolues avec une évaluation de l'impact de chaque anomalie logicielle non résolue sur la sécurité et l'efficacité du dispositif. |
|
*Déjà présent dans les orientations précédentes.
Le contenu de cette directive devrait entrer en vigueur 60 jours après sa publication, soit environs le 14 août 2023.
Si vous envisagez d'entrer sur le marché américain, il est préférable de commencer à élaborer une documentation conforme à cette directive actualisée.
PQE peut vous aider à soumettre votre dossier à la FDA et à délivrer tous les documents nécessaires.
