Prof. Dr. Christian Johner

Autor: Prof. Dr. Christian Johner

Inhaber der Johner Institut GmbH

Off-the-shelf Software (OTS) versus SOUP

Mittwoch 13. September 2017

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.

Off-the-shelf Software versus OTS: Vergleichbar aber nicht deckungsgleich

Definitionen

Off-the-shelf Software OTS

Definition: Off-the-shelf Software

„a generally available software component, used by a medical device manufacturer for which the manufacturer can not claim complete software life cycle control.“

Software of unknown provenance SOUP

Definition: Begriff

„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“

Quelle: IEC 62304

Die Definition des Begriffs SOUP hat die IEC 62304:2006+A1:2015 nicht geändert, aber durch folgende Anmerkung ergänzt:

„A MEDICAL DEVICE SOFTWARE SYSTEM in itself cannot be claimed to be SOUP.“

Da scheinen die leidvollen Erfahrungen von Auditoren eingeflossen zu sein, die sich mit zweifelhaften Argumentationen ihrer Kunden auseinandersetzen mussten.

Die FDA verwendet den Begriff SOUP ebenfalls und zwar im Guidance Dokument. Dort schreibt sie: Some or all of the software contained in a Software Device may have been obtained by the submitter from a third party. Damit deckt sich das Verständnis der FDA diesen Begriff betreffend nicht ganz mit dem der IEC 62304.

Gemeinsamkeiten und Unterschiede von SOUP und off-the-shelf Software

  • Es gibt SOUP, die auch OTS ist:
    Alle allgemein verfügbaren Komponenten, die nicht dafür entwickelt wurden, Teil des zu entwickelnden Medizingerätes zu werden, und über dessen Entwicklungsprozess der Hersteller daher auch keine Kontrolle hat, sind sowohl SOUP als auch OTS:
  • Es gibt SOUP, die keine OTS ist:
    Alle Software-Komponenten, die nicht allgemein verfügbar sind, etwa diejenigen, die der Medizinproduktehersteller selbst aber für einen anderen Zweck entwickelt hat und diese jetzt in das Medizingerät integrieren möchte, sind SOUP, aber keine OTS.
  • Es gibt OTS, die keine SOUP ist:
    Ein typisches Beispiel ist jegliche Prozess-Software von anderen Herstellern, die unter den Begriff der OTS-Software fällt, wie in den „General Principles on Software Validation“ beschreiben.

Zunächst fällt auf, dass sich die Definition der FDA nicht auf den Einsatz in Medizingräten beschränkt („A generally available software component, used by a medical device manufacturer …“). Das Guidance-Dokument, in dem man die Definition findet, heißt „Guidance […] on Off-The-Shelf Software Use in Medical devices“. Und wie der Titel schon sagt, beschäftigt sich der das Dokument nur mit OTS-Software, die Teil eines Medizingerätes ist. Das verführt leicht dazu, anzunehmen, dass die Begriffe im Wesentlichen identisch sind. Das ist aber nicht der Fall! In dem betreffenden Dokument wird nur eine bestimmte Anwendung von OTS-Software behandelt.

Es gibt jedoch eine andere. Das wird beim intensiveren Lesen in „General Principles on Software Validation“  klar. Im Kapitel 6, geht es um „Validation of automated Process equipment and quality system software“. Dort heißt es: „Software tools are frequently used to design, build and test the software that goes into an automated medical device. […] All this applications are subject to the requirement of software validation [..].“ Was hat das nun mit OTS-Software zu tun? Diesen Zusammenhang stellt das Kapitel 6.3 „Validation of the Off-the-Shelf-Software“ her. All die oben erwähnte Software „to design, build and test the software“, fällt unter den Begriff OTS-Software, wenn die von anderen Herstellern vertrieben wird. Und so kommt man zum oben genannten Fazit.

Weiterführende Informationen

Lesen Sie hier mehr zur den regulatorischen Anforderungen und zur Auswahl von SOUPs.

Regulatorische Anforderungen

Level of Concern bei off-the-shelf Software

Bestimmt man den Level of Concern vor oder nach den Maßnahmen? Diese Frage ist nicht nur entscheidend für die einzureichende Dokumentation, sondern auch bei der Entscheidung, ob die Off-The-Shelf-Software (OTS Software) überhaupt eingesetzt werden darf.

Im „Guidance for the Content of Premarket Submissions for Software Contained in Medical Devices“ verlangt die FDA, dass der Hersteller den Level of Concern zuerst „Prior to mitigation of hazards“ bestimmt. Bei einer OTS Software mit einem „major“ Level of Concern hätte das zur Folge, dass der Hersteller ein Audit beim OTS-Hersteller durchführen muss, was in der Regel nicht möglich ist.

Die gute Nachricht bezüglich Off-the-shelf-Software besteht zum Glück darin, dass es einen LoC vor und nach den risikominimierenden Maßnahmen gibt.

ots-software

Nur wenn nach diesen Maßnehmen die OTS-Software noch einen major Level of Concern hat, wird die „Special Documentation“ notwendig, zu der das Audit beim OTS-Hersteller zählt.

Sicherheitsklasse bei SOUP

SOUP sind erst einmal Software-Komponenten. Damit haben Sie die Sicherheitsklasse des umgebenden Software-Systems bzw. der umgebenden Software-Komponente. Diese Sicherheitsklasse regelt aber nur den Umfang der zu erstellenden Dokumentation. Forderungen, wie sie die FDA mit dem Audit kennt, stellt die IEC 62304 nicht.

Obwohl die FDA den Begriff SOUP wie oben erwähnt kennt, sind die Anforderungen daran eher unscharf:

„Therefore, we recommend that you explain the origin of the software and the circumstances surrounding the software documentation. Additionally, your Hazard Analysis should encompass the risks associated with the SOUP regarding missing or incomplete documentation or lack of documentation of prior testing. Nonetheless, the responsibility for adequate testing of the device and for providing appropriate documentation of software test plans and results remains with you.“

Vergleich der Anforderungen

Auch wenn die Definitionen der beiden Begriffe sich sehr ähneln, so gibt es doch folgenden regulatorischen Unterschied:

Bei den SOUP hat die Sicherheitsklasse keinen direkten Einfluss auf die Zulassung bzw. Verwendbarkeit. Bei der OTS ist dies der Fall. In beiden Fällen sind natürlich Risiken durch SOUP bzw. OTS zu analysieren und zu bewerten.

Lesen Sie hier mehr zur Abgrenzung von Legacy Software, SOUP und OTS.


Kategorien: FDA Zulassung - die U.S. Food and Drug Administration, Software & IEC 62304
Tags:

6 Kommentare über “Off-the-shelf Software (OTS) versus SOUP”

  1. Stefan Beisswenger schrieb:

    Ich habe den Verdacht, dass die regulatorischen Vorgaben bisweilen die Sicht auf das Wesentliche verstellen.
    Unter der hoffentlich allgemein anerkannten Prämisse das d. Medizin-SW so sicher wie möglich sein sollte, ist der History-Track der SW wohl d. aussagekräftigste Faktor. Wenn ich einen langen und ereignisarmen History-Track habe (vielleicht sogar mit Anwendung im Med.bereich) sind meine Risiken auch bei näherer Betrachtung wohl eher klein. UNIX/ Linux oder Legacy-Software sind sicher gute Beispiele dafür.
    Wenn ich einen schlechten History-Track habe sollte wohl schon von Anfang an eine bessere Alternative suchen.
    Wenn ich hingegen keinen oder nur einen sehr kurzen History Track habe, DANN wird die Prozessbeherrschung à la 62304 ein Thema (neben der Validierung). Das würde auch wieder das Thema der verschiedenen WIndows-Versionen beleuchten (von XP bis 8).
    Ist so eine Argumentationslinie bei Pre-Market-Approvals und Audits belastbar?

  2. Christian Johner schrieb:

    Lieber Herr Beisswenger,

    eine solche Argumentation ist aus Sicht der IEC 62304 bedingt möglich, aus der der ISO 14971 eher. Der „History Track“ wie Sie es nennen, gibt Anhaltspunkte zur Wahrscheinlichkeit von Fehlern. Diese möchte die 62304 nicht wirklich diskutiert haben.

    Für mich und auch einen Auditor sind diese Überlegungen aber absolut zielführend und unter einem ISO 13485 Blick sogar fast zwingend.

    Viele Grüße

    Christian Johner

  3. Christian Beck schrieb:

    Hallo Herr Johner,

    Wie ist es mit „bereits fertig entwickelte Software, für die angemessene Aufzeichnungen zum Entwicklungs-PROZESS _nicht_ verfügbar sind“, die aber _nicht_ allgemein erhältlich ist?

    Diese fällt zwar unter die IEC Definition von SOUP, aber nicht unter die FDA Definition von OTSS. Soweit, so gut. Aber es kann der FDA doch nicht recht sein, diese Komponente ohne die für OTSS gültigen Maßnahmen einfach zu integrieren? Muss man in diesem Fall nicht trotzdem die „Guidance […] on Off-The-Shelf Software Use in Medical Devices anwenden (wenn man im USA Markt verkaufen möchte)?

    MfG, C. Beck

  4. Christian Johner schrieb:

    Absolut, Herr Beck. Es ist genau wie Sie sagen: OTS ist hier nicht gleich SOUP.

    Es wäre der FDA nicht Recht, die Alt-Sünden einfach einzubauen. Hier hilft nur der Weg, diese Sünden zu „heilen“, indem man entsprechende Aufzeichnungen aus dem Software-Lebenszyklus nachholt oder gemäß „risk based approach“ diese als vertretbar bewertet. Diese Diskussion muss aber geführt sein.

  5. Anna Henke schrieb:

    Hallo Herr Johner,

    macht es in der Betrachtung einen Unterschied, ob ich eine OTSS als binäre, nicht veränderbare Komponente einbaue oder den ggf. verfügbaren Source Code benutze und die Komponente selber im Zuge meines Medizinproduktes baue?
    Für den Fall, dass es möglich ist, die Komponenten selber zu bauen: Wie verhält es sich, wenn ich frei verfügbare Software, wie z.B. das DCMTK nutze und Änderungen am Source Code vornehmen um z.B. einen mir bekannt gewordenen Bug zu fixen oder Funktionalität anzupassen oder zu erweitern? Reicht es aus, wenn ich dann nur die angepasste Komponente gemäß meines QM Systems einer Qualitätssicherung unterziehe oder muss sich diese dann auf die gesamte OTSS erstrecken?

    Viele Grüße
    Anna Henke

  6. Prof. Dr. Christian Johner schrieb:

    Sehr geehrte Frau Henke,

    wenn Sie über OTSS sprechen, sind Sie im FDA-Kontext.
    Falls Sie über den Source-Code verfügen, haben Sie die Möglichkeit, den Code der eigenen Qualitätssicherung zu unterwerfen und damit den Code gar nicht mehr als OTSS zu betrachten. Das geht natürlich bei rein binären Artefakten nicht.

    Wenn Sie eine OTSS-Komponente ändern, weil Sie z.B. einen Fehler beheben oder Funktionalität hinzufügen, wäre das nicht mehr im Sinn der FDA. Die Idee besteht gerade darin, dass man eine gewisse Güte erwartet, weil die Software allgemein verfügbar und damit in gewisser Weise bewährt ist.

    Bei SOUPs wäre das anders. Aber danach haben Sie ja nicht gefragt.

    Viele Grüße
    Christian Johner

Kommentar schreiben