Software – Validierung

[QuEm]

#24744

Hallo Forum,

Wer kann kurz umreißen, was die Minimalanforderung an die Validierung von Software sind.

Meine Gedanken diesbezüglich sind die folgenden:

A)Designqualifizierung; Wie wird das Lastenheft im Pflichtenheft des Herstellers umgesetzt?
B) Installationsqualifizierung: Funktioniert die Software auf dem Equipment (Maschine, Testgerät, PC), Wie ist die Stromversorgung abgesichert, passt der Standort? Definierte Anforderungen müssen erfüllt werden.
Abweichungen müssen bis zur PQ geschlossen sein.
C) Operational Qualification: Durchführung von Messsabläufen, Herstellschritte oder Datenverarbeitungsprozesse durchführen mit geschultem Personal.Definierte Anforderungen müssen erfüllt sein.
Abweichungen müssen bis zur PQ geschlossen sein.
D) Performance Qualification: sogenannter Integrationstest – alle beteiligten Schritte in Herstellung, Messung oder Datenverwaltung werden getestet und müssen die Anforderungen erfüllen.
E) Abschlussbericht mit Freigabe der Software oder ggf. keine Freigabe, wenn die Anfordeurngen nicht erfüllt werden.

Was meint Ihr?

[QM-FK]

#60915

Eine einfache Anwort kenne ich nicht.

Dein Ansatz beinhaltet einige Punkte auf Geräteebene, aber noch nicht die Software selbst.

Geht es in Richtung Medizinprodukte?

Dann schau Dir zunächst die EN 62304 an für den Softwareentwicklungsprozess an. Die Lektüre ist äußerst empfehlenswert, um einen tieferen Einblick in die Anforderungen zu bekommen, lässt aber selbst ausgerechnet das Thema Validierung beiseite.

Dann die EN 61508-3 (Produktabbildung – Funktionale Sicherheit sicherheitsbezogener elektrischer/elektronischer/programmierbarer elektronischer Systeme – Teil 3: Anforderungen an die Software (IEC 61508-3:1998 + Corrigendum 1999)

Funktionale Sicherheit sicherheitsbezogener elektrischer/elektronischer/programmierbarer elektronischer Systeme – Teil 3: Anforderungen an die Software (IEC 61508-3:1998 + Corrigendum 1999, Ausgabedatum: 2003-06-01).

Ich komme gerade von einem dreitägigen Lehrgang zum Thema. Eines ist sicher:
Es gibt nicht EINE Methode sondern – je nach Bereich und Risiken – ein Bündel von möglichen und anzuwendenden Lösungsmöglichkeiten und Vorgehensweisen.

Die ISO 26262-x (insbesondere Teil 6) liefert mögliche Ansätze: Diese Vorgehensweise geht vom Einfluss des Software-Werkzeuges auf die Eigenschaften des Medizinproduktes aus und betrachtet anschließend die Wahrscheinlichkeit der Entdeckung einer möglichen Fehlfunktion dieses Werkzeuges. Darüber hinaus wird noch die Sicherheitsklasse der betroffenen Software-Komponenten in die Betrachtung mit einbezogen. Aus diesen Faktoren lassen sich dann die notwendigen Validierungsverfahren für das Software-Werkzeug ableiten.

Einen kurzen Überblick zur einer Vorgehensweise findest Du z.B.
hier.

Lesenswert ist der FDA-Leitfaden zur Software-Validierung, wenn auch schon etwas veraltet.

Eine Methode im Bereich Pharma / Medizinprodukte ist GAMP (derzeit GAMP 5).
GAMP 5 ist an die Terminologie der ASTM E2500 und der ISPE Baseline-Guide „Commissioning and Qualification“ angepasst worden. Dadurch sind z.B. die Bezeichnungen IQ, OQ und PQ aus dem V-Modell verschwunden. Der „Testschenkel“ des V-Modells, der in GAMP 4 in zwei unterschiedlichen V-Modellen entweder mit den Engineeringtest-Bezeichnungen oder mit den Qualifizierungstest-Bezeichnungen dargestellt wurde, wird in GAMP 5 nun als Verifizierung bezeichnet und beschreibt die Engineeringtests.
Dr. Dirk Spingat von der Bayer Schering Pharma hat es so formuliert:
Der Validierungsaufwand richtet sich nun im wesentlichen nach drei Kenngrößen: zuforderst der Patientensicherheit und dann der Komplexität und der Neuheit des eingesetzten IT-Systems. Dadurch ändern sich die Sicht- und Arbeitsweisen und es müssen bewusste Entscheidungen getroffen werden. So wird zunächst eine Basis-Risikobewertung durchgeführt und die Auswirkungen des Systems untersucht. Danach werden die Funktionen ermittelt, die Auswirkungen auf die Patientensicherheit, die Produktqualität und die Datenintegrität haben. Anschließend beginnt das funktionale Risikomanagement und es werden Anzahl und Umfang der Kontrollen festgelegt. Diese müssen dann implementiert und verifiziert werden. Abschließend werden noch einmal die Risiken geprüft und die Kontrollen überwacht.

Soviel soll an dieser Stelle einmal genug sein. Ich will die Freunde des Forums nicht mit zu vielen Details erschlagen. Es soll nur verdeutlichen, dass ohne detaillierte Kenntnis des Einsatzgebietes, Analyse der Risiken usw. kaum eine einfache Antwort möglich ist.

Viele Grüße
QM-FK
—
Don’t think it – ink it.

[QM-FK]

#60916

Habe glatt vergessen zu erwähnen, dass die ISO 26262-x nicht für medizinprodukte konzipiert wurde, sondern für die Funktionale Sicherheit von Straßenfahrzeugen. Unabhängig hiervon sind die Anforderungen und Vorgehensweisen aber ähnlich.

Viele Grüße
QM-FK
—
Don’t think it – ink it.

[qualyman]

#60917

Hallo QM-FK,

wieso „Ich will die Freunde des Forums nicht mit zu vielen Details erschlagen.“?

Sehr gerne lese ich auch „artfremde Artikel“, um stetig meinen beschränkten Horizont zu erweitern.
Dein Artikel ist für mich soweit interessant, da ich mich mit Validierung und Verifizierung von Maschinen und Anlagen schon beschäftigte.
Da ist die Sache mit Software natürlch auch sehr interessant.

Außerdem lebt unser spitzenmäßiges Forum von solch kompetenten Postings, wie dieses und andere von Dir, sowie von allen übrigen Aktiven!……und das ist gut so!

Gruß aus der Pfalz über die Brück in die Kurpfalz!

„Der Mensch erfand die Atombombe, doch keine Maus der Welt würde eine Mausefalle konstruieren.“

(Albert Einstein – Physiker, 1879-1955)

Gute Zeit!

Qualyman – Qualitäter aus Überzeugung und Leidenschaft, auch wenn´s mal Leiden schafft!

info ad quality minus first dot de

geändert von – qualyman on 21/03/2012 15:26:32

[QuEm]

#60918

Wie sieht es eigentlich wirklich mit dem V-Modell aus. Ist das nicht auch schon wieder überholt?

[QM-FK]

#60919

Das V-Modell hat sich etabliert und stellt nicht nur bei der Software-Entwicklung ein erprobtes Modell zur übersichtlichen Vorgehensweise dar.
GAMP5 basiert wesentlich auf dem V-Modell und stellt DEN Standard-Ansatz bei der Validierung von Software (SW) in der Pharma-Industrie dar.

Was letztlich in das V-Diagramm aufgenommen oder dort hervorgehoben wird, hängt davon ab, was letztlich so schief geht oder jüngst folgenreich schief gegangen ist. Hinterher ist man immer schlauer und dann werden die Modelle wieder angepasst oder neu konzipiert.
Die verschiedenen Modelle (Wasserfallmodell usw.) sind z.T. historisch zu sehen und stellen Vorgehensweisen dar, die eng an Software-Tools geknüpft sind.
Die Verifizierungs- und Validierungstätigkeiten hängen wesentlich vom Risiko und der Komplexität der Anwendungen ab.
Etablierte Abschätzungen liegen bei Promille Fehler (1/1000 Codezeilen) bzw. darunter.
Bei komplexen SW-Projekten werden Millionen von Code-Zeilen eingebaut, und da sind SW-Fehler hoch wahrscheinlich.
Wer nur 20 Zeilen Quellcode schreibt hat es natürlich viel einfacher.
Die Wahrscheinlichkeit, hier einen SW-Fehler reinzubasteln, ist gering.

Auch z.B. die CNC-Programmierung kann man entspannt sehen, da hier das Ergebnis zu 100% am Werkstück verifiziert werden kann. Für die kritischen Abmessungen sind natürlich Prozessfähigkeitsüberprüfungen sinnvoll, aber dazu braucht man keine Software-Validierung, wie diese die Norm fordert.
Es gilt immer noch der Grundsatz:
Was nicht zu 100% gemessen wird, bleibt ein Kandidat für die Validierung.

Viele Grüße
QM-FK
—
Don’t think it – ink it.

[Autor]

Beiträge