DocuSign validieren: Vom Part-11-Konto zum belastbaren Signaturnachweis

1. Den Signaturprozess und seinen Regelbereich festlegen

Dieser Leitfaden betrachtet DocuSign eSignature mit aktiviertem Part-11-Umfang für regulierte Dokumentprozesse. Ein typischer Anwendungsfall ist die Prüfung und Genehmigung einer GMP-SOP. Beschreiben Sie dafür zunächst das führende Dokument, den wirksamen Versionsstand, die beteiligten Rollen und den Zeitpunkt, ab dem die Organisation die Genehmigung tatsächlich verwendet.

Für computergestützte Prozesse in der Herstellung von Humanarzneimitteln sind hier Annex 11 und Kapitel 4 des EU-GMP-Leitfadens maßgebliche Bezugspunkte. Die Europäische Kommission führt die Fassungen von Januar 2011 weiterhin im entsprechenden Bereich. Ein klinischer Einwilligungsprozess, ein Medizinprodukteverfahren oder ein gewöhnlicher Liefervertrag benötigt eine eigene Einordnung.

21 CFR Part 11 kommt hinzu, wenn die dort beschriebenen FDA-bezogenen elektronischen Aufzeichnungen und Signaturen im Anwendungsbereich liegen. Der amerikanische Herstellername oder ein internationales Unternehmen genügen dafür nicht. Halten Sie das Ergebnis der Einordnung fest, bevor Sie technische Einstellungen als regulatorische Pflicht bezeichnen.

Quellen: [6] [7] [8] [9]

2. Das tatsächliche Konto identifizieren

Die aktuelle Produktseite unterscheidet Part-11-spezifische eSignature-Funktionen und den ergänzenden Validator for Life Sciences. Das Life-Sciences-Datenblatt fasst Signaturfunktionen, Validierungsunterstützung und SMS-Authentifizierung als Angebotsbestandteile zusammen. Daraus lässt sich der Umfang eines individuellen Vertrags noch nicht ableiten.

Die Entwicklerhilfe verlangt ein für Part 11 aktiviertes Konto und nennt dafür kommerzielle Verträge, nicht die gewöhnlichen Web Plans. Wer Umschläge mit und ohne diesen Umfang verschickt, benötigt nach dieser Dokumentation getrennte Konten. Deshalb reicht es nicht, dass ein Mitarbeiter irgendwo Zugriff auf ein entsprechend bezeichnetes Konto besitzt.

Erfassen Sie das im Prozess verwendete Konto, Module, Versandweg und Integrationen. Prüfen Sie auch den technischen Absender einer QMS-Anbindung: Nutzt er das freigegebene Konto oder ein anderes? Dokumentieren Sie den tatsächlichen Stand von Test- und Produktionsumgebung. Eine Übernahme der Einstellungen sollte überprüfbar sein, statt nur auf einer Erinnerung des Administrators zu beruhen.

Quellen: [1] [2] [3]

3. Identität, Berechtigung und Signaturbedeutung auseinanderhalten

Der Zugang zu einem Dokument, die Authentifizierung beim Signieren und die Befugnis zur Genehmigung beantworten verschiedene Fragen. Eine Person kann technisch erfolgreich authentifiziert sein und dennoch für diese SOP keine Genehmigungsrolle besitzen. Legen Sie deshalb fest, wer Identitäten bestätigt, wer Rollen vergibt und wie Vertretung oder Austritt bearbeitet werden.

Die DocuSign-Hilfe unterscheidet Remote Signing und Embedded Signing. Für eingebettetes Signieren nennt sie im beschriebenen Part-11-Kontext SMS für Zugang und Signatur. Beim Remote Signing sind mehrere Kombinationen dokumentiert. Standardmäßig wird beim Signieren erneut authentifiziert; eine alternative Kontooption verschiebt die Authentifizierung auf Zugang und Abschluss der Sitzung. Prüfen Sie genau den gewählten Ablauf einschließlich Abbruch und erneuter Anmeldung.

Im FDA-Scope betreffen § 11.50 und § 11.70 die sichtbaren Signaturinformationen und den Bezug zum Datensatz. § 11.100 behandelt unter anderem die vorgelagerte Identitätsprüfung. Eine passende Auswahl des Signaturgrunds sollte für den Unterzeichner verständlich sein und seine tatsächliche Handlung widerspiegeln. Ein voreingestelltes „Genehmigt“ macht eine bloße Kenntnisnahme nicht zur fachlichen Prüfung.

Quellen: [3] [9] [7]

4. Den Validator auf seine tatsächliche Abdeckung prüfen

Das aktuelle Life-Sciences-Datenblatt beschreibt QA-Tests auf einem Part-11-Beispielkonto gegen Demo- und Produktionsumgebung. Die dazu genannten monatlichen Berichte enthalten Testscreenshots und Ergebnisse. Das sind nutzbare Lieferanteninformationen. Sie zeigen jedoch nicht automatisch, welche Ihrer Vorlagen, externen Empfänger, QMS-Felder oder Ablagen geprüft wurden.

Ordnen Sie den erhaltenen Bericht einer konkreten Version und Ihren Anforderungen zu. Halten Sie Abdeckung, Ausschlüsse und offene Punkte fest. Die folgende eigene Arbeitshilfe verhindert sowohl unnötige Doppelprüfungen als auch die ungeprüfte Übernahme eines pauschalen Gütesiegels.

Quellen: [2] [7]

5. Prüfbeispiel: Fünf Signaturen, aber nur ein passender Abschluss

Das folgende Szenario ist frei konstruiert, kein Kundenfall und kein ausgeführter Produkttest. Für SOP-Q17 Revision 3 verlangt die eigene Vorgabe zwei autorisierte Personen: A prüft, B genehmigt. Erst danach darf die Revision im QMS wirksam werden. Der Rücklauf muss Dokument und Signaturkontext dem richtigen Datensatz zuordnen. Diese Zweierfolge ist eine Beispielentscheidung, keine universelle Anforderung.

Drei isolierte Testumschläge erhalten gesonderte Kennungen. Die Sollversion wird vor Testbeginn unabhängig gesichert. So hängt die spätere Bewertung nicht von der Version ab, die versehentlich im Umschlag gelandet ist.

Quellen: [3] [5] [8]

6. Den Rücklauf ins QMS als eigenen Übergang testen

Ein erfolgreicher Signaturdienst beantwortet noch nicht, ob das richtige Dokument an der richtigen Stelle angekommen ist. Definieren Sie die Verknüpfung zwischen QMS-Dokumentkennung, Revision und Umschlagkennung. Ein Dateiname allein ist dafür häufig eine schwache Zuordnung: Derselbe Name kann auf unterschiedliche Inhalte zeigen.

Als eigene Prüffälle bieten sich ein unterbrochener Rücklauf, eine doppelte Statusmeldung und eine veraltete Zuordnung an. Die erwartete Reaktion muss vorab feststehen: beispielsweise eine kontrollierte Wiederholung ohne doppelte Wirksamsetzung oder ein sichtbarer Fehlerzustand. Welche technische Lösung dies umsetzt, hängt von der tatsächlich eingesetzten Anbindung ab.

Bei Embedded Signing verlangt die Herstellerhilfe übereinstimmende Empfängerdaten zwischen Umschlagerstellung und angeforderter Signatursitzung. Prüfen Sie diese Bindung mit absichtlich abweichender Testkennung. Die Anmeldung am QMS und die spätere DocuSign-Authentifizierung dürfen nicht stillschweigend als identische Kontrollhandlung behandelt werden. Sichern Sie für den Test beide Seiten des Übergangs.

Quellen: [3] [7] [8]

7. Dokument, Signaturinformationen und Historie gemeinsam lesbar halten

Der sichtbare Schriftzug ist nur ein Teil des Nachweises. Entscheidend sind auch Person, Zeitpunkt, Bedeutung und der Bezug zur unterzeichneten Fassung. DocuSign beschreibt Certificate of Completion, Auditinformationen und Manipulationserkennung. Legen Sie fest, welche davon für Ihren Prozess benötigt werden und wie sie später gemeinsam auffindbar bleiben.

Prüfen Sie einen Export aus Sicht eines Mitarbeiters, der den ursprünglichen Vorgang nicht kennt. Kann er die gültige Fassung bestimmen, den Unterzeichner einordnen und den Zusammenhang zwischen Dokument und Signatur erkennen? Funktioniert die vorgesehene technische Integritätsprüfung auch nach der Übernahme in die Zielablage?

Führen Sie einen Veränderungstest ausschließlich an einer gekennzeichneten Kopie durch. Das Original bleibt unverändert als Vergleich erhalten. Ein Dateivergleich kann eine Abweichung zeigen; er ersetzt aber nicht automatisch die Prüfung der Signaturinformationen und ihres Kontextes. Auch ein Ausdruck ist nicht ohne Weiteres ein Ersatz für den vollständigen elektronischen Nachweis.

Quellen: [5] [9] [8]

8. Aufbewahrung vor Löschung oder Kontowechsel klären

Die allgemeine eSignature-Hilfe unterscheidet Löschung von Dokumenten, Metadaten und bestimmten personenbezogenen Angaben. Eine konfigurierte Aufbewahrungsregel kann Dokumente automatisch zur Löschung vormerken. Die Hilfe beschreibt zudem unterschiedliche Möglichkeiten für versandte und empfangene Umschläge. Prüfen Sie, welche davon im konkreten Part-11-Konto gelten.

Entscheiden Sie, wo der maßgebliche Datensatz aufbewahrt wird: im Dienst, im QMS, in einer Archivlösung oder in einer definierten Kombination. Benennen Sie Verantwortliche, erforderliche Bestandteile, zulässige Löschaktionen und den Nachweis erfolgreicher Übernahme. Vor einer Kontoschließung sollten Zugänglichkeit und Lesbarkeit unabhängig vom bisherigen Benutzerkonto erprobt sein.

Technische Standardfristen sind keine regulatorischen Aufbewahrungsfristen. Kapitel 4 unterscheidet Dokumentarten und ihren fachlichen Zweck; Annex 11 behandelt die Zugänglichkeit und Integrität archivierter Daten. Ein im Dienst noch sichtbarer Umschlageintrag beweist nicht, dass das Dokument und sein erforderlicher Kontext ebenfalls erhalten geblieben sind.

Quellen: [4] [7] [8]

9. Änderungen nach ihrem Einfluss auf den Prozess bewerten

Neben Herstellerreleases können Vorlagen, Empfängerrollen, Telefonnummern, Authentifizierungsverfahren, Signaturgründe und Retentionregeln den Nachweis verändern. Führen Sie einen dokumentierten Ausgangsstand und ordnen Sie Änderungen den betroffenen Anforderungen zu. Ein neuer Firmenname im Briefkopf hat andere Folgen als eine Änderung des QMS-Rücklaufs.

Nutzen Sie aktuelle Lieferantenberichte, um die verbleibenden Prüfungen zu bestimmen. Betroffene unveränderte Funktionen können ebenfalls einen Nachtest benötigen, etwa wenn eine neue Integration ihre Daten anders verwendet. Umgekehrt ist die komplette Wiederholung aller bisherigen Tests nicht automatisch die beste Antwort auf jeden Release.

Beschreiben Sie auch den Störungsfall: Wer erkennt einen hängenden Umschlag, beurteilt einen fehlerhaften Rücklauf und entscheidet über eine kontrollierte Alternative? Eine Unterschrift erneut einzuholen ist keine neutrale Reparatur, wenn dadurch Version, Zeitpunkt oder Genehmigungsbedeutung wechseln. Der ursprüngliche Befund und die Entscheidung sollten miteinander nachvollziehbar bleiben.

Quellen: [7] [2]

10. Vorbereitung und Checkliste für QA und IT

Für ein KMU beginnt die Vorbereitung am besten mit einem echten, repräsentativen Dokumentweg und einer Testkopie. QA legt die fachliche Bedeutung der Unterschriften fest. Der Prozessverantwortliche bestimmt Rollen und Wirksamsetzung. IT dokumentiert Konten, Integration und Betrieb. Die Dokumentenlenkung legt fest, welcher Nachweis später in welchem System wiedergefunden werden muss.

Aufwand entsteht vor allem durch unterschiedliche Signaturwege, externe Unterzeichner, unklare Altbestände und mehrere Ablagen. Eine einzige Vorlage mit bekannten Rollen ist anders zu behandeln als ein Verbund mit automatischer Dokumenterstellung und Rückschreiben in mehrere Systeme. Planen Sie die Mitwirkung anhand dieser Übergänge, nicht anhand der Zahl sichtbarer Unterschriftenfelder.

• Anwendungsbereich und Dokumentprozess mit verantwortlichen Rollen abgegrenzt.
• Tatsächlich verwendetes Part-11-Konto und bestellter Validatorumfang bestätigt.
• Identität, Genehmigungsbefugnis und verwendeter Signaturablauf nachvollziehbar.
• Sollversion, Negativfälle und Annahmekriterien vor dem Test festgelegt.
• Rücklauf, Integrationsfehler und doppelte Verarbeitung geprüft.
• Export mit benötigtem Kontext lesbar und dem richtigen Datensatz zugeordnet.
• Retention, Exit, Änderungen und Störungsentscheidungen im Betrieb geregelt.

Quellen: [7] [3] [4]