Gemeinsame Benutzerkonten: Bleibt die GMP-Handlung einer Person zurechenbar?

1. Handlung und Identität miteinander verbinden

Im Humanarzneimittel-GMP-Scope verlangt Annex 11 angemessene Zugriffskontrollen und die nachvollziehbare Identität bei relevanten Dateneingaben, Änderungen, Bestätigungen oder Löschungen. Die Kontrolle muss zur tatsächlichen Handlung passen. Ein personalisierter Zugang an einer Stelle hilft wenig, wenn die Anwendung danach nur „Labor“ als Bearbeiter speichert.

Bewerten Sie die gesamte Kette: Anmeldung, Sitzung, Anwendungsfunktion und erzeugter Record. Eine gemeinsam verwendete Arbeitsstation ist nicht automatisch dasselbe wie ein gemeinsam verwendetes Anwendungskonto. Entscheidend bleibt, ob die relevante Person und Handlung verlässlich verbunden sind.

Quellen: [1] [2]

2. Kontotypen nach ihrer Verwendung unterscheiden

Die folgende eigene Matrix verhindert, dass jede Form eines nicht persönlichen Kontos gleich behandelt wird. Sie ist keine pauschale Zulassung der beschriebenen Konfigurationen. Für jede Zeile sind technische Möglichkeiten, Prozess und Nachweisbedarf zu prüfen.

Die FDA-Guidance unterscheidet im Drug-CGMP-Kontext reine Lesezugriffe von Tätigkeiten, die individuelle Zuordnung verlangen. Auch eine Zweitprüfung ist eine persönliche Handlung. Sie wird nicht dadurch zum bloßen Lesen, dass dabei der Ausgangsdatensatz unverändert bleibt.

Quellen: [3] [2] [1]

3. Persönliche Anmeldung allein reicht nicht immer

Ein Benutzer kann sich persönlich anmelden und eine Sitzung für die nächste Person offen lassen. Dann erscheint die technische Kennung weiterhin eindeutig, obwohl die Handlung tatsächlich jemand anderem zuzuordnen wäre. Das ist eine andere Nachweislücke als ein ausdrücklich geteiltes Konto, aber für die Bewertung nicht weniger wichtig.

Prüfen Sie angemessene Sitzungs- und Arbeitsplatzkontrollen sowie das Verhalten bei Benutzerwechsel. Welche Sperrzeiten und erneuten Authentifizierungen erforderlich sind, hängt vom Prozess ab. Die Quellen begründen keine einzige universelle Minutenfrist für alle Laborgeräte und Anwendungen.

Quellen: [1] [2] [4]

4. Eigener Prüffall: Zwei Personen, vier Handlungen

Illustratives Beispiel: Anna erfasst einen Wert, Ben korrigiert ihn, Anna erstellt einen Bericht und Ben führt die vorgesehene Zweitprüfung durch. Es gibt vier relevante menschliche Handlungen und zwei Personen. Eine Historie mit vier Einträgen unter „Labor“ zeigt vier Ereignisse, aber keine belastbare individuelle Zuordnung.

Das eigene Soll verlangt deshalb die richtige Zuordnung aller vier Handlungen. Zusätzlich wird ein automatisch erzeugter Bericht durch einen Dienst getrennt betrachtet. Dieser fünfte Vorgang darf nicht fälschlich als persönliche fachliche Prüfung durch Ben erscheinen. Das Beispiel ist ein konstruierter Testfall, kein ausgeführter Produkttest.

Quellen: [1] [3] [2]

5. Alte Systeme verlangen eine ehrliche Grenze

PIC/S behandelt den Fall, dass bei einem alten System eine persönliche Anmeldung technisch nicht verfügbar ist und keine geeignete Alternative bereitsteht. Dann müssen zusätzliche Kontrollen die erforderliche Nachvollziehbarkeit tatsächlich tragen. Das ist eine begrenzte, zu bewertende Situation und keine generelle Erlaubnis für gemeinsame Bearbeitungszugänge.

Ein Papierprotokoll kann Teil einer Lösung sein, bleibt aber anfällig, wenn Einträge nachträglich erfolgen oder mehrere Personen gleichzeitig arbeiten. Prüfen Sie, ob Zeitpunkt, Tätigkeit und Person eindeutig verbunden werden können. Reicht die Kontrolle für den vorgesehenen Einsatz nicht aus, darf diese Lücke nicht als gelöst dokumentiert werden.

Quellen: [2] [4] [1]

6. Technische Konten ohne falsche Personenidentität betreiben

Ein Dienstkonto kann beispielsweise einen kontrollierten Datentransfer ausführen. Dafür ist zunächst wichtig, welcher Prozess berechtigt ist, welche Daten er verändert und wie seine Ausführung nachvollzogen wird. Nicht jeder automatische Schritt benötigt eine erfundene menschliche Bearbeiteridentität.

Sobald eine Person eine fachliche Entscheidung trifft, muss diese jedoch angemessen zugeordnet bleiben. Ein gemeinsamer Integrationsbenutzer im Zielsystem darf den erforderlichen Bezug zum auslösenden Vorgang nicht beseitigen. Klären Sie, welche Informationen die Schnittstelle übernimmt und wo die Nachweiskette zuverlässig rekonstruiert werden kann.

Quellen: [1] [2]

7. Berechtigungen und Änderungen im Betrieb beherrschen

Legen Sie anlassbezogen fest, wie Zugänge eingerichtet, geändert und entzogen werden. Bei Rollenwechsel oder Austritt sollte die tatsächliche Berechtigung zum neuen Bedarf passen. Prüfen Sie außerdem, ob reguläre Anwender unnötige administrative Möglichkeiten besitzen und relevante Records oder deren Kontrollen beeinflussen können.

In kleinen Organisationen können Rollen personell zusammenfallen. Entscheidend sind dann geeignete Trennung von regulärer und administrativer Nutzung sowie nachvollziehbare Kontrollen. Ein Zertifikat des Softwareanbieters beantwortet nicht, wie Ihre konkreten Konten eingerichtet und im Alltag verwendet werden.

Quellen: [1] [2] [3]

8. Checkliste zur Bewertung geteilter Zugänge

Beginnen Sie bei den kritischen Tätigkeiten, nicht bei einer Liste aller Benutzernamen. Der Nachweis sollte zeigen, welche relevante Handlung wie zugeordnet wird und wo technische Grenzen bestehen. Ungeklärte Attribution ist keine bloße Formalität.

Die folgende eigene Arbeitshilfe unterstützt eine gezielte Prüfung. Sie verlangt keine pauschale Einführung eines bestimmten Identitätsprodukts und keine allein aus dem Produktnamen abgeleitete Konformität.

• Relevante Eingaben, Änderungen, Bestätigungen und Prüfungen benannt.
• Persönliche, technische und reine Lesekonten unterschieden.
• Effektive Rechte und nicht nur Rollennamen geprüft.
• Benutzerwechsel und offene Sitzungen berücksichtigt.
• Systemübergreifender Personen- beziehungsweise Prozessbezug nachvollziehbar.
• Legacy-Ersatzkontrollen anhand konkreter Fälle bewertet.
• Administrative Nutzung und Berechtigungsänderungen angemessen kontrolliert.

Quellen: [1] [2] [5]