So meistern Sie die Software Validierung nach ISO 13485

Die Zertifizierung nach DIN-Normen ist für viele Unternehmen ein kompliziertes und aufwendiges aber wichtiges Unterfangen. Die Norm DIN EN ISO 13485:2016 für das Qualitätsmanagement von Design und Herstellung von Medizinprodukten, stellt einige Unternehmen vor Herausforderungen. In der aktuellen Ausgabe der Norm, die seit 2016 auf dem Markt ist, wird die Validierung der Anwendung von Computersoftware und die Dokumentation der entsprechenden Verfahren, als Anforderung gelistet. Diese Anforderung sorgt jedoch für einige Unsicherheiten. Was genau bedeutet Softwarevalidierung? Wie funktioniert Softwarevalidierung? Welche Software muss validiert werden? Wer ist dafür verantwortlich - der Softwareanwender oder der Softwarehersteller? Wann und wie oft muss Software validiert werden?

Die Norm ISO 13485 ist, obwohl Sie in weiten Teilen mit der ISO 9001 identisch ist, eine eigenständige Norm für Medizinprodukte. Durch die Zertifizierung der ISO 13485 wird im besten Fall die Produktwirksamkeit und -sicherheit gewährleistet. Durch diverse Vorgaben an das Qualitätsmanagement der Medizinprodukte soll neben der Qualität der Produkte auch die rechtliche Absicherung des Unternehmens gewährleistet werden. Die ISO 13485 ist, anders als andere (Qualitätsmanagement-)Normen wie die ISO 9001 : 2015, nicht freiwillig. In den EU-Staaten müssen sich Unternehmen, die Medizinprodukte herstellen, eine Zertifizierung besitzen, um Ihre Produkte zu vermarkten. 

Das Ziel der Softwarevalidierung ist der Nachweis, dass eine Software fehlerfrei arbeitet.

Die ISO 9000:2015 beschreibt Validierung als objektiven Nachweis, dass eine Anforderung für einen spezifischen beabsichtigen Gebrauche bzw. Anwendung erfüllt ist. 

Der objektive Nachweis kann zum Beispiel durch die Durchführung von Tests erbracht werden (ISO 9000:2015, Kapitel 3.8.13).

Es taucht immer wieder die Frage auf, ob der Softwareanwender oder der Softwareanbieter für die Validierung verantwortlich ist. Die ISO 13485 richtet sich in den Anforderungen klar an die Organisation, die das Managementsystem betreibt. Verantwortlich im Sinne der ISO 13485 ist also der Softwareanwender. Natürlich ist dabei nicht auszuschließen, dass die Organisation auf Unterstützung des Softwareherstellers angewiesen ist.

Die ISO 13485:2016 verweist an drei Stellen auf die Validierung von Software: 

In den allgemeinen Anforderungen in Kapitel 4.1.6., in Kapitel 7.5.6 Validierung der Prozesse zur Produktion und zur Dienstleistungserbringung und 7.6 Lenkung von Überwachungs- und Messmitteln. Die Formulierungen in allen Kapiteln sind sehr ähnlich und werden hier sinngemäß wiedergegeben. Die Abweichungen in den einzelnen Kapiteln werden in Klammern dargestellt: 

Es müssen Abläufe für die Validierung der Softwarelösungen dokumentiert werden, [die im Qualitätsmanagementsystem eingesetzt werden (4.1.6)] [die bei der Produktion und Dienstleistungserbringung eingesetzt werden (7.5.6)] [, die für die Überwachung und Messung eingesetzt werden (7.6)].

Diese Softwarelösungen müssen vor ihrem ersten Einsatz und, soweit angemessen, nach Softwareaktualisierungen (Updates) oder Änderungen ihres Gebrauchs validiert werden.

Die Softwarevalidierung und -revalidierung muss in einem angemessenen Verhältnis zu dem aus der Softwarelösung resultierenden Risiko stehen (, einschließlich der Auswirkung auf die Konformität von Produkten und Dienstleistungen mit den an sie gerichteten Anforderungen (7.5.6. / 7.6)). 

Es müssen Aufzeichnungen über die Softwarevalidierung (, sowie über die Ergebnisse, Konsequenzen und daraus resultierenden Maßnahmen (7.5.6. / 7.6)) aufrechterhalten werden.

Liest man die Anforderungen der IS0 13485 zur Softwarevalidierung erkennt man schnell den risikobasierten Ansatz:

Die Validierungstätigkeiten müssen in einem angemessenen Verhältnis zu dem mit der Software verbundenen Risiko stehen!

Die ISO 13485 schafft damit wichtigen Raum für eine individuelle Betrachtung der Software und Ihres Kontextes. Die Beurteilung der Risiken wird somit zum Dreh- und Angelpunkt der Softwarevalidierung. 

Um eine Softwarevalidierung durchzuführen,  müssen Sie zunächst die zu validierende Software auswählen. Dann werden die Risiken ermittelt, die aus der Anwendung der Software resultieren. Anschließend wird die Software getestet, um die ermittelten Risiken auszuschließen.

Kapitel 4.1.6. spricht davon, dass jede Software, die im Qualitätsmanagementsystem eingesetzt wird, validiert werden muss. Wahrscheinlich lässt sich für jede Software, die in einem Unternehmen eingesetzt wird ein mittelbarer Bezug zum Qualitätsmanagementsystem herstellen. Dies beinhaltet für die meisten Unternehmen eine völlig unübersichtliche Vielzahl von Anwendungen, die unmöglich alle validiert bzw. revalidiert werden können. Dies betrifft insbesondere die Anwendungen, die Teil der grundlegenden Infrastruktur eines jeden Unternehmens sind: gängige Betriebssysteme, Textverarbeitungs- und Tabellenkalkulationssoftware, E-Mail-Programme, Internetbrowser etc. 

All diese Softwareanwendungen pauschal zu validieren ist nicht vereinbar, mit der Forderung nach einem angemessenen Verhältnis zwischen Aufwand und Risiko.

Wir gehen daher davon aus, dass der allgemeine Teil der ISO 13485 (Jede Software - Kapitel 4.1.6) eine Zusammenfassung der spezifischen Anforderungen (Kapitel 7.5.6. / Kapitel 7.6) darstellt. Somit gilt es die Software zu validieren, die unmittelbar bei der Produktions- und Dienstleistungserbringung sowie der Überwachung und Messung von Anforderungen eingesetzt wird.

Für die Auswahl der zu validierenden Software sollten Sie sich zwei Dinge zu Herzen nehmen:

1. Nutzen Sie die Freiräume des risikobasierten Ansatzes. Softwarevalidierung ist kein wertschöpfender Prozess und darf kein Selbstzweck sein.
2. Begründen und dokumentieren Sie alle Ihre Entscheidungen zur Softwarevalidierung. Dies gilt insbesondere dann, wenn Sie Software von der Validierung ausschließen. 

Finden Sie keine überzeugende Argumentation, um eine Software von der Validierung auszuschließen, ist dies ein Indikator, dass eine Validierung geboten ist.

Die Liste der zu validierenden Software und die dazugehörige Argumentation sollte regelmäßig auf Aktualität überprüft werden. 

Viele Softwareanwendungen sind umfangreich und komplex, es ist daher empfehlenswert diese so weit möglich in einzelne Funktionsbereiche, Module oder Apps herunterzubrechen und separat zu betrachten.   

Die Software muss bei auch Änderungen Ihres Gebrauchs validiert werden. Dokumentieren Sie also gleich mit, wie und zu welchem Zweck die Software zum Einsatz kommt. 

Die Risikoanalyse ist der Kern der Softwarevalidierung. Es gilt die Risiken zu identifizieren, die aus möglichen Softwarefehlern resultieren können. Aus der Perspektive des Anwenders treten Fehler in der Regel bei der Dateneingabe oder bei der Datenausgabe auf. Dies kann dazuführen, dass Softwareprozesse nicht durchgeführt werden, zu keinen oder fehlerhaften Ergebnissen führen. 

Welche konkreten Auswirkungen können fehlerhafte Softwarefunktionen auf Ihre Fähigkeiten zur Produktion, Dienstleistungserbringung oder Erfüllung weiterer Anforderungen und Spezifikationen haben?

Schreiben Sie diese Risiken auf und bewerten Sie diese hinsichtlich der Bedeutung der möglichen Auswirkungen. Je gravierender ein Risiko ist, desto intensiver sollten Sie die damit zusammenhängende Softwarefunktion validieren, um eventuelle Fehler auszuschließen.

Definieren Sie die Anforderungen, die die Software erfüllen muss, um die zuvor identifizierten Risiken auszuschließen. Mit anderen Worten: Überlegen Sie sich, wie Sie testen können, ob die Software fehlerfrei funktioniert.  

Häufig können solche Tests deutlich weniger aufwendig sein, als es auf den ersten Blick erscheint. Sie müssen bei der Validierung nur die Eingabe und die daraus resultierende Ausgabe von Daten berücksichtigen, Sie brauchen keinen Einblick in den Source-Code. Die Software-Validierung ist damit ein sogenannter Black-Box-Test.  

Im Prinzip können Sie einzelnen Softwarefunktionen in drei einfachen Schritten validieren: 

1. Definieren Sie eine Dateneingabe und das zu erwartende Ergebnis.
2. Überprüfen Sie, ob das tatsächliche Ergebnis mit dem zu erwartenden Ergebnis übereinstimmt.
3. Entscheiden Sie, ob die Validierung erfolgreich war.

Der ganze Prozess muss natürlich dokumentiert werden.

Es ist gefordert, dass Software vor Ihrem ersten Einsatz validiert werden muss. Diese Aussage ist eindeutig und lässt wenig Raum für Interpretationen. Weniger Eindeutig wird es in Bezug auf die Revalidierung der Software. Die Revalidierung muss dann erfolgen, wenn es Aufgrund von Veränderungen der Software selbst (Updates) oder Veränderungen des Gebrauchs angemessen ist.

Somit gibt die ISO 13485 keine eindeutige Antwort für die Revalidierung der Software. Die gesuchten Antworten finden Sie in Ihre Risikoanalyse. Je kritischer die Risiken sind, desto strenger muss validiert werden.  

Das Problem ist an dieser Stelle, dass insbesondere durch die zunehmende Verbreitung von Cloud-Software die Releasezyklen in der Softwareentwicklung immer kürzer werden. Die Frage ist, ob mehr Updates gleichzeitig auch immer mehr Validierung bedeuten müssen?

Hier lohnt es sich einen Blick auf die Versionsnummer der Software zu werfen, da diese häufig Aufschluss über den Umfang der Softwareänderungen geben. In der Softwareentwicklung wird häufig auf die sogenannte semantische Versionierung zurückgegriffen. Die Versionsnummer besteht aus einer Hauptversionsnummer (Major), einer Nebenversionsnummer (Minor) und eine Revisionsnumnmer (Patch), z.B. Version 2.3.11.  Die Hauptversionsnummer zeigt signifikante Änderungen an, die Nebenversionsnummer weniger signifikante Veränderungen und die Patch-Nummer zeigt in der Regel Fehlerbehebungen an. Häufig wird noch eine Build-Nummer mit angegeben.

Je nach Risikoeinschätzung kann es zulässig sein, dass Patches nicht revalidiert werden. Die Software wird dann erst mit einer Änderung der Nebenversionsnummer erneut validiert.

Zusätzlich ist es empfehlenswert sich zu einem Softwareupdate auch das Änderungsprotokoll (Changelog) anzusehen. Während die Versionsnummer Informationen über den Umfang eines Updates gibt, gibt der Changelog konkrete Informationen welche Bestandteile der Software aktualisiert wurden. Es muss dann ggf. nicht die vollständige Software, sondern nur der im Änderungsprotokoll genannten Bestandteile revalidiert werden. 

qmBase unterstützt Sie in Ihren Prozessen zur Umsetzung Ihres Qualitätsmanagementsystems. Daher werden Sie nicht drumherum kommen auch qmBase für Ihre ISO 13485 Zertifizierung validieren zu müssen. 

Wie umfangreich diese Validierung ausfallen muss, ist an dieser Stelle natürlich wieder abhängig von Ihrer Risikoanalyse. Sie sollten in Ihrer Risikoanalyse berücksichtigen, dass es  sich bei den in qmBase abgebildeten Prozessen um Unterstützungsprozesse handelt. qmBase hat somit nur einen mittelbaren Einfluss auf Ihre Produktion und Dienstleistungserbringung. 

Im Vergleich zu Software die direkt zur Maschinen- oder Produktionssteuerung, zur medizinischen Forschung, Verarbeitung medizinischer Daten oder Entwicklung medizinischer Produkte eingesetzte wird, dürfte die mit qmBase verbunden Risiken deutlich geringer sein. Entsprechend des risikobasierten Ansatzes lässt sich daher auch ein geringer Aufwand zur Softwarevalidierung rechtfertigen. 

Für eine bessere Strukturierung der Validierung empfehlen wir, die einzelnen qmBase Apps einer separaten Risikobewertung zu unterziehen und unabhängig voneinander zu validieren bzw. später auch zu revalidieren. Definieren Sie welche Funktionen für Sie tatsächlich kritisch sind. Möglicherweise bietet es sich für Sie auch an einzelnen Apps vollständig aus der Validierung auszuschließen. 

Die Entwicklungszyklen von qmBase sind ebenfalls recht kurz. Alle 14 Tage wird ein Update für qmBase veröffentlicht. Da Sie nicht alle 14 Tage qmBase revalidieren möchten, sollten Sie sich, wie oben beschrieben, die qmBase Versionsnummern und Änderungsprotokolle ansehen. Auf dieser Basis sollten Sie entscheiden, ob eine Revalidierung tatsächlich notwendig ist. Falls Sie zu dem Ergebnis kommen, dass dies der Fall ist, ist es naheliegend, nur die Funktionen zu revalidieren, die von dem Update betroffen sind. 

Möglicherweise lässt Ihre Risikoanalyse es auch zu, dass Sie qmBase nur zyklisch revalidieren, zum Beispiel einmal im Jahr. 

Folgende Informationen brauchen Sie für Ihre Software Validierung:

• Auflistung der verwendeten Software-Lösungen
• Eine dokumentierte Entscheidung zu jeder Software-Lösung, ob diese validierungspflichtig ist oder nicht. Vergessen Sie hier Ihre Begründung nicht (Risikoanalyse)!
• Für jede validierungspflichtige Anwendung eine Aufstellung der Anforderungen, die diese erfüllen muss. 
• Eine Beschreibung der Tests, mit denen die Anforderungen überprüft werden.
• Dokumentation der Tests, einschließlich der Entscheidung, ob die Softwarevalidierung erfolgreich war.

Softwarevalidierung ist kein wertschöpfender Prozess und darf auch kein bürokratischer Selbstzweck sein. Aus diesem Grund beinhaltet die ISO 13485 den risikobasierten Ansatz. Legen Sie die Anforderungen der Norm ruhig sehr eng aus. Was nicht explizit in der Norm steht, ist auch nicht gefordert.

Wichtig ist, dass Sie nachweisen können, dass Sie sich mit dem Thema Softwarevalidierung beschäftigt haben und ein Konzept vorweisen können. Sind Ihre Entscheidungen auf Basis Ihrer Risikoanalyse stichhaltig begründet, dann wird es für jeden Auditor schwierig Ihnen zu widersprechen. 

Bei Unsicherheiten oder Rückfragen sprechen Sie uns einfach an!