Elektronische Batch Records validieren: Vendor-Änderungen kontrolliert steuern

Elektronische Batch Records zu validieren bedeutet mehr als Masken, Berechnungen und Signaturen zu testen. Der Nachweis muss auch zeigen, dass nachträgliche Änderungen nur autorisiert, im nativen Audit Trail erfasst, durch das Qualitätssystem bewertet und vor der Chargenentscheidung unabhängig geprüft werden. Das gilt besonders für Eingriffe durch Softwareanbieter und Supportteams.

Warum ein Support-Ticket keinen kontrollierten Änderungsnachweis ersetzt

Ein elektronischer Batch Record bündelt Daten, Entscheidungen und Verantwortlichkeiten eines Herstellprozesses. Genau deshalb ist eine Änderung nach Abschluss des Records besonders kritisch. Sie kann Benutzerzuordnungen, Prozessparameter, Zeiten, Materialmengen, Berechnungen oder Freigabeinformationen betreffen.

Ein FDA Warning Letter an Intas Pharmaceuticals vom 30. März 2026 zeigt das Risiko konkret. Laut Schreiben hatte ein QA-Mitarbeiter einen Softwareanbieter angewiesen, Daten in einem abgeschlossenen elektronischen Batch Record zu ändern. Unter anderem wurde eine Mitarbeiterkennung ersetzt. Die Änderung erschien weder im Audit Trail noch im elektronischen Batch Record und wurde nicht durch das Qualitätssystem gesteuert.

Welche Kontrolllücken bei Benutzerrechten, Audit Trails, Rohdaten und Vendor-Änderungen wiederkehren, zeigt der ergänzende Überblick zu aktuellen FDA Warning Letters zu Datenintegrität.

Der Warning Letter adressiert diesen konkreten Empfänger und Sachverhalt. Er ist kein neues allgemeines Regelwerk. Das Beispiel zeigt jedoch, wie bestehende CGMP-Anforderungen auf Vendor-Eingriffe angewendet werden: Ein technisch ausgeführter Supportvorgang bleibt eine Änderung an einem regulierten Record.

Für System Owner folgt daraus eine klare Trennung. Ein Ticket kann Anfrage, Kommunikation und technische Bearbeitung dokumentieren. Es ersetzt aber nicht automatisch Abweichung, Change Control, Audit Trail, Auswirkungsbewertung und Quality Oversight.

Was der regulatorische Rahmen für elektronische Batch Records verlangt

21 CFR 211.188 verlangt vollständige Informationen über Herstellung und Kontrolle jeder Charge. Dazu gehören auch die Personen, die wesentliche Schritte durchführen, überwachen oder prüfen. 21 CFR 211.68 verlangt angemessene Kontrollen über automatische und elektronische Systeme sowie die Kontrolle autorisierter Änderungen.

EU GMP Annex 11 ergänzt für europäische GMP-Organisationen mehrere relevante Kontrollebenen:

• Verantwortlichkeiten externer Anbieter müssen in formalen Vereinbarungen klar geregelt sein.
• GMP-relevante Änderungen und Löschungen sollen risikobasiert durch einen systemgenerierten Audit Trail erfasst werden.
• Änderungen an System und Konfiguration müssen kontrolliert nach einem definierten Verfahren erfolgen.
• Der validierte Zustand ist periodisch zu bewerten.
• Zugriffe müssen auf autorisierte Personen beschränkt und Änderungen an Berechtigungen aufgezeichnet werden.
• Bei elektronischer Chargenfreigabe muss das System die freigebende Person eindeutig identifizieren und aufzeichnen.

Diese Anforderungen sind kein einzelnes „EBR-Protokoll“. Sie bilden ein Kontrollsystem aus Technik, Verfahren, Rollen und Review. Die GxP-Systemvalidierung muss zeigen, dass dieses System im vorgesehenen Prozess zusammenwirkt.

Support-Ticket oder Quality Change: die entscheidende Abgrenzung

Frage	Support-Ticket	Kontrollierter GxP-Änderungsvorgang
Primärzweck	Technische Anfrage bearbeiten	Record- und Produktintegrität sichern
Genehmigung	Service- oder IT-Verantwortlicher	Definierte Fach- und Quality-Rollen
Änderungsumfang	Technische Beschreibung	Alter und neuer Wert, Grund, betroffene Records und Chargen
Systemnachweis	Bearbeitungslog des Tickets	Nativer Audit Trail plus verknüpfter Quality Record
Auswirkungsbewertung	Optional oder technisch	Daten-, Prozess-, Produkt- und Freigabeauswirkung
Abschluss	Ticket geschlossen	Änderung verifiziert, Review abgeschlossen, Wirksamkeit bewertet

Ein Ticket bleibt ein sinnvoller Teil der Beweiskette. Die Schwäche entsteht, wenn es die einzige Beweiskette ist. Dann fehlen häufig die fachliche Begründung, die unabhängige Genehmigung und der Nachweis im betroffenen System.

Sechs Kontrollen für auditfähige Vendor-Änderungen

1. Änderbare EBR-Objekte und Lebenszyklusstatus definieren

Das Team muss festlegen, welche Daten ein Anbieter technisch ändern kann und in welchem Status. Ein Entwurf, ein laufender Batch Record und ein abgeschlossener Record benötigen unterschiedliche Kontrollen.

Das Inventar sollte mindestens Benutzerzuordnungen, Zeitstempel, Prozessparameter, Materialwerte, Berechnungen, Kommentare, Signaturen und Statuswechsel abdecken. Für jedes Objekt wird festgelegt, ob eine Korrektur zulässig ist, wer sie genehmigt und wie der ursprüngliche Wert erhalten bleibt.

2. Vendor-Zugriffe personengebunden und zeitlich begrenzt steuern

Gemeinsame Supportkonten verhindern eine eindeutige Zuordnung. Remote-Zugriffe sollten deshalb einer konkreten Person, einem genehmigten Zweck und einem begrenzten Zeitfenster zugeordnet sein.

Privilegierte Rechte werden nur für die notwendige Dauer aktiviert. Start, Ende, ausgeführte Aktionen und verantwortliche interne Begleitung werden protokolliert. Der Anbieter darf nicht gleichzeitig Änderung, Verifikation und Quality-Entscheidung übernehmen.

3. Änderungen im nativen Audit Trail erzwingen

Das stärkste Ticket kompensiert keinen fehlenden Audit Trail im EBR. Das System sollte bei GMP-relevanten Änderungen mindestens Identität, Zeitpunkt, betroffenen Wert, alten und neuen Wert sowie Änderungsgrund erfassen.

Die Validierung muss auch den Negativfall prüfen: Kann ein Administrator, Anbieter oder Datenbankskript den Record verändern, ohne einen sichtbaren Audit-Trail-Eintrag zu erzeugen? Wenn das technisch möglich ist, braucht es eine dokumentierte Risikobewertung, wirksame Prävention und gegebenenfalls eine Architekturänderung.

4. Quality Record vor der produktiven Änderung eröffnen

Eine Änderung an einem abgeschlossenen Batch Record ist nicht nur Wartung. Vor der Ausführung muss geklärt sein, ob Abweichung, Change Control oder ein definiertes Korrekturverfahren greift.

Der Quality Record beschreibt Grund, Scope, Genehmigung, betroffene Daten und geplante Verifikation. Für dringende Korrekturen braucht es einen vorab definierten Notfallweg. „Dringend“ darf nicht bedeuten, dass die Dokumentation erst nachträglich rekonstruiert wird.

5. Record-, Chargen- und Produktwirkung unabhängig bewerten

Eine scheinbar kleine Datenkorrektur kann weitere Entscheidungen beeinflussen. Die Bewertung sollte deshalb nicht beim geänderten Feld enden. Sie prüft mindestens:

• welche Records und Chargen betroffen sind;
• ob Berechnungen, Signaturen oder Statusentscheidungen davon abhängen;
• ob bereits eine Freigabe oder Auslieferung erfolgt ist;
• ob vergleichbare Änderungen in anderen Records vorkamen;
• ob eine Abweichung, Untersuchung oder CAPA erweitert werden muss.

Die Person, die die Änderung beantragt oder technisch ausführt, sollte nicht allein über ihre Auswirkung entscheiden.

6. Kommunikation, Audit Trail und Quality Records periodisch korrelieren

Ein periodischer Review sollte nicht nur Audit-Trail-Ereignisse einzeln prüfen. Er sollte auch Supportkommunikation, Remote-Access-Protokolle und Quality Records miteinander abgleichen.

So werden drei typische Lücken sichtbar: Ein Ticket ohne Systemereignis, ein Systemereignis ohne genehmigten Quality Record oder eine Vendor-Kommunikation außerhalb des festgelegten Kanals. Die Auswertung kann risikobasiert auf kritische Systeme, privilegierte Aktionen und abgeschlossene Batch Records fokussieren.

Welche Tests in die EBR-Validierung gehören

Eine Standardprüfung von Dateneingabe und Workflow reicht nicht. Für Vendor-Änderungen sind gezielte Challenge-Tests erforderlich:

1. Änderung nach Record-Abschluss: Das System blockiert die Änderung oder führt sie durch einen genehmigten Korrekturworkflow.
2. Privilegierter Supportzugriff: Eine konkrete Vendor-Identität wird aktiviert, überwacht und wieder entzogen.
3. Audit-Trail-Vollständigkeit: Alter und neuer Wert, Person, Zeitpunkt und Grund sind verständlich verfügbar.
4. Direkter Datenbankeingriff: Ein nicht vorgesehener Änderungsweg wird verhindert oder durch unabhängige Kontrollen erkannt.
5. Auswirkungsprüfung: Abhängige Berechnungen, Signaturen, Reports und Freigabestatus werden korrekt neu bewertet.
6. Review und Export: QA kann Record, Audit Trail und verknüpften Quality Record für eine Inspektion zusammenstellen.

Akzeptanzkriterien müssen vor Testbeginn feststehen. Ein nachträglicher Screenshot beweist nur den Endzustand. Er beweist nicht, wie die Änderung entstand oder wer sie genehmigte.

Ein fokussierter 30-Tage-Review

Der Einstieg muss kein Großprojekt sein. Ein risikobasierter Review kann in vier Schritten starten:

Woche 1: Ein kritisches EBR-System auswählen. Rollen, Vendor-Zugriffe und technisch änderbare Datenobjekte aufnehmen.

Woche 2: Änderungen an abgeschlossenen Records der letzten Monate aus Tickets, E-Mails und Remote-Access-Protokollen zusammenstellen.

Woche 3: Diese Vorgänge gegen Audit Trail, Abweichungen, Change Controls und Freigabeentscheidungen abgleichen.

Woche 4: Lücken nach Record-, Chargen- und Produktwirkung priorisieren. CAPA, technische Härtung und Regressionstests festlegen.

Für eine GxP-Audit-Vorbereitung liefert dieser Review einen belastbaren Scope. Er zeigt nicht nur, ob Dokumente vorhanden sind, sondern ob die Änderungskette rekonstruierbar funktioniert.

Häufige Fragen

Darf ein Softwareanbieter einen abgeschlossenen elektronischen Batch Record korrigieren?

Nicht als informellen Datenbank- oder Supporteingriff. Eine zulässige Korrektur braucht einen definierten Prozess, autorisierte Rollen, Erhalt der ursprünglichen Information, einen nachvollziehbaren Audit Trail, Quality Oversight und eine Bewertung möglicher Chargen- oder Produktwirkungen.

Reicht ein Audit-Trail-Eintrag für die Genehmigung einer Änderung?

Nein. Der Audit Trail dokumentiert das Systemereignis. Er ersetzt nicht die fachliche Begründung, Quality-Genehmigung, Auswirkungsbewertung oder Verifikation. Beide Nachweise müssen verknüpft und gemeinsam prüfbar sein.

Welche Vendor-Aktivitäten sollte QA regelmäßig prüfen?

Priorität haben privilegierte Zugriffe, Änderungen an abgeschlossenen Records, direkte Datenbankaktionen, Änderungen an Audit-Trail- oder Zeitkonfigurationen und Supportfälle mit möglicher Auswirkung auf Freigabeentscheidungen.

Primärquellen

• FDA Warning Letter: Intas Pharmaceuticals Limited, 30. März 2026
• EU GMP Annex 11: Computerised Systems, Revision 1
• eCFR: 21 CFR 211.68 — Automatic, mechanical, and electronic equipment
• eCFR: 21 CFR 211.188 — Batch production and control records
• FDA: Data Integrity and Compliance With Drug CGMP — Questions and Answers

---

Autor

Daniel Herrmann Consulting unterstützt Pharma-, Biotech- und MedTech-Unternehmen bei CSV, GxP-Systemvalidierung, Datenintegrität und Audit Readiness.

Sind Vendor-Zugriffe, EBR-Änderungen und Freigabeentscheidungen in Ihrem System vollständig rekonstruierbar?

In einem fokussierten Review verbinden wir technische Änderungswege, Audit Trail und Quality-Prozess zu einem belastbaren Prüfpfad.

EBR-Validierungssetup besprechen