Softwarevalidierung in der Medizintechnik - Allgemeines

Einführung

Die Softwarevalidierung wurde früher in der Medizintechnik stiefmütterlich behandelt. Obwohl die Softwarevalidierung von der FDA in 21CFR820.70(i) immer gefordert war. Mit der Revision der EN ISO 13485 und dem MDSAP Auditprogramm ist die praktische Bedeutung der Softwarevalidierung gestiegen und sie erlangt in Audits zunehmende Aufmerksamkeit.

die

Softwarevalidierung Medizinprodukte Software Validierung Medizintechnik Leonhard Blaurock csv qsr fda

Validierung von Gerätesoftware

Bei der Softwarevalidierung muss zwischen Software, die Teil des Medizinproduktes ist und sonstiger zu validierender Software unterschieden werden. Software, die Teil eines Medizinproduktes ist, lässt sich unter strikter Anwendung der harmonisierten und von der FDA anerkannten IEC/EN 62304 recht leicht validieren. Auf diese Art Software werde ich daher im Weiteren nicht eingehen.

Synonyme

Die Softwarevalidierung ist auch bekannt als:

  • Software Validierung
  • Computer System Validierung / Computer-System-Validierung / CSV
  • Validation of automated systems (siehe 21CFR 820.70(i))

Validierung von Software für die Produktion und das QM-System

Bei Software, die für die Produktion (inkl. Prüfung) von Medizinprodukten verwendet wird oder, die im Qualitätsmanagementsystem selber verwendet wird (z.B. Dokumentenmanagementsystem, Messwertdatenbank, etc.) verhält es sich wesentlich komplizierter. Für diese Art Software existiert keine anerkannte Norm, nach der man bei der Softwarevalidierung vorgehen kann. Häufig fällt im Kontext der Softwarevalidierung für das QM-System oder die Produktion der Begriff GAMP 5. Hierbei handelt es sich um einen Leitfaden aus der pharmazeutischen Industrie zur Validierung dieser Art Software. GAMP 5 ist allerdings sehr mächtig und seine vollständige Umsetzung dementsprechend aufwendig und teuer. Ich selber habe noch nicht ein Unternehmen der Medizintechnik gesehen, dass streng nach GAMP 5 vorgeht. Wo liegt also die Mindestanforderung für die Softwarevalidierung? Sofern Sie in die USA liefern, definiert die Guidance General Principles of Software Validation der FDA das erwartete Vorgehen. Richtig selbsterklärend ist diese Guidance allerdings auch nicht. Daneben existiert noch AAMI TIR36. Bei diesem Dokument handelt es sich um eine recht pragmatische Anleitung, die jedoch am Ende weiterhin viele Fragen offen lässt.

Praktische Herausforderungen bei der Softwarevalidierung

Den richtigen Ansatz für die Validierung finden

Für den Ansatz der Softwarevalidierung hat es sich in der Praxis bewährt, das Brauchbarste aus den verschiedenen bereits genannten Quellen zusammen zu mischen und darauf zu achten, dass die typischen Elemente wie User Requirements, Risikoanalyse, Testplan, Testreport etc. vorhanden sind. Es lohnt sich beispielsweise die Kategorisierung der zu validierenden Software von GAMP 5 zu übernehmen. Hier geht es im Wesentlichen darum, dass eine Software um so fehleranfälliger sein wird, je kundenspezifischer diese ist. Auf dieser Philosophie basierend, können die Aufwände bei sogenannter Off-The-Shelf-Software, also gängiger Software, wesentlich reduziert werden. Viel mehr sollte man aus Gründen der Praktikabilität allerdings nicht aus GAMP 5 für die Softwarevalidierung übernehmen.

Planung einer Softwarevalidierung

Die nächste Herausforderung bei der Softwarevalidierung für Medizinproduktehersteller ist, dass er als erstes genau aufschreiben muss, was die Software für ihn machen soll. Meist wird nur ein geringer Funktionsumfang der Software tatsächlich benötigt. Die Softwarevalidierung muss nur den tatsächlich genutzten Teil der Software umfassen. Darauf folgt die Risikoanalyse. Für jede genutzte Softwarefunktion gilt es zu analysieren, ob sich die Funktion im Fehlerfall negativ auf das Produkt auswirken könnte oder eine Fehlfunktion zu einer Nicht-Erfüllung von gesetzlichen Vorgaben, wie der Einhaltung des QM-Systems führen kann. Diese Risikoanalyse dient der Steuerung der Testumfänge im Rahmen der Softwarevaliderung. Damit die Risikoanalyse und die daraus abgeleiteten Tests jedoch einen Wert haben, müssen die an der Risikoanalyse beteiligten Personen ein Grundverständnis für Softwarearchitektur und -programmierung haben. Typischerweise wird eingekaufte Software validiert, über die keine Informationen zur genauen Funktionsweise verfügbar ist. Daher müssen die an der Softwarevalidierung beteiligten Personen wissen, wie die von Ihnen untersuchten Softwarefunktionen mit hoher Wahrscheinlichkeit aufgebaut sind. Anderenfalls lassen sich mögliche Fehlerquellen nicht identifizieren und die Risikoanalyse läuft ins Leere. Dasselbe Verständnis von Software ist für die Planung der tatsächlichen Tests der Softwarevalidierung erforderlich.

Validierung der Software einer Produktions- oder Prüfanlage

Die Komplexität einer Softwarevalidierung kann noch gesteigert werden, wenn die zu validierende Software Teil einer Produktions- oder Prüfanlage ist. In diesem Fall werden einige, jedoch nicht alle Softwarefunktionen die Anlage steuern oder deren Daten verarbeiten. Gemäß 21CFR820.70(g) ist für alles Produktionsequipment (inkl. Prüfequipment) eine Abnahme durchzuführen ist. Diese Abnahme wird meist als Installation Qualification (IQ) bezeichnet. Eine der wesentlichen Punkte der Installation Qualification ist die Abnahme der tatsächlichen Funktionen der Anlage. Jetzt treffen zwei Abnahmeinstrumente – die Softwarevalidierung und die Installation Qualification – auf dieselbe Anlage. Nun gilt es zu ermitteln, welche Teile der Softwarefunktionen bereits über die Installation Qualification zufriedenstellend geprüft werden können, und welche eine weitergehende Softwarevalidierung erfordern. Die Abgrenzung, welche Funktionen in der IQ und welche in der Softwarevalidierung abgeprüft werden, gilt es natürlich zu dokumentieren, sodass am Ende sichergestellt ist, dass wirklich alle Software- und Anlagenfunktionen getestet wurden. Eine weitere Steigerung der Komplexität der Softwarevalidierung ist möglich, wenn die Software z.B. an ihr ERP-System angeschlossen wird oder Teile der Softwarefunktion in noch weiteren Teilaspekten Ihres QM-Systems wie beispielsweise einer Kalibrierung abgedeckt we

Eine effiziente Softwarevalidierung lebt von der gründlichen Analyse der Software im Kontext ihres Anwendungsumfeldes. Für die Vermeidung von mehrfachen Testungen derselben Softwarefunktion ist eine enge Abstimmung des Risikomanagements, der Equipmentqualifizierung (IQ), der Softwarevalidierung und ggf. der Softwarevalidierungen weiterer angebundener Software notwendig. Hierfür ist interdisziplinäres Wissen und Erfahrung sowie ein Blick für das Big-Picture erforderlich.

Wie hilfreich war dieser Beitrag?

Klicken Sie auf die Sterne, um zu bewerten!

Durchschnittliche Bewertung 0 / 5. Anzahl Bewertungen: 0

Bisher keine Bewertungen! Seien Sie der Erste, der diesen Beitrag bewertet.

Wir freuen uns von Ihnen zu hören!

✉ Kontaktieren Sie uns per E-Mail:
✆ Rufen Sie uns an:

Leonhard Blaurock

Uwe Philippeit
Erhalten Sie einen Rückruf:

Diese Webseite verwendet Cookies, um Besucherstatistiken anzufertigen. Mit der Verwendung dieser Webseite erklären Sie Ihr Einverständnis zur Erhebung anonymer Besucherstatistiken. Details finden Sie im Impressum.