| Inhaltsübersicht |
|---|
| Beispiele für Legacy Software » |
| Regulatorische Anforderungen » |
| Abgrenzung zu SOUP » |
Update: Abgrenzung von Legacy Software, SOUP und OTS
Beispiel für Legacy Software
Wenn Sie ein Medizinprodukt vor März 2010 in Verkehr gebracht haben, mussten Sie die IEC 62304 noch nicht befolgen. Die Inverkehrbringung war legal, auch wenn Sie die Forderungen der Norm noch nicht erfüllt haben.
Ein erstmaliges Inverkehrbringung einer Software nach dem März 2010, die die Anforderungen der IEC 62304 nicht erfüllt, wäre hingegen keine legale gewesen, d.h. diese Software ist nicht als Legacy Software zu betrachten.
Software die erstmalig vor März 2010 in Verkehr gebracht wurde, die jedoch geändert wurde/wird und/oder in einem anderen Kontext eingesetzt wird, fällt wiederum unter die Definition des Begriffs „Legacy Software“. Allerdings unterscheiden sich die regulatorischen Anforderungen.
Legacy Software: Die Sünden der Vergangenheit (Bildquelle)
Regulatorische Anforderungen an Legacy Software
Ziel des Ammendments I mit Bezug zur Legacy Software
Das neue Ammendment I zur IEC 62304 bzw. die neue Version der IEC 62304 haben das Ziel, klare Vorgaben für die Legacy Software zu machen und dabei einerseits die regulatorischen Anforderungen nicht zu Lasten der Patientensicherheit aufzuweichen und andererseits den Herstellern einen realistischen Weg in die Legalität zu ermöglichen.
Konzept des Ammendments I bzw. der überarbeitenden Version
Die Idee hinter der Änderung der IEC 62304 mit Bezug zur Legacy Software ist die folgende:
Das Risikomanagement soll darüber entscheiden, ob es akzeptabel ist, Legacy Software
- unverändert weiter zu verwenden,
- in anderem Kontext zu verwenden,
- zu ändern und weiter zu verwenden.
Kapitel 4.4 der IEC 62304:2015 „in a nutshell“
Für Legacy Software fordert die IEC 62304 ein Risikomanagement (Kapitel 4.4.2). Anhand der Ergebnisse daraus und aus Analyse der Post-Market-Daten entscheiden Sie, welche Schritte des normalen Entwicklungsprozesses Sie nachholen wollen (Kapitel 4.4.3).
Ggf. kommen Sie zum Ergebnis, dass es kein inakzeptables Risiko gibt. Dann müssen Sie gar nichts mehr machen, außer Ihre Entscheidung zu begründen (Kapitel 4.4.5). Die Begründung benötigen Sie allerdings immer. Wenn Sie zum Ergebnis kommen, dass etwas nachgeholt werden muss, dann machen Sie das (Kapitel 4.4.4).
Voraussetzungen
Die Voraussetzung dafür, dass Sie das Kapitel 4.4 anwenden dürfen, besteht darin, dass Ihre Software überhaupt Legacy Software ist. Die Tatsache, dass die Software „alt“ bzw. nicht dokumentiert ist, reicht nicht aus. Die Software muss legal in Verkehr gebracht worden sein (s.o.). Legacy-Software darf auch nicht mit Komponenten oder OTS bzw. verwechselt werden. Mehr dazu lesen Sie weiter unten.
Konkrete Forderungen an den Einsatz von Legacy Software
Die erste konkrete Forderung, nämlich die nach einer präzisen Risikobetrachtung, wurde bereits erwähnt. Das bedingt natürlich, dass Sie die Daten aus der Marktbeobachtung gesammelt und analysiert haben.
Speziell bei Änderungen müssen die Hersteller zusätzlich eine Gap-Analyse anstellen, die die Änderungen kenntlich macht und mögliche Auswirkungen/Risiken untersucht.
Solch eine Analyse ohne eine präzise Software-Architektur zu erstellen, halte ich für schwerlich möglich – es sei denn, die ganze Software ist unkritisch.
Aber dann hätte man es wahrscheinlich eh mit einer Software der Sicherheitsklasse A zu tun. Damit würde die Dokumentation der Entwicklung auf die Software-Anforderungen und die Software-Freigabe zusammenschrumpfen. In anderen Worten: man wäre schon fast normenkonform, und das Thema „Legacy Software“ wäre erledigt.
Ab Ammendment I bzw. IEC 62304:2015 sind auch für Klasse A Software Software-System-Tests verlangt! Das war vorher erst ab Klasse B vorgeschrieben.
Wenn die Software geändert werden soll, verlangt die IEC 62304, dass konform mit dem Wartungsprozess gemäß Kapitel 6 vorgegangen wird. Doch worin besteht dann noch die Erleichterung? Schließlich verlangt dieser Prozess – abhängig von der Sicherheitsklasse – ebenso eine Architektur, ein Design sowie Tests der verschiedenen Stufen.
Legacy Software versus SOUP versus OTS
Legacy Software bezieht sich definitionsgemäß auf die gesamte „medizinische Software“, d.h. auf ein vollständiges Software-System. Wenn Ihnen die o.g. Erleichterungen nicht wirklich weiterhelfen, dann können Sie noch in Betracht ziehen, einen Teil Ihrer Software, genauer gesagt einen Teil Ihres Software-Systems, als SOUP zu deklarieren.
| Legacy Software | SOUP | OTS | |
|---|---|---|---|
| Teil eines Medizinprodukts oder Medizinprodukt selbst? | Ja | Ja | Ja oder nein |
| Ganzes Software-System? | Ja | Nein | Nein |
| Muss legal (mit Bezug auf EU-Richtlinien) in Verkehr gebracht worden sein? | Ja | Nein | Nein |
| Hersteller darf Änderungen daran durchführen? | Ja mit Auflagen | Ja | Nein |
| Muss öffentlich verfügbar sein? | Nein | Nein | Ja |
Für die SOUP benötigen Sie definitionsgemäß keine Aufzeichnungen deren Entwicklung betreffend, sondern nur
- die Anforderungen an die SOUP
- die Voraussetzungen, von denen die SOUP ausgehen kann
- die klare Identifizierung der SOUP und
- eine kontinuierliche Überwachung und Bewertung der Marktdaten, Bug-Reports oder Release Notes auf Sicherheitsrelevanz
Wenn Sie noch Last mit Ihren Altlasten haben, dann melden Sie sich. Wir helfen Ihnen, diese Software als SOUP oder Legacy Software zu deklarieren, zu bewerten und zu dokumentieren oder die Software sogar zurück auf den „Pfad der Tugend“ 🙂 zu führen.
Lesen Sie hier mehr zum Thema Abgrenzung von OTS und SOUP.
Hallo Hr. Prof. Johner,
im Blog schreiben sie:
„Wenn Sie ein Medizinprodukt vor März 2010 in Verkehr gebracht haben, mussten Sie die IEC 62304 noch befolgen. Die Inverkehrbringung war legal, auch wenn Sie die Forderungen der Norm noch nicht erfüllt haben.
Ein Inverkehrbringung einer Software nach dem März 2010, die die Anforderungen der IEC 62304 nicht erfüllt, wäre hingegen keine legale gewesen, d.h. diese Software ist nicht als Legacy Software zu betrachten.
“
Fehlt im ersten Absatz nicht das Wörtchen „nicht“? -> mussten Sie die IEC 62304 noch „nicht“ befolgen ??
Sonst geben diese beiden Absätze semantisch m.E. keinen Sinn bzw. er kommt nicht dabei durch….
und: „den „Pfad der Tugend“ J zu führen.“ hier könnte ein J zuviel stehen.
Freundliche Grüße
Ralf Niebeling
Sei haben Recht! Wird sofort korrigiert! Danke vielmals, lieber Herr Niebling!
Hallo Herr Johner,
sie schreiben „Bei Klasse A Software wäre das sogar der bequemere Weg, weil im Gegensatz zu Legacy Software keine Software-System-Tests verlangt sind!“.
Dazu folgender Hinweis: Im Amendment I ist Abschnitt 5.7.1 auf Klasse A erweitert worden. Somit sind Software-System-Tests auch für Klasse A Software gefordert. Zudem müssen Software-System-Tests hinsichtlich ihrer Adäquatheit evaluiert werden.
Beste Grüße
Jan Dörrenbächer
Sehr wichtig, lieber Herr Dörrenbacher! Danke für diese Ergänzung! Das werde ich korrigieren!
Hallo Hr. Prof. Johner,
wir wollen eine medizinische Software (Klasse B oder C) mit Microsoft .NET für Windows entwickeln.
Wie würden Sie Microsoft .NET und Windows einstufen?
Als Legacy Software oder als SOUP?
Schöne Grüße
Martin Gruber
Lieber Herr Gruber,
.NET und Windows sind keine Legacy-Software, sondern entweder SOUP (wenn Teil des Produkts) oder Teil der Laufzeitumgebung, die Sie voraussetzen.
Bei weiteren Fragen: Sie wissen, wie Sie mich erreichen.
Herzliche Grüße, Christian Johner
Sehr geehrter Herr Prof. Johner,
wie Sie auf der Seite schreiben, die die Abgrenzung von OTS und SOUP detailiert erläutert, akzeptiert die FDA keine selbst entwickelten Komponenten als OTS.
Ich habe allerdings schon in mehreren Firmen erlebt, dass eigene Software gemäß 62304 als SOUP deklariert wurde.
Wie kann also in einem solchen Fall eine FDA-konforme Dokumentation aussehen? Reicht der oben beschriebene risikobasierte Ansatz oder sind weitere Schritte nötig?
Beste Grüße,
Jan F. Eschermann.
Sehr geehrter Herr Eschermann,
Ihrer Aussage, dass Firmen eigene Software gemäß IEC 62304 als SOUP erklären — und das auch dürfen — folge ich uneingeschränkt. Das versuchte ich zu sagen.
Die Erfahrung, dass die FDA genau solche Software als OTS (wohlgemerkt OTS) akzeptiert, ist mir neu. Damit möchte ich nicht ausschließen, dass es ein Auditor / Inspektor durchgewunken hat. Aber eigene Software, die nicht allgemein verfügbar ist, widerspricht dem Gedanken der OTS: Bei dieser Software vermutet man eine gewisse Güte, weil sie sich im Markt bereits bewährt zu haben scheint. Genau diese Vermutung lässt sich bei eigener Software nicht aufrecht erhalten. Damit würde man die Anforderungen der FDA im Software Validation Guidance Document ad absurdum führen.
Bei eigener Software ist dieser zu beachten, wobei die Hersteller „risk based“ vorgehen dürfen und auch sollen.
Wie gesagt, es gibt immer Inspektoren, die Dinge anders sehen. Mir ging es um die generelle Denkweise der US-Behörde.
Beste Grüße, Christian Johner
Hallo Herr Johner.
Worauf ist zu achten, wenn eine Legacy Software im Nachhinein geändert werden muss, aufgrund von Bug-Fixing?
Reicht eine Aktualisierung der Legacy-Betrachtung aus oder muss zwangsläufig das Kapitel 6 der IEC 62304 (Software-Wartungs-PROZESS) angewendet werden?
Viele Grüße.
Sehr geehrter Herr Zecevic,
die IEC 62304 sagt in Kapitel 4.4.4.c)
Das ist leider ziemlich eindeutig.
Viele Grüße, Christian Johner