Was ist ein CQV-Masterplan?

Die meisten Validierungsprogramme scheitern nicht an der Durchführung. Sie scheitern, weil niemand vorab aufgeschrieben hat, was das Programm eigentlich beweisen soll – und wenn das offensichtlich wird, sind bereits zweihundert Protokolle auf Annahmen geschrieben worden, denen niemand zugestimmt hat.

Der CQV-Masterplan ist das Dokument, das genau das verhindert. Er steht an der Spitze der Validierungsdokumentation, und alles darunter – System Level Impact Assessments, Qualitätsrisikobewertungen, Lastenhefte (URS), FAT- und SAT-Protokolle, IQ, OQ, PQ, die Requirements Traceability Matrix – übernimmt seine Logik.

Was in einen CQV-Masterplan gehört

Ein CQVMP, dem ein Inspektor folgen und mit dem ein Projektteam tatsächlich arbeiten kann, deckt neun Punkte ab.

1. Umfang und Systemgrenzen

Welche Systeme, welche Gebäude, welche Phasen. Wichtiger noch: wo jedes System endet. Grenzstreitigkeiten – etwa zwischen der Erzeugung von gereinigtem Wasser und der Verteilschleife oder zwischen einer Abfüllanlage und dem umgebenden Isolator – sind die häufigste Ursache für Qualifizierungslücken: Zwei Teams gehen jeweils davon aus, dass die Schnittstelle dem anderen gehört.

Zeichnen Sie die Grenzen in eine Zeichnung ein, verweisen Sie auf die Zeichnungsnummer und listen Sie auf, was ausdrücklich nicht zum Umfang gehört.

2. Organisation und Verantwortlichkeiten

Wer schreibt, wer prüft, wer führt durch, wer genehmigt – und wer ist befugt, eine Abweichung zu akzeptieren. Bei einem risikobasierten Ansatz ist das wichtiger als früher, weil Fachexperten Entscheidungen übernehmen, die bisher standardmäßig bei der Qualitätseinheit lagen.

3. Der Ansatz der Risikobewertung

Das ist das Herzstück des Dokuments. Es sollte festlegen, welche Methodik verwendet wird, welche Auswirkungskategorien es gibt, wie Kritikalität bestimmt wird und – entscheidend – wie das Ergebnis der Risikobewertung in die Qualifizierungstiefe übersetzt wird. Eine Risikobewertung, die Systeme klassifiziert, aber nichts am weiteren Vorgehen ändert, ist Dekoration.

4. Die Dokumentenhierarchie

Eine Übersicht über jeden Dokumenttyp des Programms, seine Funktion und die Rückverfolgbarkeit zwischen ihnen. Erst dadurch lässt sich die Requirements Traceability Matrix konstruieren, statt sie archäologisch rekonstruieren zu müssen.

5. Die Leveraging-Strategie

Wenn Nachweise aus der Inbetriebnahme für die Qualifizierung genutzt werden sollen – und nach ASTM E2500 und dem ISPE Baseline Guide Volume 5 sollte das meist so sein –, wird das im CQVMP vereinbart, mit den zugehörigen Bedingungen: kalibrierte Instrumente, geschultes Personal, Dokumentenlenkung, vorherige Genehmigung durch die Qualitätseinheit. Nachträglich beschlossenes Leveraging ist kein Leveraging, sondern eine Lücke mit angeschraubter Begründung.

6. Grundsätze für Akzeptanzkriterien

Nicht die Kriterien selbst – die stehen in den Protokollen –, sondern die Regeln, nach denen sie festgelegt werden. Woher stammen sie? Aus URS, Lieferantenspezifikation, regulatorischem Grenzwert, Prozessanforderung? Was geschieht, wenn ein Kriterium nicht wie formuliert erfüllt werden kann?

7. Umgang mit Abweichungen und Diskrepanzen

Klassifizierung, wer was abschließen darf, und der Eskalationsweg ins QMS des Standorts. Ein CQVMP ohne Anbindung an das Abweichungsverfahren des Standorts schafft ein paralleles Qualitätssystem – und das fällt Inspektoren auf.

8. Schnittstelle zur Änderungskontrolle

Designänderungen während der Durchführung sind sicher. Der Plan sollte festlegen, wie eine Änderung auf ihre Auswirkung auf die Validierung bewertet wird und wer entscheidet, ob erneut durchgeführt werden muss.

9. Freigabekriterien

Was muss erfüllt und dokumentiert sein, bevor ein System für die GMP-Herstellung genutzt werden darf? Das ist die Frage, für deren Beantwortung das ganze Programm existiert – und es ist erstaunlich, wie oft sie unausgesprochen bleibt.

Wo er steht

CQV-Masterplan (CQVMP)
 ├── System Level Impact Assessment (SLIA)
 ├── Qualitätsrisikobewertung (QRA)
 ├── Lastenheft / User Requirement Specification (URS)
 │    └── Designqualifizierung (DQ)
 ├── FAT- / SAT-Protokolle
 ├── IQ- / OQ- / PQ-Protokolle und -Berichte
 ├── Requirements Traceability Matrix (RTM)
 └── Validierungsabschlussbericht → Systemfreigabe

Jede Ebene sollte sich aus der darüberliegenden ableiten lassen. Wenn Sie einen OQ-Test nicht über die RTM zu einer Anforderung in der URS zurückverfolgen können, von dort zu einer Kritikalitätsentscheidung in der Risikobewertung und von dort zum im CQVMP festgelegten Ansatz, dann haben Sie einen Test ohne Grund – und ein Inspektor wird fragen, warum Sie ihn durchgeführt haben oder warum Sie etwas anderes nicht durchgeführt haben.

Fünf Fehler, die einen CQVMP scheitern lassen

Ihn erst schreiben, wenn die Protokolle schon laufen. Der Plan dokumentiert dann, was passiert ist, statt zu steuern, was passieren sollte. Die Grenzen werden um bereits erledigte Arbeit gezogen.

Systemgrenzen offen lassen. An Schnittstellen entstehen Qualifizierungslücken. Wenn der Plan nicht sagt, wem die Schnittstelle gehört, gehört sie niemandem.

Den Risikoansatz mit der Technik abstimmen, aber nicht mit der Qualitätseinheit. Die Qualitätseinheit muss die Entscheidungen, die der Ansatz hervorbringt, am Ende verteidigen. Eine nachträgliche Genehmigung ist keine Genehmigung.

Keine Leveraging-Strategie. Entweder wiederholen Sie die Inbetriebnahme als Qualifizierung – teuer, langsam und nicht konformer – oder Sie nutzen Nachweise ohne dokumentierte Grundlage, was schlimmer ist.

Akzeptanzkriterien vollständig den Protokollen überlassen. Ohne festgelegte Grundsätze erfinden fünfzehn Protokollautoren fünfzehn verschiedene Maßstäbe, und die Uneinheitlichkeit wird erst bei der Prüfung sichtbar.

Wann Sie einen brauchen

Bei jedem Projekt mit mehr als einer Handvoll Systemen, jeder Greenfield-Anlage, jedem Technologietransfer und jedem Programm, bei dem mehr als eine Organisation durchführt. Eine einzelne Anlagenqualifizierung an einem laufenden Standort mit ausgereiftem VMP braucht vielleicht keinen eigenen Masterplan – muss aber unter einem stehen.

Der Test ist einfach: Könnte ein neuer Ingenieur, der morgen ins Projekt kommt, aus der Dokumentation ablesen, was qualifiziert wird, warum, in welcher Tiefe und was „fertig“ bedeutet? Wenn nicht, fehlt der Plan – egal, wie das Dokument heißt.