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.

Damit Sie noch schnellere Antworten bekommen, habe ich Ihnen auf meiner Webseite ein FAQ veröffentlicht. Dieses umfasst bisher nur einen kleinen Teil, aber ich arbeite daran, die bisherigen Antworten redaktionell aufzuarbeiten und zu anonymisieren. Auf dieser Seite können Sie Ihre Fragen direkt an mich einreichen oder mir eine E-Mail schildern.

Schneller, preisgünstiger und kompetenter werden Sie kaum Antworten bekommen. Also her damit!

Herzliche Grüße, Ihr Christian Johner

Sie haben zudem die Möglichkeit, während des Seminars “Medizinische Software” nächste Woche mir nicht nur weitere Fragen zu Ihrer spezifischen Situation zu stellen, sondern auch die Umsetzung direkt zu üben. Mit diesem neuen Wissen werden Sie sowohl sehr gut einschätzen können, in wie weit Sie Ihre Software normen- und gesetzeskonform entwickeln, als auch in der Lage sein, Korrekturen selbstständig zu planen. Mehr zu dem Seminar finden Sie auf der Webseite zum Seminar “Medizinische Software”.

Ich freue mich auf Ihre Fragen für unser FAQ und auf ein mögliches Treffen nächste Woche

Herzliche Grüße, Christian Johner

Was viele jedoch nicht wissen ist, dass ich Firmen bei der Entwicklung und Zulassung medizinischer Software aktiv unterstütze. Das kann man auch nicht wissen, weil ich dazu nicht einmal eine Webseite habe, geschweige denn dafür werbe. Dennoch ist diese kleine heimliche Firma sehr erfolgreich, hilft kleinen Firmen mit 5 Entwicklern ebenso wie DAX-Konzernen. Diesen Erfolg verdanke ich es, dass ich mich verstärken konnte:

• Sven Wittorf liebt Normen: Bei IEC 62304 und ISO 13485 leuchten seine Augen. Er ist somit nicht nur die Idealbesetzung, sondern auch ein Entwickler mit jahrelanger Erfahrung. Sven unterstützt mich als Projektleiter „medizinische Software“ nicht nur bei den Beratungsprojekten.
• Björn Quade entwickelt die Werkzeuge, die wir für die eigene Entwicklung, aber auch bei unseren Beratungsprojekten einsetzen. Zurzeit arbeiten wir an einer speziellen Version bzw. speziellen Add-ons für die Tools JIRA und Polarion.
• Methodpark: Mit dieser Firma pflegen wir eine jahrelange Partnerschaft. Studierende (nicht nur von Methodpark) erforschen beispielsweise im Rahmen ihrer Master Thesis, wie man medizinische Software planbarer und normenkonform entwickeln kann. Diese Erkenntnisse fließen dann in Produkte von Methodpark wie Stages ein. Gemeinsame Auftritte und Seminare zeugen ebenfalls von dieser Partnerschaft.
• Polarion: Für und mit Polarion entwickeln wir eine spezielle Erweiterung für deren gleichnamiges Werkzeug. Diese „Beziehung“ ist zwar noch jung, aber sehr vielversprechend. Ich halte Sie auf dem Laufenden.
• HLMC: Mit der MedConf ist HLMC wirklich ein Treffer gelandet. Eine Konferenz speziell für uns Entwickler medizinischer Software gab und gibt es sonst nicht. Zum Gelingen der MedConf tragen meine kleine Firma bzw. das Institut bei. In Form von Workshops und natürlich der jährlichen Keynote. Auch als akademischer Partner der MedConf fungieren wir. Zur MedConf werde ich ebenfalls noch einiges bloggen.

Jetzt wissen Sie es, was mich sonst noch umtreibt. Wenn Sie beim Entwickeln von medizinischer Software eine Frage haben, dann stellen Sie sie mir einfach (christian.johner [at] johner-institut.de). Das kostet Sie nichts und bereitet mir Freude. Und wenn Sie sich richtig ausbilden lassen wollen, gibt es noch den Club. Doch über dieses Projekt erzähle ich Ihnen erst viel später…

Liebe Grüße, Ihr Christian Johner

Es wird künftig ein Zertifikat speziell für Sie geben, den „Certified Professional for Medical Software“. Momentan beginnen wir damit, das Curriculum und die Prüfungsbedingungen zu erstellen. Doch das wollen wir gemeinsam mit Ihnen tun. Daher laden wir Sie ein, mit uns gemeinsam einen Verein (das „Board“) zu gründen, dessen Ziel es ist, eben diese Lehrinhalte, die Prüfungsmodalitäten und Prüfungsinhalte zu definieren. In diesem Verein sollen/werden vertreten sein:

• Firmen, die medizinische Software herstellen/entwickeln
• Benannte Stellen
• Trainingsanbieter
• Andere Interessierte

Zertifizierungsstellen wie der TÜV werden dann die Prüfung abnehmen. Das Board selbst wird die Trainingsanbieter zertifizieren, so dass eine hohe und einheitliche Qualität gewährleistet ist, auf die Sie sich verlassen können und die dem Zertifikat den Wert verschafft, der Ihnen bei Ihrer Karriere und Arbeitsplatzsuche hilfreich sein wird.

Weitere Informationen (den Request for Comments) können Sie sich hier herunterladen.

Also machen Sie mit, gestalten Sie die Zukunft der medizinischen Software aktiv mit. Schicken Sie mir gleich eine E-Mail an christian.johner [at] johner-institut.de und werden Sie Teil des Kompetenznetzwerks!

Herzliche Grüße, Ihr Christian Johner

IEC 62304

Die Medizinprodukterichtlinie (Medical Device Directive MDD) fordert seit November 2007, dass

“bei Geräten, die Software enthalten oder bei denen es sich um medizinische Software an sich handelt, die Software entsprechend dem Stand der Technik validiert werden muss, wobei die Grundsätze des Software-Lebenszyklus, des Risikomanagements, der Validierung und Verifizierung zu berücksichtigen sind”.

Nun, wie soll man nachweisen, dass diese Forderungen erfüllt sind? Die kennt dazu das sogenannte Vermutungsprinzip. Man kann vermuten, dass ein Hersteller die grundlegenden Anforderungen an ein Medizinprodukt, darunter auch die eben genannte Forderung” erfüllt, wenn harmonisierte Normen eingehalten werden. Die IEC 62304 ist genau die dafür geeignete Norm.

Gilt auch der Umkehrschluss? Muss man sich nach IEC 62304 zertifizieren lassen, um Software als Medizinprodukt in Verkehr bringen zu dürfen? Diese Frage habe ich auch dem Leadauditor einer sehr großen benannten Stelle gestellt. Seine Antwort ist eindeutig: Nein, man muss sich nicht zertifizieren lassen. Die Überprüfung, ob Software gemäß eines Lebenszyklusmodells entwickelt wird, erfolgt üblicherweise im Rahmen einer ISO 13485 Zertifizierung, also der Überprüfung des Qualitätsmanagementsystems. Eine dezidierte Zertifizierung nach IEC 62304 ist nicht verlangt. Die Forderungen der MDD müssen aber erfüllt sein. Insofern ist die IEC 62304 zumindest als Checkliste und Hilfestellung mehr als nur zu empfehlen, wenn man die Prozesse und Methoden seiner Softwareentwicklung spezifizieren und leben möchte. An dieser Stelle möchte ich Professor Stettin und seinem Team gratulieren, die maßgeblich an der Stellung der 62304 beteiligt waren.

IEC 62366

Was wir Softwareentwickler am meisten unterschätzen, ist die Gebrauchstauglichkeit. Diese umfasst weit mehr, als das leicht verständliche Design einer Benutzeroberfläche. Das Usability-Engineering geht weiter darüber hinaus und betrachtet die kompletten Arbeitsabläufe, Arbeitssituationen und das Arbeitsumfeld, in denen das Produkt eingesetzt wird. Ein gutes Usability-Engineering birgt gleichzeitig ein immenses Innovationspotential. Als Folge dieser Unterschätzung sind inzwischen 70% aller Software-bezogenen Probleme Gebrauchstauglichkeitsprobleme, so inoffizielle Zahlen der FDA. Inzwischen wird der Gebrauchstauglichkeit auch in Europa zunehmende die Bedeutung beigemessen, die ihr eigentlich zusteht. Inzwischen ist die IEC 60601-1-6 (Gebrauchstauglichkeit elektrischer Medizingeräte) harmonisiert, und sei kurzen auch die IEC 62304 (Gebrauchstauglichkeit medizinischer Systeme), die als Nachfolgenorm der IEC 60601-1-6 gehandelt wird.

Fazit

Dass die Entwicklung medizinischer Software zunehmend professionalisiert wird beobachte ich bei fast allen Herstellern. Die neuen Normen geben uns klare und wie ich finde hilfreiche Richtlinien.

Herzliche Grüße Christian Johner

PS: Wenn Sie mehr zu diesen Themen wissen wollen, so empfehle ich Ihnen eines meiner Webinare, Seminare, z.B. zu medizinischer Software (nächstes am 16.02.) oder zur Usability, oder sogar die Mitgliedschaft im Club, in dem ich ab März regelmäßige Lehrvideos zu genau diesen Themen einstellen werde.

1. gesetzliche Grundlagen: MDD, MPG, MPBetreibV sowie eine Übersicht über alle Normen
2. Gesetzeskonforme Entwicklungsprozesse einschließlich IEC 62304
3. Risikomanagement für medizinische Software nach ISO14971
4. Testen medizinischer Software
5. Usability und IEC 60601-1-6

Die Übersicht über alle Themen und Termine finden Sie auf den Institutsseiten.

• 16. + 17. Dezember 2008 in Stuttgart
• 20. Dezember 2008 in Freiburg
• 28. + 29. April 09 in Freiburg
• 14. Oktober 2009 (Keynote MedConf in München)
• 3.+ 4. November 2009 in Hamburg
• 11.  November 09 in Zürich

Mehr zum Inhalt finden Sie auf der Seite www.MedizinischeSoftware.de beschrieben.

Mit den besten Grüßen zum verlängerten Wochenende

Christian Johner

]]> http://www.ehealthkarriere.de/?feed=rss2&p=49 0 http://www.ehealthkarriere.de/?p=44 http://www.ehealthkarriere.de/?p=44#comments Mon, 22 Sep 2008 11:20:14 +0000 cjohner http://www.ehealthkarriere.de/?p=44 Am Mittwoch (24. September) beginnt in München die erste Medconf. Sie ist die erste Konferenz, die sich speziell der Entwicklung medizinischer Software widmet. Wie ich vom Veranstalter gehört habe, liegen hunderte Anmeldungen vor, so dass ich davon ausgehe, dass sich die gesamte Szene treffen wird. Darauf freue ich mich natürlich.

Ich freue mich auch, dass ich die Veranstaltung mit einer einstündigen Keynote eröffnen darf. Und Sie als Leser meines Blogs können sich bereits heute die Präsentation dazu herunterladen. Ist das kein Service?

In der Hoffnung, Sie in München zu treffen,
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