roXtra validieren: Qualitätsprozesse und Maßnahmen nachvollziehbar prüfen

Den Qualitätsprozess statt nur die Software benennen

Ein roXtra-System kann Dokumente bereitstellen, Formulare durch einen Workflow führen und Maßnahmen nachverfolgen. Beschreiben Sie zuerst, welche dieser Aufgaben in Ihrem Unternehmen eine qualitätsrelevante Entscheidung unterstützen. Dazu gehören auch Übergänge: Eine Meldung löst eine Maßnahme aus, diese verweist auf eine Anweisung und ihr Ergebnis fließt in eine Abschlussentscheidung ein.

Der regulatorische Beispielscope dieses Leitfadens ist Humanarzneimittel-GMP. Annex 11 ist eine GMP-Leitlinie für computergestützte Systeme; Kapitel 4 behandelt die Dokumentation. Der aktuelle EudraLex-Index führt die hier verwendeten Revisionen von Januar 2011. Aus dem Einsatz in Pharma, Medizintechnik oder einem Labor folgt keine pauschal gleiche Regelwerksanwendung.

Legen Sie fest, was ein fehlerhafter Status bewirken könnte. Würde eine offene Maßnahme übersehen, eine falsche Dokumentrevision verwendet oder ein nicht begründeter Abschluss akzeptiert? Solche Fehlerfolgen helfen, Anforderungen und Prüftiefe auszuwählen. Der Produktname und eine allgemeine Herstellerbeschreibung ersetzen diese Einordnung nicht.

Quellen: [7] [8] [9]

Dokumente, Prozesse und Maßnahmen sauber auseinanderhalten

roXtra wird als modulare QM-Software angeboten. Dokumente unterstützt Dokumentenlenkung; Prozesse beschreibt ausführbare, konfigurierbare Abläufe; Maßnahmen führt Aufgaben und Bewertungen zusammen. Hinzu kommen weitere Funktionsbereiche, etwa Audits oder Risiken. Erfassen Sie, welche Module und Verknüpfungen tatsächlich eingesetzt werden.

Der öffentliche Begriff roXtra GxP bezeichnet angebotene Funktionen und Unterstützung für regulierte Anwendungen. Eine vollständig bestimmte separate GxP-Edition mit festem Lizenzumfang ist daraus nicht abzuleiten. Auch eine aktuelle Gesamt-Buildnummer ist durch die für diesen Artikel verwendeten öffentlichen Seiten nicht belegt. Der historische CAPA-Beitrag vom 25. November 2020 nennt Vorlagen ab Version 8.36.0; das ist kein aktueller Releasehinweis.

Die eigene Matrix verbindet jeden Bestandteil mit einer konkreten Prüffrage. Dokumentieren Sie zusätzlich den installierten Stand und die passende Release-Dokumentation. Gleiche Modulnamen allein belegen nicht dieselbe Konfiguration, Rolle oder Prozesslogik.

Quellen: [1] [2] [3] [4] [5]

Welche Vorgabe sieht der Anwender wirklich?

Die Produktbeschreibung von roXtra Dokumente unterscheidet Bearbeiter, Prüfer und Freigeber in konfigurierbaren Dokumentenworkflows. Während einer Überarbeitung sollen Leser weiterhin die bisher gültige Revision sehen; Entwürfe sind laut Beschreibung für Empfänger und Leser nicht sichtbar. Frühere Revisionen werden in einer Dokumentenhistorie geführt.

Prüfen Sie diese Wege mit Ihren tatsächlichen Rollen und Dokumenttypen. Ein Autor benötigt einen anderen Zugang als ein Mitarbeiter, der eine gültige Anweisung ausführen soll. Beziehen Sie Suche, Direktlink und die Verknüpfung aus einem Vorgang ein. Eine allgemeine Beschreibung der Leseransicht bestätigt nicht automatisch jeden Zugriffsweg Ihrer Installation.

roXtra beschreibt außerdem Leseaufgaben und dokumentierte Lesebestätigungen. Diese können zeigen, welcher Empfänger eine Kenntnisnahme bestätigt hat. Sie sind nicht ohne Weiteres ein Nachweis praktischer Befähigung. Für bereits ausgegebene Papierkopien oder Downloads benötigen Sie ebenfalls einen passenden Umgang; deren automatische Rücknahme wird hier nicht behauptet.

Quellen: [2] [9] [8]

Ein Prozessdiagramm ist noch kein getesteter Ablauf

Der Hersteller grenzt den Flowchart-Designer zur Visualisierung von roXtra Prozesse ab. Das Modul Prozesse nutzt BPMN 2.0 für modellierbare und ausführbare Abläufe mit Formularen, Regeln und Aufgaben. Die Möglichkeit, einen Workflow im Browser zu gestalten, beweist jedoch nicht seine fachliche Richtigkeit.

Gehen Sie einen realistischen Vorgang vom Start bis zum Ende durch. Wer erhält die erste Aufgabe? Welche Eingabe steuert eine Verzweigung? Was geschieht bei Ablehnung, fehlenden Angaben oder einer nicht verfügbaren Vertretung? Halten Sie die erwartete Reaktion fest, bevor Sie das beobachtete Verhalten beurteilen.

Untersuchen Sie insbesondere Abkürzungen im Ablauf. Ein Formular kann vollständig ausgefüllt sein, obwohl die zugehörige Entscheidung noch fehlt. Ein Prozess kann technisch beendet werden, obwohl ein externer Nachweis nicht verfügbar ist. Welche Kontrollen Sie dafür benötigen, folgt aus Ihrem Verfahren. Es gibt keine pauschale Zusage, dass jede selbst konfigurierte Vorlage alle diese Fehler bereits verhindert.

Quellen: [3] [8]

Umsetzung, Wirksamkeit und Gesamtabschluss getrennt bewerten

roXtra Maßnahmen beschreibt Verantwortlichkeiten für Umsetzung und Wirksamkeitsprüfung sowie Verknüpfungen zu Prozessen, Audits oder Risiken. Diese Verbindung ist für die Nachvollziehbarkeit hilfreich. Eine als umgesetzt markierte Aufgabe beantwortet aber noch nicht, ob die beabsichtigte Wirkung fachlich beurteilt wurde.

Legen Sie die erforderlichen Nachweise je Maßnahme fest. Bei einer geänderten Arbeitsanweisung kann die Umsetzung durch den freigegebenen neuen Stand belegt sein. Ob das adressierte Problem im vorgesehenen Anwendungskontext ausreichend beherrscht wird, benötigt eine passende Beurteilung. Deren Inhalt und Zeitpunkt sind aus dem konkreten Fall abzuleiten, nicht aus einem einheitlichen Softwarestatus.

Der historische Herstellerbeitrag zeigt einen CAPA-Beispielprozess mit Meldung, Beurteilung, Ursachenanalyse, Maßnahmen und Wirksamkeitsprüfung. Er dient als Funktionsbeispiel, nicht als vorgeschriebener Kundenablauf. Prüfen Sie Ihre eigene Konfiguration und insbesondere die Voraussetzungen für den Abschluss. Eine automatische Sperre bei jeder offenen Teilaufgabe ist durch die öffentlichen Seiten nicht allgemein belegt.

Quellen: [4] [5] [8]

Illustratives Sollbeispiel: drei Maßnahmen, zwei unterschiedliche Fortschritte

Das folgende Beispiel ist konstruiert und kein ausgeführter roXtra- oder Kundentest. CAPA-07 umfasst M1, M2 und M3. M1 betrifft eine Arbeitsanweisung, M2 eine dazugehörige Schulung, M3 die zusätzliche Prüfung des geänderten Ablaufs. Für dieses Beispiel verlangt der fachliche Sollprozess vor dem Gesamtabschluss bei allen drei Maßnahmen eine dokumentierte Umsetzung und eine positive Wirksamkeitsbewertung.

Im Ausgangszustand sind M1 und M2 umgesetzt. Nur für M2 liegt eine positiv dokumentierte Wirksamkeitsbewertung vor. M3 ist noch offen. Damit sind genau zwei von drei Maßnahmen umgesetzt, aber nur eine von drei positiv bewertet. Eine Umsetzung und zwei positive Bewertungen fehlen. Nach der selbst gesetzten Beispielregel ist der Gesamtabschluss noch nicht zulässig.

Jeder Fehlerfall beginnt wieder mit diesem definierten Bestand. Prüfen Sie einzelne Identitäten und Belege, nicht nur Summen oder Farben im Überblick. Die Zahlen wurden unabhängig aus den drei Zuständen abgeleitet. Sie beschreiben ausschließlich das Lehrbeispiel; sie bestätigen keine reale Wirkung einer Schulung und keine im Produkt bereits vorhandene Abschlussautomatik.

Quellen: [4] [5] [8]

Datenübergaben bis zum richtigen Vorgang verfolgen

roXtra Prozesse beschreibt Anbindungen über Webhooks oder Datenbankzugriffe. Formulare können mit Dokumentinhalten verbunden werden; Maßnahmen lassen sich aus anderen Modulen erstellen oder mit ihnen verknüpfen. Welche Übergänge Ihr System tatsächlich verwendet, gehört in die Bestandsaufnahme.

Definieren Sie pro Übergabe eine nachvollziehbare Identität und den benötigten Inhalt. Wird eine Meldung in einem anderen System zur Maßnahme, müssen Quelle und Ziel zusammenpassen. Ein technisch bestätigter Aufruf sagt allein wenig darüber aus, ob die richtigen Daten beim richtigen Vorgang angekommen sind.

Als eigene Fehlerfälle eignen sich eine fehlgeschlagene Übergabe, eine Wiederholung und eine unvollständige Pflichtinformation. Prüfen Sie, ob der Prozess den Zustand erkennt und kontrolliert weiterbearbeitet werden kann. Die öffentlichen Quellen liefern keine generelle Zustell-, Dubletten- oder Transaktionsgarantie. Solche Erwartungen müssen Sie für Ihre Schnittstelle konkret spezifizieren und nachweisen.

Quellen: [3] [4] [8]

Entscheidungen und historische Zusammenhänge erhalten

Unterscheiden Sie technische Berechtigung und fachliche Zuständigkeit. Eine Person kann einen Datensatz bearbeiten dürfen, ohne jede darin dokumentierte Wirksamkeitsbewertung selbst treffen zu können. Regeln Sie Aufgaben, Vertretungen und den Entzug von Zugriffsrechten entlang Ihres Prozesses.

roXtra beschreibt elektronische Signaturen, Änderungsprotokollierung und rollenbasierte Berechtigungen; AD- oder SSO-Integration wird auf der GxP-Seite als optional genannt. Diese Funktionen müssen in der konkret eingesetzten Kombination beurteilt werden. Eine allgemeine Herstellerbeschreibung bestätigt weder jede Signaturrechtswirkung noch einen vollständigen Audit Trail für sämtliche individuellen Abläufe.

Kapitel 4 verlangt eine geregelte Dokumentation. Bestimmen Sie deshalb, welche Vorgabestände, Einträge und Bewertungen den abgeschlossenen Prozess verständlich machen. Zulässige Korrekturen sollen ursprüngliche Information erkennbar erhalten. Prüfen Sie auch den späteren Zugriff, wenn ein Benutzer ausgeschieden oder eine verknüpfte Anweisung ersetzt worden ist. Eine aktuelle Anzeige allein genügt nicht als historischer Nachweis.

Quellen: [1] [2] [9] [8]

Betriebsmodell und Nachweise für Änderungen zusammenbringen

roXtra unterscheidet Kauf auf eigenen Servern, Hosted als vom Anbieter betriebene Variante und lokale Miete. Eine Mietlizenz ist damit nicht automatisch SaaS. Klären Sie vertraglich, wer Updates vorbereitet, Sicherungen erstellt, Wiederherstellung prüft und benötigte Daten bereitstellt. Ein allgemeiner Hostingvorteil ist kein Nachweis dieser Aufgaben in Ihrem konkreten Vertrag.

Der Anbieter bietet Musterunterlagen und Unterstützung für die Validierung an. Prüfen Sie deren tatsächlichen Umfang, Version, Testbedingungen und Ergebnisse. Passende Belege können übernommen werden; fehlende Übergänge werden ergänzt. Die öffentlichen Seiten erlauben weder die Annahme einer vollständigen Kundenabdeckung noch die Behauptung, jedes Paket enthalte nur unveränderte Standardfunktionen.

Bei einer Änderung betrachten Sie Konfiguration, betroffene Vorgänge und historische Nachweise. Ein neuer Entscheidungsschritt erfordert andere Fälle als eine rein redaktionelle Anpassung. Release Notes sind laut Hersteller im System erreichbar. Ihre tatsächlichen Inhalte gehören in die Betroffenheitsbewertung; eine Major- oder Minor-Nummer bestimmt für sich allein keinen universellen Wiederholungsumfang.

Quellen: [6] [1] [8] [9]

Einführung, Bestand und nächste Anpassung vorbereiten

Wählen Sie einen konkreten Qualitätsvorgang als gemeinsamen Ausgangspunkt. Der Prozessverantwortliche erläutert seine Entscheidungen, QA die Einordnung in das Qualitätssystem, ein Key-User die Konfiguration und IT den Betrieb. So werden fehlende Regeln und fehlende technische Informationen als unterschiedliche Aufgaben sichtbar.

Für eine Einführung brauchen Sie einen beschriebenen Sollprozess. Im Bestand sind tatsächliche Konfiguration und repräsentative Vorgänge wichtig. Bei Änderungen wird daraus eine gezielte Betroffenheitsprüfung. Den Aufwand treiben beispielsweise viele Verzweigungen, Schnittstellen, uneinheitliche Rollen, offene Altfälle und fehlende historische Zuordnungen. Erst nach dieser Abgrenzung sind belastbare Arbeitspakete und Termine sinnvoll.

• Module, Lizenzen, konkreten Softwarestand und Betriebsmodell erfassen.
• Einen vollständigen Ablauf mit Rollen, Entscheidungen und verwendeten Dokumenten auswählen.
• Umsetzung, Wirksamkeitsbewertung und Abschlussbedingungen eindeutig festlegen.
• Offene, doppelte, unvollständige und unzulässig bearbeitete Vorgänge als Sollfälle vorbereiten.
• Anbieterbelege, Release Notes und tatsächliche Konfiguration zusammenführen.
• Aufbewahrung, Korrektur, Wiederherstellung und Verantwortlichkeiten vereinbaren.

Quellen: [8] [3] [6]