Le Forum des Dispositifs Médicaux

Veuillez pour créer des messages et des sujets de discussion.

Notion de Logiciel Hérité dans la 62304/A1:2015

Bonjour,

L’amendement A1 de 2015 introduit la notion de Logiciel Hérité comme étant, d’après l’annexe B.4.4, un logiciel qui a été conçu avant la version actuelle de la norme.

Cependant, le paragraphe 4.4, ne donne pas cette précision.

Je souhaiterais donc savoir si nous devons comprendre par ‘Logiciel Hérité’ un logiciel quand même développé selon la 62304 :2006 et pouvant présenter quelques écarts avec la version 2015, ou potentiellement un logiciel développé en dehors de la 62304 que l'on souhaiterais utiliser dans un dispositif médical.

Je souhaiterais donc savoir si nous devons comprendre par ‘Logiciel Hérité’ .... un logiciel développé en dehors de la 62304 que l'on souhaiterais utiliser dans un dispositif médical.

Oui,  à condition de documenter tous les risques qui lui sont liés et bien sûr de les mitiguer.

Bonjour,

Je me permets de rouvrir ce sujet car j'accompagne actuellement plusieurs éditeurs de logiciels dans le cadre de leur marquage MDR (Classe IIx) et qui n'ont jamais respecté l'IEC 62304 (quelque soit sa version).

J'aimerai savoir si l'un d'entre vous avait déjà expérimenté la clause de "legacy device" de la norme, lors d'un marquage CE ?

Imaginons un logiciel ayant 15 ans d'existence. Est-il possible de considérer la version du logiciel qui précède la certification comme un logiciel hérité, intégré dans le DM correspondant à la nouvelle version de ce même logiciel ?

Dans ce cas, il faut appliquer toutes les actions indiquées dans la clause 4.4 de la 62304, sur le logiciel hérité.

Est-il possible dans ce cas de ne pas faire du retro engineering complet sur les URS / SRS par exemple, mais de rester sur des spécifications d'un niveau assez global ?

En considérant par exemple le logiciel hérité comme un SOUP , intégré dans le DM global ?

Merci par avance pour vos retours. Je pense que beaucoup de fabricants de logiciels DM vont être confrontés à cette problématique.

Cordialement,

Benoit

 

 

 

 

@guillaume, avez-vous un retour d'expérience sur le sujet ? J'ai l'impression que ce n'est pas courant dans les certifications DM... Ce qui me fait dire que les logiciels autonomes sont vraiment des nouveaux arrivants dans le domaine 😉

 

Bonjour,

oui, c'est jouable, votre cas correspond à la définition de logiciel hérité

il faut néanmoins produire une documentation minimale, pour améliorer le rapport bénéfice / risque : spécifications, plans de test et rapports de test

 

voir le §9 de la procédure Cycle de vie du logiciel

D'ailleurs, à propos de la définition d'un logiciel hérité, il est indiqué dans la norme qu'il s'agit d'un logiciel qui a été mis sur le marché de façon légale.

Or, mes clients ont mis leur logiciel sur le marché sans faire l'auto-certification de classe 1, selon la MDD alors qu'ils étaient déjà concernés par la directive.

Est-ce que selon vous cette situation engendre l'impossibilité d'utiliser la clause du logiciel hérité ?

Merci par avance pour votre avis !

Benoit

Si l'on prend la norme au mot : c'est bloquant, le soft devait être marqué CE (même sans recourir à la 62304)

Mais techniquement cela ne change rien

Quelques pistes :

  • si toujours classe I : considérer que c'est un soft hérité, c'est de l'auto-certif 😇
  • si un ON est impliqué : argumenter avec lui que le soft est figé depuis 15 ans, faire un bilan des problèmes sur le marché, si négligeables alors il devrait accepter l'astuce du soft hérité

mais, souvent, un ON prend les normes au mot près...

 

Merci c'est ce qu'un autre consultant m'avait indiqué.

Peu de chance qu'un ON prenne le risque, surtout si le logiciel hérité représente 99 du DM.

Dans ce cas précis, on va devoir faire du rétro engineering (URS / SRS) sur tout le soft (peut-être qu'on pourra négocier sur le niveau de détail selon l'analyse des données de PMS disponibles).

Merci pour votre avis sur la question !