Kategorien: FDA Zulassung - die U.S. Food and Drug Administration
Tags:

9 Kommentare

  1. Philipp Ott | Donnerstag, 16. März 2017 um 11:47 Uhr - Antworten

    Hallo Herr Johner,

    vielen Dank für den informativen Artikel. Eine Frage bezüglich des Level of Concern habe ich noch. Kann bei einem Produkt, dass aus meheren Software Systemen besteht (getrennte Hardwarekomponenten mit eigener CPU und Speicher) für jedes Softwaresystem der Level of Concern bestimmt werden und somit die einzureichende Dokumentation verringert werden?

    Die IEC 62304 erlaubt ja unterschiedliche Sicherheitsklassen für verschiedene Softwaresysteme bzw. Softwareeinheiten. So ist es auch meiner Sicht möglich für verschiedene Softwaresysteme in einem Produkt unterschiedliche Sicherheitsklassen zu vergeben (ausgehend vom Schweregrad natürlich). Geht das bei dem Level of Concern auch?

    Liebe Grüße,
    Philipp Ott


    • Prof. Dr. Christian Johner | Donnerstag, 16. März 2017 um 18:58 Uhr - Antworten

      Die FDA kennt das Konzept so nicht wirklich. Sie weiß zwar, dass ein Produkt mehrere „Softwares“ enthalten kann, spricht aber dann von „Software Components“.
      Die FDA wäre verwirrt, wenn man für unterschiedliche Software-Systeme unterschiedliche LoC definiert und entsprechend einreicht.
      ABER: Das ist auch gar nicht notwendig, weil die FDA sowieso den „risk-based approach“ propagiert. Insofern unterscheidet sich die Dokumentation nicht wesentlich.


  2. Robert Prueckl | Freitag, 2. März 2018 um 10:48 Uhr - Antworten

    Sehr geehrter Herr Johner,

    sie schreiben in
    https://www.johner-institute.com/articles/software-iec-62304/safety-classes-level-of-concern/:
    „If you market your products in the US the software safety class is irrelevant. You have to document according to class C anyhow. … “

    Ich wüsste gerne ob es für diese Behauptung einen weiteren Beleg von Seite der FDA gibt welcher das Vorhandensein der vollständigen Dokumentation beim Audit verlangt. Für Software die laut 62304 in die Klasse A bzw. nach der FDA Guidance Minor Level of Concern ist fällt es sonst schwer für eine vollständige Dokumentation zu argumentieren. Vor allem wenn in der Guidance dann noch steht:
    „We believe the documents that we recommend submitting will generally be the same documents that you would normally generate during the development of a Software Device.“

    Dass eine vollständige Dokumentation von Vorteil für den Hersteller ist und eine gute Kontrolle des Designs und der Verifikation erlaubt steht natürlich außer Frage.

    Vielen Dank!


    • Prof. Dr. Christian Johner | Freitag, 2. März 2018 um 16:46 Uhr - Antworten

      Sehr geehrter Herr Prueckl,

      die FDA definiert den Level of Concern in einem Guidance Document, das den „Content of Premarket Submissions“ regelt. Es geht hier nicht um den Aufbau der SW-Dokumentation. Vielmehr fordert die FDA für SW unabhängig von dem Level of Concern die Design Controls einzuhalten.

      Daher müssen Sie damit rechnen, dass ein Inspektor die Software-Akte sehen will um den Software-Lebenszyklus in Gänze zu beurteilen.

      Ich widerspreche aber nicht, dass die meisten Inspektoren bei Minor Level Software den Fokus der Inspektion auf andere Teile lenken.


  3. I. Thiemann | Mittwoch, 20. November 2019 um 14:47 Uhr - Antworten

    Sehr geehrter Herr Johner,

    Für eine reine stand-alone SW oder auch eine „Haupt“-SW für ein Medizinprodukt ist der LoC recht klar. Aber wenn eine (weitere) Software als zusätzliche MSicherheitsmaßnahme zu existierenden HW-Sichereheitsmaßnahmen entwickelt werden soll tue ich mich schwer mit dem Ansatz:
    Die FDA schreibt: „We recommend that you determine the Level of Concern before any mitigation of relevant hazards.“ aber auch
    „We recommend that you indicate the Level of Concern for your Software Device, determined before the effects of any mitigations.“

    Wie verhält es sich denn, wenn eine HW schon im Design Sicherheitsmassnahmen (z.B. ein Laser HW-Sicherheitsmassnahmen nach relevanter Lasersicherheitsnorm) mitbringt und nun anschließend für diese HW eine Kontrollsoftware entwickelt werden soll als weitere Sicherheitsmaßnahme. Ist der LoC ohne die HW-Sicherheitsmaßnahmen zu betrachten („before any mitigation“) oder kann hier davon ausgegangen werden, dass es sich um die durch die HW-Sicherheitsmaßnahmen abgedeckten Risiken um keine relevanten Gefährdungen mehr handelt („mitigation of relevant hazards)?


    • Prof. Dr. Christian Johner | Mittwoch, 20. November 2019 um 16:37 Uhr - Antworten

      Sehr geehrter Herr Thiemann,

      danke für die spannende Frage! Die Antwort hängt – wie Sie bereits andeuten – davon ab, wann man eine Maßnahme man als risikominimierend und wann als „selbstverständlich“ klassifiziert. Dazu gibt es keine gesetzliche Regelung, aber eine wie ich finde nützliche Einschätzung eines TÜVs:

      Alle Maßnahmen, die ein junger Absolvent bzw. eine junge Absolventin einer einschlägigen Fachrichtung ergreifen würde, zählt man nicht als risikominimierend, sondern als „selbstverständlich“. Alle anderen Maßnahmen sind als risikominimierend zu klassifizieren, auch wenn sie für die Firma selbstverständlich sein mögen.

      Wenn eine Firma einen Laser nur so schwach wie notwendig einbaut, dürfte das selbstverständlich sein. Hingegen wäre eine Kontrollsoftware, die Teil einer Überwachungskomponenten ist, eine risikominimierende Maßnahme darstellen. Für diese Kontrollsoftware (und natürlich auch für die kontrollierte Software) wäre somit der LoC zu bestimmen.

      In der Hoffnung, mit dieser Faustformel etwas geholfen zu haben, und mit den allerbeste Grüßen, Christian Johner


  4. Chia | Samstag, 20. November 2021 um 13:00 Uhr - Antworten

    Dear Mr. Johner,

    I’m wondering what is the impact to OTS software? (I understand that the FDA is planning to review the OTS Guideline after finalising this Guidance Document). Does it means that OTS/SOUP that has minor LOC should have the basic documentation? If this is the case, it will be a lot of work!


    • Luca Salvatore | Montag, 22. November 2021 um 12:48 Uhr - Antworten

      Dear Chia,

      unfortunately we don’t know FDAs plans related to the revision of the OTS guidance. However, since the level of concern was removed in the draft software guidance, it will most probably be removed from the OTS guidance, too. Anyhow, also under the current OTS guidance, you always need a basic documentation, even for a minor level of concern OTS software.

      Best regards

      Luca Salvatore


  5. Chia | Montag, 22. November 2021 um 13:04 Uhr - Antworten

    Dear Luca,

    Thank you for your response! You’re right about the basic documentation requirement for minor LoC, except for the following:
    – system software architecture
    – documentation of software development and maintenance

    If these are to be added for minor LoC OTS, it will be a lot of work. Let’s wait for FDA announcement.
    Have a good day!


Hinterlassen Sie einen Kommentar

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