App or Software Development
Olivier Le Moal / stock.adobe.com
27.09.2019 Fachinformation 1281 0

Software Lebenszyklus bei Medizinprodukten: Wie Sie IEC 62304 und 82304-1 umsetzen

Die europäische Medizinprodukteverordnung (Medical Device Regulation 2017/745, „MDR“) verpflichtet Hersteller, den Software Lebenszyklus von Medizinprodukten zu betrachten. Wollen Hersteller diese Anforderung praktisch umsetzen, sind 2 Normen besonders wichtig: die IEC 62304 und die IEC 82304-1. In diesem Beitrag erörtern wir, was Hersteller bei der Betrachtung des Software Lebenszyklus beachten müssen und wie beide 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 verbreitete Betrachtungskonzept 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 Medizinprodukteverordnung 4 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, 11, MDR).
  • Der Hersteller muss ein kontinuierliches Risikomanagement während des gesamten Lebenszyklus des Produkts durchführen (Anhang I, 3, MDR).
  • Der Hersteller muss ein Qualitätsmanagementsystem einrichten und während des gesamten Lebenszyklus des Produktes pflegen (Anhang IX, 1, 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, 1, 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, 17.2, MDR).

Offensichtlich bleibt das Gesetz recht unscharf in seinen Formulierungen. Wie können Hersteller die gesetzlichen Anforderungen nun „praktisch“ erfüllen? Und: Wann genau ist man Hersteller und damit „Betroffener“?

Was ist ein Medizinprodukt?

Wenn Hersteller eine Software als Medizinprodukt entwickeln und vermarkten wollen, müssen Sie die zuvor genannten gesetzlichen Auflagen erfüllen und werden zum „Betroffenen“. Was genau ein Medizinprodukt ist, gibt ebenfalls die europäische Medizinprodukteverordnung vor. Sie definiert Medizinprodukte in erster Linie nach ihren Anwendungsgebieten (Artikel 2, 1, MDR). Diese sind:

  • Diagnose, Verhütung, Überwachung, Vorhersage, Prognose, Behandlung oder Linderung von Krankheiten,
  • Diagnose, Überwachung, Behandlung, Linderung von oder Kompensierung von Verletzungen oder Behinderungen,
  • Untersuchung, Ersatz oder Veränderung der Anatomie oder eines physiologischen oder pathologischen Vorgangs oder Zustands und
  • Gewinnung von Informationen durch die In-vitro-Untersuchung von aus dem menschlichen Körper, auch aus Organ-, Blut- und Gewebespenden stammenden Proben.

Darüber hinaus sind Produkte zur Empfängnisverhütung oder -förderung sowie zur Reinigung, Desinfektion oder Sterilisation Medizinprodukte im Sinne des Gesetzgebers.

Medizinische Geräte müssen zudem für den Menschen bestimmt sein. Außerdem ist das Wirkprinzip wichtig. Medizinprodukte wirken im oder am menschlichen Körper, jedoch nicht pharmakologisch, metabolisch oder immunologisch.

Ist Software ein Medizinprodukt?

Software kann ein Medizinprodukt sein, wenn sie einen medizinischen Zweck hat. Die Medizinprodukteverordnung weist neben Geräten, Instrumenten, Apparaten usw. ausdrücklich auf Software hin. Allerdings definiert sie Software nicht. Unser Fachbeitrag zum Thema „Stand-alone-Software als Medizinprodukt“ enthält eine detaillierte Erläuterung zur Frage der Definition von Software.

Insgesamt macht der Gesetzestext klar, dass medizinische Software mehr können muss, als „nur“ suchen, speichern, archivieren oder übermitteln. Sie interpretiert insbesondere Daten und hilft, Diagnosen zu stellen und Therapien einzuleiten. Daraus folgt zum Beispiel, dass Patientendaten-Managementsysteme, Krankenhausinformationssysteme oder medizinische Lern- und Lehrprogramme keine Medizinprodukte sind.

Wie setze ich die gesetzlichen Anforderungen zum Software Lebenszyklus von Medizinprodukten um?

Die Medizinprodukteverordnung 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 Normen.

IEC 62304

Für die Betrachtung des Software Lebenszyklus kommt hier zu allererst die Norm „Medizingeräte-Software - Software-Lebenszyklus-Prozesse" (IEC 62304) in Betracht. Die Norm beschreibt Lebenszyklus-Prozesse 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 „zentrale Elektromedizin-Norm“ 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.

Wie hilft mir die Norm IEC 62304?

Die IEC 62304 beschreibt als Prozessnorm 5 grundlegende Softwareprozesse:

  • Entwicklung
  • Wartung
  • Risikomanagement
  • Konfiguration
  • Problemlösung

Der Software-Entwicklungsprozess

Am Anfang der Softwareentwicklung erfolgt zunächst eine Planung. Dazu formuliert der Hersteller einen detaillierten Softwareentwicklungsplan, den er je nach Entwicklungsfortschritt aktuell halten muss.

Im Anschluss analysiert der Hersteller die Software-Anforderungen. 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 enthält 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 einen Fehler enthält, sind im Gegensatz zu einem physischen Medizinprodukt stets alle Kopien dieser Version der Software von diesem Fehler betroffen.

Kontakt

Florian Schlögel
„Softwarefehler sind immer systematische Fehler.“
Hans Wenner (Ingenieurbüro Wenner, Rüsselsheim)


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.

Die IEC 62304 fordert darüber hinaus 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.

Wie hilft mir die Norm 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.

Wie hilft mir die Norm IEC 60601-1?

Die Norm 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 Norm 60601-1 schlägt im Anhang H ein Modell eines Entwicklungslebenszyklus für PEMS vor. Das Modell orientiert sich am etablierten 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 Norm 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 Norm 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.

Was ist neu?

Wenn Hersteller von Medizinproduktesoftware die gesetzlichen Anforderungen aus der Medizinprodukteverordnung erfüllen wollen, sind harmonisierte europäische Normen besonders geeignet. 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.

Empfehlung

Wir empfehlen Herstellern von medizinischer Software, sich im Detail mit der praktischen Anwendung der Normen IEC 62304 und IEC 82304-1 zu befassen, um die gesetzlichen Anforderungen erfüllen zu können. Dabei können Veranstaltungen und Fachliteratur helfen.