Comment réaliser une analyse des écarts d'un logiciel existant conformément à l'IEC 62304-2015 ?

Les logiciels existants qui n'ont pas été conçus conformément à l'IEC 62304 représentent souvent un véritable casse-tête pour de nombreux fabricants de dispositifs médicaux, en particulier lorsqu'il est nécessaire de concevoir une nouvelle version d'un dispositif médical ou d'apporter des modifications à un dispositif existant.

Quelle est la manière la plus pratique et recommandée d'aborder les logiciels hérités ? Comment mettre en œuvre une analyse des écarts des logiciels hérités requise par l'IEC 62304 ? Krzysztof Minicki, notre Directeur Santé et Sciences de la Vie, examine ces problématiques et explique les moyens possibles d'aligner les logiciels existants sur les exigences de l'IEC 62304.

Qu'est-ce qu'un logiciel legacy ?

Un logiciel hérité est le type de logiciel qui existe déjà dans un dispositif médical introduit sur le marché avant 2006, date d'entrée en vigueur de la première version de l'IEC 62304, et qui est encore commercialisé aujourd'hui. Même si cela fait déjà 15 ans, de telles situations peuvent encore être rencontrées.

Logiciels hérités vs SOUP

Il arrive que l'on confonde les logiciels hérités avec les SOUP (Software of Unknown Pedigree). Cette confusion résulte du fait que les deux ont été développés sans suivre ni documenter les processus du cycle de vie logiciel.

Comment mettre un logiciel existant en conformité avec l'IEC 62304 ?

Il existe plusieurs approches possibles face à un logiciel hérité, selon qu'il sera affecté ou non par des changements.

1. Aucun changement ne sera apporté au logiciel du dispositif médical, y compris les logiciels existants

Tout d'abord, tant que vous ne modifiez rien concernant le logiciel du dispositif médical dont le logiciel hérité fait partie, il n'est pas nécessaire d'agir. Supposons que le logiciel hérité ne soit pas affecté par les changements. Dans ce cas, l'approche la plus simple et recommandée consiste à le traiter comme un SOUP, un logiciel externe sur lequel vous n'avez aucun contrôle, et à suivre les étapes appropriées requises par l'IEC 62304.

Les choses se compliquent lorsque vous souhaitez apporter des modifications à la partie logicielle héritée, et au logiciel de dispositif médical dans son ensemble, sans nécessairement inclure la partie héritée. Imaginez votre logiciel de dispositif médical comme un cercle, où le logiciel hérité n'en est qu'une tranche. Vous pouvez adopter plusieurs approches, selon que vous souhaitez apporter des modifications à n'importe quelle partie de ce cercle qui n'est pas cette tranche, ou que vous souhaitez apporter des modifications à l'ensemble.

Permettez-moi d'illustrer cela par un exemple. Supposons qu'il y a 15 ans, une entreprise ait commercialisé un dispositif médical utilisé pour visualiser des données, comme un moniteur ECG. Le pilote de ce dispositif n'a pas été conçu conformément aux exigences de l'IEC 62304 car la norme n'était pas encore en vigueur. Aujourd'hui, il est nécessaire de modifier les couleurs qu'il affiche. Dans un tel cas, vous n'avez pas besoin d'apporter de modifications au pilote car il communiquera avec le moniteur de la même manière, seules les commandes concernant les couleurs affichées seront différentes. Un tel pilote peut être traité comme un SOUP.

Cependant, si vous souhaitez éliminer les marges à l'écran, cela ne sera pas possible sans modifier le mode d'affichage. Cela conduit à son tour à apporter des modifications au pilote, ou en d'autres termes à notre logiciel existant. Dans un tel cas, vous devez l'aligner sur les exigences de l'IEC 62304. Nous décrirons comment procéder dans les paragraphes suivants. Pour l'instant, revenons un instant aux stratégies, car il y en a au moins deux autres que vous pouvez appliquer dans ce cas.

2. Des modifications seront apportées au logiciel du dispositif médical et/ou au logiciel existant

Tout d'abord, vous devez vous poser une question : le changement est-il suffisamment significatif et étendu pour affecter le logiciel existant ou non. Si c'est le cas et que le changement impacte le logiciel existant, celui-ci ne peut plus être traité comme un SOUP, mais une refonte complète est nécessaire et la norme IEC 62304 doit être appliquée dans son intégralité. Sinon, il y aurait trop de difficultés et il serait difficile de le maintenir.

Une autre possibilité consiste à diviser le logiciel existant en composants qui seront modifiés et ceux qui ne le seront pas, mais qui représentent moins de 10-15 % de l'ensemble. Ensuite, nous abordons la partie révisée du logiciel existant comme un SOUP, comme nous l'avons déjà expliqué. De plus, nous pouvons construire une couche d'intégration supplémentaire d'atténuation des risques qui nous protégera contre les éventuelles conséquences négatives de l'intégration d'un SOUP avec un dispositif médical. Le risque associé à une telle intégration doit être évalué afin de déterminer s'il est nécessaire de mettre en œuvre des mesures de contrôle supplémentaires. Cette approche est assez fréquemment utilisée lorsqu'il s'agit de logiciels existants.

Une autre approche consiste à analyser et à évaluer le logiciel existant conformément à la norme IEC 62304, précisément au chapitre 4.4. Il y est indiqué que vous pouvez réaliser un développement complet de la conception selon toutes les exigences décrites dans les chapitres 5 à 9 et qu'aucune autre action ne doit donc être entreprise concernant le logiciel existant. Cette approche présente toutefois un inconvénient majeur : elle génère des coûts très élevés.

Maintenant que nous avons décrit les stratégies les plus courantes, passons à la partie pratique.

Comment aligner le logiciel existant sur l'IEC 62304 ?

Étape 1 : Évaluation des risques des logiciels hérités

Tout d'abord, conformément aux exigences de gestion des risques, nous devons analyser l'architecture de notre solution et déterminer la classe de risque du logiciel existant. Il existe trois classes de risque : A, B et C. Si notre dispositif médical appartient à l'une de ces classes, en particulier la classe C à haut risque, nous devons alors vérifier si une décomposition peut être réalisée.

Une fois la décomposition effectuée, nous pouvons déterminer si le logiciel existant est responsable de fonctions non médicales présentant un risque plus faible pour le patient, par exemple la transmission de données, ou s'il s'agit d'un composant critique de classe B ou C. Sur cette base, nous devons déterminer si nous pouvons traiter notre logiciel existant comme un SOUP ou si ce n'est pas une option, par exemple dans une situation où le dispositif médical appartient à la classe C et notre logiciel existant appartient également à la classe C, tandis que d'autres composants relèvent de classes de risque inférieures.

Le premier élément à prendre en compte pour réaliser l'analyse des risques concerne les problèmes potentiels que notre logiciel cause, sur la base des retours des utilisateurs. Dans notre évaluation des risques, nous devons décrire toutes les activités qui impactent le dispositif, l'organisation, les processus et les patients.

Autre chose est d'évaluer le risque associé à l'intégration de notre logiciel existant avec d'autres composants du dispositif médical, qu'ils fassent ou non partie du logiciel existant. Nous devons vérifier si des risques ont déjà été décrits pour notre logiciel médical et quelles mesures de contrôle ont été mises en œuvre pour réduire ou limiter ces risques, et valider si notre logiciel existant a un impact sur ces mesures de contrôle. Si c'est le cas, nous devons évaluer le risque possible et vérifier si ces mesures resteront efficaces.

Si nous nous référons maintenant à notre exemple de moniteur ECG, la marge sur l'écran a peut-être été mise en œuvre comme mesure de contrôle des risques afin qu'aucune information importante ne soit coupée. Ainsi, si nous la supprimions, il pourrait y avoir un risque que de telles informations soient manquées. Dans un tel cas, des mesures supplémentaires de contrôle des risques devraient être définies et incluses dans le dossier de gestion des risques.

L'étape suivante consiste à réaliser une analyse des écarts.

Étape 2 : analyse des écarts des logiciels existants selon l'IEC 62304

Lorsque la classe de risque de notre logiciel existant est déterminée, nous devons réaliser une analyse des écarts et vérifier que nous ne manquons aucune documentation requise conformément aux chapitres 5.2 (Exigences logicielles), 5.3 (Conception de l'architecture logicielle), 5.7 (Tests du système logiciel) et 7 (Processus de gestion des risques logiciels).

Au minimum, notre logiciel existant devrait :

• satisfaire aux exigences concernant la fonctionnalité, l'efficacité, la sécurité, etc. telles que décrites au chapitre 5.2 ;

• être inclus dans la documentation de l'architecture logicielle avec une description claire de ses limites, les éléments d'isolation et d'intégration ainsi que le plan d'intégration avec d'autres composants, y compris les risques possibles associés à leurs classes respectives, conformément au chapitre 5.3 ;
• tous les tests nécessaires ont été réalisés et documentés conformément au chapitre 5.7 ;
• avoir mis en œuvre les processus de gestion des risques conformément aux exigences du chapitre 7.

L'analyse des écarts nous aide à déterminer quels éléments de documentation concernant le logiciel existant manquent d'informations essentielles qui doivent être complétées. Elle nous donne également une meilleure vision des risques potentiels et de l'importance du logiciel existant pour l'ensemble du logiciel de dispositif médical.

Sur la base de nos conclusions, nous pouvons préparer un plan qui inclut les résultats de l'analyse des écarts ainsi que des étapes décrites en détail que nous allons entreprendre pour corriger les problèmes identifiés. Le calendrier de mise en œuvre des étapes dépend de la criticité des risques et de la gravité des conséquences pour les utilisateurs finaux. Vous devez également vous rappeler de justifier pourquoi vous souhaitez continuer à maintenir le logiciel legacy, pendant combien de temps et si vous prévoyez d'arrêter de l'utiliser à l'avenir.

En résumé

Si vous ne prévoyez pas d'apporter de modifications à votre logiciel de dispositif médical, l'approche la plus pratique et recommandée consiste à le traiter comme un SOUP, si possible. Ainsi, le logiciel existant sera beaucoup plus facile à maintenir. Toutefois, quelle que soit l'approche choisie, vous devez toujours faire preuve de diligence raisonnable : tester le logiciel existant, évaluer les risques, valider les mesures de contrôle, déterminer les exigences manquantes et décrire votre plan d'action.

Pour plus d'informations sur la réalisation d'une analyse des écarts d'un logiciel hérité, veuillez vous référer à l'IEC 62304.

Si vous avez besoin d'aide pour choisir la bonne approche concernant votre logiciel hérité ou pour réaliser l'analyse des écarts, n'hésitez pas à contacter Krzysztof Minicki via le formulaire ci-dessous.