Ständig ändern sich Gesetze für Hersteller von Medizinprodukten.
Wir halten Sie 1x pro Woche kompakt auf dem Laufenden, damit Sie nichts verpassen
Die IEC 62304 ist eine in Europa harmonisierte Norm für „Medizingeräte-Software“. Sie stellt Mindestanforderungen an die wichtigsten Software-Lebenszyklus-Prozesse, konkret an die Software-Entwicklung, die Software-Wartung, an das Software-Risikomanagement (inkl. Verweis auf die ISO 14971), und das Software-Konfigurationsmanagement und die Problemlösung bei Software.
Die Norm ist anwendbar bei embedded und bei standalone Software, d.h. bei
Die folgenden Artikel sind nach den Kapiteln der Norm gruppiert.
Hier finden Sie Artikel, die die Norm im Allgemeinen betreffen:
Diese Norm wiederum schreibt fünf Prozesse vor, nach denen die Medizinprodukte-Hersteller Software (weiter)entwickeln sollen:
Eine besondere Bedeutung kommt dabei dem Software-Entwicklungsprozess vor. Die Norm IEC 62304 schreibt kein(!) konkretes Prozessmodell vor (z.B. Wasserfall-Prozess, V-Modell, agiler Prozess). Sie stellt aber Anforderungen an konkrete Aktivitäten, die innerhalb dieses Prozesses durchzuführen sind, insbesondere die Dokumentation der
Sie erfahren durch klicken auf die jeweiligen Links mehr darüber, auf was Sie bei der Dokumentation der jeweiligen Phasen zu achten haben.
Ebenso finden Sie eine ausführliche Diskussion der agilen Entwicklung im Kontext der IEC 62304.
Der Auditgarant zeigt Ihnen in 60+ Videotrainings, wie Sie Schritt für Schritt eine IEC 62304-konforme Dokumentation ohne unnötigen Aufwand und ohne QM-Bürokratie erstellen können.
Videotrainings zur IEC 62304 ansehen
Die Medizinprodukterichtlinie (auch MDD oder 93/42/EWG genannt) verlangt in den sogenannten „grundlegenden Anforderungen“ im Anhang I verbindlich, dass
„bei Produkten, 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“.
Diese Forderung ist durch den Verweis des Medizinproduktegesetzes auf die MDD eine gesetzliche. Ein Verstoß dagegen kann mit Geld- und Freiheitsstrafen belegt werden.
Hersteller von Medizingeräten/Medizinprodukten weisen die Konformität mit diesen grundlegenden Anforderungen meist dadurch nach, dass sie harmonisierte Normen einhalten. Das sind im Kontext der Entwicklung von Medizinprodukten v.a die Norm IEC 60601-1, die Norm IEC 62304 (speziell für die Software-Lebenszyklus-Prozesse) und die Norm ISO 14971 für das Risikomanagement.
Während die Entwicklung von Medizingeräte- bzw. Medizintechnik-Software durch die oben genannten Normen relativ detailliert geregelt ist, gibt es mit Ausnahme der IEC 62366 zur Gebrauchstauglichkeit von Medizinprodukten noch keine Norm, die die Validierung von stand-alone Software ausreichend adressiert: Die Norm IEC 62304 geht nicht auf die Validierung, sondern nur auf die Verifizierung ein. Sie fordert zudem ein Qualitätsmanagement-System und empfiehlt eines nach ISO 13485.
Eine künftige Norm IEC 82304 wird auch Forderungen an die Validierung benennen, so dass der wichtige Lebenszyklus-Prozess, der Entwicklungsprozess, vollständig beschrieben sein wird. Allerdings wird die IEC 82304 nicht nur Forderungen an die Entwicklung von Medizinprodukte bzw. Medizingeräte-Software stellen, sondern sogar auch an die Lebenszyklus-Prozesse von Health-Software.
Eine neue Version der IEC 62304 wird nicht vor 2018 erwartet, da im Oktober 2014 die Überarbeitung der Norm nochmals komplett neu begonnen wurde. Die nächste Version der IEC 62304 wird einen erweiterten Scope haben, der sich nicht auf Medizinprodukte und nicht auf die Software-Entwicklung beschränkt. Ein Artikel zur zweiten Version der IEC 62304 und zum Ammendment I informiert Sie über weitere Details.
Unter dem Begriff Medizingeräte-Software versteht man meist Software, die Teil eines medizintechnischen Geräts ist z.B. die embedded Software eines Defibrillators. Damit ist Medizingeräte-Software eine Untergruppe der Medizinprodukte-Software, die alle Software umfasst, die entweder als standalone Software oder als Teil eines Medizinprodukts unter das Medizinproduktegesetz fällt. Der noch allgemeinere Begriff ist Health-Software, der alle Software im medizinischen Kontext umfasst.
Haben Sie weitere Fragen zur normenkonformen Entwickung Ihrer Software bzw. Ihres Medizinprodukts? Benötigen Sie Hilfe? Dann nutzen Sie gerne…
Kostenlose Hilfe bekommen! Auditgarant: Videotrainings ansehen!
Zunehmend bieten Prüfstellen eine IEC 62304 Zertifizierung an. Sie kommunizieren dies teilweise als ein Zwischending zwischen vollständigem QM-System und Baumusterprüfung. Einige werben sogar damit, dass man damit den Testaufwand reduzieren könne.
Zuerst möchte ich Sie ermutigen, IEC 62304 konform zu arbeiten – nicht nur um den gesetzlichen Forderungen an medizinische Software nachzukommen. Ich möchte Sie aber auch vor falschen Rückschlüssen warnen:
Im Rahmen einer ISO 13485 (!) Zertifizierung, die von akkreditierten Stellen vorgenommen wird, wird der Auditor indirekt sowieso die Konformität mit IEC 62304 prüfen, zumindest exemplarisch.
Vor einer IEC 62304 Zertifizierung möchte ich nicht generell abraten, aber Sie sollten genau wissen, was Sie sich davon erwarten.
Montag 16. Juli 2018 von Prof. Dr. Christian Johner
Bei Software als Medizinprodukt unterscheidet man standalone (eigenständige) Software und Software, die Teil eines Medizinprodukts ist.
Update: Der EuGH hat ein wichtiges Urteil zur Zertifizierbarkeit von Software-Modulen als Medizinprodukt gesprochen (mehr…)
Mittwoch 11. Juli 2018 von Prof. Dr. Christian Johner
Das V-Modell ist ein Entwicklungsprozessmodell, das ursprünglich für staatliche Projekte entwickelt wurde.
| Inhaltsübersicht |
|---|
| Phasen im V-Modell » |
| Verantwortlichkeiten » |
| V-Modell s. agile Entwicklung » |
| Typische Missverständnisse und Fehler » |
| Unterstützung » |
Das hat den Vorteil, dass unvollständige Spezifikationen frühzeitig erkannt werden, auch dadurch, dass die für das Testen verantwortlichen Personen mit eingebunden werden.
Sonntag 13. Mai 2018 von Prof. Dr. Christian Johner
Viele Lastenhefte und Pflichtenhefte unterscheiden sogenannte funktionale Anforderungen und nicht-funktionale Anforderungen. Funktionale Anforderungen sind Anforderungen mit Bezug zur Zweckbestimmung des Produkts. Zu den nicht-funktionale Anforderungen zählen Anforderungen wie die Zuverlässigkeit und das Zeitverhalten.
Donnerstag 10. Mai 2018 von Prof. Dr. Christian Johner
Software-Systeme sollten aus Komponenten bestehen, die über Software-Schnittstellen miteinander kommunizieren.
Donnerstag 1. März 2018 von Prof. Dr. Christian Johner
Lastenheft und Pflichtenheft, Systemspezifikation und Systemanforderungen
Die Vorstellungen darüber, was diese Lastenhefte und Pflichtenhefte enthalten müssen, gehen weit auseinander – manchmal auch innerhalb einer Firma.
Regelmäßig beobachtet das Johner Institut, dass alle mehrere Dokumente etwa die gleichen Anforderungen beschreiben.
| Inhaltsübersicht |
|---|
| Lastenheft: Zweck und Inhalt » |
| Pflichtenheft: Zweck und Inhalt » |
| Stakeholder & System-Anforderungen » |
| Regulatorische Anforderungen » |
| Typische Probleme » |
Nur in der Granularität und dem Detailgrad unterscheiden sie sich. Schon aus regulatorischer Sicht sollten Sie die Begriffe Lastenheft und Pflichtenheft gegeneinander abgrenzen.
Donnerstag 18. Januar 2018 von Prof. Dr. Christian Johner
Das IMDRF (International Medical Device Regulators Forum) möchte zur Harmonisierung der international unterschiedlichen Vorschriften beitragen und dadurch die Zulassung von Medizinprodukten vereinheitlichen und vereinfachen. Dazu veröffentlichen die Freiwilligen des IMDRF Leitfäden, die zwar nicht verbindlich sind, aber Hilfestellungen geben. In diesem Artikel stelle ich Ihnen v.a. die Leitfäden mit Bezug zur Software „as a Medical Device“ vor.
Dienstag 16. Januar 2018 von Prof. Dr. Christian Johner
Fuzz-Testing ist eine Methode zur Identifizierung bisher nicht-erkannter Schwachstellen und Sicherheitslücken in Software (stand-alone oder embedded), die die Schnittstellen der Systeme automatisiert mit korrekten oder falschen Werten testet.
Freitag 12. Januar 2018 von Prof. Dr. Christian Johner
Unter einem Security Patch versteht man eine Nachbesserung an einer Software, um eine Sicherheitslücke zu stopfen. Für einen Security Patch gelten teilweise andere regulatorische Anforderungen als an andere Software Updates. Auf was Sie achten müssen, erfahren Sie in diesem Beitrag.
Dienstag 9. Januar 2018 von Prof. Dr. Christian Johner
Der UL 2900-2-1 nennt sich „Particular Requirements for Network Connectable Components of Healthcare and Wellness Systems“. Er zählt zur UL-2900-Familie, der Normenfamilie zur IT-Security.
Lesen Sie in diesem Artikel, welche Schwächen der Standard hat und unter welchen Umständen er Ihnen dennoch nützlich sein kann.
Dienstag 19. Dezember 2017 von Prof. Dr. Christian Johner
Decision Support Systeme, zu Deutsch Entscheidungsunterstützungssysteme, finden auch in der Medizin zunehmend Anwendung. Handelt es sich dabei um Medizinprodukte, müssen diese die gesetzlichen Anforderungen (z.B. die grundlegenden Anforderungen) erfüllen.
| Inhaltsübersicht |
|---|
| Definition und Beispiele » |
| FDA Guidance Document » |
| Regulatorische Anforderungen in Europa » |
| Herausforderungen » |
Dieser Artikel stellt die besonderen Herausforderungen vor, welche Hersteller von Decision Support Systemen bewältigen müssen, und gibt Tipps, wie diese Herausforderungen gemeistert werden können. Er erläutert auch das entsprechende Guidance Document der FDA.
Den ganzen Beitrag lesen »
Ein rascher Überblick über Normen und Gesetze.
Kostenlose Beratung
Haben Sie eine Frage? Wir antworten schnell, unbürokratisch und kostenlos!
120+ Trainingsvideos helfen Ihnen, schnell und einfach Zulassungsunterlagen und ein schlankes QM-System zu erstellen.
Kompaktes Expertenwissen
DIE Fachbücher für Medizinprodukte-Hersteller
