Die Entwicklung von Software für die Medizingeräteindustrie erfordert eine sorgfältige Balance zwischen Innovation und Sicherheit. Da sich die Medizintechnik rasant weiterentwickelt, müssen Hersteller strenge Richtlinien einhalten, um die Zuverlässigkeit der Software zu gewährleisten. Um diese Ziele zu erreichen, ist ein klar strukturierter Ansatz für die Softwareentwicklung erforderlich – einer, der potenzielle Risiken antizipiert, qualitativ hochwertige Ergebnisse sicherstellt und sich an die sich entwickelnden Erwartungen von Regulierungsbehörden weltweit anpasst. In vielen Fällen besteht ein Medizinprodukt aus Hardware und hochentwickelter Software, die nahtlos funktionieren muss, um klinische Standards zu erfüllen.

Bei Scythe ist unser Hauptdienst die umfassende Entwicklung von Embedded-Software, und die Mehrheit unserer Kunden sind genau Medizingerätehersteller oder Start-ups. Da die Entwicklung von Software für Medizingeräte unser tägliches Geschäft ist, haben wir ISO 13485:2016 eingeführt und natürlich
arbeiten wir im Rahmen der IEC 62304.

Im Folgenden untersuchen wir, wie ein risikobasierter Ansatz, robuste Sicherheitsmaßnahmen und gut abgestimmte Strategien die Software für Medizingeräte gemäß IEC 62304 gestalten können. Darüber hinaus unterstreicht die Anwendbarkeit der Norm auf verschiedene Arten medizinischer Elektrogeräte ihre Rolle bei der Förderung von Konsistenz im Gesundheitssektor.

 

Was ist IEC 62304?

IEC 62304:2006 ist eine international anerkannte Norm für den Softwarelebenszyklus, die (nicht ganz eindeutig :)) Anleitungen zu Prozessen, Aktivitäten und Aufgaben gibt, die für die Erstellung und Wartung von Software für Medizingeräte erforderlich sind. Durch die Vorgabe eines risikobasierten Ansatzes hilft sie Entwicklern, ihre Implementierungsphase zu strukturieren, die Softwarearchitektur zu verfeinern und robuste Tests der Softwaresysteme sicherzustellen – und das alles unter Wahrung hoher Sicherheitsstandards.

Die Einhaltung der IEC 62304 zeigt ein klares Bekenntnis zur Patientensicherheit und zur regulatorischen Vorbereitung. Sie wird in der Medizingeräteindustrie weltweit von Regulierungsbehörden anerkannt. In der Europäischen Union wurden die
Medical Device Regulation (MDR 2017/745) und die
In-Vitro-Diagnostik-Verordnung (IVDR 2017/746) mit dieser Norm harmonisiert, und auch die US-amerikanische FDA erkennt sie als Konsensnorm an.

Der vollständige Name der Norm lautet:
„Medical Device Software – Software Life Cycle Processes“ (Medizingeräte-Software – Software-Lebenszyklus-Prozesse).

 

Was regelt die IEC 62304 für die Entwicklung von Software für Medizingeräte?

Die Norm bietet einen Rahmen für Entwickler zur Etablierung von Lebenszyklusprozessen, die Aktivitäten zur sicheren Entwicklung und zur Wartung nach der Markteinführung des Geräts beinhalten. Jeder Zyklus enthält spezifische Anforderungen. Ein einzelner Prozess besteht aus mehreren Aktivitäten, und jede Aktivität umfasst verschiedene Aufgaben.

Die IEC 62304 definiert folgende Prozesse für die Software von Medizingeräten:

 

1. Software-Entwicklungsprozess
2. Software-Wartungsprozess
3. Software-Risikomanagement-Prozess
4. Software-Konfigurationsmanagement-Prozess
5. Software-Problembehandlungsprozess

Die Norm verlangt von Herstellern, eine detaillierte technische Dokumentation zu erstellen und zu pflegen, die den Regulierungsbehörden vorgelegt wird. Über den genauen Inhalt dieser Dokumentation werden wir später in diesem Artikel berichten.

Falls Sie nach einem PDF der IEC 62304:2006 mit dem vollständigen Inhalt der Norm suchen, muss ich Sie enttäuschen. Sie müssen es selbst erwerben, da jede Kopie so markiert ist, dass sie nicht kopiert werden darf. Ich bin nicht unbedingt ein Fan davon, aber es ist letztendlich keine große Investition.

 

IEC 62304-Prozesse für die Entwicklung von Software für Medizingeräte

 

Warum ist IEC 62304 für Sie wichtig?

Die Einhaltung der IEC 62304 wird zunehmend auf nationalen und internationalen Märkten gefordert. Regulierungsbehörden wie die FDA in den USA und die Europäische Kommission erwarten einen Nachweis über ein solides Softwareentwicklungs-Framework, bevor sie Medizingeräte für den Verkauf zulassen. Die Einhaltung der IEC 62304 kann:

 

• Den Zulassungsprozess durch strukturierte regulatorische Einreichungen beschleunigen.
• Das Vertrauen von Stakeholdern (Gesundheitsdienstleister, Investoren, Patienten) stärken.
• Risiken von Softwareausfällen minimieren und schwerwiegende Verletzungen verhindern.
• Einen strukturierten und wiederholbaren Softwareentwicklungsprozess gewährleisten.

Kurz gesagt, IEC 62304 ist für jedes Unternehmen, das ernsthaft im Medizingerätemarkt tätig sein möchte, unverzichtbar.

 

Grundlagen der IEC 62304

Schauen wir uns nun einige der grundlegendsten, aber dennoch wesentlichen Informationen an, die Sie kennen sollten, um eine Vorstellung davon zu bekommen, worüber Sie sprechen.

 

Sicherheitsklassen (A, B, C)

IEC 62304 kategorisiert Software für Medizingeräte in drei Sicherheitsklassen. Hersteller sollten ihre Produkte basierend auf potenziellen Gefährdungen und möglichen Schäden einstufen.

 

• Klasse A: Es können keine Verletzungen oder gesundheitlichen Schäden entstehen, selbst wenn die Software ausfällt.
• Klasse B: Ein Softwarefehler könnte zu einer nicht schwerwiegenden Verletzung führen.
• Klasse C: Ein Softwarefehler könnte zum Tod oder zu einer schweren Verletzung führen.

Die Klassifizierung bestimmt den erforderlichen Umfang der Dokumentation und der Strenge im Entwicklungsprozess. Zum Beispiel erfordern Klasse-C-Geräte umfassendere Verifizierungs- und Validierungsprozesse als Klasse-A- oder Klasse-B-Geräte, da das Risiko für Patienten höher ist.

Regulierungsbehörden wie die europäische MDR oder die FDA in den USA definieren ihre eigenen Klassifizierungen. In den USA gibt es drei Klassen (I, II, III), während es in der EU eine zusätzliche Zwischenklasse gibt (I, IIa, IIb, III). In beiden Fällen entspricht Klasse C in etwa Klasse III, während Klasse A die niedrigste Risikostufe darstellt und mit Klasse I übereinstimmt.

 

Sicherheitsklassen gemäß IEC 62304

 

Technische Dokumentation

IEC 62304 fordert eine umfangreiche Dokumentation. Zu den wichtigsten Elementen der Dokumentation gehören:

 

• Software-Anforderungsdokumentation (SRS): Ein strukturiertes Dokument, das alle funktionalen und nicht-funktionalen Anforderungen der Software definiert.
• Sicherheitsrisikobewertung: Eine systematische Analyse potenzieller Gefahren, ihrer Ursachen und Maßnahmen zur Risikominderung.
• Software-Detaildesign (SDD): Ein Dokument, das die interne Struktur, Architektur und Designelemente der Software beschreibt und die Nachvollziehbarkeit der Anforderungen gewährleistet.
• Cybersecurity-Bewertung: Eine Analyse potenzieller Sicherheitsrisiken und Angriffsszenarien, um die Integrität und Vertraulichkeit der Daten zu gewährleisten.
• Traceability-Matrix: Ein Dokument, das Softwareanforderungen mit Design, Implementierung, Verifizierung und Validierung verknüpft, um eine vollständige Abdeckung und Compliance sicherzustellen.
• Code-Review, statische Codeanalyse, Unit- und Integrationstestberichte: Dokumentation der Code-Prüfungen, automatisierten Analysen und Testergebnisse zur Sicherstellung der korrekten Funktion und der regulatorischen Anforderungen.
• Überwachungsplan: Eine Strategie zur Marktüberwachung nach der Markteinführung, um Leistungsprobleme frühzeitig zu erkennen und Software-Updates oder Korrekturmaßnahmen zu implementieren.

Natürlich ist dies keine vollständige Liste. Viele dieser Punkte sollten in separate Dokumente aufgeteilt werden. Wie Sie die Dokumentation organisieren, liegt in Ihrem eigenen Ermessen.

 

Softwarearchitektur

Da IEC 62304 ein häufig verwendeter Rahmen für die Entwicklung von Software für Medizingeräte ist, müssen Sie die Dokumentation der Architektur Ihres Medizingeräts genau definieren. Das ist kein Hexenwerk, und später werde ich erklären, wie man mit der Unklarheit dieser Norm umgehen kann. Natürlich hängt dies alles von der Klassifizierung und der Komplexität des Medizingeräts ab.

Der wichtigste Punkt ist, dass die Softwarearchitektur auf den Anforderungen basieren sollte. Das bedeutet, dass Sie zuerst analysieren müssen, welche Funktionen Ihr Gerät erfüllen soll, bevor Sie spezifizieren, wie dies technisch umgesetzt wird. Mindestens sollte die Softwarearchitektur die verschiedenen Softwarekomponenten identifizieren und deren Interaktionen beschreiben. Dazu gehören Schnittstellen wie physische Verbindungen oder drahtlose Kommunikation (Bluetooth, TCP/IP, MQTT usw.).

Beispiel eines High-Level-Designs

 

Risikomanagement

IEC 62304 erfordert ein robustes Risikomanagement. Die Norm steht in engem Zusammenhang mit ISO 14971, dem international anerkannten Standard für das Risikomanagement von Medizingeräten. Entwickler müssen:

 

• Potenzielle Gefahren im Zusammenhang mit der Software identifizieren.
• Risiken bewerten und analysieren.
• Maßnahmen zur Risikominderung implementieren.
• Alle risikobezogenen Aktivitäten und Ergebnisse dokumentieren.

Dieser strukturierte Risikomanagementansatz ermöglicht es, neu auftretende Risiken frühzeitig zu erkennen und zu reduzieren, wodurch gefährliche Situationen vermieden werden. Das Risikomanagement bildet die Grundlage für die Klassifizierung der Software.

 

IEC 62304 Softwareentwicklungsprozess

Die IEC 62304 verlangt, dass der Entwicklungsprozess für medizinische Softwaresysteme aus mehreren wichtigen Lebenszyklusanforderungen besteht:

 

Planung

Eine effektive Planung bildet die Grundlage für ein erfolgreiches Projekt. In dieser Phase definieren Teams den Umfang der Software, ihre vorgesehene Nutzung, die erforderliche Sicherheitsklassifizierung und die Aktivitäten, die zur Einhaltung der IEC 62304 erforderlich sind. Durch detaillierte Projektpläne, Ressourcenallokation und Zeitpläne werden klare Erwartungen für Stakeholder und Entwickler geschaffen.

 

Anforderungsanalyse

Nach der Planungsphase geht es an die Erstellung der Anforderungen. Diese sollten:

 

• Nachvollziehbar zu den Benutzeranforderungen und Risikokontrollen sein.
• Klar und begründet sein.
• Vor der weiteren Entwicklung geprüft und genehmigt werden.

Anforderungen betreffen nicht nur Funktionen – sie umfassen verschiedene Aspekte wie Sicherheit, Benutzerfreundlichkeit, Leistung und Compliance. Funktionale Anforderungen beschreiben Features, während nicht-funktionale Anforderungen Aspekte wie Performance, UX/UI und Sicherheit abdecken.

 

Architekturdesign

Die Architekturdesign-Phase definiert die übergeordnete Struktur der Software, einschließlich der Komponenten, Interaktionen und des Datenflusses. Dieser Schritt stellt sicher, dass die Software modular, skalierbar und sicherheits- sowie leistungsorientiert entwickelt wird. Die Architektur wird dokumentiert, um die Rückverfolgbarkeit zu gewährleisten und Risikobewertungen zu ermöglichen. So kann sichergestellt werden, dass kritische Systemteile (z. B. Fehlertoleranz und Redundanz) angemessen berücksichtigt werden.

 

Detailliertes Design

In der Phase des detaillierten Designs werden die Architekturkomponenten in Softwaremodule verfeinert. Dabei werden die interne Logik, Datenstrukturen und Interaktionen der einzelnen Module definiert. Sicherheitsmechanismen, Fehlerbehandlung und Cybersicherheitsmaßnahmen sind ebenfalls Bestandteil dieses Prozesses. Durch eine umfassende Dokumentation wird sichergestellt, dass die Software sowohl funktionale als auch regulatorische Anforderungen erfüllt.

 

Implementierung

Die Implementierungsphase umfasst das Schreiben und Kompilieren des Quellcodes gemäß dem genehmigten Design. In dieser Phase halten sich Entwickler in der Regel an Codierungsstandards und bewährte Praktiken für die Medizingerätebranche. Code-Reviews, statische Analysen und Integrationsprüfungen helfen, die Qualität zu gewährleisten und potenzielle Sicherheitsrisiken frühzeitig zu identifizieren.

 

Testen und Validierung

Während die Verifizierung sicherstellt, dass die Software die definierten Anforderungen erfüllt, bestätigt die Validierung, dass sie in realen Anwendungsszenarien korrekt funktioniert. Der Umfang der Tests hängt von der Sicherheitsklassifizierung ab:

 

• Unit-Tests für einzelne Softwarekomponenten.
• Integrationstests, um sicherzustellen, dass die Module korrekt zusammenarbeiten.
• Systemtests, um die gesamte Funktionalität mit den Anforderungen abzugleichen.
• Benutzerakzeptanztests (UAT), um das Verhalten der Software unter realen Bedingungen zu überprüfen.

Alle diese Testaktivitäten müssen dokumentiert werden, um die regulatorischen Anforderungen zu erfüllen.

 

Freigabe und Wartung

Auch nach der finalen Softwarefreigabe muss das Medizingerät kontinuierlich überwacht und gewartet werden. IEC 62304 legt besonderen Wert auf:

 

• Überwachung nach der Markteinführung: Sammeln von Nutzerfeedback und Fehlerberichten, um neue Risiken frühzeitig zu erkennen.
• Korrektur- und Vorbeugemaßnahmen: Behebung von Problemen, bevor sie kritisch werden.
• Updates und Patches: Behebung von Sicherheitslücken, Anpassungen an regulatorische Änderungen und Verbesserungen der Benutzerfreundlichkeit.

 

IEC 62304:2006 Softwareentwicklungsprozess

 

Wie entwickelt man Software für Medizingeräte, ohne den Verstand zu verlieren?

Auf den ersten Blick kann es überwältigend erscheinen, Prozesse gemäß IEC 62304:2006 zu implementieren. Man sitzt da und weiß nicht, wo man anfangen soll. Bevor Sie an Ihrer Berufswahl zweifeln, lassen Sie mich erklären, warum der formale Teil der Entwicklung von Medizingeräte-Software so komplex ist – und wie man ihn bewältigt.

Ich muss zugeben, dass selbst nach Jahren in der Embedded-Software-Entwicklung jedes Projekt eine Herausforderung bleibt. Unternehmen haben Schwierigkeiten, Softwarearchitekturen zu entwerfen, UX/UI-Designs und Gerätekonzeptionen zu entwickeln, die Elektronik zu implementieren, robuste Tests durchzuführen – und wenn dann noch regulatorische Anforderungen, Analysen und Risikomanagementmaßnahmen hinzukommen… dann denken manche, es lohnt sich gar nicht erst anzufangen. Das eigentliche Problem ist jedoch nicht nur der Arbeitsaufwand (der je nach Gerät variiert), sondern vor allem die Unvertrautheit mit der Norm. Genau aus diesem Grund habe ich diesen Artikel geschrieben.

Meine Lösung für dieses Problem: Nehmen Sie an Schulungen teil und machen Sie diese gemeinsam mit den wichtigsten Personen in Ihrem Team. So haben alle zumindest ein grundlegendes Verständnis der Norm. Ich habe bereits erlebt, dass einzelne Personen nach einer Schulung erfolgreich die gesamte Dokumentation eigenständig erstellt haben. Falls Ihnen die Zeit oder das Fachwissen fehlt oder Sie einfach einen erfahrenen Partner suchen, sollten Sie die Zusammenarbeit mit Softwareberatern in Erwägung ziehen, die sich mit der Entwicklung von Medizingeräte-Software auskennen.

Ein weiteres Problem der IEC 62304 ist, dass die Entwicklungspraktiken in anderen Branchen oft unterschiedlich sind. Viele Entwickler, Softwareingenieure und Manager sind nicht an den Entwicklungsprozess gewöhnt, den die Norm vorschreibt. Mit all den Anforderungen, Risikobewertungen und Planungen, die zuerst erledigt werden müssen, erscheint das Wasserfallmodell als natürlicher Ansatz für die Softwareentwicklung. Doch viele Entwickler, die nicht aus der Medizintechnik stammen, bevorzugen agile Methoden. Die Norm schreibt vor, dass insbesondere für sicherheitskritische Systemelemente ein detailliertes Design vorab erforderlich ist, doch in der Praxis weiß man oft nicht von Anfang an, wie bestimmte Features umgesetzt werden sollen.

Meine Empfehlung: Eine gute Planung zahlt sich aus. Sobald Sie lernen, wie es richtig gemacht wird, werden Sie den Nutzen erkennen. Sie sollten Ihre Ingenieure frühzeitig einbeziehen, damit sie – auch wenn sie noch nicht genau wissen, wie eine Funktion implementiert werden soll – bereits Machbarkeitsstudien und Tests durchführen können. Und vergessen Sie nicht: Nichts ist in Stein gemeißelt. Dokumente können und sollen überarbeitet werden, solange die Nachvollziehbarkeit gewährleistet bleibt.

Ein agiler Entwicklungsprozess kann auch innerhalb der IEC 62304 umgesetzt werden. Sie können nach und nach Versionen Ihres Medizingeräts erstellen, diese Stakeholdern präsentieren und Feedback einholen, bevor Sie mit der nächsten Funktionalität fortfahren.

 

 

Sichere medizinische Software entwickeln: Wählen Sie einen Entwicklungspartner, der Effizienz in den Mittelpunkt stellt

Die Wahl des richtigen Entwicklungspartners kann den entscheidenden Unterschied für Ihre IEC-62304-Compliance machen. Wenn Ihnen das wirklich wichtig ist – und das sollte es –, dann suchen Sie nach einem Team, das:

 

• Erfahrung mit Medizingeräte-Software hat: Sie sollten sich mit klinischen Abläufen, Patientensicherheit und regulatorischen Anforderungen auskennen.
• Vorgefertigte Komponenten bietet: Softwarebibliotheken, bevorzugte Hardwareplattformen, Templates und Know-how, um Ihr Projekt schneller voranzutreiben.
• Eine nachweisbare Erfolgsbilanz hat: Referenzen oder Fallstudien zu IEC-62304-Projekten.
• Ein integriertes Qualitätsmanagementsystem (QMS) nutzt: Zum Beispiel ISO 13485.