Prof. Dr. Christian Johner: Softwareentwicklung, Medizintechnik und Qualitätssicherung

Guest Article

Sie entwickeln Software für Medizingeräte oder Software, die selbst ein Medizinprodukt darstellt? Dann wird Ihnen die Norm IEC 62304 zumindest dem Namen nach begegnet sein. Viele Entwickler stöhnen über die vielen Regularien: Da gibt es die Medizinprodukterichtlinie 93/42 und das Medizinproduktegesetz MPG. Dann sind Normen zum Risikomanagement (ISO 14971) und ggf. zum Qualitätsmanagementsystem (ISO 13485) einzuhalten. Einen Kunden, den ich bei der „Zulassung” seiner Software unterstützen durfte, meinte, man käme vor lauter Normen nicht mehr zu entwickeln. Und so wie er die Normen umsetzte, hatte er sogar Recht damit. Also, was tun?

Zuerst die gute Nachricht. Sie müssen die IEC 62304 nicht unbedingt einhalten. Sie hilft Ihnen aber, und das auf gleich zwei Weise:

1. Wenn Sie diese harmonisierte Norm einhalten, muss Ihr Auditor vermuten, dass Sie die gesetzlichen Forderungen nach Software-Lebenzyklusprozesse und Software-Verifizierung erfüllen. Glauben Sie mir, das ist beim Audit mehr als die halbe Miete.


2. Eine zeitgemäße Softwareentwicklung (nicht nur für Medizinprodukte) erfüllt sowieso die Forderungen der IEC 62304. Zumindest weitestgehend. So arbeitet man eben „state-of-the-art”, so entwickelt man am effizientesten gute Software. Die IEC 62304 dient Ihnen somit als perfekte Checkliste für Ihre Prozesse, Ihre Methoden und Werkzeuge.

Apropos Werkzeug: Das Problem meines Kunden bestand darin, dass bei ihm die tatsächliche Softwareentwicklung und das, was in Qualitätsmanagementhandbüchern stand, herzlich wenig miteinander zu tun hatten. Besonders Software-Entwickler hassen es (zu Recht, wie ich finde), redundante Arbeit zu erledigen, Formulare auszufüllen, nur um einer Norm gerecht zu werden. Wenn hingegen all das, was in den Handbüchern steht, direkt in die Entwicklungstools integriert ist, arbeitet der Entwickler implizit normenkonform. Und dazu bedarf es Werkzeuge.

In meiner Firma hatte ich das aufwendig selbst implementiert. Ein Entwickler kümmerte sich ausschließlich um diese Eigenentwicklung. Heute bieten Werkzeuge wie Polarion die komplette Infrastruktur. Alle wesentlichen Elemente wie Konfigurationsmanagement, Traceablity, Prozessunterstützung, Dokumentation und Checklisten sind nicht nur vorhanden, sondern bereits integriert und vorkonfiguriert. Ich bin so überzeugt von dieser Lösung, dass ich mich mit meinem Team an die Arbeit gemacht habe, ein spezielles Plugin für die Entwicklung medizinischer Software dafür zu entwickeln. Zur MedConf im Oktober werden wir eine erste Version fertiggestellt haben.

Bei aller Begeisterung empfehle ich dennoch die Reihenfolge beizubehalten:

1. Strategisches Firmenziel finden, dokumentieren und kommunizieren.


2. Prozesse definieren und etablieren, beispielsweise Entwicklungsprozess, Wartungsprozess, Problemlösungsprozess und Risikomanagementprozess. Also die Prozesse, die auch die IEC 62304 vorschreibt.


3. Methoden wie Requirements-Engineering, Testen usw. festlegen, um die Prozesse wirkungsvoll und effizient ablaufen zu lassen.


4. Werkzeuge auswählen und implementieren, welche Prozesse und Methoden unterstützen. Und da habe ich Ihnen ja meinen Favoriten für das sogenannte „Application Live Cycle Management” bereits genannt. Ich weiß, wir Entwickler beginnen am liebsten mit diesem Punkt. Wahrscheinlich hätte Polarion gar nichts dagegen ;-).

Bei meinem Kunden habe ich übrigens zwei Drittel des Qualitätsmanagementhandbuchs entsorgt, die Prozesse entschlackt und Wirklichkeit und Anspruch zueinander geführt. Der Auditor fand es jedenfalls gut.

Herzliche Grüße

Ihr Christian Johner