Kategorien: Beliebteste Beiträge, Regulatory Affairs, Software & IEC 62304
Tags: , , ,

44 Kommentare

  1. Pierre Baum | Dienstag, 27. Januar 2015 um 15:21 Uhr - Antworten

    Hallo Herr Johner,

    vielen Dank für die Zusammenfassung der Dokumente. Leider ist der Link zu http://www.imdrf.org/docs/imdrf/final/technical/imdrf-tech-131209-samd-key-definitions.pdf nicht. Über http://www.imdrf.org/docs/imdrf/final/technical/imdrf-tech-131209-samd-key-definitions-140901.pdf#search=„samd key definitions“ habe ich es dann gefunden.

    Viele grüße,
    Pierre Baum


  2. Regina Preysing | Dienstag, 13. Dezember 2016 um 15:03 Uhr - Antworten

    Hallo Herr Prof. Johner,

    die Auseinandersetzung mit den unterschiedlichen Anleitungen, wie nun die Produkte zu klassifizieren sind, ist sehr spannend – vor allem unter dem Aspekt, wie das wohl eine Benannte Stelle sieht.
    Laut EU Kommission sind die MEDDEV Guidelines rechtlich nicht bindend.
    Das BfARM hat aktuell auf seiner Webseite https://www.bfarm.de/DE/Medizinprodukte/Abgrenzung/MedicalApps/_node.html zur Klassifizierung auf Anhang IX der Richtlinie 93/42/EWG verwiesen.
    Wenn wir dementsprechend in diesem Jahr/Anfang 2017 ein neues Produkt als Klasse I einstufen und entsprechend in den Markt bringen, machen wir dann etwas falsch? Gibt es auch bei den Guidelines eine Übergangsfrist, auf die man sich berufen kann?

    Vielen Dank und viele Grüße
    Regina Preysing


    • Prof. Dr. Christian Johner | Dienstag, 13. Dezember 2016 um 21:55 Uhr - Antworten

      Liebe Frau Preysing,
      Stand Dezember 2017 gibt es nur den Anhang IX. Bitte ignorieren Sie noch alle künftigen Klassifizierungen der MDR. Noch ist die nicht verabschiedet. Das wird voraussichtlich Frühsommer 2017. Natürlich sollte man sich auf die MDR vorbereiten. Das wird mehr Arbeit als uns allen lieb ist. Aber noch keine Produkte anders klassifizieren.
      Herzliche Grüße, Christian Johner


  3. Christian Sauter | Dienstag, 2. Januar 2018 um 20:52 Uhr - Antworten

    Hallo,
    meiner Meinung nach steht in der „COICR Contribution“ tatsächlich nichts neues, das ist im Grunde nur die Meddev 2.1/6 noch mal erläutert/abgeschrieben ….

    viele Grüße
    Christian


  4. Christos Freris | Dienstag, 9. Januar 2018 um 10:45 Uhr - Antworten

    Hallo Herr Prof. Johner,

    ihre Beiträge samt scharfsinnigen Kommentaren sind sehr informativ und auf dem Punkt! Vielen dank!

    Es gibt eine Kategorie von SW, die in keinem Dokument erwähnt wird, zumindest meiner Verständnis nach. Der Unterschied zwischen Embedded und Stand-Alone Software als MD ist mir klar.

    Was ist aber mit einem SW-Tool, welches kein MD ist, und nicht von Kunden sondern nur von Service Technikern eingesetzt wird um die SW eines MD zu verändern. Konkretes Beispiel: Ein selbst entwickeltes SW-PC-Tool für die

    a. Durchführung eines SW-Updates oder
    b. Änderung von individuellen Parametern (Konfiguration-Kalibrierung).

    Fällt es unter der Kategorie „Accessory“ obwohl es nicht an Kunden verkauft wird?

    Vielen Dank im Voraus
    Christos Freris


    • Prof. Dr. Christian Johner | Dienstag, 9. Januar 2018 um 12:45 Uhr - Antworten

      Sehr geehrter Herr Feris,

      bei einem solchen Tool handelt es sich in der Tat um ein Zubehör. Allerdings liegt bei Ihnen keine Inverkehrbringung vor. Entsprechend muss kein Konformitätsbewertungsvefahren durchlaufen werden. Die grundlegenden Anforderungen müssen aber erfüllt sein.

      Viele Grüße, Christian Johner


  5. Christos Freris | Dienstag, 9. Januar 2018 um 13:11 Uhr - Antworten

    Sehr geehrter Herr Prof. Johner,

    vielen Dank für die prompte Reaktion! Ich wollte Ihre Meinung wissen, welche absolut Sinn macht.

    Leider war der FDA-Inspektor der Ansicht, es sei „part of the medical device, because it changes the configuration or the whole SW on the device“ und verpasste uns eine 483, weil das Tool als SW Class A von uns eingestuft war anstatt Class C (die der SW des Gerätes). Widerstand zwecklos!

    Vielen Dank
    Christos Freris


    • Prof. Dr. Christian Johner | Dienstag, 9. Januar 2018 um 21:23 Uhr - Antworten

      Das tut mir leid, lieber Herr Freris!

      Die SW ist ein Zubehör, da irrt der Inspektor wahrscheinlich. Allerdings hat er mit der Klassifizierung möglicherweise Recht. Wenn die SW durch eine Fehlkonfiguration einen nennenswerten Schaden zur Folge haben kann, dann ist die SW Klasse C.

      Dass der Inspektor überhaupt von Sicherheitsklassen nach IEC 62304 spricht, überrascht mich. Haben Sie Konformität mit diesem Standard erklärt? Das wäre nicht notwendig gewesen. Oder geht es um den Level of Concern?

      Beste Grüße, Christian Johner


  6. Matthias Marzinko | Dienstag, 10. Juli 2018 um 10:53 Uhr - Antworten

    Vielen Dank für den sehr interessanten Artikel. Die Ausführungen zu den Modulen deckt sich meines Erachtens auch sehr gut mit der FDA (draft) Guidance vom April 2018: „Multiple Function Device Products: Policy and Considerations“
    darin schließt die FDA auch die Bewertung von nicht medizinischen Modulen / Funktionen aus.
    Quelle:
    https://www.fda.gov/downloads/MedicalDevices/DeviceRegulationandGuidance/GuidanceDocuments/UCM605683.pdf


  7. Dr. Klaus Ellinger | Mittwoch, 11. Juli 2018 um 09:51 Uhr - Antworten

    Newsletter Abo


  8. Roland Weghorn | Mittwoch, 11. Juli 2018 um 15:07 Uhr - Antworten

    Sehr geehrter Herr Prof. Johner,

    vielen Dank für den wie immer sehr interessanten Artikel. Eine Frage: Wie muss man sich die CE-Kennzeichnung eines Software-Moduls vorstellen? Hier fehlt mir völlig die Vorstellung.

    Für einen Hinweis wäre ich Ihnen sehr dankbar.

    Herzliche Grüße
    Roland Weghorn


    • Prof. Dr. Christian Johner | Donnerstag, 12. Juli 2018 um 14:45 Uhr - Antworten

      Sehr geehrter Herr Weghorn,

      das ist auch schwer vorstellbar. Genau diese Frage stellt der Artikel auch. Ggf. könnte es der Splash-Screen oder das Help>About der übergeordneten Anwendung einen Ansatz bieten.

      Viele Grüße, Christian Johner


  9. Roland Weghorn | Freitag, 13. Juli 2018 um 09:21 Uhr - Antworten

    Vielen Dank Herr Prof. Johner. Wenn das reicht, ist alles gut.


  10. Thomas Hertwig | Donnerstag, 4. Oktober 2018 um 07:38 Uhr - Antworten

    Sehr geehrter Herr Prof. Johner,

    wir nutzen in der Entwicklung unserer Medizinproduktesoftware Developer-Express-Komponenten. Würden Sie diese eher als zur Laufzeitumgebung (ähnlich wie das .net-Framework) gehörend oder eher als SOUP sehen?
    Und wie verhält es sich mit Angular (Laufzeitumgebung)?

    Viele Grüße,
    Thomas Hertwig


    • Prof. Dr. Christian Johner | Donnerstag, 4. Oktober 2018 um 07:49 Uhr - Antworten

      Lieber Herr Hertwig,

      die formale Antwort ist die: Wenn Sie die Komponenten als Teil Ihres Produkts mit ausliefern, sind das SOUP.

      Die inhaltliche Antwort: Die DevExp-Komponenten und Angular sind fast immer Teil des Produkts, das setzt man nicht als bereits installiert voraus. Einmal sind diese Komponenten zu spezifisch, zum anderen wollen Sie sicher sein, dass genau die richtigen Versionen genutzt werden. Also: SOUP.

      Die praktische Antwort: ein Auditor wird das in der Regeln nicht unterscheiden können.

      Viele Grüße, Christian Johner


  11. Anne-Kathrin Lerke | Donnerstag, 21. März 2019 um 12:31 Uhr - Antworten

    Sehr geehrter Herr Professor Johner,

    vielen Dank für Ihren ausführlichen und äußerst interessanten Artikel zum Thema Software als Medizinprodukt.
    Wir als IVD-Hersteller stehen im gegenwärtigen Entwicklungsprozess genau vor diesem Problem. Für einen unserer Analyzer gibt es künftig eine neue Software. Damit auch Geräte im Feld von der neuen Software profitieren, wird unsererseits ein Software-Update ermöglicht. Realisiert wird dieses Software-Update durch eine eigens geschriebenen Software, die keinen medizinischen Zweck hat, sondern lediglich eine Update-Funktion. Zudem überprüft sie vor dem Start des Updates, ob die Einstellungen des Analyzers (Datum, Parameter) korrekt sind. Wenn nicht, werden diese Parameter durch die Software entsprechend korrigiert. Somit würde sie in ein Medizinprodukt eingreifen.
    Müssen wir die Update-Software als Medizinprodukt klassifizieren, oder genügt die Begründung, dass die Software keinen medizinischen Zweck erfüllt?
    Ich danke Ihnen im Voraus für eine Einschätzung.
    Herzliche Grüße
    Anne-Kathrin Lerke


    • Prof. Dr. Christian Johner | Donnerstag, 21. März 2019 um 15:52 Uhr - Antworten

      Sehr geehrte Frau Lerke,

      danke für die spannende Frage! Wenn Sie eine Software schreiben, die speziell dafür gedacht ist, die Software auf Ihrem Medizinprodukt zu aktualisieren, ist das ein Zubehör. Für Zubehör gelten leider die gleichen Regularien wie für Medizinprodukte.

      Viele Grüße, Christian Johner


  12. Anne-Kathrin Lerke | Dienstag, 26. März 2019 um 10:48 Uhr - Antworten

    Sehr geehrter Herr Professor Johner,

    ich danke Ihnen für die schnelle Antwort, die das bestätigt, was unser RA-Kollege bereits vermutet hat. Insgeheim hatte natürlich noch gehofft, weder in die Kategorie Medizinprodukt noch in die Kategorie Zubehör zu fallen.

    Viele Grüße

    Anne-Kathrin Lerke


  13. Rainer Gutschmidt | Freitag, 26. April 2019 um 19:47 Uhr - Antworten

    Guten Tag,
    mobile Produkte, die sogen. wearables sind in aller Munde. Diese oft als smart watch ausgeführten, multifunktionalen Geräte können in der einfachsten Version manuell oder automatisch Notfall-Alarmierungen auslösen.

    Ist nach der neuen MDD eine smart watch, die eine Alarmierung bei einem Notdienst auslöst, wenn ein Senior selbst den button drückt oder z.B. per Areal-Überwachung(GPS) einen Dementen außerhalb des Areals erfaßt, damit schon ein Medizinprodukt?

    Anders gefragt – wird eine einfache chinesische tracker smart watch, welche nach LVD, EMV und RED die EU-Konformität hatte, durch Implementation einer Senioren-Überwachungs app durch eine Software-Firma in der EU zum Medizinprodukt? Die Konsequenzen einer Fehlfunktion des Geräts könnten sich durchaus lebensbedrohlich auswirken.

    Oder bleibt die Konformität der „hardware“ inkl. Betriebssystem zur Kommunikation und Positionsüberwachung nach LVD, EMV und RED bestehen und es muß nur die zugefügte app einer Neubewertung nach MDD unterzogen werden?

    MfG
    Rainer Gutschmidt
    CE-Koordinator


    • Prof. Dr. Christian Johner | Samstag, 27. April 2019 um 09:21 Uhr - Antworten

      Sehr geehrter Herr Gutschmidt,

      danke für Ihre Frage zu Klassifizierung und das anschauliche Beispiel!

      Die Klassifizierung hängt nicht primär von der Funktionalität, sondern von der Zweckbestimmung ab. Wenn die Zweckbestimmung darin besteht, dass ein dementer Patient überwacht werden soll, dann liegt die Zweckbestimmung in der Überwachung einer Krankheit. Genau das würde unter die Begriffsdefinition „Medizinprodukt“ fallen.

      Eine hierfür relevante Änderung der Definition zwischen MDD und MDR (die meinten Sie, oder?), gibt es nicht.

      In dem genannten Fall wäre die App das Medizinprodukt, weil die App und nicht die Hardware für die o.g. Zweckbestimmung in den Verkehr gebrach wird. Allerdings muss der Hersteller die Risiken, die sich aus diese Hardware ergeben berücksichtigen und beherrschen.

      Der Hersteller ist nicht verpflichtet, für die Hardware (SmartPhone) die EMV zu gewährleisten, da er das Produkt nicht in den Verkehr bringt.

      Viele Grüße, Christian Johner.


  14. Peter R. Egli | Mittwoch, 22. Mai 2019 um 10:17 Uhr - Antworten

    Guten Tag,

    Bei der Klassifikation von Produkten als Medizinprodukt ja / nein (MEDDEV 2.1/6 spricht hier von Qualification, passt für mich besser als der Begriff Klassifikation, aber leider ist die MEDDEV 2.1/6 nicht mehr anwendbar mit der MDR) sehe ich bei Medizinproduktherstellern immer wieder, dass das Risiko, ob ein Patient geschädigt werden kann, einfliesst in die Entscheidung, ob es sich um ein Medizinprodukt handelt oder nicht. Ich kenne keine einzige Stelle in den einschlägigen Guidelines und Regularien, wo das Risiko als Faktor für die Qualifikation herangezogen werden kann.

    Vielleicht habe ich das eine wichtige Dokument nicht gelesen oder den Inhalt nicht verstanden. Können Sie mir einen Hinweis dazu geben, ob das Risiko an sich ein Faktor bei der Qualifikation sein kann oder nicht?

    Besten Dank und freundliche Grüsse

    Peter Egli


    • Prof. Dr. Christian Johner | Mittwoch, 22. Mai 2019 um 14:52 Uhr - Antworten

      Sehr geehrter Herr Egli,

      danke für die spannende Frage! Sie haben Recht, dass die MEDDEVs unter der MDR nicht mehr gültig sein werden. Ich erwarte allerdings, dass man sich weiter an diesen Leitlinien orientiert, bis man etwas Neues hat.

      Dass das Risiko alleine nicht entscheidend ist, halte ich für richtig. Sonst müsste z.B. ein Geländer im Krankenhaus auch als MP klassifiziert werden. Denn wenn es zusammenbricht, ist der Schaden hoch.

      Entscheidend ist also weiterhin die Frage, ob das Produkt der Diagnose, Therapie, Überwachung usw. dient.

      Beste Grüße, Christian Johner


  15. Dr. med. Achim Kredteck | Montag, 26. August 2019 um 17:10 Uhr - Antworten

    Sehr geehrter Herr Prof. Johner

    …toll, Ihre Kompetenz in der Sache und ihre Bereitschaft, bei „quälenden“ Fragen vieler Menschen zu helfen.
    Meine Frage: Wenn ich in meiner Dokumentations- Befundungssoftware Laborwerte aus dem KIS des Krankenhauses lade und ohne Empfehlung/Deutung zur Verfügung stelle, z.B. bevor eine ANGIO gemacht wird, macht das meine Software zum MP? Im Grunde genommen könnte ja ein falscher Wert durch HL7 Übermittlungsfehler z.B. Folgen haben. Oder soll ich diese Funktion besser rausnehmen.

    Danke für Ihre Hilfe

    Dr. Achim Kredteck


    • Prof. Dr. Christian Johner | Montag, 26. August 2019 um 17:54 Uhr - Antworten

      Danke für die netten Zeilen, lieber Dr. Kredteck!

      Laut MEDDEV 2.1/6 macht eine reine Anzeige von Daten eine Software noch nicht zum Medizinprodukt.

      Die Frage, ob etwas passieren kann, ist bei der Klassifizierung unerheblich.

      Falls die Software mehr macht als Daten unverändert anzuzeigen, abzuspeichern, abzufragen oder anzuzeigen, entscheidet nicht die Funktionalität, sondern die Zweckbestimmung.

      Beste Grüße, Christian Johner


  16. Klaus Malmede | Donnerstag, 24. Oktober 2019 um 10:53 Uhr - Antworten

    Sehr geehrter Herr Prof. Johner,

    als KIS Hersteller ist insbesondere der letzte genannte Punkt für uns von großer Relevanz.
    In erster Linie wird ein KIS ja auch lediglich zur Dokumentation genutzt,
    dann wäre es auch laut MDR weiterhin kein Medizinprodukt, soweit richtig? Aber wenn bestimmte Module zur Therapie gedacht sind, fielen diese dann unter das MDR, also z.B. eine Therapieplanung oder eine Pflegeplanung. Und nur diese Teile wären dann als Medizinprodukt zuzulassen, aber nicht das ganze KIS. Liege ich damit richtig?

    Mit freundlichen Grüssen

    Klaus Malmede


    • Prof. Dr. Christian Johner | Donnerstag, 24. Oktober 2019 um 14:35 Uhr - Antworten

      Sehr geehrter Herr Malmede,

      die MDR ändert in der Tat (fast) nicht, was die Qualifikation von Produkten als MP (oder eben nicht) betrifft.

      Es ist auch zutreffend, dass Module zur Therapieplanung alleine als MP „zugelassen“ werden können, nicht aber notwendigerweise das ganze KIS.

      Beste Grüße, Christian Johner


  17. Petra Roosen | Dienstag, 3. März 2020 um 18:19 Uhr - Antworten

    Sehr geehrter Herr Prof. Johner,

    ein potenzielles Medizinprodukt der Klasse I, das ich in Ihren detaillierten Klassifizierungsbeispielen für Stand-Alone-Software (herzlichen Dank dafür!) ebenfalls leider nicht gefunden habe, ist die Gruppe der Übungs-/Trainings-Software, die speziell nach neurologischen Ausfällen für ein häusliches Training beeinträchtigter kognitiver Funktionen von Bedeutung ist, weil praktisch keine andere Übungsform als hochfrequentes Üben eine Aussicht auf Erfolg bietet. Konkrete Beispiele: Anklicken von Bildern nach Benennung durch Computer, schriftliche Benennungen von Bildern, Punkte auf Bildschirm suchen, …

    Dass sie in die Klasse I hineingehört, dürfte unbestritten sein, aber wo beginnt die für den Klassifizierungsaufwand beim Inverkehrsbringer entscheidende Einstufung in Klasse I* im Gegensatz zur relativ einfach zu handhabenden Selbstklassifizierung ohne benannte Stelle nach I (ohne Zusatz)? Sind Ergebnisdarstellungen in Form von „High-Scores“ oder qualitative Bereichsdarstellungen, die nur der Selbstinformation des Übenden dienen, bereits eine Messfunktion?

    Mit freundlichem Gruß,
    Petra Roosen


    • Prof. Dr. Christian Johner | Dienstag, 3. März 2020 um 20:03 Uhr - Antworten

      Sehr geehrte Frau Roosen,

      danke für Ihre Frage!

      Sie fragen, wann Sie in die Klasse I* fallen würden. Meines Erachtens kommt nur ein Im in Frage. Wie man diese Klassifizierung vornimmt habe ich im MEDDEV 2.1/5: Medizinprodukte mit Messfunktion beschrieben.

      Meine starke Vermutung ist, dass Sie nicht als Produkt mit Messfunktion zu klassifizieren sind.

      Viele Grüße, Christian Johner


  18. Petra Roosen | Mittwoch, 4. März 2020 um 10:36 Uhr - Antworten

    Sehr geehrter Herr Prof. Johner,

    zunächst herzlichen Dank für die schnelle Antwort und den zielsicheren Verweis auf die spezifische „Messfunktions“-Interpretation!

    Ich habe mir Ihren Starterpack heruntergeladen und versuche anhand der ausgesprochen umfangreichen, darin enthaltenen Informationen nun zusammenzupuzzeln, wie das konkrete Prozedere einer Anmeldung eines einfachen Klasse-I-Softwareprodukts denn nun vonstatten zu gehen hat. Speziell die MDR-Checkliste enthält ja extrem viele Punkte, die für Klasse-I-Software irrelevant ist.

    Wenn ich es richtig verstehe, läuft eine Produktanmeldung auf folgende Schritte hinaus:

    # Ein Deckblatt mit extrem kurzer Inhaltsbeschreibung, Affiliierung und Verantwortlichkeitszuweisung als (formloses?) Anmeldungsformblatt erstellen

    # Eine technische Dokumentation gemäß der Übersichtsgrafik „…/Dokumentation/Technische-Dokumentation_DE.pdf“ erstellen, wobei auch hier viele der angesprochenen Punkte für Klasse-I-Software irrelevant erscheinen.

    # Sich selber (auf der Basis der positiv zusammengetragenen Informationen in der technischen Dokumentation) die CE-Kennzeichnung zuweisen.

    Anschließend umnebelt sich jedoch aktuell mein Verständnis der weiteren Vorgehensweise:

    # Ist die obige Zusammenstellung der Notwendigkeiten vollständig?

    # Was mache ich / an wen wende ich mich mit diesem Material, wenn keine benannte Stelle einzuschalten ist? Wäre das z.B. eine mit der MPG-Überwachung betraute Stelle einer Bezirksregierung?

    Sollten Sie für diesen wohl vergleichsweise „harmlosen Zulassungsfall“ auch bereits eine dedizierte Infoseite erstellt haben, wäre ein kurzer Hinweis darauf auf jeden Fall sehr hilfreich!

    Mit freundlichem Gruß,
    Petra Roosen


  19. Petra Roosen | Mittwoch, 4. März 2020 um 13:48 Uhr - Antworten

    Kurzer Nachtrag: Die Stelle, an der wir uns als Entwickler eintragen und das Produkt anmelden müssen (https://www.dimdi.de/dynamic/de/medizinprodukte/informationssystem/) habe ich bereits in der Zwischenzeit gefunden. Bliebe aber insbesondere noch die Frage nach dem Umfang und der Struktur der zusammenzustellenden Informationen.

    Mit freundlichem Gruß,
    Petra Roosen


    • Prof. Dr. Christian Johner | Mittwoch, 4. März 2020 um 22:38 Uhr - Antworten

      Sehr geehrte Frau Roosen,

      die Unterlagen, die die technische Dokumentation umfassen muss, haben Sie bereits gefunden.

      Dann bleiben die Anforderungen an ein QM-System. Dessen Umfang variiert abhängig davon, ob Sie nach MDD oder MDR Ihr Produkt in den Verkehr bringen. Die ISO 13485 gibt Ihnen eine gute Übersicht.

      Sie finden bei uns auch einen Artikel zum Thema Verfahrensanweisung für QM erstellen.

      Bei einem Klasse-I-Produkt benötigen Sie keine Zertifizierung des QM-Systems.

      Beste Grüße, Christian Johner


  20. Tom Weber | Montag, 6. April 2020 um 12:02 Uhr - Antworten

    Sehr geehrter Herr Prof. Johner,

    ich möchte ein Kommunikationshilfsmittel für Behinderte in das Hilfsmittelverzeichnis eintragen lassen.

    Dieses besteht aus einem Microsoft-Tablet-Computer, einer Software als Medizinprodukt und einem Case.

    Für den Microsoft-Tablet-Computer steht mir die EU-Konformitätserklärung von Microsoft zur Verfügung, welche scheinbar ausreichend ist.

    Der Herr von der Zertifizierungsstelle teilte mir mit:

    Die CE Konformitätserklärung allein für das Tablet ist in Ordnung.
    Darüber hinaus müssen Sie als Hersteller des Kommunikationshilfsmittels eine CE-Konformitätserklärung zu dem Gesamtprodukt, also Hardware, Software und ggf. spezielle Cases für das Tablet erstellen und ein entsprechendes Konformitätsbewertungsverfahren durchführen.

    Trotz umfangreicher Recherche werde ich aus der Aussage nicht schlau.
    Können Sie mir sagen, welches Konformitätsbewertungsverfahren hier in Frage kommt? Muss ich dieselben Tests, die Microsoft für das Gerät durchgeführt hat, noch einmal durchführen?
    Welches Konformitätsbewertungsverfahren wähle ich für Software als Medizinprodukt aus?

    Über eine Antwort würde ich mich freuen.

    Dankeschön.

    Tom Weber


    • Prof. Dr. Christian Johner | Montag, 6. April 2020 um 17:21 Uhr - Antworten

      Sehr geehrter Herr Weber,

      für jede EU-Richtlinie bzw. jede EU-Verordnung, die für Ihr Produkt anwendbar ist, müssen sie die jeweiligen Konformitätsbewertungsverfahren durchlaufen. Wenn Sie für Ihr Produkt die MDR bzw. MDD erfüllen müssen, weil Ihr Produkt ein Medizinprodukt ist, müssen Sie die entsprechenden Konformitätsbewertungsverfahren dieser Regularien durchlaufen. Welche das konkret sind, hängt von der Klasse des Produkt ab.

      Im Starterkit, das Sie sich von der Startseite unseres Webauftritts herunterladen können, finden Sie weitere Informationen. Wenn Sie dann noch Fragen haben, nutzen Sie unser kostenloses Microconsulting, ebenfalls auf unserer Startseite.

      Viele Grüße, Christian Johner


  21. Markus Heimel | Montag, 5. Oktober 2020 um 16:03 Uhr - Antworten

    Sehr geehrter Herr Prof. Johner,

    vielen Dank für das Erstellen dieser hilfreichen Website. Leider konnte mir der Inhalt bei folgendem Problem nur bedingt weiterhelfen:
    Ich möchte mit einer Software ein Medizinprodukt der Klasse IIb steuern, ohne einen medizinischen Zweck zu verfolgen (auch die Kombination aus Beiden nicht, es geht hierbei nur um eine Fernsteuerung des MP für Übungszwecke). MPG und MDR sagen beide aus, dass es sich bei der Software in diesem Fall um kein Medizinprodukt handelt, solang kein medizinischer Zweck verfolgt wird. Ebenso Punkt 3.2 des MDCG 2019-Dokuments. Allerdings bezieht sich das Dokument unterPunkt 3.3 „Software driving or influencing the use of a medical device“ nur auf den medizinischen Zweck der „Steuerung“. Da dieser Zweck ebenfalls nicht vorhanden ist, wird unter „Note“ angegeben, dass die Software durch die MDR abgedeckt ist, obwohl mit der Steuerung kein medizinischer Zweck verfolgt wird.. Ist dies tatsächlich der Fall, obwohl selbst auch mit dem Medizinprodukt kein medizinischer Zweck verfolgt wird?

    Ich freue mich über eine Antwort.

    Mit freundlichen Grüßen

    Markus Heimel


    • Prof. Dr. Christian Johner | Montag, 5. Oktober 2020 um 17:20 Uhr - Antworten

      Sehr geehrter Herr Heimel,

      meines Erachtens ist ihre software kein Medizinprodukt, sondern ein Zubehör. Allerdings bin ich nicht ganz sicher, was Sie mit „Übungszwecke“ meinen. Wenn jemand eine konkrete Behandlung übt, ist das etwas anders als wenn jemand die Bedienung eines Geräts unabhängig von einem spezifischen Patienten üben will.

      Dass Zubehör keinen eigenen medizinischen Zweck verfolgt, ist der Sache inhärent.

      Beste Grüße, Christian Johner


  22. Markus Heimel | Montag, 5. Oktober 2020 um 18:14 Uhr - Antworten

    Sehr geehrter Herr Prof. Johner,
    vielen Dank für Ihre schnelle Antwort. Als Nachtrag möchte ich hinzufügen:
    Mit der Steuerung soll die Anwendung des Gerätes patientenunabhängig geübt werden.

    Bezüglich Ihrer Aussage, müsste als „Zubehör“ nicht trotzdem die medizinische Zweckbestimmung des Gerätes verfolgt werden, also dass das Zubehör laut Artikel 1 Abs. 2 MDR die Verfolgung der medizinischen Zweckbestimmung des Medizinproduktes unterstützt? Wie ist es aber wenn die Steuerung dies eben nicht tut, also das MP in Kombination mit der Steuerung nur für patientenunabhängige Übungen und Ausbildungen genutzt wird und somit keinen medizinischen Zweck verfolgt?

    Vielen Dank für Ihre Rückmeldung.

    Mit freundlichen Grüßen

    Markus Heimel


    • Prof. Dr. Christian Johner | Montag, 5. Oktober 2020 um 20:02 Uhr - Antworten

      Sehr geehrter Herr Heimel,

      dann ist es weder ein Medizinprodukt noch ein Zubehör. Die MDR ist somit ebenso wenig anwendbar wie die MDD.

      Beste Grüße, Christian Johner


  23. Andreas Schnitzbauer | Dienstag, 6. Oktober 2020 um 13:56 Uhr - Antworten

    Sehr geehrter Herr Prof. Johner,

    ein riesiger Knackpunkt der sich bei uns in der Entwicklung gerade stellt ist die Kombination einer Software (App, Klasse IIa/b)-Produkt mit der wir Puls, Schritte, Strecke messen wollen. Wir benötigen also ein(e) geeignete programmierbare(s) wearable/smartwatch für iOS und Android-Geräte. Das Produkt muss dann gemeinsam zertifiziert werden. Kann man das ohne die in den Verkehr-bringende Fa. schaffen (in dem man ein geeignetes wearable für sich auswählt) oder benötigt man auf Grund der notwendigen Zugriffe auf Quellcode/Programmierung/Data safety auf alle Fälle eine entsprechend geregelte Kooperation?

    Mit freundlichen Grüßen,
    Andreas Schnitzbauer


    • Prof. Dr. Christian Johner | Dienstag, 6. Oktober 2020 um 17:56 Uhr - Antworten

      Sehr geehrter Herr Schnitzbauer,

      mir fehlt möglicherweise noch etwas der Kontext, um qualifiziert antworten zu können.

      Daher kann ich nicht beurteilen, ob man das System aus Software und Wearable in der Tat als ein Produkt in den Verkehr bringen muss. Das würde ich nämlich versuchen zu vermeiden. Wenn Sie eine SmartWatch als Medizinprodukt oder als Teil dessen in den Verkehr bringen, müssen Sie die Anforderungen u.a. der IEC 60601-Familie erfüllen.

      Ob diese Entkopplung und der „Nicht-Zugriff“ auf den inneren Aufbau des Hardware-Produkts (inkl. dessen Software) möglich ist, entscheidet sich auch im Risikomanagement.

      So weit meine ersten Gedanken ohne tieferes Verständnis des Produkts, seiner Zweckbestimmung und seiner Risiken.

      Beste Grüße, Christian Johner


  24. Wolfgang Decker | Mittwoch, 18. November 2020 um 13:58 Uhr - Antworten

    Hallo Hr. Professor Johner,

    ich bin mit einer sehr interessanten Fragestellung konfrontiert. Es geht um die Umsetzung einer mathematischen Formel aus einer Publikation für eine mögliche Berechnung eines Behandlungsvolumens auf Basis der Eingabe von Körpergröße und -gewicht. Muss man diese Umsetzung einer Formel z. B. auf einer Webpage oder App bereits grundsätzlich als Decision Support ansehen und wäre damit als Medizinprodukt zu klassifizieren?
    Sie haben im Eingang dieses Artikels sehr schön beschrieben und dargelegt, dass der Hersteller ja über die Festlegung des Intended Purpose definiert, ob dies ein Medizinprodukt ist. In dem Fall sehe ich es allerdings als schwierig an, einen Intended Purpose zu beschreiben, der diese in eine Software umgesetzte Formel nicht als Decision Support klassifizieren würde. Ihre Meinung dazu würde mich sehr interessieren.

    Herzliche Grüße und vielen Dank vorab

    Wolfgang Decker


    • Prof. Dr. Christian Johner | Mittwoch, 18. November 2020 um 15:53 Uhr - Antworten

      Lieber Herr Decker,

      das ist wirklich eine spannende Frage!

      Ich vermute, dass Sie sich auf das europäische Recht beziehen, da in den USA die Decision Support Systeme nicht notwendigerweise Medizinprodukte sind, zumindest keine ohne „enforcement discretion“.

      Weiter nehme ich an, dass die Berechnung eine gewissen Trivialität hat, weshalb Sie überlegen, wie man eine Qualifizierung als Medizinprodukt vermeiden kann.

      Sie ahnen schon, dass die Argumentation in Europa nicht ganz einfach ist, um eines solche Qualifizierung zu vermeiden. Dennoch hier ein paar Gedanken:

      • Ausbildung, Training
      • Simulation, um Einflüsse abschätzen oder Formel verstehen zu können. Das ist inbesondere dann stichhaltig, wenn man sich nicht auf einen ganz konkreten Patienten bezieht.
      • Manchmal hilft eine Zweckbestimmung hinsichtlich Fitness, Gesundheit, Wellness. Das wird im konkreten Kontext nicht gehen.

      Was immer hilfreich ist, ist den Bezug zum konkreten Patienten zu vermeiden und den Hinweis zu ergänzen, dass das Produkt nicht ur Diagnose, Therapie oder Überwachung von Krankheiten und Verletzungen vorgesehen sei.

      Vielleicht ist ein Gedanke dabei, der Ihnen nützlich ist.

      Viele Grüße, Christian Johner


  25. Jakob Muaz | Donnerstag, 25. November 2021 um 11:47 Uhr - Antworten

    Vielen Dank Prof. Johner für die wertvolle Erklärung über SaMD.

    Ich habe zu dem Thema eine Frage:

    Gilt eine Smartwatch (z.B. Apple Watch) als Medizinprodukt. Wir haben hier 3 Komponente (Die Uhr mit den Sensoren für die Messungen und die Software, die diese Messungen interpretiert und das Handy, auf dem die App heruntergeladen wird).

    1. Gilt in diesem Fall die Uhr als Medizinprodukt oder als Zubehör und wenn als Zubehör gilt, ist ein Zubehör ein Medizinprodukt und muss klassifiziert werden anhand MDR Klassifizierregeln.

    2. Gilt das Handy in dem Fall auch als Zubehör?

    3. Ist die Software als Standalone-software zu betrachten? (die Software interpretiert die Messungen, die von den Uhrsensoren gemessen werden)

    Vielen Dank, dass Sie Ihre wertvolle Erfahrung im Bereich medizinische Zulassungen mit uns teilen.


    • Daniel Reinsch | Montag, 29. November 2021 um 15:33 Uhr - Antworten

      Guten Tag Herr Muaz,
      ob es sich um ein Medizinprodukt handelt oder nicht hängt von der Zweckbestimmung ab. Eine Smartwatch ist per se kein Medizinprodukt. Erst wenn sie vom Hersteller dafür bestimmt ist einen spezifischen medizinischen Zweck zu erfüllen (z.B. Diagnose, Verhütung, Überwachung, Vorhersage, Prognose, Behandlung oder Linderung von Krankheiten vgl. MDR Art.2 (1)) wird sie zu einem Medizinprodukt. Also z.B. wenn die Zweckbestimmung der Smartwatch mit der App lautet: „Zur Therapie und Rehabilitation bei Herzkreislauferkrankungen bei Erwachsenen Menschen zwischen 18 und 60 Jahren.“
      Um ein Zubehör (vgl. MDR Art. 2 (2)) handelt es sich, wenn es die Zweckbestimmung des Medizinprodukts unmittelbar unterstützt. Ein Zubehör ist per Definition kein Medizinprodukt wird aber von der MDR so behandelt wie eines (vgl. MDR Art. 1 (1)). Das würde man beim Handy in diesem Fall aber nicht so sehen, da es auch (fast) egal ist um welches Handy es sich handelt, es stellt nur eine Umgebung dar, auf der die Software laufen kann.
      Es gäbe die Smartwatch, auf der eine embedded Software läuft und die App, die man als Standalone Software betrachten könnte. Das Medizinprodukt, sofern es eines wird, könnte aber aus der Kombination von Smartwatch und App bestehen auch wenn es physisch getrennt ist.

      Viele Grüße
      Daniel Reinsch


Hinterlassen Sie einen Kommentar

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