LORENZ docuBridge validieren: Vom richtigen Dokumentstand zur nachvollziehbaren Einreichung

1. Softwarevalidierung und Einreichungsprüfung auseinanderhalten

LORENZ docuBridge unterstützt das Zusammenstellen, Publizieren, Importieren und Prüfen regulatorischer Einreichungen. Der Gegenstand ist ein Dossier mit Dokumenten, Metadaten und Lebenszyklusbeziehungen. Das Produkt ist kein System zur Bearbeitung einzelner Nebenwirkungsfälle. Auch klinische Daten werden nicht allein dadurch in docuBridge erhoben, dass ein Studienbericht später Bestandteil einer Einreichung wird.

Für die Eignungsbewertung sind drei Fragen zu unterscheiden: Funktioniert Ihr konfiguriertes System für den vorgesehenen Arbeitsablauf? Entspricht das ausgegebene Paket den technischen Einreichungsregeln? Ist sein fachlicher Inhalt richtig und für das Verfahren geeignet? Ein bestandener Validatorlauf beantwortet nicht alle drei Fragen. Die europäische eCTD-Guidance trennt technische Validierung und Inhaltsprüfung ausdrücklich.

Bestimmen Sie deshalb zuerst Produkt, Verfahren, Empfänger, Format und maßgebliche Aufzeichnungen. Annex 11 ist im zutreffenden Humanarzneimittel-GMP-Zusammenhang relevant, nicht automatisch für jede Zulassungstätigkeit. Bei US-bezogenen elektronischen Aufzeichnungen ist der konkrete Part-11-Scope zu klären. Der Produktname liefert weder eine feste GAMP-Kategorie noch eine allgemeine Signaturpflicht. Die folgenden Prüfvorschläge beziehen sich auf Ihren beschriebenen Einsatz und ersetzen keine verfahrensspezifische regulatorische Entscheidung.

Quellen: [1] [8] [12] [11]

2. Edition, Module und Betrieb konkret benennen

docuBridge ist eine Produktfamilie. Die öffentlichen Beschreibungen unterscheiden ONE, TWO und FIVE. ONE ist auf einen Einzelarbeitsplatz ausgerichtet. TWO wird als standardisierte Mehrbenutzerlösung beschrieben, FIVE als konfigurierbares modulares System. Die Namen sagen jedoch noch nicht, welche regionalen Module, Schnittstellen oder Erweiterungen Sie tatsächlich erworben und eingerichtet haben.

Für ein kleines Zulassungsteam kann die standardisierte Variante ein anderer Ausgangspunkt sein als eine international vernetzte Installation. Das ist keine automatische Eignungsempfehlung aufgrund Ihrer Unternehmensgröße. Fragen Sie nach den benötigten Formaten, Regionen, gleichzeitigen Aufgaben, externen Quellen und Prüfwegen. Die öffentliche Editionsmatrix nennt außerdem unterschiedliche lokale und Cloud-Betriebsformen.

Die Arbeitshilfe zeigt, was vor der Detailplanung feststehen sollte. Ein in FIVE beschriebenes Zusatzmodul wird nicht ohne Prüfung auf TWO oder ONE übertragen. Besonders wichtig ist die Trennung zwischen integriertem Validator, einer gesonderten eValidator-Edition und dem tatsächlichen Kriterienprofil. Halten Sie den beauftragten Lieferumfang und die Verantwortlichkeit für Betrieb, Konfiguration und Änderungen fest.

Quellen: [1] [2] [3] [7]

3. Softwarestand und regionale Regeln getrennt führen

Der Softwarebuild ist nur ein Teil des prüfbaren Standes. Dazu gehören das regionale Publishingmodul, das Validatorprofil und gegebenenfalls ein Regulatory Update Package. LORENZ beschreibt solche Pakete als eigene Möglichkeit, Einreichungskonfigurationen an Spezifikationsänderungen anzupassen. Eine gleich gebliebene Programmversion bedeutet deshalb nicht zwingend einen unveränderten Einreichungsprozess.

Die öffentliche Beschreibung zu docuBridge 25.2 nennt EU-eCTD-4.0-Funktionen auf Basis des damaligen Entwurfs des Implementation Guide. Daraus darf keine pauschale Aussage über heute zulässige EU-Verfahren entstehen. Die EMA beschreibt im Stand vom Juli 2026 optionale Nutzung für neue zentralisierte Zulassungsanträge und eine weiterhin gesonderte Erprobung der Weiterführung bestehender 3.2.2-Lebenszyklen.

Definieren Sie für einen konkreten Test den freigegebenen Zielstand: Region, Verfahren, Formatversion, Kriteriensatz und relevante Module. Stimmen Sie ihn mit Regulatory Affairs ab. Prüfen Sie bewusst auch, ob ein ungeeignetes Profil erkennbar gewählt wurde. Der Kalender eines Herstellers ersetzt diese Zuordnung nicht; aus einem April-/Oktober-Releasetakt wird hier keine neueste verfügbare Ausgabe abgeleitet.

Quellen: [4] [6] [9]

4. Freigegebene Quelle, Ausgabe und Verweise verbinden

Eine Einreichung kann technisch lesbar sein und trotzdem die falsche Dokumentfassung enthalten. Beschreiben Sie deshalb, wie ein freigegebener Quellstand in docuBridge gelangt und wie er im ausgegebenen Paket wiedererkannt wird. Relevant sind Dokumentidentität, Version, Platzierung und Links. Bei einer externen Content-Management-Anbindung kommt die Bedeutung der übertragenen Metadaten hinzu.

LORENZ beschreibt für FIVE sowohl eigenes Regulatory Content Management als auch Anbindungen an Drittsysteme. Das ist ein Ausgangspunkt für die Systemgrenze, kein Nachweis Ihrer konkreten Schnittstelle. Prüfen Sie einen vorgesehenen Transfer und einen gezielt falschen Stand. Wird ein Dokument mit gleichem Dateinamen, aber anderer Revision geliefert, muss Ihr Verfahren den Unterschied angemessen erkennen und behandeln.

Bei Rendering oder Nachbearbeitung zählt das tatsächlich erzeugte Ergebnis. Kontrollieren Sie für die relevanten Dokumentarten beispielsweise Inhalt, Lesbarkeit und Verweisziele anhand eines unabhängig festgelegten Solls. Ein erfolgreicher Import allein belegt diese Eigenschaften nicht. Umgekehrt müssen Sie nicht jede Formatoption ohne Nutzungsbezug prüfen. Die ausgewählten Fälle sollen diejenigen Fehler erkennen können, die Ihre Einreichung oder ihre spätere Verwendung tatsächlich beeinträchtigen würden.

Quellen: [3] [1] [8]

5. Illustratives Beispiel: Gleiche Anzahl, anderer Dokumentbestand

Dieses Beispiel ist frei konstruiert und kein ausgeführter Produkttest. Betrachtet werden nur Nutzdokumente eines festgelegten eCTD-3.2.2-Lebenszyklus, keine XML-Dateien oder vollständigen regulatorischen Dossieranforderungen. Im Ausgangsstand sind A1, B1, C1 und D1 aktuell. Die geplante Folgesequenz ersetzt B1 durch B2, fügt E1 hinzu und nimmt D1 aus dem aktuellen Bestand. A1 und C1 bleiben unverändert.

Der erwartete aktuelle Bestand lautet A1, B2, C1 und E1. Vier Ausgangsdokumente plus eines hinzugefügt minus eines aus dem aktuellen Bestand entfernt ergeben wieder vier. Die Ersetzung verändert diese Anzahl nicht. Historisch sind sechs Dateiversionen zu berücksichtigen: die vier Ausgangsversionen sowie B2 und E1. Die Delete-Operation im Modell ist keine Behauptung, dass die historische Datei physisch gelöscht wird.

Die Tabelle wird vor der Prüfung festgelegt. Vergleichen Sie danach Identitäten, Zielbezüge und aktuelle Ansicht, nicht nur die Zahl der Dokumente. Als Fehlerfall wird B2 irrtümlich auf C1 bezogen, obwohl B1 ersetzt werden sollte. Auch dann kann die Gesamtzahl plausibel bleiben. Zusätzlich werden ein falscher Metadatenwert und ein defekter Link untersucht. Vor jedem Fall werden dieselbe Ausgangssequenz und dieselben freigegebenen Quelldateien wiederhergestellt.

Quellen: [1] [8]

6. Einen Validatorbericht fachlich richtig interpretieren

docuBridge TWO und FIVE werden mit integriertem eValidator beschrieben. Für die separate Edition eValidator FIVE nennt LORENZ unter anderem aktuelle, frühere und erweiterte Prüfprofile. Welche Eigenschaften im eigenen integrierten Aufbau verfügbar sind, ist gesondert zu bestätigen. Ein Profilname ohne Version und Konfiguration macht einen Bericht nur eingeschränkt nachvollziehbar.

Die technische Prüfung betrachtet definierte Regeln. Die europäische Guidance weist ausdrücklich darauf hin, dass Kriterien nicht die Richtigkeit sämtlicher Metadaten prüfen können. Ein technisch zulässiger Eintrag kann also für das Produkt oder Verfahren falsch sein. Ergänzen Sie deshalb gezielte fachliche Abgleiche gegen die freigegebene Quelle und den vorgesehenen Dossierumfang.

Halten Sie Paketstand, Profil, Zeitpunkt und Ergebnis zusammen. Ein Bericht zu einer früheren Ausgabe beantwortet nicht automatisch die Frage nach dem später versendeten Paket. Bewerten Sie Meldungen nach dem tatsächlich einschlägigen Regelwerk und ihrem Inhalt. Der Artikel legt keine universelle Behandlung jedes Warnhinweises fest. Ein formal erfolgreicher Lauf ersetzt ebenso wenig den Nachweis, dass die Software mit Ihrer Konfiguration und Ihren Schnittstellen den vorgesehenen Arbeitsablauf geeignet unterstützt.

Quellen: [2] [3] [7] [8]

7. Review, Übermittlung und Behördenantwort getrennt abschließen

Vor der Übermittlung sollte der geprüfte Einreichungsstand eindeutig bestimmt sein. Verbinden Sie ihn mit der fachlichen Reviewentscheidung und dem vorgesehenen Empfänger. Ein im System angezeigter Status beschreibt zunächst einen internen Zustand. Für den nächsten Schritt ist zusätzlich zu prüfen, ob die konfigurierte Übermittlung den richtigen Paketstand und das richtige Ziel verwendet.

Die EMA beschreibt Gateway und Web Client als Übermittlungskanäle mit technischer Rückmeldung. Diese Rückmeldung darf nicht ohne Weiteres als inhaltliche Zulassungsentscheidung behandelt werden. Halten Sie daher Versand, technischen Empfang beziehungsweise technische Annahme und den weiteren regulatorischen Verfahrensstatus auseinander. Das ist besonders wichtig, wenn Meldungen automatisiert zurück in ein RIM-System übertragen werden.

Bei einer Korrektur wird zunächst geklärt, ob das Problem technischer oder inhaltlicher Art ist und welcher Einreichungsweg nach den anwendbaren Vorgaben passt. Ein stiller Austausch des intern gespeicherten PDF würde die Beziehung zum bereits versendeten Stand verlieren. Vereinbaren Sie Zuständigkeit, Entscheidungsbeleg und die Zuordnung der nachfolgenden Sequenz oder erneuten Übermittlung. Die konkrete regionale Regel ist maßgeblich; derselbe Ablauf wird nicht pauschal für EU, USA und andere Regionen vorausgesetzt.

Quellen: [5] [10] [8]

8. Bearbeitungsrechte und historische Stände verständlich halten

Für den vorgesehenen Ablauf muss klar sein, wer Quelldokumente übernimmt, Metadaten ändert, ein Paket prüft und den Versand veranlasst. Diese Aufgaben müssen nicht zwangsläufig vier Personen entsprechen. Entscheidend sind die begründete Verantwortungsverteilung und die tatsächlichen Berechtigungen. Prüfen Sie einen unerlaubten Änderungsversuch an einem bereits maßgeblichen Stand sowie den vorgesehenen kontrollierten Korrekturweg.

LORENZ beschreibt für docuBridge FIVE 24.2 eine Audit-Trail-Timeline mit Filtern, etwa nach Benutzer oder Ereignis. Diese Funktionsbeschreibung ist keine Zusage, dass Ihre Installation jede benötigte Information vollständig und unveränderbar erfasst. Prüfen Sie, ob die für Ihren Vorgang relevanten Änderungen verständlich rekonstruiert werden können und wie die entsprechenden Informationen später zugänglich bleiben.

Wenn Aufzeichnungen einen GMP-Prozess unterstützen, sind ihre Beziehungen und kontrollierte Korrekturen auch im passenden Dokumentationskontext zu betrachten. Bei FDA-relevanten elektronischen Aufzeichnungen folgt die Einordnung dem konkreten Scope. Daraus entsteht keine allgemeine elektronische Signaturpflicht für jeden Publishing-Schritt. Ebenso wird die notwendige Aufbewahrung anhand des Verfahrens und der betreffenden Aufzeichnungen begründet, nicht allein anhand einer Softwarefunktion.

Quellen: [5] [13] [12] [11]

9. Änderungen und Übernahmen anhand ihrer Wirkung prüfen

Unterscheiden Sie Programmupdate, regionales Regelpaket, Profiländerung und Wechsel einer Schnittstelle. Für jedes Ereignis wird gefragt, welche bislang belegte Annahme betroffen ist. Ein geändertes Validatorprofil kann beispielsweise neue Ergebnisse erzeugen, obwohl Dokumente und Programmoberfläche gleich aussehen. Die passende Prüfung richtet sich dann auf Kriterienwahl, Meldungen und deren Zuordnung zum Paket.

Der Hersteller beschreibt Regulatory Update Packages als eigene Änderungsmöglichkeit. Seine allgemeine Aussage zum Umgang mit vollständiger Revalidierung wird hier nicht als pauschale Betreiberregel übernommen. Bewerten Sie den tatsächlichen Umfang, geeignete vorhandene Lieferantenbelege und verbleibende Prüflücken. Diese Belege können unterschiedliche Konfigurationen abdecken; weder vollständige Abdeckung noch ausschließlich unveränderte Standardfunktionen werden vorab unterstellt.

Bei einer Migration reichen Anzahl und Größe übernommener Dateien nicht aus. Das eigene Soll sollte relevante Dokumentidentitäten, Revisionen, Lebenszyklusbeziehungen, Metadaten und Verweise enthalten. Prüfen Sie den aktuellen Dossierstand und ausgewählte historische Stände gegen die bekannte Quelle. Erhaltene PDF-Dateien mit falsch zugeordnetem Ersetzungsziel wären kein geeigneter Abschluss. Legen Sie ebenso fest, wie offene Befunde und der Zugang zum alten Bestand behandelt werden.

Quellen: [6] [3] [4] [12]

10. Das Projekt mit Regulatory Affairs, QA und IT vorbereiten

Für ein KMU sollte vor dem Start ein repräsentatives Dossier einschließlich einer relevanten Folgesequenz verfügbar sein. Regulatory Affairs legt fachlichen und regionalen Zweck fest. Publishing-Verantwortliche erklären Quellübernahme und Ausgabe. IT beziehungsweise der Betreiber beschreibt Installation, Zugriff und Schnittstellen; QA wird für den zutreffenden Qualitätsscope und die Nachweisentscheidung einbezogen.

Der Aufwand hängt besonders von Edition, Regionen, Formaten, externen Dokumentquellen, Migration und dokumentierten Ausnahmen ab. Ein kleiner Benutzerkreis kann trotzdem komplexe Lebenszyklen bearbeiten. Umgekehrt verlangt ein klar begrenzter standardisierter Einsatz nicht automatisch den Nachweis jeder verfügbaren Erweiterung. Für einen Neueinsatz wird das Soll geplant; im Bestand werden zuerst tatsächliche Versionen, Regeln und Arbeitsweisen abgeglichen.

Die folgende Vorbereitungsliste macht den Auftrag prüfbar. Bereits vorhandene Unterlagen dürfen genutzt werden, sofern ihr Umfang und ihre Passung erkennbar sind. Offene Fragen zu einem nicht zugänglichen Herstellerpaket werden nicht durch vermutete Inhalte ersetzt.

• Edition, Build, regionale Module und Betriebsform benennen.
• Format- und Kriterienversion sowie Regulatory Update Packages erfassen.
• Freigegebene Quelldokumente und erwarteten Lebenszyklus bereitstellen.
• Verantwortliche für Inhalt, Publishing, Review und Übermittlung festlegen.
• Sichere Testumgebung und eindeutig getrennte Testpakete vorbereiten.
• Berichte, Versandnachweise und Rückmeldungen dem richtigen Paket zuordnen.
• Anbieterbelege, Migrationsumfang und verbleibende Prüflücken dokumentieren.

Quellen: [2] [3] [6] [11]