Die europäische Medizinprodukteverordnung (MDR) verpflichtet Hersteller, den Software Lebenszyklus von Medizinprodukten zu berücksichtigen. Wollen Hersteller diese Anforderung praktisch umsetzen, sind 3 Normen besonders wichtig. In diesem Beitrag erörtern wir, was Hersteller bei der Betrachtung des Software Lebenszyklus beachten müssen und wie die Normen konkret dabei helfen.
Was ist ein Software Lebenszyklus bei Medizinprodukten?
Der Lebenszyklus eines Produktes beschreibt einen Prozess von der Produktidee bis zur Marktherausnahme. Dieses Konzept findet auch bei Software als Medizinprodukt Anwendung. Der europäische Gesetzgeber verpflichtet Hersteller, die Prinzipien des Produktlebenszyklus zu berücksichtigen.
Konkret finden sich in der MDR vier direkte Verweise auf den Lebenszyklus von Medizinprodukten:
- Der Hersteller muss die klinische Bewertung und die dazugehörigen Unterlagen während des gesamten Lebenszyklus des Produkts aktuell halten (Artikel 61, MDR).
- Der Hersteller muss ein kontinuierliches Risikomanagement während des gesamten Lebenszyklus des Produkts durchführen (Anhang I, MDR).
- Der Hersteller muss ein Qualitätsmanagementsystem einrichten und während des gesamten Lebenszyklus des Produktes pflegen (Anhang IX, MDR).
- Der Hersteller muss eine Baumusterbewertung bei einer Benannten Stelle beantragen, aus der hervorgeht, dass das Produkt während des gesamten Lebenszyklus den Bestimmungen der Medizinprodukteverordnung entspricht (Anhang X, MDR).
Ein weiterer 5. Verweis bezieht sich ausdrücklich auf Software als Medizinprodukt. Dort heißt es:
- „Bei Produkten, zu deren Bestandteilen Software gehört, oder bei Produkten in Form einer Software wird die Software entsprechend dem Stand der Technik entwickelt und hergestellt, wobei die Grundsätze des Software Lebenszyklus, des Risikomanagements einschließlich der Informationssicherheit, der Verifizierung und der Validierung zu berücksichtigen sind“ (Anhang I, MDR).
Wie setze ich die gesetzlichen Anforderungen zum Software Lebenszyklus von Medizinprodukten um?
Die MDR definiert im Anhang I die grundlegenden Anforderungen an Sicherheit und Leistungsfähigkeit von Medizinprodukten. Möchte ein Hersteller eine Software als Medizinprodukt vermarkten, muss er nachweisen, dass er diese Anforderungen erfüllt.
Zur praktischen Umsetzung helfen ihm insbesondere die folgenden 3 Normen:
IEC 62304
Für die Betrachtung des Software Lebenszyklus kommt hier zu aller erst die Norm „Medizingeräte-Software – Software-Lebenszyklus-Prozesse” (IEC 62304) in Betracht. Die Norm beschreibt Anforderungen an einen Lebenszyklus-Prozess und ordnet ihnen bestimmte Aktivitäten und Aufgaben zu.
Sie gilt für die Entwicklung und Wartung von medizinischer Software. Dabei spielt es keine Rolle, ob die Software selbst ein Medizinprodukt ist oder ob sie als eingebetteter oder integraler Bestandteil eines Medizinprodukts Verwendung findet.
Die Anwendung der Norm setzt voraus, dass der Hersteller seine Software als Teil eines Qualitätsmanagement- und Risikomanagement-Systems entwickelt und pflegt.
IEC 82304-1
Eine weitere Norm „Gesundheitssoftware – Allgemeine Anforderungen an die Produktsicherheit” (IEC 82304-1) ist ebenfalls wichtig. Sie bezieht sich auf Fragen zu Sicherheit und Risiken von Software, die hardwareunabhängig („eigenständig“) vermarktet werden soll („Stand-alone-Software“, „Health Apps“).
Dabei kann eine Health App auch ein Medizinprodukt sein. Die Norm beschreibt die Anforderungen an Hersteller und deckt den gesamten Lebenszyklus ab. Dies umfasst Design, Entwicklung, Validierung, Installation, Wartung und Entsorgung.
Damit ist der Anwendungsbereich umfassender im Vergleich zu dem der IEC 62304. Die Norm beschreibt auch übergeordnete Anforderungen, die über die reine Softwareentwicklung hinausgehen. Es gibt zudem einen erkennbaren Fokus auf Security.
IEC 60601-1
Neben den beiden oben genannten Normen spielt die Norm „Medizinische elektrische Geräte – Teil 1: Allgemeine Festlegungen für die Sicherheit einschließlich der wesentlichen Leistungsmerkmale (IEC 60601-1)“ als grundlegende Norm für medizinische elektrische Geräte eine Rolle.
Das Kapitel 14 befasst sich mit „Programmierbaren elektrischen medizinischen Systemen (PEMS)“ und gibt den allgemeinen Rahmen für eine Lebenszyklusbetrachtung medizinischer Software vor.
Gegenwärtig befindet sich eine 2. Version der IEC 62304 in Abstimmung. Ziel dieser Normentwicklung ist es, einen einheitlichen Rahmen für alle Softwaretypen zu schaffen. Insgesamt lassen sich eigenständige oder gerätezugehörige Software mit jeweils medizinischer oder (lediglich) gesundheitsbezogener Zweckbestimmung differenzieren, die jeweils auf einer spezifischen oder allgemeinen Hardwareplattformen in Betrieb sind.
Was beschreibt die IEC 62304?
Die IEC 62304 beschreibt als Prozessnorm 5 grundlegende Anforderungen an Softwareprozesse:
- Entwicklung
- Wartung
- Risikomanagement
- Konfiguration
- Problemlösung
Zunächst fordert die IEC 62304 Hersteller auf, die Risiken ihrer medizinischen Software zu klassifizieren. Dazu gibt die Norm ein 3-Klassen-Modell vor, dass aus den Sicherheitsklassen A, B und C besteht. Die Sicherheitsklassen richten sich nach dem Beitrag der Software zu einer Gefährdungssituation. Hersteller wenden die oben dargestellten Prozesse in Abhängigkeit von der jeweiligen Sicherheitsklasse an.
Der Software-Entwicklungsprozess
Nachdem die Software-Sicherheitsklasse festgelegt wurde, erfolgt die Planung der Softwareentwicklung. Auf Basis der Software-Sicherheitsklasse formuliert der Hersteller einen detaillierten Software-Entwicklungsplan aus Aufgaben und Aktivitäten, den er je nach Entwicklungsfortschritt aktuell halten muss.
Im Anschluss analysiert der Hersteller die Softwareanforderungen. Dies beinhaltet beispielsweise Merkmale wie Zeitverhalten, Betriebssystem, Speichergröße, Voreinstellungen, Schnittstellen, Authentifizierung, Netzwerkprotokolle und vieles mehr.
Der Hersteller muss dann eine geeignete Software-Architektur designen und nachfolgend beschreiben, wie er die Software implementieren und integrieren will.
Die IEC 62304 erläutert die Anforderungen an die Software-Architektur im Detail. Diese umfassen etwa Schnittstellen zwischen Komponenten und spezielle Anforderungen an „unbekannte“ Software-Komponenten. Die Norm bezeichnet solche Komponenten als SOUP, „Software Of Unknown Provenance” oder „Off-The-Shelf-Software“. Es handelt sich dabei um allgemein verfügbare Software, die nicht für das jeweilige Medizinprodukt entwickelt wurde.
Aus Sicht des Risikomanagements bestehen bei SOUP naturgemäß besondere Herausforderungen. Es ist daher nicht überraschend, dass sich im Entwicklungsprozess auch eine Darstellung zur Softwareprüfung findet. Der Software-Entwicklungsprozess schließt mit Angaben zur Dokumentation und Archivierung ab.
Der Software-Wartungsprozess
Der Software-Wartungsprozess beginnt mit einer Wartungsplanung, die beispielsweise Verfahren für Empfang, Dokumentation und Rückverfolgung umfasst.
Die IEC 62304 fordert dann eine systematische Analyse von Problemen und Änderungen, die in Zusammenhang mit der Softwareanwendung aufgetreten sind. Hier ist unter anderem eine entsprechende Kommunikation mit Anwendern und zuständigen Behörden vorgesehen. Abschließend beschreibt die Norm, wie Änderungen umgesetzt und geordnet freigegeben werden müssen.
Der Software-Risikomanagement-Prozess
Das Risikomanagement fordert wenig überraschend zunächst eine Gefährdungsanalyse. Im Mittelpunkt stehen Komponenten, die zu einer Gefährdungssituation beitragen könnten, sowie deren Ursachen.
Dabei ist zu beachten, dass es bei Software keine zufälligen Fehler geben kann, wie sie etwa bei physischen Medizinprodukten aufgrund einer minderwertigen Qualität eines gelieferten und verarbeiteten Materials oder durch Fehler aufgrund von Unaufmerksamkeit von Mitarbeitern in der Produktion vorkommen können.
Wenn eine Software ein Fehler enthält, sind im Gegensatz zu einem physischen Medizinprodukt alle Kopien dieser Version der Software von diesem Fehler betroffen. Softwarefehler sind daher immer systematische Fehler.
Auch hier spielt SOUP wieder eine herausgehobene Rolle, denn die Norm fordert ausdrücklich eine Evaluation öffentlich verfügbarer Listen mit „SOUP-Anomalien“.
An die Gefährdungsanalyse schließt sich eine Betrachtung von Maßnahmen zur Risikobeherrschung, deren Verifizierung sowie Rückverfolgbarkeits-Dokumentation an. Hersteller sollen auch die Risiken von Softwareänderungen explizit betrachten und organisieren.
Der Software-Konfigurationsmanagement-Prozess
Die IEC 62304 überlässt die „richtige“ Konfiguration der medizinischen Software nicht dem Zufall. Eine detaillierte Aufschlüsselung von Identifikations-, Dokumentations- und Genehmigungsschritten sorgt dafür, dass der Hersteller eine bestmögliche Konfiguration finden, anpassen und rückverfolgen kann. Der Prozess beinhaltet wiederum eine besondere Betrachtung von SOUP.
Der Software-Problemlösungsprozess
Die Norm fordert, dass der Hersteller Probleme, die in Zusammenhang mit der Anwendung medizinischer Software auftreten, berichtet, untersucht und beteiligte Stellen unterrichtet. Der Hersteller soll auch alle Aufzeichnungen aufbewahren und überdies eine Trendanalyse zu Softwareproblemen erstellen. Der Prozess schließt mit einer Prüfungsdokumentation ab.
Was beschreibt die IEC 82304-1?
Die Norm beschreibt zunächst eine Reihe von Anforderungen an Health Apps:
- Risikomanagement-Anforderungen (z. B. in Bezug auf die Zweckbestimmung und das Nutzerprofil),
- Nutzeranforderungen (z. B. in Bezug auf Informationssicherheit und Software-Support) und
- Systemanforderungen (z. B. in Bezug auf Interoperabilität und Performance).
Es folgt eine Betrachtung des Software Lebenszyklus-Prozesses. Dabei bezieht sich die Norm unmittelbar auf die IEC 62304.
Zudem beschreibt die IEC 82304-1 die Validierung von Health Apps und leitet Hersteller an, entsprechende Begleitpapiere zu formulieren. Die Begleitpapiere sollten u.a. folgende Inhalte aufgreifen:
- Bedienungsanleitung mit Beschreibung der Health App
- Sicherheitswarnungen
- Installationsanleitung
- Einschalt- und Abschaltprozeduren
- Bedienungshinweise
- Benachrichtigungen
- Außerbetriebnahme
- technische Beschreibung, etwa für die Netzwerkintegration
Abschließend formuliert die Norm Rahmenbedingungen für alle Aktivitäten des Herstellers nach Inverkehrbringen einer Health App. Dies schließt natürlich eine entsprechende Wartung und Pflege der Software ein sowie die Re-Validierung und geordnete Außerbetriebnahme am Ende des Lebenszyklus.
Wichtig sind auch definierte Prozesse, wenn es darum geht, etwaige Fehler oder Probleme zu dokumentieren und an die zuständigen Behörden zu kommunizieren.
Was beschreibt die IEC 60601-1?
Die IEC 60601-1 ergänzt in Kapitel 14 die vorhandenen Anforderungen zum Risikomanagementprozess und zur Lebenszyklusbetrachtung um erforderliche Aspekte medizinischer Software (Programmierbare elektrische medizinische Systeme, PEMS).
Dies beinhaltet Ergänzungen zu folgenden PEMS-Aspekten:
- Dokumentation
- Risikomanagement-Plan
- Entwicklungslebenszyklus
- Problemlösung
- Risikomanagementprozess
- Anforderungsspezifikation
- Architektur
- Design und Ausführung
- Verifizierung
- Validierung
- Modifikation
- Einbindung in IT-Netzwerke
Die IEC 60601-1 schlägt im Anhang H ein Modell eines Entwicklungslebenszyklus für PEMS vor. Das Modell orientiert sich am V-Modell für Softwareentwicklung und gliedert sich in einen Zerlegungs- und einen Integrationsprozess.
Beginnend mit den Anwenderbedürfnissen beschreibt das Modell in schichtenartiger Darstellung unterschiedliche Software-Spezifikations- und Entwicklungsschritte, die nachfolgend für die Software-Verifizierung und Validierung zusammengeführt werden. Das Modell setzt die einzelnen Schritte in Bezug zum Risikomanagement.
Dabei erweitert die IEC 60601-1 den Risikomanagementprozess um softwarespezifische Aspekte, insbesondere in Bezug auf Daten, wie z. B.:
- Datenverfügbarkeit,
- Datenintegrität,
- Datenfehler,
- Datenzeitzuordnung oder
- Datensicherheit.
Die Einbindung von Software in IT-Netzwerke erfordert naturgemäß besondere Vorkehrungen in Sachen Sicherheit und Risikomanagement. Die IEC 60601-1 greift diesen Aspekt explizit auf.
Die Norm fordert beispielsweise, den Zweck der Einbindung, die Merkmale und die Konfiguration des Netzwerks zu dokumentieren. Zudem soll der Inverkehrbringer den Nutzer der Software auf die entstehenden Risiken hinweisen, die durch die Netzwerkeinbindung entstehen.
Fazit
Wenn Hersteller von Medizinproduktesoftware die gesetzlichen Anforderungen aus der Medizinprodukteverordnung erfüllen wollen, ist die Anwendung harmonisierter europäischer Normen eine wichtige Möglichkeit.
Kürzlich wurde von der EU Kommission eine Liste von Normen veröffentlicht, die harmonisiert werden sollen. Die Liste enthält die neue Ausgabe der IEC 62304. Allerdings findet sich in der Liste nicht die IEC 82304-1. Möglicherweise ist die Harmonisierung nicht vorgesehen. Das wäre vor allem für Hersteller von eigenständiger medizinischer Software ein Nachteil.
Wir empfehlen Herstellern von medizinischer Software, sich im Detail mit der praktischen Anwendung der Normen IEC 62304, IEC 82304-1 und IEC 60601-1 zu befassen, um die gesetzlichen Anforderungen erfüllen zu können.
_____________________________________________________________________________________________
Updates zum aktuellen Stand des Software-Lebenszyklus-Standard IEC 62304:
Zukunft von Software-Lebenszyklus-Standard IEC 62304 ungewiss (12.04.2021)
Update: Zukunft des Software-Lebenszyklus-Standards IEC 62304 (26.04.2021)
_____________________________________________________________________________________________
