Prozess
validiert.
Phase für
Phase.
Geplant: QIMS wird Prozessvalidierungen nach §7.5.6 in acht dokumentierte Phasen gliedern — IQ, OQ und PQ mit Vier-Augen-Freigabe je Phase. Parametergrenzen gespeichert, Revalidierungsauslöser erkannt.
ISO 13485 §7.5.6 · IQ/OQ/PQ · Vier-Augen · Parametergrenzen · Revalidierung
Die Siegelanlage wurde ausgetauscht — baugleich, gleiche Parameter. Der Auditor fragt nach der Validierung der neuen Anlage. Es gibt keine.
§7.5.6 verlangt Prozessvalidierung für alle Prozesse, deren Ergebnis nicht vollständig durch nachgelagerte Kontrolle verifiziert werden kann. Die Validierung gilt für das spezifische Equipment unter den spezifischen Bedingungen — nicht für "baugleiche Nachfolgemodelle" oder "identische Parameter". Maschinentausch, Materialwechsel und Parameteränderungen außerhalb der validierten Grenzen sind Revalidierungsauslöser, auch wenn die Prüfergebnisse weiterhin in Ordnung sind.
Geplant: QIMS soll den validierten Zustand explizit sichtbar und technisch schützbar machen. Parametergrenzen werden hinterlegt, Änderungen gegen diese Grenzen geprüft. Wer eine Änderung freigibt, die die Validierungsbasis berührt, soll das aktiv dokumentieren — kein stilles Fortschreiben, kein "haben wir so gemacht wie immer".
Prozessvalidierung ist kein einmaliges Projekt — es ist ein laufender Steuerungsprozess. Geplant ist, dass QIMS den validierten Zustand dauerhaft sichtbar macht und technisch an den Änderungsmanagement-Workflow koppelt.
§7.5.6 verlangt einen dokumentierten Validierungsplan mit klaren Akzeptanzkriterien — IQ, OQ und PQ sind der strukturierte Nachweis, dass ein Prozess unter definierten Bedingungen reproduzierbar konformes Ergebnis liefert.
QIMS (geplant): Geplant: QIMS wird jede Validierung in Installations-, Betriebs- und Leistungsqualifizierung gliedern. Jede Phase soll eigene Akzeptanzkriterien, Testprotokolle und einen eigenständigen Freigabe-Schritt erhalten; ohne abgeschlossene IQ-Freigabe soll keine OQ begonnen werden können.
Jede abgeschlossene Validierungsphase braucht eine zweite dokumentierte Freigabe — wer die Phase durchgeführt hat, kann sie nicht selbst als validiert deklarieren.
QIMS (geplant): Geplant: Durchführungsverantwortlicher und Freigebender sollen systemseitig getrennt sein. Der Freigebende soll die Akzeptanzkriterien prüfen und eine Begründung hinterlegen — kein Phasenabschluss ohne dokumentierten Vier-Augen-Nachweis.
Die Validierung definiert erlaubte Parameterbereiche. Jede Überschreitung — durch Änderung, Materialwechsel oder Maschinentausch — ist ein Revalidierungsauslöser nach §7.5.6.
QIMS (geplant): Geplant: QIMS soll die validierten Parametergrenzen pro Prozess speichern. Wird ein Change-Record angelegt, der einen validierten Prozess betrifft, soll das System prüfen, ob die Änderung die Validierungsgrenzen berührt — und bei Bedarf eine Revalidierungspflicht setzen.
Prozessvalidierung und Änderungsmanagement sind keine getrennten Silos. Jede Parameteränderung ist eine potenzielle Änderung der Validierungsbasis — §7.5.6 und §4.1.4 greifen ineinander.
QIMS (geplant): Geplant: Änderungen an Equipment, Material oder Prozessparametern sollen in QIMS gegen die gespeicherten Validierungsgrenzen geprüft werden. Ein Revalidierungsauslöser soll als Pflichtfeld im Change-Record dokumentiert werden, bevor die Freigabe erteilt werden kann.
Prozessbezeichnung, Equipment-ID, zu validierende Prozessparameter, Begründung für die Validierungspflicht nach §7.5.6. Scope-Abgrenzung: Welche Parameter sind innerhalb des Vorhabens, welche nicht — und warum. Pflichtfeld vor Phasenbeginn.
Für jede Phase: Akzeptanzkriterien, Testumfang und Verantwortlichkeiten — risikobasiert skaliert. Kritische Prozessparameter erfordern statistisch abgesicherte PQ. Für weniger kritische Prozesse kann der Umfang reduziert werden, wenn die Reduktion begründet dokumentiert ist.
Geplant: Jeder Testschritt wird mit Sollwert und Akzeptanzkriterium verknüpft. Ein Testergebnis "nicht bestanden" soll den Phasenabschluss verhindern. Abweichungen sollen mit Bewertung und Disposition dokumentiert werden.
User-ID des Freigebenden, Zeitstempel der Freigabe, Bestätigung der geprüften Akzeptanzkriterien, Freigabe-Begründung. Geplant: Rücknahme möglich, aber mit eigenem Zeitstempel und Begründungspflicht protokolliert.
Geplant: Validierte Parameterbereiche werden pro Prozess hinterlegt — Ober- und Untergrenzen für alle kritischen Parameter. Wird ein Parameter außerhalb der Grenzen betrieben oder eine Änderung beantragt, die die Grenzen berührt, soll das System eine Revalidierungsmarkierung setzen.
Vorhaben → IQ-Planung → IQ-Durchführung → IQ-Freigabe → OQ-Durchführung → OQ-Freigabe → PQ-Durchführung → PQ-Freigabe. Geplant: Jeder Phasenwechsel zeitgestempelt, Rückwechsel protokolliert; der Validierungsnachweis soll direkt aus den Phasendaten entstehen.
Geplant: Eine Prozessvalidierung in QIMS soll acht Phasen durchlaufen: Vorhaben, IQ-Planung, IQ-Durchführung, IQ-Freigabe, OQ-Durchführung, OQ-Freigabe, PQ-Durchführung, PQ-Freigabe. Jeder Phasenwechsel soll zeitgestempelt, Rückwechsel protokolliert und der Phasenwechsel geblockt sein, bis die Voraussetzungen der vorangehenden Phase erfüllt sind.
Die Freigabe-Phasen sind die kritischen Punkte: Hier greift das Vier-Augen-Prinzip. Wer die Phase durchgeführt hat, soll sie nicht selbst freigeben können. Der Freigebende soll die Akzeptanzkriterien prüfen, das Protokoll bestätigen und eine Begründung hinterlegen — geplant als Systemregel, nicht nur als prozessuale Empfehlung.
Norm-Bezug: §7.5.6
§7.5.6 verlangt, dass validierungspflichtige Prozesse vor der Nutzung validiert werden — und dass Validierungen bei Änderungen überprüft werden. Geplant: QIMS wird beide Anforderungen abbilden — strukturierte Erstvalidierung und Revalidierungsauslöser bei Change-Records. Ausgerichtet an den Anforderungen aus ISO 13485 §7.5.6.
Welche Prozesse müssen nach ISO 13485 §7.5.6 validiert werden?
§7.5.6 gilt für alle Prozesse, deren Ergebnis durch nachgelagerte Messung oder Überwachung nicht vollständig verifiziert werden kann — also wo Mängel erst nach der Nutzung oder nach der Auslieferung sichtbar werden. Klassische Beispiele: Sterilisation, Heißsiegelung von Sterilverpackungen, Schweißprozesse, Gussverfahren, aseptische Abfüllung. Die Norm verlangt keine IQ/OQ/PQ für jeden Prozess, sondern eine dokumentierte Entscheidung, ob Validierungspflicht besteht. Diese Entscheidung muss selbst begründet aufgezeichnet sein — "nicht validierungspflichtig" ist ein gültiges Ergebnis, wenn begründet.
Was ist der Unterschied zwischen IQ, OQ und PQ?
IQ (Installation Qualification) dokumentiert, dass das Equipment korrekt installiert ist und den Spezifikationsanforderungen entspricht — Kalibrierungsnachweise, Utilities-Anschlüsse, Safety-Features. OQ (Operational Qualification) belegt, dass der Prozess innerhalb der definierten Parametergrenzen reproduzierbar läuft — bei Worst-Case-Bedingungen. PQ (Performance Qualification) zeigt, dass der Prozess unter realen Produktionsbedingungen konsistent konformes Produkt erzeugt — mit definierter Stichprobengröße und statistischer Absicherung. Alle drei Stufen bauen aufeinander auf: ohne abgeschlossene IQ keine OQ, ohne abgeschlossene OQ keine PQ.
Wann muss ein validierter Prozess revalidiert werden?
Revalidierungsauslöser nach §7.5.6 sind alle Änderungen, die die Validierungsbasis berühren — Maschinenwechsel (auch bei baugleichem Nachfolgemodell), Materialwechsel bei kritischen Inputs, Parameteränderungen außerhalb der validierten Grenzen, Standortwechsel der Anlage, Software-Updates für prozessrelevante Steuerungen. Die Entscheidung "keine Revalidierung erforderlich" ist nur dann ausreichend, wenn sie dokumentiert und begründet vorliegt. Geplant ist, dass QIMS beim Anlegen eines Change-Records prüft, ob ein validierter Prozess betroffen ist.
Wie verhält sich Prozessvalidierung zu Änderungsmanagement in QIMS?
Beide Module sind in QIMS geplant (in Entwicklung) und sollen verknüpft werden. Jeder Change-Record soll Validierungsvorhaben als betroffene Objekte aufführen können. Ändert sich ein Parameter eines validierten Prozesses, soll der Change-Record mit einem Revalidierungshinweis markiert werden — der Freigebende soll explizit bestätigen, ob eine Revalidierung eingeleitet wird oder der Änderungsumfang nachweislich außerhalb der Validierungsgrenzen liegt.
Gilt §7.5.6 auch für Software und IT-Systeme im QMS?
Ja. Software, die in der Produktion oder im QMS für qualitätsrelevante Entscheidungen eingesetzt wird, unterliegt der Validierungspflicht nach §7.5.6. Für Medizinprodukte-Software gilt zusätzlich IEC 62304 als Entwicklungsstandard. Wie die Einführung von QIMS selbst validiert werden kann, besprechen wir gern im Demo-Gespräch.
Prozessvalidierung nach ISO 13485 §7.5.6: Welche Prozesse, IQ/OQ/PQ und wann Revalidierung Pflicht ist →
Abgrenzung §7.3 Design-Validierung versus §7.5.6 Prozessvalidierung, vier reale Audit-Szenarien und typische Revalidierungsauslöser.
QIMS Feature · ÄnderungsmanagementÄnderungsmanagement: Wenn eine Änderung die Validierungsbasis berührt →
Geplant: Change-Records sollen in QIMS gegen die gespeicherten Parametergrenzen geprüft werden — der Revalidierungsauslöser als Pflichtfeld im Freigabe-Schritt.
QIMS Feature · CAPA-VerbindungReklamation & Vigilanz: Wenn CAPA eine Revalidierung auslöst →
Reklamationsereignisse mit systematischer Ursache können auf einen validierten Prozess hinweisen — CAPA und Revalidierungsvorhaben sollen in QIMS künftig verknüpft dokumentiert werden.
Prozess
validiert.
Nachweis
gesichert.
In einer Demo zeigen wir den heutigen Produktumfang von QIMS und besprechen die geplante Prozessvalidierung — acht Statusphasen, Vier-Augen-Freigabe je Phase, Parametergrenzen und Revalidierungsauslöser bei Change-Records.
Kein Pitch. Kein Abschlussgespräch nach dem Termin.