Startseite > Medizintechnik > E-Health > Strategien zur Vermeidung von IEC 62304 Klasse C

Entwicklung medizinischer Software

Strategien zur Vermeidung von IEC 62304 Klasse C

3. Juni 2024, 10:19 Uhr | Ein technischer Kommentar von Bernd Seidenspinner und Miriam Schulze, Bayoomed

Wie läßt sich die IEC 62304 Klasse C bei der Entwicklung von Medizinischer Software vermeiden? Ein eher ungewöhnliches Bild von den beiden Autoren Miriam Schulze und Bernd Seidenspinner.

Eine zentrale Norm der medizinischer Softwareentwicklung ist die IEC 62304, sie regelt den Software-Lebenszyklus für medizinische Geräte. Um die strengen Anforderungen zu erfüllen und gleichzeitig Software effizient und flexibel zu entwickeln, helfen Strategien wie Modularisierung und Segregation.

▶ Diesen Artikel anhören

Segregation in der Softwareentwicklung

Segregation bezeichnet die Aufteilung eines Softwaresystems in verschiedene Softwareeinheiten, die separat klassifiziert und behandelt werden können. Laut IEC 62304 müssen diese Einheiten die Sicherheitsklassifizierung des ursprünglichen Softwaresystems übernehmen, es sei denn, der Hersteller dokumentiert eine nachvollziehbare Begründung für eine abweichende Klassifizierung. Diese muss darlegen, wie die neuen Softwareeinheiten getrennt sind, um zu verhindern, dass niedriger klassifizierte Einheiten, solche mit größerem Risiko für Patient:innen beeinflussen.

Die Norm fordert, dass Hersteller die notwendigen Segregationen für die Risikokontrolle identifiziert und sicherstellt, dass diese wirksam sind.

Modularisierung: Ein flexibler Ansatz

Modularisierung ist ein Konzept, das eng mit der Segregation verbunden ist, jedoch einen breiteren Ansatz verfolgt. Die Modularisierung ermöglicht es, medizinische Software in verschiedene Module aufzuteilen, von denen einige medizinische Zwecke erfüllen und andere nicht. Module, die den medizinischen Vorschriften unterliegen (FDA: device functions), müssen diese erfüllen, während nicht-medizinische Module (FDA: other functions) davon ausgenommen sind.

Die MDCG-2019-11 und die FDA-Richtlinien bieten Hinweise zur Modularisierung. Die FDA-Richtlinie »Content of Premarket Submissions for Device Software Functions«, vom 14. Juni 2023, liefert Informationen, wie »multiple function device products« auf Dokumentationsebene behandelt werden sollten. Es ist wichtig zu beachten, dass die Modularisierung nicht gleichbedeutend mit der Segregation gemäß IEC 62304 ist. Das Konzept der Segregation gibt es bei der FDA nicht: Das »documentation level« ist für die gesamte Software gleich, somit sind die Zielmärkte ein entscheidender Faktor bei der Auswahl der Strategie.

Anwendung der Modularisierung

Unsere Erfahrung zeigt, dass der FDA-Ansatz praktikabler ist, da zunächst Funktionen identifiziert und erst später im Designprozess den Modulen zugeordnet werden. Dies verhindert, dass wichtigen Architekturentscheidungen durch eine frühe Zerlegung vorgegriffen wird.

Ebenfalls sollte nicht zu feingranular unterteilt werden. Im ersten Schritt sollten Funktionen identifiziert werden, die für sich genommen bereits eine eigene Software sein könnten. Hierfür werden die Stakeholder Requirements herangezogen.
Es folgt die Klassifizierung in medizinische und nicht-medizinische Funktionen (FDA: device functions/other functions) anhand der Zweckbestimmung sowie der MDCG bzw. FDA-Richtlinien.
Danach werden die Funktionen einzelnen Modulen in der Architektur zugeordnet. Aus dieser Zuordnung lassen sich Abhängigkeiten zwischen Modulen erkennen.
Basierend auf Architektur und Klassifizierung erfolgt eine erste Risikoanalyse, die die Abhängigkeiten und möglichen Wechselwirkungen zwischen den medizinischen und nicht-medizinischen Modulen betrachtet.

Das Resultat kann eine Kombination aus Maßnahmen, die in medizinischen Modulen umgesetzt werden müssen, Änderungen an der Architektur oder Änderungen an der Klassifizierung sein.

Herausforderungen und Überlegungen

Bei der Implementierung von Modularisierung und Segregation müssen verschiedene Faktoren berücksichtigt werden – nicht zuletzt, ob das eigene QMS die erforderlichen Prozesse abdecken kann. Auch die Frage »nach welchem Prozess werden nicht-medizinische Module entwickelt?«, muss beantwortet werden.

Beim Change Management ist zu berücksichtigen, dass dieses immer alle Änderungen (auch an nicht-medizinischen Modulen) erfassen muss. Eine Änderung kann aus einem nicht-medizinischen Modul ein medizinisches Modul machen.

Eine Cybersecurity-Analyse ist immer auf das gesamte System anzuwenden. Hier sind die Vorgaben der FDA eindeutig. Nach unserer Auffassung ist eine Beschränkung auf medizinische Module unzulässig, denn es muss das Gesamtsystem betrachtet werden, um Cybersecurity wirklich zu gewährleisten.

Trennung und Dokumentation der Software-Teile

Modularisierung und Segregation bieten vielversprechende Ansätze, um den Anforderungen der IEC 62304 und FDA gerecht zu werden und gleichzeitig die Effizienz und Flexibilität der Softwareentwicklung zu verbessern. Durch eine Trennung und Dokumentation der Softwareeinheiten können Hersteller die Sicherheit und Zuverlässigkeit ihrer Produkte gewährleisten, den Entwicklungsprozess optimieren, die Markteinführungszeit verkürzen und agiler mit Änderungen an nicht-medizinischen Modulen umgehen. Die richtige Anwendung dieser Strategien erfordert jedoch sorgfältige Planung und kontinuierliche Risikobewertung, um den hohen Standards der medizinischen Softwareentwicklung gerecht zu werden. (uh)