aiti-suite validieren: Dokumentstand, Prozessentscheidung und Schulung verbinden

1. Produktfamilie, Module und Betriebsform sauber benennen

Die unter dem Suchbegriff aiti Life Science Suite geführte Produktfamilie wird vom Hersteller als aiti-suite bezeichnet. SOP-Guard dient der Dokumentenverwaltung, FORM-Guard den Formular- und Qualitätsprozessen und SKILL-Guard dem Schulungsmanagement. Die Module werden einzeln oder kombiniert angeboten. Eine einzelne SOP-Guard-Installation ist daher nicht automatisch der vollständige Dreierverbund.

Die Suite-Seite beschreibt eine Webanwendung als virtuelle Maschine mit Betrieb im Unternehmen oder Rechenzentrum. Bei SOP-Guard nennt der Hersteller zusätzlich ausdrücklich private Cloud als möglichen Installationsort. Daraus lässt sich kein pauschales SaaS-Modell ableiten. Dokumentieren Sie Umgebung, Module, Version, Datenhaltung, Infrastrukturverantwortung und Wartungsumfang Ihres Vertrags.

Dieser Artikel behandelt den Einsatz in Humanarzneimittel-GMP-Prozessen. Die Europäische Kommission führt hierfür unter anderem Annex 11 sowie die Kapitel 1, 2 und 4. Andere Life-Science-Bereiche benötigen eine eigene Einordnung. Eine Herstellerbezeichnung mit GxP oder FDA legt nicht automatisch fest, welche Anforderungen für jeden Ihrer Datensätze gelten.

Quellen: [1] [2] [6] [7]

2. Lieferantenpakete mit dem eigenen Prozess abgleichen

Die öffentlichen Modulbeschreibungen nennen Validierungspakete mit Installationsdokumentation, Testfalldokumenten und Risikoanalyse. Das ist eine Grundlage für die Planung. Welche Version, Komponenten, Konfigurationen und Bedingungen ein tatsächlich geliefertes Paket abdeckt, muss aus dessen Inhalt hervorgehen. Ein Produkttext mit einer GAMP-Kategorie beantwortet diese Frage nicht für den Kundenprozess.

Ordnen Sie geeignete Belege Ihren Anforderungen zu und benennen Sie verbleibende Lücken. Ein gelieferter Test kann beispielsweise eine allgemeine Formularfunktion belegen, ohne Ihre mehrstufige Genehmigungsregel abzudecken. Umgekehrt muss eine ausreichend belegte Funktion nicht allein deshalb erneut getestet werden, weil der Nachweis vom Lieferanten stammt.

Die folgende eigene Arbeitshilfe trennt Komponenten und Übergänge. Sie verhindert, dass die Bereitstellung einer virtuellen Maschine als vollständiger fachlicher Nachweis oder eine einzelne Modulprüfung als Abdeckung der gesamten Suite behandelt wird.

Quellen: [2] [3] [4] [7]

3. Dokumentgenehmigung, Wirksamkeit und Verteilung auseinanderhalten

SOP-Guard beschreibt Erstellung, Prüfung, Freigabe, Verteilung und Archivierung. Die Branchenübersicht ergänzt Versionierung mit Historie und die Verbindung zu Änderungen, Abweichungen und CAPAs. Für Ihre Validierung sollte feststehen, wie eine neue Revision durch diesen Ablauf geht und welcher Stand an welchem Zeitpunkt verwendet werden darf.

Bereiten Sie dafür ein Dokument mit eindeutig unterscheidbaren Revisionen vor. Prüfen Sie den berechtigten Genehmigungsweg und den Zugriff einer normalen Anwenderrolle. Kann diese Person die vorgesehene gültige Fassung erkennen? Bleibt ein historischer Nachweis mit der damals maßgeblichen Fassung verständlich? Eine Suche nach dem Dokumenttitel allein genügt nicht, wenn mehrere Revisionen ähnlich benannt sind.

Eine genehmigte Änderung kann zusätzliche Maßnahmen vor ihrem festgelegten Wirksamwerden erfordern. Dazu können passende Schulung oder eine kontrollierte Umstellung gehören. Das ist anhand der tatsächlichen Änderung zu entscheiden, nicht automatisch bei jeder redaktionellen Korrektur. Testen Sie den eigenen Ablauf einschließlich einer fehlenden Voraussetzung, ohne eine öffentlich nicht belegte Standardsperre der Software zu behaupten.

Quellen: [2] [5] [8] [9]

4. Formularfelder an fachliche Entscheidungen binden

FORM-Guard verarbeitet unter anderem CAPA-, Änderungs- und Abweichungsprozesse. Die Modulbeschreibung erläutert, dass Mitarbeiter den zugewiesenen Formularbereich entsprechend ihrer Zuständigkeit bearbeiten und das Formular anschließend weitergeleitet wird. Autorisierungen, Fristen und Eskalationsstufen sind gestaltbar. Diese Funktionen sollten den fachlich genehmigten Ablauf abbilden.

Beschreiben Sie daher pro Schritt, welche Information erforderlich ist, wer sie bewertet und was bei einer Ablehnung geschieht. Vollständig ausgefüllte Felder sind noch keine tragfähige Ursachenanalyse. Ebenso belegt die Weiterleitung eines Formulars nicht, dass eine notwendige unabhängige Entscheidung vorliegt. Prüfen Sie eine fehlende Angabe, eine unzulässige Bearbeiterrolle und eine begründet zurückgewiesene Entscheidung.

Widgets und Auswertungen können den Bearbeitungsstand zeigen. Legen Sie fest, welche Statusbedeutung ein Bericht transportieren soll. „Eingabe vollständig“, „zur Entscheidung vorgelegt“ und „fachlich abgeschlossen“ dürfen im eigenen Prozess nicht unbeabsichtigt zusammenfallen. Für qualitätsrelevante Maßnahmen bleibt die begründete Bewertung einschließlich erforderlicher Wirksamkeitsprüfung maßgeblich.

Quellen: [3] [5] [9] [7]

5. Schulungsbedarf unabhängig vom Abschlussbericht bestimmen

SKILL-Guard beschreibt Schulungspläne nach Jobrollen, Abteilungen oder Fähigkeiten sowie eine Trainingsmatrix mit Bezug zu Organisationseinheiten. Diese Mechanismen können die Zuweisung unterstützen. Ob sie Ihren tatsächlichen Bedarf vollständig abbilden, prüfen Sie gegen einen unabhängig festgelegten Personenkreis und die dazugehörigen Aufgaben.

Berücksichtigen Sie Eintritt, Rollenwechsel, Vertretung und Austritt. Bei einem Wechsel muss nachvollziehbar sein, welche bisherigen Nachweise bestehen bleiben, welche neuen Anforderungen entstehen und welche Zuordnungen entfallen. Ein Mitarbeiter, der zufällig im Abschlussbericht auftaucht, gehört nicht allein deshalb zur Sollgruppe. Eine fehlende Zuweisung darf umgekehrt nicht einfach den Nenner verbessern.

Kapitel 2 des EU-GMP-Leitfadens fordert bedarfsgerechte anfängliche und fortlaufende Schulung sowie die periodische Bewertung ihrer praktischen Wirksamkeit. Ein elektronischer Abschluss belegt zunächst den definierten Schulungsvorgang. Ob die Person eine Tätigkeit selbstständig ausführen darf und praktisch beherrscht, ist eine weitere fachliche Frage. Ein LMS-Status sollte dafür nicht ohne passendes Verfahren eingesetzt werden.

Quellen: [4] [10] [7]

6. Prüfbeispiel: Die richtige Revision und der richtige Nenner

Das folgende Beispiel ist frei konstruiert und kein ausgeführter Kunden- oder Produkttest. Änderung CH-24 betrifft SOP-P12 Revision 4. Die vorab festgelegte Sollgruppe besteht aus A, B, C und D. Für diesen Fall verlangt das genehmigte Verfahren einen passenden Schulungsnachweis vor dem definierten Tätigkeitsbeginn. Eine pauschale Nachschulungspflicht für jede SOP-Änderung wird daraus nicht abgeleitet.

A und B haben passende Nachweise zu Revision 4. C besitzt nur einen Nachweis zu Revision 3; eine Äquivalenzentscheidung liegt nicht vor. D ist neu und noch offen. E hat zwar Revision 4 abgeschlossen, gehört aber nicht zur Sollgruppe. Die ursprüngliche Personenliste und die Revisionsanforderung bleiben als unabhängige Referenz erhalten.

Der Test vergleicht den tatsächlichen Bericht, die Zuweisungen und die verknüpften Dokumentstände mit dieser Referenz. Wird der Formularvorgang geschlossen, obwohl der eigene Abschlussprozess noch erforderliche Schritte verlangt, ist dies als Befund zu bewerten. Die passende technische oder organisatorische Kontrolle muss für den konkreten Ablauf nachgewiesen werden.

Quellen: [2] [3] [4] [10] [8]

7. Rollen, Signaturen und Identitäten über Modulgrenzen prüfen

Die Produktseiten nennen elektronische Signaturen, Audit-Trail und rollenbezogene Zugriffe. Entscheidend ist, welche Handlung eine Person im konkreten Prozess ausführen darf. Leserechte an einer SOP, Bearbeitung eines Formularbereichs und Genehmigung eines Qualitätsentscheids sollten entsprechend der fachlichen Verantwortung eingerichtet und geprüft werden.

Die dokumentierte LDAP-Anbindung eröffnet einen weiteren Prüfbereich. Stellen Sie fest, wie Benutzer eindeutig zugeordnet werden und welche Änderungen aus dem Verzeichnis tatsächlich übernommen werden. Ein deaktiviertes Verzeichniskonto, eine geänderte Gruppenzugehörigkeit und eine Vertretung sind unterschiedliche Fälle. Erwartetes Verhalten und Zuständigkeit werden vor dem Test festgelegt; automatische Umsetzung wird nicht vorausgesetzt.

Bei verwendeten elektronischen Signaturen prüfen Sie Bedeutung und Bindung an den richtigen Dokument- oder Formularstand. Eine spätere Änderung sollte im vorgesehenen Verfahren nachvollziehbar bewertet werden. Die technische Anmeldung allein beantwortet weder die Genehmigungsbefugnis noch die Frage, was die Person bestätigt hat. Annex 11 behandelt diese Kontrollen im Zusammenhang mit Zugriff und elektronischer Signatur.

Quellen: [5] [1] [7]

8. Historische Vorgänge und übernommene Nachweise verständlich halten

Bei einer Einführung werden häufig Dokumente und Schulungsnachweise aus bestehenden Ablagen übernommen. Legen Sie vorab fest, welche Informationen erhalten bleiben müssen: beispielsweise Person, Inhalt, Revision, Datum und ursprünglicher Nachweiszusammenhang. Nicht jeder Altdatensatz enthält dieselbe Tiefe. Eine Lücke ist sichtbar zu bewerten, statt beim Import unbemerkt eine neue fachliche Aussage zu erzeugen.

Ein alter Abschluss darf etwa nicht ohne passende Grundlage als Schulung der heutigen Revision erscheinen. Testen Sie neben vollständigen Datensätzen auch uneindeutige Personenkennungen und fehlende Versionsbezüge. Ein erfolgreicher Import zählt übertragene Datensätze; er beweist nicht automatisch deren richtige Bedeutung. Bewahren Sie für den Vergleich die ursprüngliche Referenz auf.

Für Export und Aufbewahrung verfolgen Sie einen vollständigen Vorgang durch die relevanten Module. Kann ein späterer Leser erkennen, welche SOP galt, welche Formularentscheidung getroffen wurde und auf welchen Schulungsnachweis sie sich stützte? Umfang und Aufbewahrungsdauer hängen vom Prozess ab. Eine beliebige PDF-Sammlung oder ein aktueller Dashboardstatus ersetzt diesen Zusammenhang nicht automatisch.

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

9. Änderungen und Wiederherstellung am verbundenen Prozess bewerten

Änderungen betreffen nicht nur Softwareversionen. Auch ein Formularfeld, eine Gruppe, eine Eskalationsregel oder eine Dokumentenzuordnung kann den Nachweis verändern. Ordnen Sie die Änderung den betroffenen Anforderungen zu und bewerten Sie laufende sowie historische Vorgänge. Eine neue Regel darf nicht stillschweigend als Erklärung für einen alten Abschluss dienen.

Nutzen Sie passende Lieferantenunterlagen und ergänzen Sie gezielte Prüfungen des eigenen Ablaufs. Betroffene unveränderte Funktionen gehören in die Betrachtung, wenn ihre Daten oder Voraussetzungen geändert wurden. Umgekehrt folgt aus einem Update keine pauschale Wiederholung sämtlicher Tests. Entscheidend ist eine nachvollziehbare Bewertung der verbleibenden Abdeckung.

Der Betrieb als virtuelle Maschine macht Zuständigkeiten für Sicherung, Wiederherstellung und Wartung besonders konkret. Prüfen Sie, ob die vorgesehene Wiederherstellung einen zusammenpassenden Stand von Anwendung, Daten und benötigten Beziehungen liefert. Ein startender Server allein ist dafür zu wenig. Vereinbaren Sie mit Betreiber und Lieferant auch, wie Rollen, Schnittstellen und relevante historische Vorgänge anschließend überprüft werden.

Quellen: [1] [2] [7] [8]

10. Vorbereitung und Checkliste für QA und IT

Beginnen Sie mit einem typischen Änderungsvorgang und seinen echten Übergängen. QA legt fest, welche Revision, Entscheidung und Schulung benötigt werden. Dokumentenverantwortliche und Schulungskoordinator bestimmen Inhalte, Sollgruppen und vorhandene Nachweise. IT beschreibt die Umgebung, Identitäten, Anbindungen und Betriebsaufgaben. Der System Owner führt diese Beiträge mit den Lieferantenunterlagen zusammen.

Der Aufwand hängt besonders von unterschiedlichen Formularwegen, Rollenmodellen, Altdaten und Modulverknüpfungen ab. Für ein KMU ist daher eine überschaubare, repräsentative Variantenauswahl hilfreich. Sie muss die kritischen Unterschiede abdecken, statt lediglich viele ähnliche Dokumente zu zählen. Offene fachliche Regeln sollten geklärt werden, bevor ein großer Testkatalog entsteht.

• Module, Versionen, VM-Umgebung und vertragliche Betriebsverantwortung erfassen.
• Lieferantenpakete anhand ihrer wirklichen Abdeckung den Anforderungen zuordnen.
• Dokumentgenehmigung, Wirksamkeit und notwendige Begleitmaßnahmen festlegen.
• Formularschritte mit Verantwortlichen, Informationen und Annahmekriterien beschreiben.
• Schulungszielgruppe und Revisionsbedarf unabhängig vom Ergebnisbericht bestimmen.
• Benutzer-, Gruppen- und Signaturverhalten anhand gezielter Negativfälle prüfen.
• Migration, Historie und Export mit Originalreferenzen vergleichen.
• Änderungsbewertung und Wiederherstellung des vollständigen Nachweiszusammenhangs regeln.

Quellen: [7] [1] [10]