L'organisme de réglementation des dispositifs médicaux aux États-Unis a clarifié ses recommandations visant à déterminer quels types de modifications apportées à un logiciel ou micrologiciel exigent une nouvelle déclaration préliminaire 510 (k) pour un dispositif médical.

Une nouvelle directive de la FDA des États-Unis relative aux modifications des logiciels a été publiée séparément de celle adressant les autres modifications de DM pour lesquelles les fabricants doivent remplir un nouveau 510 (k), reflétant ainsi la reconnaissance par la FDA du rôle plus omniprésent et complexe du logiciel en tant que composant essentiel de la fonctionnalité d'un dispositif.

Définir le « logiciel » dans le contexte des dispositifs médicaux

La FDA, dans la directive, définit le logiciel comme tout ensemble d'instructions électroniques qui contrôlent les actions, entrée ou sortie, d'un dispositif médical. Un logiciel qui « est intégré à, ou composant d'un dispositif médical de manière permanente,...est un accessoire d'un autre dispositif médical, ou ... qui est destiné à être utilisé à une ou plusieurs fins médicales, et qui le réalise sans faire partie d'un dispositif médical matériel » entre dans le champ de la directive, indique la FDA.

La directive ne s'étend pas aux logiciels comme certaines applications médicales mobiles pour lesquels la FDA ne prévoit pas de renforcer les contrôles réglementaires, ni aux questions liées au cycle de vie des logiciels, ni aux exigences de documentation 510 (k) pour modification de logiciel, ou aux principes de validation des logiciels de DM, tous ces points étant abordés par d'autres documents directeurs.

(Vous trouverez davantage d'informations sur les points reliés à cette directive FDA dans nos livres blancs sur le parcours réglementaire d'enregistrement 510(k) et les exigences américaines en matière de cybersécurité des dispositifs médicaux.)

Les modifications du logiciel qui exigent, ou pas, un nouveau 510 (k)

La directive contient un tableau destiné à aider les fabricants et développeurs à déterminer quels types de modifications apportées au logiciel signifient la présentation d'un nouveau 510(k) et celles qui ne l'exigent pas.

Selon la FDA, deux grands types de modifications ne justifient pas de nouveaux 510 (k) :

• Les modifications apportées uniquement pour améliorer la cybersécurité, qui n'ont aucun autre impact sur le logiciel ou le dispositif
• Les modifications apportées uniquement pour remettre le système d'un dispositif dans les caractéristiques de la plus récente version autorisée du logiciel

Pour de tels cas, la directive recommande que les déclarants documentent ces modifications dans leurs dossiers.

Ensuite, le tableau énumère quatre grands types de modifications de logiciels qui nécessitent habituellement un nouveau dépôt de 510 (k) :

• Les changements qui introduisent de nouvelles causes ou modifient les causes existantes de situations dangereuses entraînant des dommages importants ; ce risque n'est pas atténué dans la version la plus récente autorisée du dispositif
• Les changements qui introduisent directement de nouvelles situations dangereuses entraînant des dommages importants ; ce risque n'est pas atténué dans la version la plus récente autorisée du dispositif
• Les changements qui créent ou nécessitent de nouvelles mesures ou modifications à des mesures de maîtrise des risques existantes pour les situations dangereuses qui pourraient entraîner des dommages importants
• Les changements qui affectent considérablement la fonctionnalité clinique ou la performance associée à l'utilisation prévue du dispositif

Bienvenue à cette directive distincte relative aux logiciels

Le fait que la FDA traite les modifications de logiciels dans une directive séparée des autres types de modifications montre une meilleure compréhension par celle-ci des problèmes particuliers qui se posent avec les produits logiciels.

« Le cycle de modification pour les logiciels est beaucoup plus petit que pour les autres types de modifications comme la documentation ou les matériaux » explique Richard Vincins, vice président Assurance Qualité Emergo. « Cette directive est destinée à accompagner les fabricants lorsque des modifications sont apportées au logiciel, mais elle conseille fortement l'utilisation des principes directeurs et la justification de la nécessité des changements. »