Wie immer benötige ich einige Tage, um solch ein webbased Training zu erstellen. Dieses Mal sogar einen Tag mehr als üblich. Einfach, weil ich mir besondere Mühe gebe, Ihnen das Thema bestmöglich aufzubereiten. Und deshalb verzögert sich die Sache bis Mittwoch. Freuen Sie sich also darauf und haben Sie noch ein wenig Geduld. Es ist es definitiv wert!

Dieses webbased Training ist meines Erachtens das einzige, erste und kompakteste, das es meines Wissens gibt. Und kostenlos ist es auch! Interessiert, dann schauen Sie am nächsten Montag hier vorbei.

Und wenn Sie noch mehr Tipps haben möchten, wie Sie Ihr Audit sicher bestehen, dann können Sie mich kostenlos fragen oder mich bei meinem Seminar zu Medizinischer Software am 24./25. Juni besuchen. Das ist übrigens die letzte Chance bis zum Frühjahr 2011.

Also bis sehr bald, herzliche Grüße
Ihr Christian Johner

So stellt sich vielen Herstellern die Frage, was nun das Medizinprodukt ist. Die Software alleine? Die Software und der PC, auf dem sie läuft? Oder gar die Software mit dem PC und einem anderen Medizingerät? Müssen gar die Netzwerkkomponenten wie Router, welche die Software mit dem anderen Medizingerät verbinden, selbst als Medizinprodukt klassifiziert werden?

Die Antwort auf die Frage, was denn hier das Medizinprodukt sei, ist ebenso schnell wie einfach beantwortet: Das, was der Hersteller in Verkehr bringt, um Menschen zu diagnostizieren und zu behandeln, ist das Medizinprodukt. Wenn der Hersteller sagt, die Software alleine sei ein Produkt, mit dem Menschen diagnostiziert oder behandelt werden, und diese einzeln verkauft, dann ist diese Software das Medizinprodukt. Wenn der Hersteller die Software zusammen mit dem PC in Verkehr bringt, dann ist diese Kombination das Medizinprodukt.

Ich halte eine andere Frage für die spannendere: Was sollte der Hersteller als Medizinprodukt in Verkehr bringen? Hier ist meine Antwort etwas differenzierter, denn es gibt Vor- und Nachteile der verschiedenen Ansätze:

Für eine Inverkehrbringung von möglichst granularen Produkten (hier Software und Medizingerät einzeln) sprechen die folgenden Gründe:

1. Sie sind freier in der Kombination: Solange die einzelnen Medizinprodukte ein CE-Zeichen haben und in der ursprünglichen Zweckbestimmung eingesetzt werden, können Sie alle Kombinationen vermarkten. Und das erneute Konformitätsprüfung.
2. Sie sind nicht so abhängig von Komponenten wie dem Router: Gerade Netzwerkkomponenten sind einem schnellen Technologiewandel unterworfen, und Sie wollen nicht bei jeder neuen Generation die Konformitätsprüfung erneut durchlaufen.
3. Wenn es Änderungen an einem der Medizinprodukte gibt, z.B. bei der Software, so müssen Sie nur die Software, nicht aber die vollständige Kombination neu „zulassen“.

Es gibt allerdings auch Gründe, welche gegen eine Inverkehrbringung der einzelnen Medizinprodukte sprechen:

1. Wenn Sie die Software, um ein Beispiel zu nennen, ohne den PC in Verkehr bringen, werden Ihre Kunden preiswerte Hardware einkaufen. Ein Medizinprodukt, welches die gleiche Hardware und Software kombiniert, ließe sich wahrscheinlich mit einer höheren Marge vertreiben.
2. Wenn Sie alle Komponenten, in unserem Beispiel inklusive dem Router, in Verkehr bringen, so haben Sie auch die Kontrolle über alle Komponenten. Dies kann bei der Risikoanalyse und Risikokontrolle einiges vereinfachen. So hätten Sie die Möglichkeit, bei einem Router (den Sie herstellen) gewisse Risiken, welche durch eine fehlerhafte Datenübertragung verursacht werden, durch eigene Prüfroutinen zu erkennen und geeignet zu reduzieren.

Fazit: Die Entscheidung, was nun das Medizinprodukt ist, ist weit mehr als eine regulatorische Angelegenheit. Hier spielen Marketinggesichtspunkte und das Risikomanagement eine wichtige Rolle.

Herzliche Grüße, Ihr Christian Johner

PS: Sind Sie an Antworten auf Fragen rund um die Entwicklung und Qualitätssicherung medizinischer Software interessiert? Dann schauen Sie sich mein Audit-FAQ zu diesem Thema an oder schreiben Sie mir eine E-Mail (christian.johner [at] johner-institut.de). Ich antworte gerne und kostenlos.

Noch für kurze Zeit biete ich den Auditleitfaden zum Subskriptionspreis an. Also sichern Sie sich gleich eines der 99 Exemplare.
Beste Grüße, Ihr Christian Johner

1. Wie unterscheidet sich die Zulassung von Software als Medizinprodukt (genau genommen muss man vom Konformitätsbewertungsverfahren sprechen) von der Zulassung anderer Medizinprodukte?
2. Was sind die typischen Fehler, welche dem Auditor bei Softwareentwicklungsabteilungen auffallen?

Dr. Wagners Antworten sind kurz und präzise – so wie man das von einem Auditor eben erwartet:

Besonderheiten bei der Zulassung medizinischer Software

Hier gibt es zuerst keine besonderen Forderungen. Wie bei allen Produkten muss der Hersteller die grundlegenden Anforderungen, die in der Medizinprodukterichtlinie 93/42/EC genannt sind, erfüllen. Diesen Nachweis kann der Hersteller besonders einfach erbringen, wenn er die Einhaltung von Normen, besonders von harmonisierten Normen nachweist.  Bei Software, die gemeinsam mit Hardware zugelassen wird, zählen zu diesen Normen sicher die Mitglieder der Normenfamilie IEC 60601-1. Besonders zu nennen sind die IEC 60601-1-4 und die IEC 60601-1-6 (Gebrauchstauglichkeit). Demnächste wird eine weitere Norm harmonisiert, die IEC 62304, die den Lebenszyklus von medizinischer Software beschreibt.

Auch beim Konformitätsbewertungsverfahren gibt es ein paar Unterschiede, weil einige Verfahren  nicht besonders für Software anwendbar sind. Beispielsweise könnten Medizinprodukte der Klasse I mit Messfunktion nach Anhang VII für die Entwicklung und für die Produktion nach einem der Anhänge IV, V oder VI zugelassen werden. Somit würde die benannte Stelle die Produktion überwachen. Die Produktion beschränkt sich aber auf die Vervielfältigung von CDs, und das stellt nun wirklich nicht das Hauptproblem dar. Auch eine Baumusterprüfung (Anhang III) eignet sich eher für Prüfung der mechanischen oder elektrischen Sicherheit von Medizingeräten und weniger der Überprüfung von Millionen Code-Zeilen. Insofern muss der Entwicklungsprozess und nicht nur das Endprodukt geprüft werden.

Das Konformitätsbewertungsverfahren insgesamt – und das sein nochmals betont – unterscheidet sich nicht.

Typische Fehler 

Ich muss gestehen, hier war ich schon neugierig, was ein so erfahrener Auditor typischerweise als Problem findet. So berichtet mit Dr. Wagner:

Speziell bei kleineren Firmen fehlen Ressourcen für Dokumentation.

• Dies wirkt sich dahingehend aus, dass die Spezifikation sowie die Verifikation und Validierung nicht ausreichend dokumentiert sind. Bei letzteren wird nicht dargelegt, was die Inputs, was die Outputs, was die Erwartungswerte und was die Akzeptanzkriterien sind. 
• Ebenfalls unzureichend dokumentiert sind in der Software verbliebene Anomalien und die Kriterien für deren Akzeptanz. 
• Weiterhin fällt auf, dass mangelndes Konfigurationsmanagement zu nicht konsistenter Dokumentation, speziell des Technical Files, führt. So kann nicht mehr reproduziert werden, welche Version der Unterlagen zum Zeitpunkt der Einreichung und zum jetzigen Zeitpunkt aktuell waren bzw. sind. 
• An das oben Gesagte: Bei den Prüfaufzeichnungen fehlen oft Informationen darüber “wer hat geprüft”, “was wurde geprüft”. 
• Und schließlich fällt auf, dass nur unzureichend rückverfolgbar ist, ob und wie die Anforderungen und die Risikokontrollmaßnahmen bei der Umsetzung und der Verifikation bzw. Validierung berücksichtigt wurden. 

Man kann, so Dr. Wagner, aber keineswegs behaupten, dass kleine Firmen schlechter seien. Die großen Firmen haben aufgrund der zahlreichen internen und externen Schnittstellen, z.B. zu externen Dienstleistern, einen besonderen Dokumentationsaufwand und -bedarf.

Soweit der erste Teil meines Reiseberichts. Demnächst berichte ich über das Thema “Wann wird Software zum Medizinprodukt?”

Bis dann,

liebe Grüße

Euer Christian