SOUP – Software of Unknown Provenance

SOUP ist ein Akkronym für Software of Unknown Provenance. Die IEC 62304 definiert eine SOUP als eine Software-Komponente,

„die bereits entwickelt und allgemein verfügbar ist und die nicht entwickelt wurde, um in das MEDIZINPRODUKT integriert zu werden (auch bekannt als „Off-The-Shelf Software“), oder bereits fertig entwickelte Software, für die angemessene Aufzeichnungen zum Entwicklungs-PROZESS nicht verfügbar sind.“.

Der Begriff SOUP entspricht aber nicht ganz dem Begriff OTS der FDA.

SOUPs, COTS, OTS: Unterschiede und Gemeinsamkeiten der Begriffe

Gleich drei Begriffe verwechseln viele Hersteller von Medizinprodukten, die Software enthalten oder eigenständige Software sind, nämlich COTS, OTS und SOUP. Diese Begriffe sind aber nicht ganz deckungsgleich.

  • Off-the-Shelf Software (OTS software): A generally available software component, used by a medical device manufacturer for which the manufacturer can not claim complete software life cycle control (Definition durch die FDA).
  • Commercial Off-the-Shelf Software (COTS software): OTS-Software, die von einem kommerziellen Anbieter stammt.
  • Software of Unknown Provenance (SOUP Software): SOFTWARE-KOMPONENTE, die bereits entwickelt und allgemein verfügbar ist und die nicht entwickelt wurde, um in das MEDIZINPRODUKT integriert zu werden (auch bekannt als „Off-The-Shelf Software“), oder bereits fertig entwickelte Software, für die angemessene Aufzeichnungen zum Entwicklungs-PROZESS nicht verfügbar sind.

Es wird klar, dass die SOUP eine Übermenge der OTSS und COTS ist. Bei letzterem muss nämlich ein Hersteller „greifbar“ sein, bei der OTSS nicht. Open Source Software wäre beispielsweise OTSS aber nicht COTS.

Weiterführende Informationen

Lesen Sie mehr in diesem Artikel zu Gemeinsamkeiten und Unterschieden von SOUP und OTS.

Die FDA, die den Begriff OTSS definiert, und die IEC 62304, von der der Begriff SOUP stammt, haben auch unterschiedliche Konzepte, was den Umgang mit diesen Komponenten angeht. Zu diesen Unterschieden zählen:

  • Die FDA nutzt einen „risk based“ Ansatz (greift aber dann doch auf den Level of Concern zurück), um die Forderungen an OTS zu skalieren. Diese Forderungen können soweit gehen, die OTS zu verbieten. Die IEC 62304 nennt keine konkreten Forderungen, insbesondere gibt es keine Abhängigkeit von der Sicherheitsklasse.
  • Die FDA hat eine konkrete Liste an Eigenschaften, die für jede OTS-Komponente zu dokumentieren ist. Die IEC 62304 ist unspezifischer (siehe Kapitel 5.3.3 und 5.3.4)
  • Die FDA kennt ein Lieferantenaudit für kritische Software, bei dem die Software-Lebenszyklusprozesse zu bewerten sind. Ist das nicht möglich – das dürfte bei den meisten COTS- und bei (fast) allen OTSS-Herstellern, die nicht COTS sind, der Fall sein – darf die OTS-Software nicht genutzt werden.
  • Die FDA erlaubt es nicht, eigene Software, für die keine adäquaten Aufzeichnungen vorhanden sind, als OTSS zu behandeln.

Benötigen Sie Unterstützung dabei, die COT-, OTS- oder SOUP-Software zu bewerten, um die Forderungen der europäischen und US-amerikanischen Regularien sicher einzuhalten? Dann fragen Sie uns. Wir antworten oft kostenlos.

Software in Hardware-Bauteilen

Wie geht man mit Software um, die bereits in Bauteilen enthalten ist, die Hersteller von Dritten beziehen wie z.B.

  • Software in einem Modem- oder GSM-Chips
  • Software in einem USB-Baustein
  • Software in Display-Controllern
  • Software in Ethernet-Chips und sonstigen Microcontrollern
Software in Hardware-Bausteinen: Auch eine SOUP?

Wir empfehlen, diese Software nicht als SOUP zu behandeln, aus folgenden Gründen:

  1. Für den Hersteller ist es nicht nachvollziehbar, welcher Teil der Funktionalität einer gekauften Hardware in Software implementiert ist. Damit kann der Hersteller auch keine Anforderungen an diese Software formulieren, wie von der IEC 62304 formuliert.
  2. Diese „embedded“ Software fällt nicht unter die Definition des Begriffs SOUP.
  3. Ein Auditor wird Sie wahrscheinlich nicht auf diese Software ansprechen, sondern wenn auf das ganze Bauteil. Machen Sie die Sache nicht unnötig kompliziert.
  4. Die Risiken, dass diese Software Fehler enthält, können und sollten Sie nicht auf Ebene dieser Software diskutieren und beherrschen, sondern auf Ebene des Bausteins bzw. der System-Architektur.

Die Frage, ob Software in Hardware-Bauteilen eine SOUP sei, stellen mir v.a. Hersteller, die die Gesamtheit aller Software in einem Medizinprodukt als das Software-System definieren. Davon rate ich aber ab. Definieren Sie als Software-System die Gesamtheit aller Software innerhalb eines Prozessoren- bzw. Speicherbereichs. In einem Medizingerät kann es somit mehrere Software-Systeme geben. Zumindest eines pro PESS (programmierbares elektrisches Subsystem). Weshalb Sie dies so aufteilen sollten, verrate ich u.a. in den Videotrainings des Auditgarant.

Kriterien zur Auswahl von SOUPs

Die folgenden Kriterien können bei der Auswahl eines SOUP-Herstellers bzw. einer SOUP relevant sein:

  • Kann man den SOUP-Hersteller auditieren? (z.B. ein Lieferantenaudit des Entwicklungsprozesses und des Wartungsprozesses)
  • Bietet die SOUP die Funktionalität, die wir benötigen? Wie vollständig erfüllt sie unsere Anforderungen?
  • Können wir der SOUP die von ihr notwendigen Laufzeitbedingungen wie Hardware, RAM, Betriebssystem usw. bereitstellen?
  • Wie oft ist sie im Einsatz? => Abschätzen der Fehlerwahrscheinlichkeit
  • Veröffentlicht der Hersteller Buglisten? => Input für die Risikoanalyse
  • Ist eine technische Dokumentation der SOUP verfügbar? Beispielsweise eine Architektur? Testberichte?
  • Sind gar Testergebnisse wie beispielsweise bei den Apache-Projekten einsehbar?
  • Ist möglicherweise sogar der Source-Code erhältlich?
  • Gibt es Berichte aus vorangegangenen Audits?
  • Ist ein QM-System beim SOUP-Hersteller vorhanden? (z.B. nach Normen ISO 9001, ISO 15504, ISO 13485, etc.)
  • Ist die SOUP in anderen Medizinprodukten bereits im Einsatz?
  • Was kostet sie?
  • Wie gut ist der Support? Wie schnell reagiert er? Zu welchen Zeiten ist er verfügbar?

Erstellen Sie eine Nutzerwertanalyse, mit der Sie die einzelnen Kriterien für Ihren konkreten Anwendungsfall gewichten.

Regulatorische Anforderungen and SOUPs

Forderungen der IEC 62304

Die IEC 62304 betrachtet SOUPs als Software-Komponenten. Die Hersteller müssen für SOUPs (wie für jede andere Komponente) die Anforderungen daran spezifizieren und deren Erfüllung testen. Zusätzlich zu „normalen“ Komponenten müssen die Hersteller auch die Voraussetzungen spezifizieren, von denen die SOUP ausgehen kann z.B. mit Bezug zu Ressourcen (RAM, CPU, …) oder dem Betriebssystem.

Dokumentation von SOUPs

Um die Forderungen der IEC 62304 umzusetzen empfehle ich Ihnen die SOUPs anhand folgender Parameter z.B. tabellarisch zu dokumentieren:

  • Name der SOUP
  • Version  (diese unterliegen genau wie alle anderen Artefakte der Versionskontrolle)
  • SOUP-Hersteller
  • Anforderungen an SOUP (ggf. Verweis auf getrenntes Dokument oder Software-Architektur)
  • Anforderungen durch SOUP z.B. an Speicher oder Hardware
  • Webseite von Bug Reports und Release Notes

Nachverfolgung

Im Rahmen der Post-Market Surveillance und der nachgelagerten Phase des Risikomanagements müssen die Hersteller aktiv nachverfolgen, ob es Informationen gibt, die Rückschlüsse auf Bugs oder durch SOUP verursachte Risiken gibt. Zu den Informationsquellen zählen:

  • Kundenrückmeldungen (Beschwerden, Fehlermeldungen, Beobachtungen)
  • Meldungen der Hersteller z.B. in Form von Release Notes oder Bug Reports
  • Meldungen anderer Hersteller zu Problemen mit der SOUP z.B. beim BfArM oder der FDA Maude Datenbank.

Wie bei jedem potenziellen Problem, muss der Hersteller das Problem analysieren und entsprechende Maßnahmen ergreifen wie:

  • Austausch der SOUP durch neue Version
  • Ersatz  durch eigene oder andere Komponente
  • Entfernen und ggf. deaktivieren von Funktionalität
  • Verbot, das Produkt weiter zu nutzen
  • Hinweise zum Umgang mit dem Produkt bzw. dem Fehler

Versionskontrolle

Wie alle anderen müssen auch die SOUPs der Versionskontrolle unterliegen. Im Gegensatz zum Source-Code würde man aber den kompilierten Code (z.B. die dll, die jar-Datei, das Executable) z.B. im Versionverwaltungssystem einchecken. Zusätzlich unterliegt die auszuliefernde Software, also das Ergebnis des Build-Prozesses der Konfigurationskontrolle und nicht nur die Artefakte, die als Input dessen dienen.

Zertifizierung von SOUPs nach IEC 62304

Oft stellt sich die Frage: Wäre es nicht besser, eine zertifizierte SOUP zu nehmen? Es gäbe ja z.B. Hersteller von Betriebssystemen, die so etwas anbieten würden (Beispiel).

Ein SOUP-Hersteller muss überhaupt nichts im Sinne des MPGs beachten, schließlich ist er kein Inverkehrbringer. Natürlich wäre es sinnvoll, einen Hersteller auszuwählen, von dem man annehmen kann, dass er Software professionell entwickelt.

Dass es IEC 62304 zertifizierte Produkte geben soll, erscheint aber doch als fragwürdig, denn die IEC 62304 ist eine Prozessnorm und keine Produktnorm. D.h. man kann sich nur zertifizieren lassen, dass man konform mit den (geringen) Anforderungen dieser Norm entwickelt. Über die Güte des Produkts sagt das aber nicht aus.

Ich empfinde diese Form der Werbung/Kommunikation zumindest als missverständlich. Damit spiele ich aber auf keinen konkreten Fall an.

Sonderfall Linker

Wie gehen wir als Auditoren mit den Linkern um? Diese Frage stellte ich mir mit den Vertretern der benannten Stellen, die bei mir zum Expertengespräch waren.

Ein Audior meinte, ein Linker würde Software-Teile für den Kompiliervorgang in das Programm rein-linken. Insofern müsste dieser in die Software gelinkte Teil der Software als SOUP betrachtet werden.

Ein Linker selbst ist keine SOUP. Vielmehr ist er wie der Compiler eine Prozess-Software. Man könnte eher diskutieren, ob der Linker deshalb zu validieren ist.

Eine SOUP ist, nochmals zu Erinnerung, „eine Software-Komponente, die bereits entwickelt wurde, und allgemein verfügbar ist, und die nicht entwickelt wurde, um in das Medizinprodukt integriert zu werden, oder bereits fertig entwickelte Software, für die angemessene Aufzeichnungen zum Entwicklungsprozess nicht verfügbar sind.”

Ein Linker erstellt aber gerade keine Komponenten, außerdem war das was der Linker erstellt, keinesfalls vorher vorhanden und allgemein verfügbar.


Mittwoch 13. September 2017 von Prof. Dr. Christian Johner

Sowohl die FDA als auch die IEC 62304 kennen Software durch Dritte und sprechen einmal von Off-the-Shelf Software OTS und einmal von  Software of Unknown Provenance SOUP. Worin unterscheiden sich SOUP und Off-The-Shelf-Software? Welche Gemeinsamkeiten haben beide? Dieser Artikel gibt Antworten.

Den ganzen Beitrag lesen »


Donnerstag 23. März 2017 von Prof. Dr. Christian Johner

Java Virtual Machines (JVM) sind Software-Programme, die Hardware und Betriebssysteme abstrahieren, indem sie Programmen eine virtuelle Betriebssystem- und Hardware-unabhängige Schicht zur Verfügung stellen. „Write once, run everywhere“ war einst der Slogan.

Eine JVM ist somit eine Software. Aber ist eine Java Virtual Machine auch eine SOUP? Antworten finden Sie in diesem Beitrag.

Den ganzen Beitrag lesen »


Mittwoch 26. Oktober 2016 von Prof. Dr. Christian Johner

Müssen Medizinproduktehersteller bei der Auswahl des Betriebssystems darauf achten, dass das Betriebssystem IEC 62304-konform ist? Dieser Artikel

Den ganzen Beitrag lesen »