Inhaltsverzeichnis
Das Wichtigste vorab
Was bedeuten IQ, OQ und PQ bei Computersystemen?
IQ betrachtet die definierte Einrichtung, OQ die spezifizierte Funktion und PQ die Eignung im vorgesehenen Ablauf. Bei Computersystemen müssen diese Prüfziele zum tatsächlichen Einsatz und zu Annex 11 passen. Die Begriffe ergeben weder automatisch drei getrennte Dokumente noch ein Drei-Chargen-Schema. Entscheidend ist, dass geeignete Nachweise den betrachteten Stand und seine Risiken nachvollziehbar abdecken.
- Ordnen Sie jedem Nachweis eine konkrete Aussage über das System zu.
- Übertragen Sie Anlagenprüfungen nicht ungeprüft auf Software.
- Bewerten Sie Herstellerunterlagen gegen Ihren Einsatz und Ihre Konfiguration.
- Verknüpfen Sie Teilprüfungen mit dem vollständigen betrieblichen Ablauf.
1. Anlagenqualifizierung und Computersystemvalidierung zusammen einordnen
Dieser Leitfaden betrachtet Computersysteme im Humanarzneimittel-GMP-Umfeld. Am Quellenstand 6. Oktober 2026 führt die Europäische Kommission Annex 11 in der Revision Januar 2011 und Annex 15 in der seit Oktober 2015 geltenden Revision. Beide sind GMP-Leitlinien; Konsultationsentwürfe bilden hier keine zusätzliche Pflicht.
Annex 15 erläutert Qualifizierung und Validierung vor allem für Einrichtungen, Ausrüstung, Versorgungssysteme und Prozesse. Für Computersysteme verweist sein Grundsatz auf Annex 11. Dort werden die Validierung der Anwendung und die Qualifizierung der IT-Infrastruktur unterschieden. Ein Softwareprojekt lässt sich deshalb nicht durch bloßes Umbenennen einer Anlagenvorlage sinnvoll prüfen.
Verwenden Sie IQ, OQ und PQ als Ordnung für unterschiedliche Nachweisfragen. Die folgenden Tabellen und das Beispiel sind eigene Arbeitshilfen für diese Übertragung. Ob Ihre Organisation diese Bezeichnungen oder andere geeignete Begriffe nutzt, sollte zum geregelten Vorgehen passen. Eine andere Überschrift beseitigt keine fachliche Nachweislücke.
2. Drei Nachweisfragen vor der Dokumentenstruktur klären
Beginnen Sie mit dem vorgesehenen Ablauf und den Informationen, auf die eine Entscheidung gestützt wird. Fragen Sie anschließend, welche Annahmen über Installation, Funktion und Nutzung dafür stimmen müssen. So wird erkennbar, ob ein Beleg eine notwendige Voraussetzung, eine einzelne Funktion oder deren Zusammenspiel im Betrieb absichert.
Die Matrix ist eine Orientierung für ein Computersystem, keine verbindliche Zuordnung jedes Prüfpunkts. Ein Berechtigungstest kann beispielsweise zugleich die eingerichtete Rolle und ihre Wirkung prüfen. Beschreiben Sie beide Aussagen und ihre Voraussetzungen, statt denselben Versuch unter mehreren Überschriften zu vervielfachen.
| Prüfziel | Geeigneter Nachweis im Softwareprojekt | Was damit allein offen bleibt |
|---|---|---|
| IQ: definierter Stand eingerichtet | Abgleich von Anwendungsversion, Konfiguration, benötigten Diensten und Endpunkten mit der vorgesehenen Baseline | Ob fachliche Regeln korrekt arbeiten |
| OQ: spezifizierte Funktion wirksam | Ausgeführter Test einer zulässigen Aktion und relevanter Fehlerfälle mit vorab festgelegtem Soll | Ob der vollständige Routineablauf unter seinen tatsächlichen Bedingungen trägt |
| PQ: vorgesehener Ablauf geeignet | Durchgängiger Vorgang mit passenden Rollen, Daten, Schnittstellen und Arbeitsanweisungen | Nicht betrachtete Varianten, Betriebskontrollen oder spätere Änderungen |
3. IQ: Den eingerichteten Stand prüfbar machen
Eine brauchbare Installationsbasis beschreibt, was tatsächlich bereitgestellt wurde. Erfassen Sie für Ihren Scope beispielsweise Anwendungsversion, freigegebenen Konfigurationsstand, benötigte Laufzeitumgebung, Schnittstellenadresse und Zuordnung zur Testumgebung. Entscheidend ist nicht die längste Inventarliste, sondern die Wiedererkennbarkeit der Voraussetzungen für die folgenden Prüfungen.
Prüfen Sie außerdem, woran eine Abweichung erkennbar wäre. Ein Screenshot der Startseite kann eine sichtbare Versionsnummer belegen. Er zeigt jedoch nicht zwangsläufig, welcher Hintergrunddienst oder welche Druckerzuordnung wirksam ist. Wählen Sie den Beleg nach der konkreten Frage; technische Ausgaben, kontrollierte Konfigurationsauszüge oder Lieferantennachweise können unterschiedliche Teile beitragen.
Bei einem Cloud-Dienst ist die physische Installation häufig nicht Ihre eigene Aufgabe. Klären Sie dann, welche Aussage der Anbieter für seine Umgebung liefert und welche Mandanten-, Zugriffs- oder Integrationskonfiguration Sie selbst bestätigen müssen. Ein nicht zugänglicher Server rechtfertigt weder erfundene lokale Prüfprotokolle noch das Weglassen relevanter Voraussetzungen.
Halten Sie die Grenze fest: Eine korrekt bereitgestellte Anwendung kann weiterhin eine falsche fachliche Einstellung enthalten. Der Installationsnachweis ersetzt daher keinen Test dieser Einstellung.
4. OQ: Funktionen mit aussagekräftigen Fällen prüfen
Formulieren Sie vor der Ausführung, welches Verhalten eine Anforderung erfüllt. Zu einer zulässigen Buchung gehört beispielsweise die Frage, was bei fehlenden Pflichtdaten, unzulässiger Rolle oder unterbrochener Kommunikation geschehen soll. Für Computersysteme hebt Annex 11 Abschnitt 4.7 Grenzen und Fehlerbehandlung ausdrücklich hervor.
Leiten Sie die Daten aus dem betrachteten Risiko ab. Wenn ein Zahlendreher zu einer falschen Menge führen könnte, genügt ein Test mit einem einzigen beliebigen Wert kaum als Erklärung Ihrer Auswahl. Umgekehrt brauchen Sie keine mechanische Prüfung jeder denkbaren Kombination, wenn Sie nachvollziehbar zeigen, welche Fälle die relevante Wirkung abdecken.
Ein Test kann durch eine verborgene Voraussetzung falsch aussagekräftig werden. Kontrollieren Sie deshalb Benutzerrolle, Anfangsstatus und vorherige Daten. Wer eine Sperrfunktion mit einem Administrator ausführt, prüft möglicherweise einen anderen Ablauf als beabsichtigt. Der tatsächliche Zustand gehört in die Ausführungsbelege.
Trennen Sie das Soll vom Ergebnis. Wird erst nach dem Lauf entschieden, welches Verhalten akzeptabel sein soll, verliert der Vergleich seine Grundlage. Fachlich begründete Änderungen bleiben möglich, müssen aber als Änderung bewertet werden.
5. PQ: Den vollständigen Einsatz statt einer weiteren Klickfolge betrachten
Für die praktische Übertragung auf Software ist die zentrale Frage: Funktioniert der vorgesehene Arbeitsablauf mit den benötigten Menschen, Daten und Übergaben? Ein erfolgreich geprüfter Knopf beantwortet noch nicht, ob der nachfolgende Arbeitsplatz die richtige Information erhält oder ein Mitarbeiter eine Fehlersituation angemessen bearbeiten kann.
Wählen Sie einen repräsentativen Vorgang und begründen Sie die Auswahl. Ein Standort mit anderer Druckersteuerung oder eine Schnittstelle mit abweichendem Datenformat kann eine zusätzliche Variante darstellen. Zehn identische Durchläufe liefern dazu möglicherweise weniger Erkenntnis als ein gezielt anderer Ablauf.
Die MHRA erläutert in Abschnitt 6.19 ihrer Datenintegritätsleitlinie den Bezug von Validierung zum tatsächlichen Einsatzzweck. Lieferantentests losgelöst von Anwenderkonfiguration und Prozess reichen dafür nicht aus. Die britische Behördenorientierung ergänzt hier den EU-GMP-Rahmen; sie macht nicht jeden Lieferantennachweis wertlos.
Bei softwaregestützten Herstellanlagen können zusätzlich eigenständige Prozess- und Anlagennachweise erforderlich sein. Halten Sie deren Zweck getrennt sichtbar. Ein vollständiger IT-Ablauf ersetzt keine erforderliche Bewertung des Herstellprozesses.
6. Geeignete Nachweise kombinieren und Lieferantenbelege gezielt nutzen
Annex 15 sieht geeignete Kombinationen von Qualifizierungsdokumenten vor. Auch die öffentliche ISPE-Beschreibung des GAMP-Ansatzes unterstützt iterative und inkrementelle Spezifikation und Verifikation. Daraus folgt für die Planung kein Zwang, jedes Projekt in drei voneinander abgeschottete Dokumentenblöcke zu pressen.
Ein gemeinsames Protokoll kann zunächst den eingerichteten Stand bestätigen und anschließend darauf aufbauende Funktionen prüfen. Kennzeichnen Sie die Abhängigkeit: Wenn die benötigte Konfiguration nicht stimmt, bleibt die Aussage des nachfolgenden Tests eingeschränkt. Ein gemeinsamer Dateiname macht diese Voraussetzung nicht entbehrlich.
Übernommene Lieferantenergebnisse sollten die konkrete Frage beantworten können. Vergleichen Sie geprüfte Version, Einstellung, Daten, Akzeptanzkriterium und Ergebnis mit Ihrem Bedarf. Ein vollständig passender Beleg kann unnötige Wiederholung vermeiden. Eine Lücke führt zu einer gezielten Ergänzung, nicht automatisch zur Verwerfung des gesamten Pakets.
Dokumentieren Sie die Entscheidung dort, wo sie später auffindbar ist. Für KMU hilft eine kurze Zuordnung: Aussage, vorhandener Beleg, Reichweite, verbleibende lokale Prüfung. Die eigentliche Übernahmebewertung gehört in den dafür vorgesehenen Prozess.
7. Illustratives Beispiel: Vom Auftrag bis zum geprüften Etikett
Der folgende Fall ist vollständig konstruiert; er beschreibt keinen Kunden und keinen ausgeführten Produkttest. Eine Anwendung erzeugt Etiketten für interne Materialbehälter. Die Beispielanforderung lautet: Auftrag M-204 darf nur mit freigegebener Vorlage V3 und genau zugehöriger Materialkennung gedruckt werden. Bei Kommunikationsabbruch darf das System keinen nicht bestätigten Druck als abgeschlossen behandeln.
Als geplanter Stand werden Anwendung A2, Konfiguration K4, Schnittstellenprofil S1 und Drucker P1 festgehalten. Die lokalen Rollen heißen Vorbereitung und Druck. Diese Namen, Versionen und Regeln sind frei gewählt; sie sind weder Herstellerfunktionen noch allgemeine GMP-Vorgaben.
Der Prüfablauf beginnt bei einem kontrollierten Auftragsdatensatz, führt über Vorlagenauswahl und Übergabe zum Drucker und endet beim Abgleich von lesbarem Inhalt, maschinenlesbarer Kennung und Auftragsstatus. Für den Fehlerfall wird die Verbindung an einem vorab festgelegten Punkt unterbrochen. Bewertet wird das definierte Verhalten einschließlich Wiederaufnahme, nicht allein eine sichtbare Fehlermeldung.
| Schritt und Aussage | Konkrete Ausführung | Soll und Bewertung |
|---|---|---|
| Einrichtung, IQ-Bezug | A2/K4/S1 sowie Zuordnung P1 mit vorgesehener Baseline vergleichen | Übereinstimmung belegt die Voraussetzung; anderes Profil verhindert die geplante Aussage |
| Regelwirkung, OQ-Bezug | Für M-204 erst V2, dann V3 auswählen | V2 ist im Beispiel gesperrt; V3 enthält die festgelegte Materialkennung |
| Fehlerbehandlung, OQ-Bezug | Übertragung kontrolliert unterbrechen | Unbestätigter Druck bleibt offen; keine falsche Abschlussmeldung |
| Routineablauf, PQ-Bezug | Vorbereitung und Druck bearbeiten M-204 nach Arbeitsanweisung | Auftrag, lesbarer Text, geprüfte Kennung und Abschlussstatus stimmen zusammen |
| Wiederaufnahme, übergreifend | Nach Unterbrechung den vorgesehenen Wiederaufnahmeweg ausführen | Tatsächliche Drucklage wird geklärt; kein unkontrollierter zusätzlicher Druck |
8. Abweichungen und geänderte Voraussetzungen nachverfolgen
Führen Sie einen fehlgeschlagenen Lauf mit seinem ursprünglichen Ergebnis weiter. Beschreiben Sie erwartetes und tatsächliches Verhalten, betroffene Versionen, vermutete Reichweite und die nächste Untersuchung. Ein später bestandener Versuch erklärt nicht von selbst, warum der erste fehlgeschlagen ist.
Im Beispiel könnte eine Korrektur von K4 auf K5 die Statusbehandlung ändern. Prüfen Sie dann nicht nur erneut den Abbruch. Bewerten Sie auch, ob normaler Abschluss, Wiederaufnahme oder Doppelverarbeitung betroffen sein können. Der Umfang folgt der Änderung und ihrer Wirkung, nicht allein dem bisherigen Etikett IQ, OQ oder PQ.
Annex 15 Abschnitt 2.10 behandelt einen autorisierten Übergang zur nächsten Qualifizierungs- oder Validierungsstufe. Das ist keine allgemeine Erlaubnis zum Produktivstart mit kritischen offenen Punkten. Benennen Sie deshalb, welche nächste Tätigkeit ein bewerteter Zwischenstand tatsächlich tragen kann.
9. Mitwirkung und Aufwand nach den offenen Aussagen planen
Der Aufwand wächst insbesondere mit Varianten, Schnittstellen, unklaren Voraussetzungen und fehlender übertragbarer Evidenz. Eine umfangreiche Vorlage kann schnell ausgefüllt sein und trotzdem die lokale Übergabe übersehen. Planen Sie deshalb die benötigten fachlichen Beiträge, bevor Sie Seitenzahlen oder Testfallmengen schätzen.
Benötigt werden Kenntnisse über Prozess, Systemkonfiguration und geeignete Prüfung. Welche Person ausführt, bewertet oder autorisiert, folgt Qualifikation und geregelter Befugnis. Aus den drei Kürzeln ergibt sich keine feste Aufteilung zwischen Lieferant, IT, Fachbereich und QA.
Stellen Sie Testdaten, repräsentative Zugriffe und erreichbare Ansprechpartner bereit. Reservieren Sie außerdem Zeit für Befundklärung. Ein enger Termin ersetzt diese Mitwirkung nicht; ein sauber begrenzter Scope macht sie dagegen konkret planbar.
10. Checkliste vor Ausführung und Abschluss
Nutzen Sie die folgende Arbeitshilfe beim Durchgehen Ihres Prüfplans. Beantworten Sie jeden Punkt mit einem konkreten Verweis oder einer benannten offenen Aufgabe. Eine pauschale Bestätigung „IQ/OQ/PQ vorhanden“ verdeckt Unterschiede zwischen geplant, ausgeführt und fachlich bewertet.
Nach Abschluss müssen die zusammengeführten Ergebnisse den beantragten Einsatz tragen. Die anschließende Nutzungsentscheidung berücksichtigt darüber hinaus die benötigte Betriebsbereitschaft. Änderungen im späteren Betrieb werden erneut nach ihrer Auswirkung eingeordnet.
- Prozess, Systemgrenze und betrachteter Release sind eindeutig benannt.
- Für jede Prüfung ist die zu belegende Aussage formuliert.
- Benötigte Installation und Konfiguration sind vor der abhängigen Ausführung bestätigt.
- Akzeptanzkriterien und Sollwerte stehen vor dem Lauf fest.
- Lieferantenbelege sind auf ihre tatsächliche Reichweite bewertet.
- Normale Abläufe, relevante Grenzen und Fehlerfälle sind begründet ausgewählt.
- Mindestens die benötigten fachlichen Übergaben werden im Zusammenspiel betrachtet.
- Abweichungen, Korrekturen und Folgen für andere Nachweise bleiben nachvollziehbar.
- Ausführende und Entscheider verfügen über passende Qualifikation und Befugnis.
- Der Abschluss bezeichnet den belegten Stand und verbleibende Einschränkungen.
Häufige Fragen zu IQ, OQ und PQ
Müssen wir für jedes Computersystem drei getrennte IQ-, OQ- und PQ-Dokumente erstellen?
Nein. Entscheidend sind die benötigten Nachweisaussagen und ein nachvollziehbarer Zusammenhang. Annex 15 erlaubt geeignete Kombinationen von Qualifizierungsdokumenten. Legen Sie in Ihrem Vorgehen fest, wo Einrichtung, Funktion und vorgesehener Ablauf belegt werden. Ein kombiniertes Protokoll kann zweckmäßig sein, sofern Voraussetzungen, Ergebnisse und Bewertungen erkennbar bleiben. Organisatorische Vorgaben Ihres Qualitätssystems sind dabei zu berücksichtigen.
Was unterscheidet OQ und PQ bei einem softwaregestützten Ablauf?
Für die praktische Planung prüft OQ, ob spezifizierte Funktionen unter den betrachteten Bedingungen arbeiten. PQ richtet den Blick auf den vorgesehenen betrieblichen Ablauf. Eine korrekt arbeitende Vorlagenwahl belegt beispielsweise noch nicht die richtige Übergabe an den Druckarbeitsplatz. Einzelne Tests können beide Fragen unterstützen; beschreiben Sie ihre Reichweite und die noch nicht betrachteten Varianten.
Braucht eine Software-PQ grundsätzlich drei Chargen?
Aus den Kürzeln IQ, OQ und PQ folgt kein universelles Drei-Chargen-Schema für Computersysteme. Annex 15 behandelt auch Herstellprozesse und Anlagen; deren spezifische Anforderungen dürfen nicht pauschal auf jede Anwendung übertragen werden. Bestimmen Sie benötigte Abläufe und Wiederholungen nach dem Einsatzzweck. Ist das System Teil einer Prozessvalidierung, muss zusätzlich deren konkret anwendbarer Rahmen berücksichtigt werden.
Dürfen wir IQ/OQ-Ergebnisse des Herstellers übernehmen?
Ja, wenn ihre Aussage zu Ihrem betrachteten Stand und Bedarf passt. Prüfen Sie insbesondere Version, Konfiguration, Kriterien, Ausführung und Ergebnis. Die Übernahme kann vollständig, teilweise oder mit Ergänzungen erfolgen. Ein Herstellerpaket ohne Bezug zum lokalen Einsatzzweck beantwortet nicht automatisch Ihre offenen Fragen. Ebenso wäre es unzweckmäßig, passende Belege allein wegen ihrer Herkunft nochmals zu erzeugen.
Was bedeutet IQ bei einer Cloud-Anwendung ohne eigenen Server?
Klären Sie, welche Infrastruktur- und Bereitstellungsaussagen der Dienstleister trägt und welche lokalen Voraussetzungen verbleiben. Dazu können Mandantenstand, wirksame Konfiguration, Rollen oder Integrationsendpunkte gehören. Diese Auswahl ist einsatzabhängig. Verlangen Sie keine erfundenen lokalen Installationsnachweise für fremd betriebene Server; bewerten Sie geeignete Anbieterbelege und die davon nicht erfassten eigenen Einstellungen.
Wer muss IQ, OQ und PQ durchführen und freigeben?
Die Zuordnung folgt benötigter Kompetenz und den Befugnissen Ihrer Organisation. Die Kürzel schreiben keine feste Rollenverteilung vor. Technisches Wissen kann für einen Installationsabgleich nötig sein, Prozesswissen für die Bewertung einer fachlichen Übergabe. Legen Sie Ausführung, Bewertung, Autorisierung und Stellvertretung konkret fest. Angemessene Qualitätsaufsicht bleibt Teil des geregelten Validierungsvorgehens.
Kann ein bestandener PQ-Lauf einen offenen OQ-Fehler ausgleichen?
Nicht allein durch sein Bestehen. Prüfen Sie, ob der PQ-Lauf den Fehler überhaupt erfasst und unter vergleichbaren Voraussetzungen ausgeführt wurde. Im Etikettierbeispiel sagt ein erfolgreicher Normaldruck nichts über die falsche Abschlussmeldung nach Abbruch. Bewerten Sie den Befund, seine Reichweite und notwendige Korrekturen ausdrücklich. Ein späteres positives Ergebnis ersetzt diese Untersuchung nicht.
Muss nach jedem Update die gesamte IQ/OQ/PQ wiederholt werden?
Bestimmen Sie zunächst, welche Voraussetzungen und Aussagen sich durch das Update ändern. Ein neuer Schnittstellenstand kann andere Nachweise betreffen als eine rein redaktionelle Hilfeänderung. Leiten Sie daraus Bestätigungen, Wiederholungen und gegebenenfalls zusätzliche Prüfungen ab. Der bestehende Nachweis muss zum weitergenutzten Stand passen; weder vollständige Wiederholung noch vollständiger Verzicht ist ohne diese Bewertung begründet.
Sind Screenshots als alleiniger Nachweis ausreichend?
Das hängt von der Aussage ab. Ein Screenshot kann einen sichtbaren Status zeigen, aber nicht automatisch dessen Datenquelle oder das Verhalten nach einem Verbindungsabbruch. Kombinieren Sie bei Bedarf beobachtbares Ergebnis, technische Aufzeichnung und fachlichen Abgleich. Benennen Sie Ausführung, Stand und Kontext so, dass der Beleg verständlich bleibt. Die Anzahl der Bilder ist kein Maß für die erreichte Absicherung.
Quellen: [2]
Ist nach abgeschlossener IQ/OQ/PQ das System automatisch produktiv freigegeben?
Nein. Die Ergebnisse sind eine Grundlage für die Entscheidung über den konkreten Einsatz. Offene Befunde, Betriebsprozesse, Schulung und Zuständigkeiten müssen ebenfalls passend bewertet sein. Annex 15 Abschnitt 2.10 beschreibt einen Stufenübergang im Qualifizierungs- und Validierungsprozess, keine pauschale Produktivfreigabe. Dokumentieren Sie deshalb den beantragten Nutzungsumfang und die dafür tatsächlich erfüllten Voraussetzungen.
Quellen & fachlicher Stand
Quellenstand: 6. Oktober 2026. Schwerpunkt Humanarzneimittel-GMP. Tabellen, Checkliste und Etikettierfall sind eigene Arbeitshilfen. Die MHRA-Leitlinie dient als ergänzende britische Behördenorientierung. Von GAMP wurde die öffentliche Verlagsübersicht gelesen, nicht der kostenpflichtige Volltext.
- Europäische Kommission: EudraLex Volume 4
- Europäische Kommission: EU-GMP Annex 11 – Computerised Systems
- Europäische Kommission: EU-GMP Annex 15 – Qualification and Validation
- ISPE: GAMP 5 Guide, 2nd Edition – öffentliche Verlagsübersicht
- MHRA: GxP Data Integrity Guidance and Definitions
- ICH Q9(R1): Quality Risk Management – offizielle EU-Fassung
Zuletzt fachlich geprüft am 06.10.2026.
Daniel Herrmann Consulting
Passende Nachweise für Ihren Systemstand planen
Wir helfen Ihnen, vorhandene Unterlagen und offene Prüfziele zu einer nachvollziehbaren Nachweisstrategie zu verbinden. Dabei betrachten wir den tatsächlichen Ablauf, seine Voraussetzungen und die benötigte Mitwirkung.
- IT-GxP-Consulting →
Prüfziele, geeignete Nachweise und konkrete Ergänzungen gemeinsam ausarbeiten.
- IT-GxP-Audit →
Vorhandene Qualifizierungs- und Validierungsbelege auf ihre Aussagekraft prüfen.