Validierung von Software für Qualitätsmanagement und Produktion – risikobasiert, effizient, normkonform

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.

Regulatorische Grundlagen: ISO 13485, 21 CFR 820 und FDA-Guidance im Überblick

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:

• Es muss ein dokumentiertes Verfahren für Softwarevalidierung etabliert sein.
• Es ist zu definieren, welche Softwareanwendungen validiert werden müssen und welche nicht.
• Vor der ersten Nutzung einer Software muss das dokumentierte Softwarevalidierungsverfahren angewendet werden.

Ist dies nicht mehr möglich muss nachträglich bewertet werden, ob eine Validierung notwendig ist und wenn ja in welchem Umfang.

• Änderungen an der Software selbst oder die Nutzung für einen anderen Zweck können eine erneute Durchführung des Validierungsverfahrens notwendig machen (Re-Validierung).
• Bei der Umsetzung des Verfahrens ist ein risikobasierter Ansatz zu wählen, der den Nutzungskontext der Software berücksichtigt.

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:

• ISO/TR 80002-2:2017 "Validation of software for medical device quality systems"
• FDA Guidance "General Principles of Software Validation" (2002)
• FDA Draft Guidance "Computer Software Assurance for Production and Quality System Software" (2022)

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.

Wann muss Software validiert werden?

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:

1. Könnte das Versagen oder ein Fehler der Software die Sicherheit oder Qualität von Medizinprodukten beeinträchtigen?
2. Automatisiert oder führt die Software eine Tätigkeit aus, die regulatorisch vorgeschrieben ist (insbesondere in den Vorschriften für Qualitätsmanagementsysteme für Medizinprodukte)? Beispiele hierfür sind die Erfassung elektronischer Unterschriften und/oder Aufzeichnungen, die Aufrechterhaltung der Rückverfolgbarkeit von Produkten, die Durchführung und Erfassung von Testergebnissen, die Führung von Datenprotokollen wie CAPA, Nichtkonformitäten, Beschwerden, Kalibrierungen, usw.

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.

Direkt, indirekt, nicht relevant: Die Einteilung von Software im Validierungskontext

In der FDA Guidance wird eine Unterteilung von Software in die Kategorien direkter und indirekter Bestandteil der Produktion oder QMS vorgeschlagen:

Nur Software, die Teils des QMS oder der Produktion ist, muss betrachtet werden. Darunter fallen somit nicht z. B. Buchhaltungs- und Personalmanagement-Software oder E-Mail Anwendungen.

Beispiel: Die Klimaanlagensteuerung und ihre Validierungspflicht

Ob eine Software validiert werden muss, hängt wie beschrieben entscheidend vom Kontext ihrer Anwendung ab. Ein typisches Beispiel: die Steuerung einer Klimaanlage. Wird diese Software lediglich zur Regulierung der Raumtemperatur in Büros genutzt, hat sie keinen Einfluss auf die Produktsicherheit - eine Validierung ist hier nicht notwendig. Anders sieht es aus, wenn die gleiche Software zur Überwachung und Steuerung der Klimatisierung von Produktionsräumen eingesetzt wird. In diesem Fall könnte eine Fehlfunktion die Produktqualität beeinflussen.

Fazit: Identische Software kann je nach Einsatzbereich unterschiedlich bewertet werden, diese Entscheidung sollte jedoch immer dokumentiert sein.

Risikoanalyse und Validierungsstrategie: Wie viel Validierung ist angemessen?

Nachdem festgestellt wurde, dass die Software zu validieren ist, muss nun noch ermittelt werden, welche Tätigkeiten erforderlich sind, also welcher objektive Nachweis erbracht werden muss, damit die Software als validiert gilt.

Es muss identifiziert werden, welche möglichen Fehler auftreten können, welche Risiken diese Fehler erzeugen können, und welche Aktivitäten durchgeführt werden müssen, damit diese Fehler nicht auftreten. Dies sollte im Rahmen einer Risikoanalyse durchgeführt werden. Die ISO/TR 80002-2 fordert in Kapitel 5.3.2.3 eine risikobasierte Betrachtung auf Basis von drei Kategorien:

• Risiken bezogen auf direkten und indirekten Schaden an Personen (Patienten und Nutzer)
• Risiken bezogen auf Schaden an der (physischen und virtuellen) Umwelt
• Risiken bezogen auf die Nichteinhaltung von regulatorischen Vorschriften.

Je nach Risikohöhe werden Validierungsmethoden gewählt: einfache Reviews bei geringem Risiko, strukturierte Testverfahren bei hohen Risiken. Die FDA unterscheidet zusätzlich zwischen Prozessrisiken und Medizinprodukterisiken. Ein hohes Prozessrisiko ist dann vorhanden, wenn ein Fehler der Funktion eine Beeinträchtigung der Qualität zur Folge hätte, die vorhersehbarerweise Sicherheit und Leistung des Medizinprodukt beeinflusst.

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.

Festlegung der notwendigen Prüfaktivitäten

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:

• Geskriptetes Testen: Vorgegebene Testfälle und Abläufe
• Ungeskriptetes Testen: Flexible, risikobasierte Prüfungen ohne festes Skript

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.

Softwarevalidierung effizient dokumentieren: Anforderungen an Nachweise, Risiko, Testumfang

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:

• eine Beschreibung des Nutzungskontexts und Verwendungszwecks der Software
• eine Risikobewertung der Software,
• eine Beschreibung der geplanten bzw. durchgeführten Prüfaktivitäten,
• sowie je nach Testmethode (geskriptet oder ungeskriptet) eine detaillierte oder grobe Testplanung, inklusive Akzeptanzkriterien.

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.

Retrospektive Validierung: Was tun, wenn Software bereits im Einsatz ist?

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.

Warum Software-Änderungen kontinuierliche Aufmerksamkeit erfordern

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.

Konform, effizient und auditfest – aber nicht ohne strukturiertes Vorgehen

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.