Elektronische Signatur Version 1.0 Oktober 2007 - APV

APV-Empfehlung: Elektronische Signaturen, Version 1.0
Die festgelegten User Requirements beeinflussen entsprechend die nachfolgenden Spezifikations- und Design-Schritte (z. B.
Functional Specifications, System Design Specifications, Software Design Specifications). In diesem Rahmen wird auch
spezielles Signaturequipment (z. B. Kartenleser) in Abhängigkeit von der Art der zu verwendenden Signatur (z. B. qualifizierte
elektronische Signatur) definiert.
Soweit eine systembezogene Risikoanalyse erstellt wird, sollten darin die mit der elektronischen Signatur verbundenen
Risiken auf Basis der genannten Dokumente adäquat betrachtet werden.
4.1.2 Änderungen signierter Daten
Der Sinn einer Signatur ist in erster Linie, Daten zu fixieren und zu bestätigen. Das bedeutet, dass Änderungen nicht vorgesehen
sind und nur in speziellen Ausnahmefällen durchgeführt werden dürfen. Ausnahmen können z. B. Eingabefehler sein
(z. B. Zahlendreher), die bei der Signatur übersehen wurden.
Nachfolgend wird detaillierter auf Änderungsprozesse signierter Daten eingegangen, die ggf. zu weiteren Anforderungen
führen können. Hierbei sind folgende Aspekte zu berücksichtigen:
Freigabestatus der Daten
Die Änderungsprozesse sind abhängig vom Freigabestatus der Daten (z. B. „im Entwurf“, „geprüft“, „freigegeben“) zu
definieren. Einmal per Signatur freigegebene Daten sollten nicht mehr ohne zusätzliche Signatur mit gleicher Befugnis
geändert werden können.
Kritikalität der Daten
Im Sinne des „Risk-Based Approach“ sollte ein System so flexibel sein, dass in Abhängigkeit von der Kritikalität der Daten
(z. B. Herstellbericht vs. Training-Handouts) unterschiedliche Änderungsprozesse etabliert und unterstützt werden.
Kritikalität des Fehlers
Stellt man z. B. Rechtschreibfehler oder nicht den Inhalt verfälschende Fehler (z. B. Korrektur von Seitennumerierungen) fest,
so kann man unter Umständen diese zunächst belassen und erst in einer späteren Version mitkorrigieren. Handelt es sich um
kritische Fehler, sollte eine zeitnahe Korrektur erfolgen.
Verknüpfung zwischen Daten und Signatur
Ausgehend von der gleichen Vorgehensweise, wie dies GxP-gerecht auf Papier erfolgen würde, muss bei Verwendung computerisierter
Systeme spezifiziert sein, welche Daten mit welcher Signatur verknüpft sind.
Die unautorisierte Änderung von verknüpften Daten (Signatur und Electronic Record) darf außerhalb der Applikation und
des zugehörigen Änderungsverfahrens nicht möglich sein. Für autorisierte Änderungen außerhalb der Applikation siehe
Kapitel 4.3.4.
4.2 Entwickler- und Abnahmetests
Die Erfüllung der signaturbezogenen Anforderungen aus User Requirements, Spezifikation und Design in Verbindung mit
einer eventuell vorhandenen Risikoanalyse ist in Abhängigkeit von der Lieferantenbewertung im Rahmen der Entwicklerbzw.
Abnahmetests zu überprüfen (siehe auch Tab. 11).
Tab. 11: Beispiel für Abnahmetests (Auszug).
Testfall-Nr. Thema des Testfalles Ziel Testfall
19.15 Drei Signaturen – Negativtest
nicht-korrekter User1
Ein nicht als der vorgesehene Benutzer
identifizierter User darf nicht die Aktivität
einfordern oder das Dokument
unterschreiben.
19.21 Drei Signaturen – Sign1 Nach der vorherigen Ablehnung durch
den dritten Unterschreibenden wird
die erste Unterschrift dem Dokument
korrekt hinzugefügt.
19.28 Drei Signaturen – Abschlusstest Der Status des Dokumentes ist bestätigt.
Attribute und Inhalte können
nicht verändert werden.
19.32 Test Audit Trail – Bewilligung Der Bewilligungsschritt eines Dokumentes
wird in dem Audit Trail-Datenbestand
richtig aufgezeichnet.
[PBF00525]
[PBF01034]
[PBF00536]
[PBF00662]
24 APVnews 04/07 copyright apv