Was ist Software of Unknown Provenance (SOUP)?

In der Welt der Medizinprodukte spielt Software eine entscheidende Rolle. Allerdings wird nicht die gesamte in diesen Geräten verwendete Software von Grund auf neu entwickelt. Oft ist Standardsoftware oder Software unbekannter Herkunft (SOUP) in das Gerät integriert. Aber was genau ist SOUP?

Software unbekannter Herkunft / Software of Unknown Provenance (SOUP)

Software of Unknown Provenance (SOUP) ist ein Begriff, der branchenübergreifend verwendet wird, um Software zu beschreiben, deren Sicherheit, Leistung und potenzielle Risiken nicht vollständig bekannt sind, da sie nicht vom Gerätehersteller selbst entwickelt wurde. Dazu gehört Standradtsoftware / off-the-shelf (OTS) Software, die im Sinne der Transparenz mit einem unbekannten Softwareentwicklungsprozess oder einer unbekannten Softwareentwicklungsmethode entwickelt wurde. Sie kann von einem Betriebssystem, einem Datenbankverwaltungssystem oder einer einfachen Softwarebibliothek zur Formatierung von Daten alles sein. Im Folgenden werden wir einige spezifischere Beispiele dafür nennen und dir helfen, SOUPs für dein Gerät korrekt zu handhaben.

Die Verwendung von SOUP in Medizinprodukten ist aufgrund der potenziellen Risiken, die diese für die Sicherheit und Leistung des Geräts darstellen kann, besonders wichtig. Wenn die Herkunft der Software nicht bekannt ist, kann es schwierig sein, die Zuverlässigkeit, Sicherheit und potenzielle Risiken im Zusammenhang mit ihrer Verwendung einzuschätzen. Dies ist besonders wichtig bei medizinischen Geräten, bei denen Softwarefehler zu schweren Schäden oder sogar zum Tod führen können.

Die Norm IEC 62304 bietet einen Rahmen für die Lebenszyklusprozesse von Software für medizinische Geräte, einschließlich der Verwendung von SOUP. Gemäß Abschnitt 8.1.2 dieser Norm musst du SOUP anhand des Namens, der Version und des Herstellers jeder SOUP identifizieren. Wir haben festgestellt, dass dies am besten durch eine globale SOUP-Liste erreicht werden kann.

Darüber hinaus schreiben die Abschnitte 7.1.2 und 7.1.3 vor, dass die Hersteller jede SOUP auf potenzielle Risiken für Patienten, Bediener oder Dritte hin analysieren. Dazu gehört auch die Identifizierung bekannter Softwareanomalien, die zu einer Gefahrensituation beitragen könnten. Ein guter Ort, um dies zu überprüfen, sind GitHub-Issues oder andere Issue-Boards für die Software.

Die Verwendung von SOUP kann zwar bestimmte Vorteile wie Kosten- und Zeiteinsparungen bieten, es ist jedoch von entscheidender Bedeutung, dass die Hersteller die potenziellen Risiken, die mit ihrer Verwendung verbunden sind, gemäß der Norm IEC 62304 gründlich dokumentieren und bewerten.

Du fragst dich jetzt vielleicht: „Wie in aller Welt soll ich das alles für mein Produkt dokumentieren?“ Nun, nicht alle Softwarekomponenten müssen als SOUPs klassifiziert werden. Lass uns darüber sprechen, welche SOUPs sind und warum.

SOUP ermitteln

Die Feststellung, ob es sich bei einer Softwarekomponente um eine SOUP handelt, kann eine Herausforderung sein, insbesondere wenn es sich um komplexe Systeme oder Legacy-Code handelt. Wie klassifizieren wir solche Komponenten?

Der erste Schritt bei der Klassifizierung einer Softwarekomponente als SOUP besteht darin, festzustellen, ob die Softwarekomponente nach einem bekannten Softwareentwicklungsprozess oder einer bekannten Methode für die Medizintechnik entwickelt wurde. Hat der Hersteller IEC 62304 befolgt und wurde es nach ISO 13485 gebaut? Ist dies nicht der Fall oder sind diese Informationen nicht verfügbar, kann die Softwarekomponente als SOUP betrachtet werden.

In der Praxis beinhaltet die Klassifizierung einer Softwarekomponente als SOUP eine gründliche Bewertung der Softwarekomponente, ihres Verwendungszwecks im Medizinprodukt und der damit verbundenen potenziellen Risiken. Dieser Prozess erfordert ein tiefes Verständnis sowohl der Softwarekomponente als auch des medizinischen Geräts, in dem sie verwendet werden soll. Im Folgenden findest du einige allgemeine Beispiele zu verschiedenen Arten von Softwarekomponenten:

• Node/Python-/Java/Rust-Abhängigkeiten: Wenn diese aus Bibliotheken Dritter stammen und in deiner Medizinproduktsoftware enthalten sind, handelt es sich um SOUPs
• Gehostete Dienste wie Authentifizierung oder Benachrichtigungen: Das hängt von der Funktion ab. Wenn sie in deiner Anwendung enthalten sind, handelt es sich um SOUPs. Oft befinden sich diese Dienste außerhalb dessen, was wir als „medizinisches Software-Gerät“ bezeichnen, und in diesem Fall handelt es sich bei diesen Diensten nicht um SOUP.
• Betriebssysteme oder Frameworks: Darüber gibt es einige Debatten. Da Betriebssysteme und Frameworks oft als die Umgebung betrachtet werden, in der die Software ausgeführt wird, und nicht als Teil des Software-Medizinprodukts selbst, könnte man begründen, dass sie nicht als SOUP aufgeführt werden.
• Tools für die Entwicklung: Alle in der Entwicklung verwendeten Tools wie IDEs und Compiler gelten nicht als SOUP, da sie nicht für medizinische Zwecke, sondern für die Erstellung der Software verwendet werden.

‍

Schauen wir uns einige Beispiele und Gegenbeispiele für SOUPs an. Stellen wir uns für dieses Beispiel vor, dass es sich bei unserem Medizinprodukt um eine Software handelt, die ein Foto deiner Haut analysiert, um die durch Psoriasis verursachten Hautausschläge zu überwachen und dir zu helfen, über deine Behandlungen auf dem Laufenden zu bleiben. Die Software wurde intern entwickelt, enthält jedoch einige Softwarekomponenten von Drittanbietern. In der folgenden Tabelle findest du einige Beispiele für diese Komponenten und ob es sich um SOUP handelt oder nicht.

‍

‍

Denke daran, dass die Anwendung von SOUP dich nicht davon entbindet, die Sicherheit und Wirksamkeit des Medizinprodukts zu gewährleisten. Du bist weiterhin für die Leistung des Geräts verantwortlich, einschließlich aller Softwarekomponenten, die als SOUP eingestuft sind. Daher ist ein strenger Risikomanagementprozess beim Umgang mit SOUP unerlässlich.

Verwaltung der IEC 62304-Dokumentationsanforderungen für SOUP

Um die IEC 62304-Dokumentationsanforderungen für SOUP effektiv zu verwalten, kannst du einige praktische Strategien anwenden. Dazu gehören die Führung eines SOUP-Inventars, die Durchführung regelmäßiger Risikobewertungen und die Einrichtung eines robusten Änderungsmanagementprozesses.

Im Folgenden wird detaillierter beschrieben, wie diese Prozesse durchgeführt werden:

• Identifiziere SOUPs: Der erste Schritt besteht darin, alle in deiner Medizinproduktesoftware verwendeten SOUP anhand des Namens, des Herstellers und der Version der von Ihnen verwendeten Software zu identifizieren. Du solltest auch ermitteln, wo sich die SOUP in deiner Softwarearchitektur befindet. Die erste Anlaufstelle für SOUP ist deine Liste der Depenendcies für jedes Softwareelement in deiner Medizinproduktsoftware. Wenn die Abhängigkeiten wiederum Abhängigkeiten aufweisen, werden diese durch deine Bewertung der ursprünglichen Abhängigkeit berücksichtigt.
• Risiken managen: Der Standard verlangt, dass du die Risiken im Zusammenhang mit der Verwendung aller SOUPs verwaltest. Dies kann individuell pro SOUP oder allgemeiner in deiner Risikomanagementdatei erfasst werden. Wenn das Versagen einer SOUP zu einem Schaden für den Patienten führen kann, dokumentierst du dies in deiner Risikoanalyse.
• Dokumentiere die SOUP-Anforderungen: Für Software der Risikoklassen B und C müssen bei SOUP-Artikeln die Funktions- und Leistungsanforderungen sowie die Hardware- und Softwareanforderungen des Systems dokumentiert werden. In deiner Liste der SOUPs kannst du angeben, welche Aufgaben deine SOUPs erfüllen müssen bzw. was für ihre Ausführung erforderlich ist.
• SOUP-Anomalien: Es ist erforderlich, dass alle SOUPs auf bekannte Anomalien überprüft werden. Zumindest sollten alle Anomalielisten, die für die SOUPs existieren, überprüft werden, um sicherzustellen, dass die bekannten Anomalien im Zusammenhang mit der SOUP bekannt sind.

Offensichtlich kann dies eine lästige Menge an Dokumentation sein, wenn du lange Listen von Bibliotheken von Drittanbietern hast, die du in deine Software integrierst. Wir haben festgestellt, dass es am besten funktioniert, eine Tabelle zu verwenden, um so viele deiner SOUP-Informationen wie möglich zu dokumentieren. Darüber hinaus empfiehlt es sich, die Anforderungen der SOUP in der Dokumentation zur Softwarearchitektur zu vermerken.

FormlyAI: Dein Partner für die Zertifizierung von Medizinprodukten

Bei FormlyAI verstehen wir die Komplexität der MDR-Zertifizierung von Medizinprodukten. Unser Service bietet einen optimierten und effizienten Weg zur CE-Kennzeichnung und alle Tools, um sicherzustellen, dass dein Medizinprodukt allen erforderlichen EU-Vorschriften entspricht. Und das alles zu einem Bruchteil der Kosten, die bei der Inanspruchnahme herkömmlicher Berater anfallen. Auf diese Weise kannst du deine Konformitätsdokumentation erstellen und die CE-Kennzeichnung innerhalb weniger Wochen statt Jahre beantragen.

Erfahre mehr über unsere Software und beschleunigen deinen Weg zur CE-Kennzeichnung mit Formly.