Qu'est-ce qu'un logiciel de provenance inconnue (SOUP)?

Dans le monde des dispositifs médicaux, les logiciels jouent un rôle essentiel. Cependant, tous les logiciels utilisés dans ces appareils ne sont pas développés à partir de zéro. Souvent, un logiciel standard ou un logiciel de provenance inconnue (SOUP) est intégré à l'appareil. Mais qu'est-ce que la soupe exactement ?

Update: We also released a new license checker that you can use for the SOUPs in your software, completely free to use. Simply upload your package.json or requirements.txt to get all the licenses for SOUPs in your software. It saved our clients a ton of time so we decided to make it public. Check it out here after reading the article.

Logiciel de provenance inconnue alias SOUP

Software of Unknown Provenance, ou SOUP, est un terme utilisé dans tous les secteurs pour décrire les logiciels dont la sécurité, les performances et les risques potentiels ne sont pas entièrement connus car ils n'ont pas été développés par le fabricant de l'appareil lui-même. Cela inclut les logiciels prêts à l'emploi qui n'ont pas été développés selon un processus ou une méthodologie de développement logiciel connu et qui peuvent inclure n'importe quoi, qu'il s'agisse d'un système d'exploitation, d'un système de gestion de base de données ou même d'une bibliothèque de logiciels. Nous en donnerons quelques exemples plus spécifiques ci-dessous.

L'utilisation de la SOUP dans les dispositifs médicaux est particulièrement importante en raison des risques potentiels qu'elle peut présenter pour la sécurité et les performances du dispositif. Si la provenance du logiciel est inconnue, il peut être difficile d'évaluer la fiabilité, la sécurité et les risques potentiels associés à son utilisation. Cela est particulièrement crucial pour les dispositifs médicaux où les défaillances logicielles peuvent entraîner de graves dommages, voire la mort.

La norme IEC 62304 fournit un cadre pour les processus du cycle de vie des logiciels des dispositifs médicaux, y compris l'utilisation du SOUP. Selon la section 8.1.2 de cette norme, vous devez identifier le POP par le nom, la version et le fabricant de chaque article SOUP. Nous avons découvert que le meilleur moyen d'y parvenir était d'établir une liste mondiale de soupes.

En outre, les sections 7.1.2 et 7.1.3 obligent les fabricants à analyser chaque produit à base de SOUP pour détecter les risques potentiels pour le patient, l'opérateur ou des tiers. Cela inclut l'identification des anomalies logicielles connues qui pourraient contribuer à une situation dangereuse. Les problèmes de GitHub ou d'autres forums de discussion relatifs au logiciel constituent un bon endroit pour vérifier cela.

Bien que l'utilisation du SOUP puisse apporter certains avantages tels que des économies de temps et d'argent, il est essentiel que les fabricants documentent et évaluent de manière approfondie les risques potentiels associés à son utilisation conformément à la norme IEC 62304.

Vous vous demandez peut-être « comment diable vais-je documenter tout cela pour mon produit ? » Eh bien, tous les composants logiciels n'ont pas besoin d'être classés dans la catégorie des SOUP. Parlons de ce que sont les soupes et pourquoi

Déterminer les problèmes liés à la soupe et à la

Il peut être difficile de déterminer si un composant logiciel est un SOUP, en particulier lorsqu'il s'agit de systèmes complexes ou de code existant. Comment classer ces composants ?

La première étape de la classification d'un composant logiciel dans la catégorie SOUP consiste à déterminer si le composant logiciel a été développé selon un processus ou une méthodologie de développement logiciel connu lié à la technologie médicale. Le fabricant a-t-il suivi la norme IEC 62304 et a-t-il été construit selon la norme ISO 13485 ? Si ce n'était pas le cas, ou si ces informations ne sont pas disponibles, le composant logiciel peut être considéré comme du SOUP.

Concrètement, la classification d'un composant logiciel dans la catégorie SOUP implique une évaluation approfondie du composant logiciel, de son utilisation prévue dans le dispositif médical et des risques potentiels qu'il présente. Ce processus nécessite une compréhension approfondie à la fois du composant logiciel et du dispositif médical dans lequel il sera utilisé. Voici quelques considérations générales concernant les différents types de composants logiciels :

• Dépendances Node/Python/Java/Rust : S'ils proviennent de bibliothèques tierces et s'ils sont inclus dans le logiciel de votre dispositif médical, il s'agit de SOUP
• Services hébergés tels que l'authentification ou les notifications : Cela dépend de la fonction. S'ils sont contenus dans votre application, il s'agit de SOUP. Souvent, ceux-ci peuvent se situer en dehors de ce que nous considérons comme un « dispositif médical logiciel » et, dans ce cas, ces services ne sont pas des SOUP.
• Systèmes d'exploitation ou frameworks: Cela fait l'objet d'un débat. Étant donné que les systèmes d'exploitation et les frameworks sont souvent considérés comme l'environnement dans lequel le logiciel fonctionne et non comme une partie du dispositif médical logiciel lui-même, vous pourriez justifier qu'ils ne soient pas inclus dans un SOUP.
• Outils de développement: Tous les outils utilisés dans le développement, tels que les IDE et les compilateurs, ne sont pas considérés comme des SOUP car ils ne sont pas utilisés pour une fonction médicale mais pour créer le logiciel.

‍

Examinons quelques exemples de plats à base de soupe et de produits autres que les soupes. Dans cet exemple, considérons que notre dispositif médical est un logiciel qui analyse une photo de votre peau pour surveiller les éruptions cutanées causées par le psoriasis afin de vous aider à rester au courant de vos traitements. Le logiciel a été développé en interne par une équipe d'ingénieurs mais contient des composants logiciels tiers. Dans le tableau ci-dessous, nous avons fourni quelques exemples de ces composants et indiquons s'ils sont des SOUP ou non.

‍

‍

N'oubliez pas que l'utilisation du SOUP ne vous dispense pas de garantir la sécurité et l'efficacité du dispositif médical. Vous êtes toujours responsable des performances de l'appareil, y compris de tous les composants logiciels classés dans la catégorie SOUP. Par conséquent, un processus de gestion des risques rigoureux est essentiel lorsqu'il s'agit de SOUP.

Gestion des exigences de documentation de la norme IEC 62304 pour le SOUP

Pour gérer efficacement les exigences de documentation de la norme IEC 62304 pour le SOUP, vous pouvez adopter quelques stratégies pratiques. Il s'agit notamment de tenir à jour un inventaire des SOUP, de réaliser des évaluations régulières des risques et de mettre en place un solide processus de gestion du changement.

Vous trouverez ci-dessous une description plus détaillée de la manière de procéder à ces processus :

• Identifier les SOUP : La première étape consiste à identifier toutes les SOUP utilisées dans le logiciel de votre dispositif médical par leur nom, leur fabricant et la version du logiciel que vous utilisez. Vous devez également identifier où se trouve le SOUP dans votre architecture logicielle. Le premier endroit que vous devriez consulter pour SOUP est la liste des dépendances pour chaque élément logiciel du logiciel de votre dispositif médical. Si vos dépendances comportent des dépendances, elles sont couvertes par votre évaluation de la dépendance d'origine.
• Gérer les risques : la norme exige que vous gériez les risques liés à l'utilisation de toutes les SOUP. Cela peut être saisi individuellement par le SOUP ou de manière plus générale dans votre dossier de gestion des risques. Si l'échec d'un SOUP peut nuire au patient, documentez-le dans votre analyse des risques.
• Consignez les exigences du SOUP : pour les logiciels des classes de risque B et C, les exigences fonctionnelles et de performance des articles SOUP doivent être documentées, ainsi que les exigences matérielles et logicielles de leur système. Dans votre liste de SOUPS, vous pouvez spécifier ce que vos SOUPS doivent faire et ce qui est requis pour les exécuter, respectivement.
• Anomalies des SOUP : il est nécessaire que toutes les SOUP soient examinées pour détecter toute anomalie connue. Au minimum, toute liste d'anomalies existant pour les SOUP doit être revue pour s'assurer que les anomalies connues associées aux SOUP sont connues.

Évidemment, cela peut représenter une lourde quantité de documentation si vous avez de longues listes de bibliothèques tierces que vous intégrez à votre logiciel. Nous avons constaté que l'utilisation d'un tableau pour documenter autant d'informations que possible sur votre SOUP pourrait être la solution la plus efficace. En outre, il est recommandé de noter les exigences du SOUP dans la documentation de l'architecture logicielle.

FormlyAI : votre partenaire en matière de certification des dispositifs médicaux

Chez FormLyAI, nous comprenons les complexités de la certification des dispositifs médicaux MDR. Notre service fournit une voie rationalisée et efficace vers le marquage CE et tous les outils nécessaires pour garantir que votre dispositif médical respecte toutes les réglementations européennes nécessaires. Le tout pour une fraction du coût de l'utilisation de consultants traditionnels. De cette façon, vous pouvez établir votre documentation de conformité et demander le marquage CE en quelques semaines, et non en quelques années.

Apprenez-en plus sur notre logiciel et accélérez votre parcours vers le marquage CE avec Formly.