Traceability, Open Source und Dokumentation: GXP-Mythen im Check | Christof Layher

Wer darf die Dokumentation im Team machen? Gibt es Agilität
imGXP-Umfeld? Ändert die Validierung mit der PQ
eineValidierungspflicht?


Darum geht es in der neuen Folge vom ChaosHacker-Talk,
derMythbusters-Edition.


Host Christof Layher macht ein neues Experiment mit diesem
Format.


Denn in seinen Gesprächen kommen immer wieder dieselben Mythen
auf. Damit will sich Christof auseinandersetzen.


Mythos 1: Man muss das ganze System revalidieren wegen einer
Änderung.


Christof empfiehlt, das unter dem Stichwort der Risikobewertung
zu betrachten, denn sonst lähmt man sein gesamtes System. Teste
die Dinge, die du geändert hast mit Fokus auf deinen regulierten
Prozess.


Mythos 2: Open Source-Software ist nicht GXP-konform.


Ja, man bekommt für Open Source oft keinen Support – fair point.


Allerdings kann man sich den auch intern aufbauen.


Der Punkt: Man weiß nicht, was drin ist, der gilt allerdings
wirklichnicht, denn das weiß man bei Closed Source auch nicht!


Mythos 3: Agilität im GXP-Umfeld ist nicht möglich, weil die
Anforderungen nicht klar sind.


Das ist tatsächlich Unsinn, denn kein Entwickler im agilen Umfeld
fängt an zu arbeiten, ohne dass die Anforderungen klar sind.


Mythos 4: Agilität ist klasse, denn da muss man nicht
dokumentieren.


Das ist einfach falsch, denn bei einer agilen Arbeitsweise werden
alle Zwischenschritte mitgetrackt. Das bedeutet: Nicht
wenigerDokumentation, sondern oft mehr!


Mythos 5: In agilen Projekten gibt es keine Traceability.


Christof erzählt, dass er viele nicht-agile Projekte kennt, in
denen esextrem viele Dokumente und Punkte gibt, die dann in einer
endlos großen Excel-Liste zusammengetragen sind – das besteht
keine Traceability mehr!


Mythos 6: Wir brauchen IQ, OQ und PQ – steht ja im Gesetz.


Im Gesetz steht aber auch, dass das Ganze applicable sein darf.
Passt es also einfach so an, dass es für euch passt!


Mythos 7: SOPs machen das Leben schwer, weil sie uns vorgeben,
welche Dokumente man braucht.


Das sagt das Gesetz aber nicht! Deswegen gilt es zu challengen:
Welche Dokumente bringen uns einen Mehrwert?


Übrigens: Das muss auch nicht zwingend in einem traditionellen
Dokument sein.


Mythos 8: Jedes Detail eines Systems muss dokumentiert sein.


Christof’s Antwort ist: Maybe! Aus GXP-Sicht muss das
dokumentiert sein, was Einfluss auf den pharmazeutischen Prozess
hat.


Mythos 9: Die Dokumentation erstellt das IT Quality-Team.


Aber eigentlich sollte die Dokumentation da erfolgen, wo auch
dieTätigkeit ausgeführt wird! Denn jedes Mal, wenn wir
Informationen auf eine andere Quelle transferieren, gehen Dinge
verloren.


00:00:00 Neue Folge: Mythbusters


00:00:59 System revalidieren


00:01:59 Open Source-Software


00:02:55 Agilität im GXP-Umfeld


00:03:56 Counterpart


00:05:05 Traceability


00:06:17 IQ, OQ und PqQ


00:07:05 Welche Dokumente brauchen wir


00:08:50 Alles muss dokumentiert sein


00:10:10 Wer erstellt die Dokumentation