Inhaltsverzeichnis
Das Wichtigste vorab
Kann ein Herstellerpaket eigene Validierungsnachweise ersetzen?
Geeignete Herstellerbelege können für bestimmte Anforderungen übernommen werden, wenn Umfang, Qualität und Übertragbarkeit begründet sind. Prüfen Sie die tatsächlich untersuchte Version und Konfiguration, die Testumgebung, ausgeführte Ergebnisse und relevante Abweichungen. Ein Paket muss weder pauschal vollständig wiederholt werden noch automatisch nur Standardfunktionen abdecken. Entscheidend ist die belegte Passung zum vorgesehenen Gebrauch; verbleibende Lücken erhalten gezielte Maßnahmen.
- Bewerten Sie jeden übernommenen Nachweis gegen eine eigene Anforderung und deren Akzeptanzkriterien.
- Ein geeigneter Lieferant und ein geeigneter Einzelnachweis beantworten unterschiedliche Fragen.
- Unterschiedliche Umgebungen schließen eine Übernahme nicht automatisch aus; ihre Bedeutung muss geklärt sein.
- Dokumentieren Sie Übertragungsbedingungen, verbleibende Tests und die spätere Änderungsbewertung.
1. Den Übernahmeentscheid von der Lieferantenbewertung trennen
Die Lieferantenbewertung untersucht, ob ein Anbieter und seine Leistungen angemessen beherrscht sind. Hier geht es um eine engere Entscheidung: Welcher konkrete Beleg unterstützt welche Anforderung Ihres Systems? Ein positiv bewerteter Softwarehersteller kann Unterlagen liefern, die für eine bestimmte Schnittstelle ungeeignet sind. Umgekehrt kann ein Partnerbericht Ihren individuellen Ablauf einschließlich negativer Prüffälle bereits sorgfältig abdecken. Beides lässt sich nur am Inhalt erkennen. Auch ein Auditbericht kann konkrete passende Evidenz enthalten; seine Aussagekraft richtet sich nach dem tatsächlich untersuchten Umfang.
Der regulatorische Beispielrahmen dieses Beitrags ist Humanarzneimittel-GMP. Annex 11 ist eine GMP-Leitlinie; die aktuell verlinkte Fassung behandelt unter anderem Anwenderanforderungen, Lieferantendokumentation und risikobasierte Validierung. Annex 15 ergänzt Gesichtspunkte zur Verwendung externer Daten und zur Eignung fremder Prüfprotokolle. Seine Qualifizierungsbeispiele sind kein pauschaler Freibrief für jede Cloudanwendung.
Die folgenden Matrizen sind eigene Arbeitshilfen. Sie ersetzen weder die Bewertung des konkreten Regelbereichs noch Ihre geregelte Abschlussentscheidung. Für Medizinprodukte, andere GxP-Bereiche oder einen zusätzlichen US-Bezug ist die Anwendbarkeit gesondert festzulegen. Aus dem Einkauf eines Pakets entsteht keine allgemeine Compliance-Zusage.
2. Mit Ihrer Anforderung und dem benötigten Ergebnis beginnen
Legen Sie zunächst fest, welche Aussage Sie belegen wollen. „CAPA funktioniert“ ist dafür zu ungenau. Brauchen Sie einen Nachweis zur Abschlussberechtigung, zur Wirksamkeitsbewertung, zur Fristenberechnung oder zur unveränderten Übertragung eines Datensatzes? Jede dieser Fragen kann andere Voraussetzungen und Belege haben. Verweisen Sie auf eine eindeutige Anforderungskennung mit Version, statt den Herstellertest lediglich einer allgemeinen Modulüberschrift zuzuordnen.
Beschreiben Sie außerdem den vorgesehenen Gebrauch: beteiligte Rollen, verwendete Daten, aktivierte Funktionen, relevante Schnittstellen und Abhängigkeiten. Halten Sie fest, welches fehlerhafte Ergebnis den Prozess beeinträchtigen würde. Daraus ergibt sich, wie genau Sie Testergebnis und Übertragbarkeit beurteilen müssen. Die bloße Zahl vorhandener Testfälle sagt darüber wenig aus.
Markieren Sie Anforderungen außerhalb des Lieferumfangs ausdrücklich. So wird eine organisatorisch geregelte Entscheidung nicht versehentlich als Softwarefunktion behandelt. Diese Vorarbeit kann bestehende URS, Prozessbeschreibung und Konfigurationsliste verknüpfen; ein zusätzliches umfangreiches Dokument ist nicht automatisch notwendig. Annex 11 verlangt nachvollziehbare Anwenderanforderungen, schreibt hierfür aber keine bestimmte Tabellenanwendung vor.
Quellen: [2]
3. Paket, Produktstand und tatsächlichen Lieferumfang identifizieren
Erfassen Sie Dokumentkennung, Revision, Datum und den zugehörigen Produktstand. Unterscheiden Sie geplante Prüfungen von ausgeführten Protokollen, Zusammenfassungen von Einzelergebnissen sowie Produktunterlagen von Implementierungsbelegen. Eine Datei namens „Validation Report“ kann sehr unterschiedliche Inhalte haben. Entscheidend ist, ob der benötigte Zusammenhang zwischen geprüfter Funktion, Voraussetzungen und Ergebnis nachvollziehbar bleibt.
Ein reales Organisationsbeispiel liefert Qualio: Die geöffnete Herstellerseite „Validation Resources“ beschreibt Feature-ValPacks nach Launch Train beziehungsweise Release und unterscheidet Dokumentationsbereiche. Historische Unterlagen werden ebenfalls angeboten. Daraus lässt sich eine versionsbezogene Ablagestruktur erkennen. Die öffentlich gelesene Übersichtsseite belegt jedoch weder den Inhalt eines bestimmten Testberichts noch dessen Eignung für Ihre Konfiguration.
Prüfen Sie deshalb den tatsächlich erhaltenen Lieferumfang. Er kann Standardfunktionen, konfigurierte Abläufe oder kundenspezifische Leistungen enthalten. Verlangen Sie keine erneuten Tests allein deshalb, weil sie extern ausgeführt wurden. Akzeptieren Sie ebenso wenig eine unbestimmte Verweisung auf „aktuelle Unterlagen“, wenn die Zuordnung zum bewerteten Systemstand offenbleibt.
4. Eine kommentierte Entscheidungszeile je Nachweis führen
Die folgende Arbeitshilfe verbindet Anforderung und Beleg. Verwenden Sie bei mehreren unabhängig entscheidbaren Anforderungen getrennte Zeilen oder Untereinträge. Gleiche Dokumente dürfen mehrfach referenziert werden; sie müssen dafür nicht mehrfach abgelegt werden. Trennen Sie dabei die Feststellung, dass ein Nachweis grundsätzlich passt, von noch ungeklärten Voraussetzungen seiner Verwendung.
Ein Übernahmeentscheid sollte in verständlichen Worten enden. Beispielsweise: „Beleg P-17 deckt den beschriebenen Negativfall für Konfiguration K-0 ab; für K-1 ist die identische Steuerungslogik noch zu bestätigen.“ Eine offene Voraussetzung wird dadurch sichtbar und erhält einen Verantwortlichen. Das ist aussagekräftiger als ein grünes Feld „Paket vorhanden“.
| Feld | Was Sie eintragen | Warum es die Entscheidung verändert |
|---|---|---|
| Eigene Anforderung | Kennung, Revision, Akzeptanzkriterium und vorgesehener Gebrauch | Eine allgemeine Produktfunktion ist nicht automatisch das benötigte Ergebnis. |
| Externer Beleg | Dokumentrevision, Testfall und tatsächlich ausgeführter Schritt | Eine Vorlage allein belegt noch keine erfolgreiche Durchführung. |
| Version und Konfiguration | Geprüfter Stand; Vergleich mit Ihrem Einsatz | Abweichungen können die geprüfte Logik betreffen oder begründet unerheblich sein. |
| Testumgebung | Relevante Rollen, Daten, Dienste und Schnittstellen | Unterschiede werden nach ihrer Wirkung bewertet. |
| Ergebnis und Abweichung | Beobachtung, Akzeptanzbewertung, verknüpfte Feststellungen | Ein Gesamtstatus darf widersprechende Einzelergebnisse nicht verdecken. |
| Übertragungsbedingung | Was für die Nutzung des Belegs nachweislich gelten muss | Eine Annahme wird als zu prüfende Bedingung erkennbar. |
| Restnachweis | Konkrete offene Frage, vorhandene Ergänzung oder gezielter Test | Ergänzung folgt der Lücke, nicht pauschal dem ganzen Paket. |
| Entscheidung | Begründung, Zuständiger, Freigabestand und Wiedervorlageanlass | Der spätere Leser erkennt Umfang und Grenzen der Übernahme. |
5. Ausgeführte Ergebnisse und Abweichungen wirklich lesen
Verfolgen Sie bei relevanten Testfällen die Kette von Voraussetzung über Handlung und Beobachtung bis zur Bewertung. Ein erwartetes Ergebnis in einer leeren Vorlage ist noch kein beobachtetes Ergebnis. Ein Screenshot kann eine wichtige Beobachtung belegen, erklärt aber allein häufig nicht, welche Rolle, Konfiguration oder Eingabekombination verwendet wurde. Umgekehrt ist nicht für jede Aussage zwingend ein Screenshot die beste Evidenz.
Prüfen Sie offene Abweichungen auf ihre Bedeutung für Ihre Anforderung. Wurde ein fehlgeschlagener Schritt nur aus dem Umfang entfernt? Betrifft ein bekannter Fehler die verwendete Funktion? Ist eine Korrektur mit passender Version und Nachweis verknüpft? Eine abgeschlossene Lieferantenfeststellung beantwortet nicht automatisch, ob eine kundenspezifische Auswirkung erledigt ist.
Fehlende Einzelheiten führen zunächst zu einer gezielten Rückfrage. Möglicherweise existiert ein ergänzender Bericht oder eine nachvollziehbare Begründung. Erst wenn der benötigte Nachweis dadurch nicht entsteht, bestimmen Sie eine passende Ergänzung. Die Kriterien für fremde Protokolle und die Behandlung von Abweichungen finden sich insbesondere in Annex 15; Umfang und Anwendung auf das Computersystem bleiben begründet festzulegen.
6. Unterschiede nach ihrer Wirkung auf das Ergebnis bewerten
Gleicher Produktname bedeutet nicht gleiche Prüfbasis. Vergleichen Sie insbesondere Funktionsstand, relevante Parameter, Rollenmodell, Zeitzonen, Datenformate und angebundene Dienste. Ein Unterschied ist weder automatisch bedeutungslos noch automatisch ein Ausschlussgrund. Fragen Sie, ob er den geprüften Mechanismus, seine Eingangsdaten oder das fachliche Ergebnis verändern kann.
Bei einer Schnittstelle kann ein Hersteller die Annahme gültiger Nachrichten nachgewiesen haben, während Ihr Partner zusätzlich Feldzuordnung, Wiederholung und Fehlerbehandlung geprüft hat. Zusammen können diese Belege einen Prozess weitgehend abdecken. Bleibt lediglich die konkrete Berechtigungszuordnung offen, ist ein gezielter Nachweis dazu hilfreicher als eine vollständige Wiederholung der Schnittstellentests.
Dokumentieren Sie die Begründung auch bei als unerheblich bewerteten Unterschieden. Verweisen Sie dafür beispielsweise auf eine bestätigte Konfiguration oder einen freigegebenen Vergleich. Die erforderliche Detailtiefe richtet sich nach der betroffenen Funktion. Annex 11 spricht die Eignung von Testumgebungen an; daraus folgt kein universeller Anspruch, dass externe und produktive Umgebung in jedem Detail identisch sein müssen.
Quellen: [2]
7. Ein konstruiertes CAPA-Beispiel Schritt für Schritt durchgehen
Das folgende Szenario ist vollständig illustrativ: kein Kundenfall, kein ausgeführter Produkttest und keine Aussage über Qualio. Ein Unternehmen plant einen CAPA-Ablauf auf dem erfundenen Systemstand S-2. Die eigene Anforderung CAP-01, Revision 1.2, erlaubt den Abschluss erst nach dokumentierter Wirksamkeitsbewertung. Die Referenzkonfiguration heißt K-0, die vorgesehene Konfiguration K-1. Diese Kennungen dienen ausschließlich der Erklärung.
Im angenommenen Herstellerbericht P-17 werden ein Abschlussversuch ohne Wirksamkeitsbewertung und anschließend ein zulässiger Abschluss beschrieben. Voraussetzungen, Beobachtungen und Bewertung sind nachvollziehbar; für diese Funktion bestehen im Szenario keine offenen berichteten Abweichungen. Ein bestätigter Konfigurationsvergleich zeigt, dass K-1 die betreffende Abschlussbedingung unverändert nutzt. Damit kann dieser Nachweis für CAP-01 begründet übernommen werden.
Die eigene Rolle „QA-Entscheider“ ist jedoch anders zugeordnet als die Referenzrolle. Die Anforderung CAP-02 zur Berechtigung ist damit noch nicht erledigt. Zusätzlich verwendet der gewünschte Erinnerungsablauf Arbeitstage, während der angenommene Beispieltest Kalendertage nutzt. Beide Unterschiede werden separat bearbeitet. Ein passender Partnernachweis könnte sie bereits schließen; andernfalls planen Sie genau die fehlenden Prüfungen.
8. Übernahme, Bedingung und Resttest getrennt entscheiden
Die zweite Arbeitshilfe setzt das Beispiel fort. Alle Dokumente und Ergebnisse sind erfunden. Sie zeigt, weshalb ein Paket für manche Anforderungen unmittelbar nützlich sein kann und für andere nicht ausreicht. „Ergänzen“ bedeutet dabei zunächst einen fehlenden Nachweis beschaffen; erst danach steht fest, ob ein neuer Test erforderlich ist.
Wenn Sie testen müssen, schreiben Sie die offene Frage vor der Durchführung auf. Beim Arbeitstage-Beispiel wären ein Wochenende und der verwendete Feiertagskalender gezielte Bedingungen. Erwartete Termine werden aus der vereinbarten Fachregel abgeleitet. Das Ergebnis darf nicht erst nach Beobachtung des Systemverhaltens passend definiert werden.
| Eigene Anforderung | Angenommener verfügbarer Beleg | Begründete Entscheidung | Verbleibender Nachweis |
|---|---|---|---|
| CAP-01: Wirksamkeitsbewertung vor Abschluss | P-17 prüft Negativ- und Positivfall in K-0; Vergleich bestätigt unveränderte Bedingung in K-1. | Für diese Bedingung übernehmen. | Keine Wiederholung ohne zusätzlichen Anlass; Vergleich und Bericht referenzieren. |
| CAP-02: Abschluss nur durch berechtigte Rolle | P-17 prüft Referenzrolle; Zuordnung der eigenen Rolle fehlt. | Mechanismus nutzbar, eigene Zuordnung offen. | Geeigneten Partnerbeleg beschaffen oder erlaubten und unerlaubten Abschluss gezielt prüfen. |
| CAP-03: Erinnerung nach vereinbarten Arbeitstagen | P-22 prüft Kalendertage; tatsächliches Ergebnis ist nachvollziehbar. | Belegt die eigene Fristenregel nicht. | Kalenderkonfiguration und relevante Grenzfälle nachweisen. |
| CAP-04: ERP-Rückmeldung der richtigen CAPA zuordnen | P-31 prüft Nachrichtenannahme; kundenspezifische Zuordnung ist nicht enthalten. | Schnittstellenbasis teilweise nutzbar. | Mapping, Zuordnung und Fehlerfall anhand passender Integrationsbelege schließen. |
9. Den Entscheid bei Änderungen nachvollziehbar erhalten
Bewahren Sie die verwendete Belegrevision und den Übernahmeentscheid zusammenhängend auf. Ein Link auf einen fortlaufend ersetzten Download ist als alleinige Identifikation häufig ungeeignet. Klären Sie Zugriff, Bereitstellung und vertragliche Möglichkeiten der Aufbewahrung rechtzeitig. Es geht um nachvollziehbare Evidenz, nicht um eine unnötige Kopiensammlung oder die Umgehung von Nutzungsrechten.
Bei einer Änderung prüfen Sie, welche Voraussetzungen betroffen sind. Ändert ein Release die Abschlusslogik, muss der CAP-01-Entscheid erneut betrachtet werden. Betrifft es einen ungenutzten Bereich ohne relevante Abhängigkeit, kann die Bewertung entsprechend kurz ausfallen. Die Zuordnung ermöglicht damit gezielte Neubewertungen statt einer automatischen Vollwiederholung.
Annex 11 behandelt kontrollierte Änderungen und periodische Bewertung. Bei tatsächlich ausgelagerten GMP-Tätigkeiten kommen die passenden Verantwortungs- und Aufzeichnungsregelungen aus Kapitel 7 hinzu. Nicht jeder Softwarekauf ist deshalb pauschal eine ausgelagerte GMP-Tätigkeit. Vereinbaren Sie die benötigte Nachweisversorgung entsprechend der wirklich übernommenen Leistung.
10. Mit einem überschaubaren Arbeitsstand beginnen
Für den Start benötigen Sie einen ausreichend geklärten Einsatz, die betroffenen Anforderungen, den aktuellen Systemstand und Zugang zu den relevanten Unterlagen. Der Prozessverantwortliche erläutert das fachliche Ergebnis; IT oder Systemverantwortlicher klären Konfiguration und Abhängigkeiten; QA beurteilt den geregelten Nachweis- und Entscheidungsweg. Der Anbieter beantwortet konkrete Lücken im gelieferten Material.
Der Aufwand hängt vor allem von der Nachvollziehbarkeit der Belege, den Unterschieden zum eigenen Einsatz und der Bedeutung verbleibender Lücken ab. Ein großes Paket kann wenig Klärung brauchen; ein kurzes Dokument kann zeitaufwendige Rückfragen auslösen. Beginnen Sie deshalb mit einer wichtigen Anforderung und erproben Sie daran die Entscheidungsstruktur, bevor Sie den gesamten Bestand bearbeiten.
- Anforderung, Revision und Akzeptanzkriterium eindeutig benannt.
- Belegrevision, Produktstand und tatsächliche Durchführung identifiziert.
- Relevante Konfigurations- und Umgebungsunterschiede bewertet.
- Ergebnis und betroffene Abweichungen nachvollzogen.
- Übertragungsbedingungen belegt oder als offen mit Zuständigkeit markiert.
- Restnachweis konkret beschrieben und geeignete vorhandene Ergänzungen geprüft.
- Entscheid und spätere Neubewertungsanlässe dokumentiert.
Häufige Fragen zu Hersteller-Nachweise
Ist ein Validierungspaket nach positiver Lieferantenbewertung automatisch nutzbar?
Nein. Die Lieferantenbewertung schafft Vertrauen in Anbieter und Leistung, beantwortet aber nicht jede Frage zur Eignung eines bestimmten Berichts. Prüfen Sie dessen Bezug zu eigener Anforderung, Systemstand und Einsatzbedingungen. Nutzen Sie bereits erhobene Lieferanteninformationen als Hintergrund, ohne daraus einen unbegrenzten Übernahmeentscheid abzuleiten. So vermeiden Sie doppelte Anbieterfragen und behalten die konkrete Nachweislücke im Blick.
Quellen: [2]
Deckt ein Herstellerpaket immer nur unveränderte Standardfunktionen ab?
Das lässt sich nicht pauschal sagen. Der tatsächliche Lieferumfang kann auch konfigurierte oder kundenspezifische Prüfungen enthalten. Lesen Sie Vertrag, Protokolle und Ergebnisse gemeinsam. Ein passender Implementierungsbericht kann beispielsweise Ihren Rollenablauf bereits prüfen. Umgekehrt sollte eine allgemein gehaltene Paketbeschreibung nicht als Beleg für solche Leistungen gelten. Entscheidend ist die nachvollziehbare Abdeckung.
Müssen wir übernommene Tests vorsichtshalber vollständig wiederholen?
Eine pauschale Wiederholung ersetzt keine Eignungsbewertung. Wenn vorhandene Evidenz die Anforderung unter passenden Bedingungen zuverlässig abdeckt, begründen Sie ihre Nutzung. Wenn Bedingungen offenbleiben, beschaffen Sie eine passende Ergänzung oder planen einen gezielten Test. Dokumentieren Sie, welche Frage dadurch beantwortet wird. Der Umfang folgt dem konkreten Risiko und der Beleglage, nicht der bloßen Herkunft des Tests.
Können Belege einer älteren Version noch verwendet werden?
Unter Umständen ja. Entscheidend ist, ob der belegte Mechanismus und seine relevanten Voraussetzungen für den aktuellen Einsatz weiterhin passen. Dafür brauchen Sie eine nachvollziehbare Änderungsbewertung, nicht nur einen ähnlich klingenden Versionsnamen. Historische Unterlagen können die Kette unterstützen. Eine Herstellerablage nach Release hilft bei der Zuordnung, ersetzt aber die Bewertung der betroffenen Funktion nicht.
Reicht eine Zusammenfassung mit dem Ergebnis „bestanden“?
Sie kann Teil der Evidenz sein, muss aber die benötigte Aussage tragen. Wenn Prüfumfang, Systemstand, Kriterien oder relevante Abweichungen daraus nicht erkennbar sind, fordern Sie gezielt ergänzende Angaben an. Eine Zusammenfassung ist nicht allein wegen ihrer Kürze ungeeignet. Ebenso beweist ein umfangreicher Bericht wenig, wenn der Zusammenhang zwischen Beobachtung und eigener Anforderung unklar bleibt.
Quellen: [3]
Muss die Hersteller-Testumgebung unserer Umgebung vollständig entsprechen?
Nicht jedes Detail muss identisch sein. Untersuchen Sie diejenigen Unterschiede, die das Ergebnis beeinflussen können: etwa Rollen, Daten, Schnittstellen, Parameter oder Dienste. Begründen Sie die Übertragbarkeit oder benennen Sie die offene Bedingung. Die bloße Aussage „anderes Testsystem“ ist ebenso wenig ausreichend wie „gleiche Software“. Maßgeblich ist die Eignung der Umgebung für die geprüfte Aussage.
Quellen: [2]
Was tun wir mit einer offenen Abweichung im Herstellerbericht?
Klären Sie, welche eigene Anforderung und welcher Einsatzfall betroffen sind. Berücksichtigen Sie Korrekturstand, verfügbare Ergänzungen und mögliche Auswirkungen. Eine offene Abweichung darf nicht durch den Gesamtstatus des Pakets verschwinden. Ob ein Beleg trotzdem für einen klar begrenzten anderen Sachverhalt nutzbar bleibt, ist nachvollziehbar zu entscheiden; daraus folgt keine automatische Freigabe des Gesamtsystems.
Wer sollte einen Übernahmeentscheid fachlich bearbeiten?
Binden Sie die Personen ein, die Anforderung, Systemkonfiguration und geregelten Nachweisweg beurteilen können. Das sind typischerweise Prozessverantwortlicher, Systemverantwortlicher oder IT und QA, ergänzt durch den Anbieter bei Rückfragen. Rollen können in einem KMU zusammenfallen, sofern Zuständigkeit und Kompetenz klar bleiben. Eine feste universelle Unterschriftenzahl ergibt sich daraus nicht.
Quellen: [2]
Was müssen wir vor Beginn bereitstellen, und was treibt den Aufwand?
Hilfreich sind eine abgegrenzte Nutzung, identifizierte Anforderungen, der aktuelle Konfigurationsstand und zugängliche Berichte. Aufwand entsteht durch unklare Zuordnung, fehlende Ergebnisse, relevante Unterschiede und ungeklärte Abweichungen. Lassen Sie eine wichtige Anforderung probeweise vollständig bearbeiten. Das zeigt konkrete Informationslücken und beteiligte Rollen zuverlässiger als eine Schätzung allein anhand der Paketgröße.
Wann muss ein bereits dokumentierter Übernahmeentscheid erneut betrachtet werden?
Wenn sich seine Voraussetzungen ändern können: etwa durch ein relevantes Release, eine Konfigurationsänderung, neue Schnittstelle oder bekannt gewordene Abweichung. Nutzen Sie die bestehende Zuordnung, um betroffene Anforderungen zu finden. Die periodische Bewertung kann zusätzlich erkennen, ob der Gesamtstand noch passt. Eine universelle jährliche Neuerstellung aller Übernahmeentscheidungen ist daraus nicht abzuleiten.
Quellen: [2]
Quellen & fachlicher Stand
Quellen am 6. Oktober 2026 geöffnet. Regulatorischer Beispielrahmen ist Humanarzneimittel-GMP. Kapitel 7 betrifft tatsächlich ausgelagerte GMP-Tätigkeiten. Die Qualio-Übersichtsseite belegt die beschriebene Dokumentorganisation; einzelne ValPacks und ihre Prüfergebnisse wurden nicht untersucht. Beide Tabellen, das CAPA-Szenario und die Checkliste sind eigene illustrative Arbeitshilfen.
- Europäische Kommission: EudraLex Volume 4, aktuelle Übersicht der GMP-Leitlinien
- EU-GMP Annex 11: Computerised Systems, Revision Januar 2011
- EU-GMP Annex 15: Qualification and Validation, Revision 2015
- EU-GMP Kapitel 4: Documentation, Revision Januar 2011
- EU-GMP Kapitel 7: Outsourced Activities, Revision 2012
- Qualio: Validation Resources, Stand 23. Mai 2026
Zuletzt fachlich geprüft am 06.10.2026.
Daniel Herrmann Consulting
Herstellerbelege in belastbare eigene Entscheidungen übersetzen
Daniel Herrmann Consulting unterstützt Sie dabei, vorhandene Nachweise konkreten Anforderungen zuzuordnen, Übertragungsbedingungen zu klären und verbleibende Prüfungen gezielt zu planen.
- IT-GxP-Audit →
Vorhandene Pakete, Belegqualität und konkrete Nachweislücken einordnen.
- IT-GxP-Consulting →
Übernahmeentscheidungen, Ergänzungen und Änderungsbewertung gemeinsam ausarbeiten.