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

5 Kommentare

  1. Stefan Koch | Mittwoch, 15. Oktober 2014 um 08:41 Uhr - Antworten

    Hallo Herr Prof. Johner,

    ich denke, es hängt davon ab, wie man den Begriff „Komponente“ definiert. Wenn man eine Komponente als die Zusammenfassung von Daten+Aktivitäten (Ablaufdiagramme, Algorithmen etc.) versteht, dann kann die Aussage der 62304 durchaus Sinn machen.

    Im Rahmen dieser Interpretation wäre dann das detaillierte Design genau die Sammlung statischer und dynamischer Aussagen über das Innenleben der Komponente. Gleichzeitig würde man sagen, dass eine Sinus-Funktion, Socket usw. keine Komponente im Sinne der obigen Aussage ist, sondern eher ein Primitive. Klar würde man kein detailiertes Design der Sinus-Funktion aus einer mathematischen OTS-Bibliothek machen.

    Grüße,
    Stefan Koch


  2. Dietmar Ferstl | Mittwoch, 10. Januar 2018 um 12:52 Uhr - Antworten

    Hallo Hr. Prof. Johner,

    ich hätte da noch eine Frage zum „detaillieren Design“. Wenn ich Grafiken/Daten etc. an den Drucker schicke, ist das ein sehr komplexer Vorgang der da abläuft bis das Papier aus dem Drucker kommt. (Hab da selber schon was Low-Level gemacht…) Aus „high-Level“ Programmierersicht (C#, C++) sind das aber nur ein paar abstrakte Befehlszeilen. Wie soll man das detaillieren und vor allem sinnvoll testen(außer ein paar Seiten ausdrucken und schauen ob Farbe aufm Papier ist)? Oder sind Betriebssystem-Funktionen generell da außen vor?

    Viele Grüße,
    Dietmar Ferstl


    • Prof. Dr. Christian Johner | Mittwoch, 10. Januar 2018 um 18:16 Uhr - Antworten

      Sehr geehrter Herr Ferstl,

      besten Dank für die spannende Frage! Das Betriebssystem ist eine SOUP. Für SOUP nehmen Sie definitionsgemäß kein detailliertes Design vor.

      D.h. Sie würden „nur“ die Anforderungen an Ihre SOUP beschreiben („soll ausdrucken können“) und die Erfüllung der Anforderungen verifizieren bzw. validieren.

      Beste Grüße

      Christian Johner


  3. Dietmar Ferstl | Donnerstag, 11. Januar 2018 um 10:27 Uhr - Antworten

    Vielen, vielen Dank für die schnelle Antwort !

    Ich sehe da eine grundsätzliche Problematik. Nehmen wir an, man hätte einen Windows/Linux-PC der die reine Bedienung und Visualisierung von Daten realisiert. auf der anderen Seite einen PC der Ultra-Low-Level programmiert ist, also ohne Betriebssystem, ohne Programmiersprache und die Festplatte nicht einmal formatiert ist.
    Dieses High-Performance-System erhält vom WIN-PC nur Anweisungen und liefert Daten.
    Kann man jetzt einfach hergehen und nur die „Lalli“-Win-PC-Software für ein Audit einen Lebenszyklus samt Risiko-Analyse verpassen und den eigentlich kritischen PC zum SOUP erklären?
    Würde doch das Audit stark „vereinfachen“, oder habe ich da was übersehen? 🙂

    schönen Gruß,
    Dietmar Ferstl


    • Prof. Dr. Christian Johner | Donnerstag, 11. Januar 2018 um 18:41 Uhr - Antworten

      Wenn der „High-Performance-PC“ kein Medizinprodukt sein sollte — was zu hinterfragen wäre — und auch kein Teil des Medizinprodukts, dann ist seine Software nicht einmal eine SOUP. Dann wird einem wahrscheinlich in der Risikoanalyse für das MP der Daten-Input vom High-Performance-PC um die Ohren fliegen, weil man darüber keine Aussage treffen kann.

      Das Kapseln von Altlasten oder kritischen Komponenten in eine SOUP ist daher nicht der Königsweg.


Hinterlassen Sie einen Kommentar

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