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

10 Kommentare

  1. Stefan Beisswenger | Donnerstag, 19. Februar 2015 um 11:30 Uhr - Antworten

    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?


    • Christian Johner | Freitag, 20. Februar 2015 um 14:58 Uhr - Antworten

      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


  2. Christian Beck | Dienstag, 3. November 2015 um 11:20 Uhr - Antworten

    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


    • Christian Johner | Mittwoch, 4. November 2015 um 18:40 Uhr - Antworten

      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.


  3. Anna Henke | Freitag, 23. Juni 2017 um 08:59 Uhr - Antworten

    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


    • Prof. Dr. Christian Johner | Freitag, 23. Juni 2017 um 13:14 Uhr - Antworten

      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


  4. Patrick Broser | Montag, 14. Dezember 2020 um 11:21 Uhr - Antworten

    Sehr geehrter Herr Johner,
    mich würde Ihre Einschätzung zu folgendem Sonderfall sehr interessieren:

    Es handelt sich um eine Software die mithilfe eines Algorithmus anhand von US-Bildern exakt den Körperfettanteil bestimmen kann. Die SW ist erfolgreich im Einsatz, es existieren auch wissenschaftliche Studien dazu. Die SW soll jetzt aber auch als eine SaMD(Risikoklasse A) zum Einsatz kommen. Allerdings wurde diese Software mehr im Zuge eines „wissenschaftlichen Projektes“ entwickelt. Es existieren demnach keine dokumentierten Tests, kein Entwicklungsplan oder generell Software-Lebenszyklus Prozesse nach EN 62304 und auch kein QM-System nach ISO 13485. Lediglich die Bestätigung anhand von zahlreichen Praxisanwendungen, dass sie die erwarteten Ergebnisse liefert.

    Meiner Meinung nach wäre dann das ganze Software-System eine SOUP, was gemäß EN 62304 ja nicht möglich ist.
    Wie würde hier die Strategie für eine erfolgreiche Zulassung aussehen, falls dies überhaupt möglich ist?
    Die für RK A geforderten Software-Systemtests können ja nachgeholt und dokumentiert werden. Die Entwicklung innerhalb eines QM-Systems und nach einem definierten Entwicklungsplan aber, ist nicht mehr möglich.

    Vielen Dank für Ihre wertvollen Beiträge.
    Liebe Grüße


    • Prof. Dr. Christian Johner | Montag, 14. Dezember 2020 um 17:45 Uhr - Antworten

      Sehr geehrter Herr Boser,

      danke für die spannende Frage!

      Wenn Sie das Produkt unter der MDR in den Verkehr bringen wollen (die MDD läuft ja bald ab), dann fällt das wahrscheinlich gemäß Regel 11 in die Klasse IIa. Damit wäre sogar ein zertifiziertes QM-System notwendig.

      Aber auch bei einem Klasse-I-Produkt müssen Sie die Anforderungen nach Lebenszyklusprozesse einhalten, die bereits seit der MDD gelten.

      D.h. Sie müssten u.a. konform u.a. mit der IEC 62304 nachdokumentieren. Dazu zählt nicht nur die Dokumentation fürs Produkt, sondern auch für das QMS. Denn die IEC 62304 und die MDR fordern bei jeder Klasse ein QM-System.

      Unter der MDR müsste man erwägen, ob eine Dokumentation nach Sicherheitsklasse A überhaupt die Anforderungen an die grundlegenden Sicherheits- und Leistungsanforderungen erfüllt, da z.B. keine SW-Architektur vorliegt.

      Kurze Version der Antwort: Sieht nach „risikobasierter Nachdokumentation“ aus.

      Danke auch für Ihr wertschätzendes Feedback, über das ich mich freue!

      Beste Grüße, Christian Johner


  5. Andreas Schätti | Donnerstag, 4. März 2021 um 18:02 Uhr - Antworten

    Sehr geehrter Herr Johner

    Ich beziehe mich auf Ihre Antwort auf die Frage von Frau Henke vom Juni 2017.
    Wie sieht die Situation denn für SOUP aus? Was ist, wenn die Software sowohl SOUP als auch OTS ist?

    Ich kann die Argumentation bei OTS nicht recht nachvollziehen. Wenn ich OTS wähle, damit sie Software eine hohe Qualität und wenige Fehler hat, und ich Fehler darin korrigiere und den veränderten Code teste, dann ist doch die Qualität noch höher als vorher, was im Sinne der FDA sein müsste?

    Beste Grüsse
    Andreas Schätti


    • Prof. Dr. Christian Johner | Donnerstag, 4. März 2021 um 20:07 Uhr - Antworten

      Sehr geehrter Herr Schätti,

      ich bin nicht ganz sicher, ob ich Ihre Frage wirklich verstehe. Eine SW kann durchaus SOUP und OTS sein. Das ist bei uns Herstellern sogar der Normalfall.

      Die Annahme bei OTS besteht darin, dass die SW durch die Tatsache, dass sie allgemein verfügbar ist, eine gewisse (Mindest-)Qualität habe.

      Wenn Sie diese Software ändern, kollabiert diese Vermutung, denn man kann ja gerade keine Annahme mehr bezüglich der Prozesse der ändernden Organisation treffen. D.h. Ihr Schluss, dass eine Software nach einer Änderung eine höhere Qualität habe, wird für Ihre Organisation stimmen. Ich halte diese aber in dieser Allgemeingültigkeit für gerade nicht zutreffend.

      Um diese Vermutung aufrecht zu halten, würde man eine qualitätsgesicherte Entwicklung benötigen. Hätte ein Hersteller diese, könnte er je nach Art der (OTS-) Komponente auch den konsequenten Schritt gehen und die Software zu „internalisieren“, d.h. die fehlende Evidenz einer Konformität zu heilen z.B. durch eine entsprechende Dokumentation. Dazu zähen beispielsweise die von Ihnen erwähnte Dokumentation der Tests.

      Beste Grüße, Christian Johner


Hinterlassen Sie einen Kommentar

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.