Software übernimmt immer mehr Aufgaben in der Medizintechnik, Doch wie stellen Hersteller sicher, dass sie regulatorisch auf der sicheren Seite sind? Ob Dokumentenmanagement, Prozessüberwachung oder Rückverfolgbarkeit: Software, die im Qualitätsmanagementsystem (QMS) oder der Produktion von Medizinprodukten verwendet wird, unterliegt strengen Anforderungen. Die ISO 13485 und die FDA verlangen eine Validierung – aber was heißt das konkret? Wann reicht eine pragmatische Lösung, wann ist Tiefgang gefragt? In diesem Beitrag beleuchten wir die Anforderungen an die Validierung von Software im Kontext von QM-Systemen, zeigen typische Herausforderungen und geben Impulse, wie Sie mit einem risikobasierten Ansatz Aufwand und Compliance unter einen Hut bringen.
Die Validierung von Software ist in der Medizintechnik kein "Nice-to-Have" - sie ist Pflicht, unter bestimmten Bedingungen.
Mit fortschreitender Digitalisierung werden nach und nach Aufgaben und Prozesse von Software durchgeführt. So auch bei der Herstellung von Medizinprodukten. In dieser Umgebung verwendete Software fällt unter den Geltungsbereich des Qualitätsmanagementsystems (QMS) des Herstellers. Ziel der Validierung der Software ist es, durch objektive Nachweise zu belegen, dass die Software für den vorgesehenen Zweck geeignet ist und die regulatorischen Anforderungen erfüllt.
Die ISO 13485:2016 fordert in mehreren Kapiteln (u. a. 4.1.6, 7.5.6, 7.6) ein dokumentiertes Verfahren für die Validierung eingesetzter Computersoftware. Auch die FDA verlangt im 21 CFR 820.70(i), dass Software vor der ersten Nutzung und nach Änderungen validiert wird: risikobasiert und umfassend dokumentiert. Hersteller stehen also vor der Aufgabe, auch nicht-produktbezogene Software entsprechend zu validieren.
Was einfach klingt, bringt in der Praxis erhebliche Unsicherheiten mit sich: Welche Software ist betroffen? Was muss validiert werden? Und wie geht man bei Bestandssoftware oder systemübergreifenden Funktionen vor?
Aus den Anforderungen der ISO 13485 resultieren die folgenden Tätigkeiten:
Ist dies nicht mehr möglich, muss nachträglich bewertet werden, ob eine Validierung notwendig ist und wenn ja in welchem Umfang.
Auch die FDA nennt in 21 CFR part 820.70 Production and process controls (i) konkrete Anforderungen. So wird hier eindeutig formuliert, dass die Software, die Teil der Produktion oder des QMS ist, zu validieren ist. Ebenfalls wird ein dokumentiertes Verfahren für diesen Prozess gefordert.
Weitere Dokumente, die neben der ISO 13485 bzw. der 21 CFR part 820.70 für Softwarevalidierung im Kontext von QMS von Medizinprodukten relevant sind:
Die Grundidee ist überall gleich: Validierungsumfang und -tiefe müssen sich am Risiko orientieren, das durch fehlerhafte Softwarefunktionen für Patientensicherheit oder regulatorische Compliance entstehen kann.
Anmerkung: Es ist wichtig, immer zu klären, ob es um Softwarevalidierung für ein Medizinprodukt geht oder um Softwarevalidierung im Kontext der Nutzung im QMS. Dies ist wichtig, da jeweils unterschiedliche regulatorische Anforderungen umgesetzt werden müssen.
Der 21 CFR 820 und die ISO 13485 sind sich in dem Punkt einig: Software oder Softwarefunktionen, die ein Teil der Produktion oder des QMS sind, müssen validiert werden.
Um noch etwas konkreter zu werden, hat der ISO/TR 80002-2 in Kapitel 5.2.2 folgende Fragen definiert:
Wird eine der beiden Fragen mit "ja" beantwortet, muss die Software validiert werden.
Der Verwendungszweck der Software ist das primäre Argument, wenn eine Software nicht validiert werden soll. Daher ist es immer ratsam, eine solche Entscheidung zu dokumentieren, um bei Nachfragen direkt die Antwort parat zu haben. Abhängig von der Komplexität der Software bedarf es ggf. einer ausführlicheren Betrachtung mit einer Risikoanalyse, um festzulegen, für welche Funktionen eine Validierung durchgeführt werden muss.
In der FDA Guidance wird eine Unterteilung von Software in die Kategorien direkter und indirekter Bestandteil der Produktion oder QMS vorgeschlagen:
Nur Software, die Teil des QMS oder der Produktion ist, muss betrachtet werden. Darunter fallen somit nicht z. B. Buchhaltungs- und Personalmanagement-Software oder E-Mail-Anwendungen.
Ein hohes Prozessrisiko ist also ein Risiko, was letzten Endes ein Medizinprodukterisiko zur Folge haben kann.
Diese Einteilung der Risiken in hoch und niedrig sind keine Vorgabe der FDA Guidance. Die Kategorien sollten sinnvoll gewählt werden. Dabei sollte immer beachtet werden, welchen Mehrwert eine weitere Unterteilung in Risikokategorien erbringt.
Um die beschriebene Risikoanalyse vornehmen zu können, ist es unerlässlich, den Prozess, in dem die Software genutzt wird, klar zu definieren.
Die Prüfintensität bei der Softwarevalidierung sollte immer in einem angemessenen Verhältnis zum Risiko stehen, das durch eine mögliche Fehlfunktion entsteht. Bei hohem Prozessrisiko ist der Maßstab das potenzielle Risiko für das Medizinprodukt. Ist das Prozessrisiko gering, genügt eine entsprechend reduzierte Prüfstrategie.
Wichtig: Hier geht es ausschließlich um Software, die bei der Produktion oder im Qualitätsmanagementsystem eingesetzt wird - nicht um Software, die in einem Medizinprodukt verwendet wird oder selbst als solches gilt.
Die FDA empfiehlt in ihrer Guidance verschiedene Prüfmethoden, insbesondere:
Ein ungeplantes Testing entbindet nicht von der Pflicht, die Testergebnisse und das gewählte Vorgehen zu dokumentieren.
Je höher das Risiko der Software, desto größer sollte sowohl der Testaufwand als auch die Nachweisdichte sein. Skriptbasiertes Testen bieten hier den höchsten Grad an Nachvollziehbarkeit und Struktur.
Zudem sollte Software nie isoliert betrachtet werden. Gibt es im Prozess zusätzliche Kontrollmechanismen, die Fehler erkennen würden, kann der Validierungsaufwand reduziert werden. Gleiches gilt für zugekaufte Software, die bereits geprüft oder validiert wurde – auch hier kann der Umfang der eigenen Prüfaktivitäten angepasst werden.
Entscheidend ist jedoch wie immer eine nachvollziehbare Dokumentation, um z. B. im Audit eine Begründung vorlegen zu können. Letztendlich liegt die Verantwortung beim Hersteller, zu bewerten welche Prüfaktivitäten für welches Risiko angemessen sind.
Mit der Dokumentation muss der objektive Nachweis erbracht werden, dass die Software oder Softwarefunktionen den vorgesehenen Verwendungszweck erfüllen. Dieser Verwendungszweck bildet die Grundlage für alle weiteren Validierungsschritte.
Die Dokumentation sollte enthalten:
Unabhängig vom Testansatz gilt: Fehlfunktionen müssen klar dokumentiert und beschrieben werden. Der Testbericht sollte ein abschließendes Statement enthalten, ob die Software für den vorgesehenen Verwendungszweck geeignet ist.
Im Folgenden ist das notwendige Vorgehen bei der Softwarevalidierung dargestellt. Diese Schritte müssen geplant und dokumentiert werden.
Sonderfall integrierte Software in Fertigungsanlagen: Wird Software als Bestandteil von Anlagen eingesetzt (z. B. Steuerung einer Fertigungslinie), kann die Validierung über die Anlagenqualifizierung oder Prozessvalidierung erfolgen. Die ISO/TR 80002-2 empfiehlt, auf diese Nachweise zu verlinken oder sie direkt in die Softwarevalidierungsdokumentation zu integrieren.
Gerade in etablierten Unternehmen ist Software oft schon jahrelang im Einsatz, bevor Softwarevalidierungs-Themen strukturiert betrachtet wurden. In diesen Fällen muss retrospektiv validiert werden – das heißt: Eine nachträgliche Bewertung inklusive Risikobetrachtung und Dokumentation muss erfolgen.
Auch nach der Einführung einer Software ist die Arbeit noch lange nicht erledigt. Mit jeder neuen Version können zusätzliche Funktionen hinzukommen oder bestehende Features verändert werden. Solche Änderungen bringen potenziell neue Risiken mit sich, die identifiziert, analysiert und bewertet werden müssen.
Damit das gelingt, müssen die Verantwortlichen für die Softwarevalidierung stets über den aktuellen Stand der Softwarekonfiguration informiert sein – und das dauerhaft und verlässlich. Das gilt für sämtliche Softwarelösungen, die im Qualitätsmanagementsystem oder in der Produktion eingesetzt werden.
Um diese Transparenz sicherzustellen, braucht es ein funktionierendes System innerhalb Ihrer Organisation. Das kann eine strukturierte Prozesslandschaft sein, unterstützt durch geeignete Tools, möglicherweise sogar durch eine spezielle (natürlich validierte!) Softwarelösung.
Die Softwarevalidierung ist ein elementarer Bestandteil regulatorischer Konformität im Rahmen der ISO 13485 und der FDA-Anforderungen. Besonders herausfordernd ist dabei die retrospektive Validierung bestehender Systeme sowie die Bewertung von Softwarefunktionen im Grenzbereich zwischen QMS, Produktion und allgemeinen IT-Anwendungen.
Um Validierungsaufwand und Konformitätsdruck in Einklang zu bringen, ist ein risikobasierter Ansatz entscheidend - idealerweise gestützt durch erfahrene Partner, die technische Tiefe und regulatorisches Know-how verbinden.
Sie stehen vor der Herausforderung, ältere Systeme nachzudokumentieren oder neue Softwarelösungen effizient und regelkonform zu validieren? Wir unterstützen Sie bei der Analyse, Planung und Umsetzung maßgeschneiderter Softwarevalidierungsprozesse – ob retrospektiv, parallel zur Digitalisierung oder im Rahmen eines internen Audits.
Kontaktieren Sie uns für ein unverbindliches Erstgespräch.