Greenlight Guru validieren: Änderungen, Training und Qualitätsentscheidungen verbinden

QMS-Software im Medizintechnikbetrieb richtig einordnen

Greenlight Guru unterstützt Qualitätsprozesse für Medizinprodukte. Beginnen Sie deshalb mit Ihrer Rolle, den betroffenen Produkten und Absatzmärkten. Eine intern genehmigte SOP, ein dokumentierter Entwicklungsnachweis und eine Marktfreigabe beantworten unterschiedliche Fragen. Die Eignung der unterstützenden Software belegt weder die Sicherheit Ihres Medizinprodukts noch dessen vollständige Konformität.

Im EU-Kontext beschreibt die MDCG-Leitlinie 2019-07 Rev.1 die Herstellerverantwortung und verweist auf das verhältnismäßige Qualitätsmanagement nach MDR Artikel 10 Absatz 9. Für einen zutreffenden US-Scope gilt seit dem 2. Februar 2026 die QMSR mit Einbindung von ISO 13485:2016. Die FDA-CSA-Guidance vom 3. Februar 2026 gibt nichtbindende Empfehlungen für Produktions- und QMS-Software; sie ist keine Produktzulassung.

Legen Sie fest, welche Informationen in Greenlight Guru führend sind und welche Entscheidungen darauf beruhen. Ein fehlerhafter Trainingsnachweis kann etwa dazu führen, dass ein Mitarbeiter eine geänderte Prüfanweisung ohne Vorbereitung verwendet. Diese konkrete Auswirkung bestimmt die Nachweistiefe. Humanarzneimittel-GMP ist ein eigener, gegebenenfalls zusätzlicher Einsatzbereich und folgt nicht automatisch aus dem Begriff eQMS.

Quellen: [1] [9] [7] [8]

Quality, Ultralight und EDC nicht vermischen

Der Hersteller gliedert seine Plattform in Qualitätsmanagement, Produktentwicklung und klinische Evidenz. Neben Greenlight Guru Quality beziehungsweise eQMS erscheint die Bezeichnung Ultralight. Das EDC zur klinischen Datenerfassung wird ausdrücklich separat angeboten. Dokumentieren Sie daher den Vertragsumfang und die tatsächlich verfügbaren Arbeitsbereiche, bevor Sie eine Funktionsliste zum Prüfplan machen.

Eine öffentlich belegte aktuelle Buildnummer für alle Kunden lässt sich daraus nicht ableiten. Die Validation Guidance vom November 2025 verweist für die Versionsnummer auf das Kundensystem. Halten Sie diesen Stand zusammen mit Rollen, eingerichteten Abläufen, Zusatzfunktionen und Integrationen fest. Ältere Anleitungen zu bestimmten Quality-Arbeitsbereichen sind nicht automatisch für jede Ultralight-Einrichtung maßgeblich.

Für ein kleines Team kann zunächst Dokumentenlenkung mit Training ausreichen; ein anderer Betrieb benötigt zusätzlich Lieferanten- und Qualitätsereignisse. Entscheidend ist die eigene Aufgabe. Lassen Sie bestätigen, welche Nachweisdokumente genau Ihre Produktlinie und Konfiguration betreffen. Besonders bei einer Umstellung zwischen Angeboten sollten vorhandene Daten, historische Entscheidungen und neue Statusbedeutungen ausdrücklich abgeglichen werden.

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

Den Nachweis entlang einer Änderung aufbauen

Wählen Sie einen repräsentativen Ablauf, statt sämtliche Menüpunkte gleich tief zu testen. Die folgende Arbeitshilfe zeigt einen selbst konstruierten Änderungsfall. SOP-17 beschreibt eine Endprüfung, CO-17 die Änderung auf Revision B und CAPA-17 den Anlass. Ob Ihr System diese Kennungen oder Status verwendet, ist unerheblich; die Beziehungen müssen fachlich eindeutig sein.

Zu jeder Anforderung gehört eine Aussage darüber, woran Sie die korrekte Funktion erkennen. Ein vorhandener Link beweist beispielsweise noch nicht, dass die richtige Revision verknüpft ist. Ebenso belegt ein hochgeladener Bericht nicht dessen inhaltliche Eignung. Ergänzen Sie deshalb zu den vorgesehenen Belegen den tatsächlich bewerteten Stand und verbleibende Prüfaufgaben.

Diese Matrix ist eine eigene Planungshilfe. Sie verlangt weder ein bestimmtes Dokumentformat noch separate Akten für jeden Baustein. Ihr Nutzen liegt darin, widersprüchliche Erwartungen früh sichtbar zu machen: Wenn QA die Freigabe des Dokuments meint, die Produktion aber eine Einsatzberechtigung erwartet, muss diese Unterscheidung vor der Konfiguration geklärt werden.

Quellen: [1] [8]

Freigegebene Fassung und geschulte Personen zusammen prüfen

Die Produktbeschreibung verbindet Dokumentenlenkung, Änderungsabläufe und Training. Für Ihre Einrichtung ist besonders wichtig, wann eine neue Fassung wirksam wird und welche Personen betroffen sind. Eine Trainingszuordnung kann fehlen, obwohl das Dokument selbst korrekt freigegeben wurde. Prüfen Sie deshalb auch eine Rollenänderung, einen neuen Mitarbeiter und eine Vertretung.

Formulieren Sie eine überprüfbare Regel: Für die Tätigkeit Endprüfung muss Person C die für diesen Ablauf gültige Revision B kennen, bevor sie die Tätigkeit selbstständig ausführt. Ein alter Abschluss zu Revision A erfüllt diese Regel nicht. Wie die erforderliche Befähigung festgestellt wird, bestimmt Ihr Verfahren; eine Lesebestätigung ist nicht automatisch ein Kompetenznachweis.

Beziehen Sie den tatsächlichen Arbeitsort ein. Wird eine ausgedruckte Anweisung verwendet, muss deren Aktualität organisatorisch oder technisch gesichert werden. Wird die Tätigkeit in einem anderen System gestartet, braucht die Übergabe eine eigene Betrachtung. Aus einem Trainingsstatus im eQMS folgt keine belegte automatische Sperre einer Maschine oder eines ERP-Benutzers.

Quellen: [1] [4] [8]

CAPA-Abschluss und Wirksamkeit auseinanderhalten

Greenlight Guru beschreibt konfigurierbare Qualitätsereignisse und Verbindungen zu betroffenen Dokumenten, Produkten und Änderungen. Prüfen Sie, was Ihre Konfiguration unter erledigt, verifiziert oder abgeschlossen versteht. Eine ausgeführte Maßnahme und eine nachgewiesene Wirksamkeit können zeitlich auseinanderliegen. Das System soll diese Unterscheidung in Ihrem Verfahren nachvollziehbar unterstützen.

Im konstruierten Fall wurde eine missverständliche Prüfanweisung überarbeitet. Der Nachweis der Maßnahme umfasst die neue Fassung und das betroffene Training. Die Wirksamkeitsbewertung könnte zusätzlich eine vorab festgelegte Beobachtung späterer Prüfungen benötigen. Zeitraum, Umfang und Akzeptanzkriterium müssen zum Problem passen; hier wird keine allgemeine Anzahl von Prüfungen vorgegeben.

Ein sinnvoller Fehlerfall versucht den Abschluss mit fehlendem Wirksamkeitsbeleg. Das erwartete Verhalten kann eine verhinderte Statusänderung oder eine ausdrücklich begründete, kontrollierte Zwischenentscheidung sein, je nach genehmigtem Verfahren. Definieren Sie den zulässigen Weg vorab. Eine frei ausgefüllte Begründung darf nicht unbemerkt jede fachliche Voraussetzung ersetzen.

Quellen: [1] [5] [8]

Anbieterbelege nach ihrem tatsächlichen Inhalt übernehmen

Die Hersteller-Guidance beschreibt einen Validation Test Report mit vorgesehenen Nutzungen und zugeordneten Testnachweisen. Für Product Updates und bestimmte Änderungen wird eine erneute Kundenbewertung erläutert. Das ist eine konkrete Grundlage für die Nachweisplanung, aber noch kein eingesehener Bericht Ihrer Umgebung.

Ordnen Sie den erhaltenen Beleg der eigenen Anforderung zu: Welche Funktion, Version, Konfiguration und Testumgebung sind erfasst? Ist das Ergebnis nachvollziehbar, gibt es relevante Abweichungen und unter welchen Bedingungen ist die Aussage übertragbar? Ein tragfähiger Beleg kann übernommen werden. Eine tatsächliche Lücke führt zu einer ergänzenden Aktivität, nicht automatisch zur Wiederholung sämtlicher Herstellertests.

Beispielsweise kann ein Anbieterbeleg das Auslösen einer Trainingsaufgabe abdecken, während die Auswahl Ihrer drei Rollen noch geprüft werden muss. Umgekehrt kann ein kundenspezifisches Lieferpaket bereits genau diese Zuordnung enthalten. Halten Sie den Übernahmeentscheid und seine Grenzen fest. Ein allgemeines Lieferantenaudit ist dafür nur soweit aussagekräftig, wie sein tatsächlicher Umfang die betreffende Frage beantwortet.

Quellen: [3] [8]

Ein Sollmodell mit drei Schulungszuordnungen durchspielen

Das folgende Beispiel ist vollständig konstruiert und wurde nicht in einem Hersteller- oder Kundensystem ausgeführt. Ausgangszustand: SOP-17 Revision A ist gültig; Revision B befindet sich im Änderungsprozess CO-17. Die Personen A, B und C führen dieselbe betroffene Tätigkeit aus. Für diesen Fall gilt die eigene Regel: Der neue Ablauf wird erst für das gesamte Dreierteam gestartet, wenn alle drei erforderlichen Zuordnungen zu Revision B abgeschlossen und die fachlichen Voraussetzungen bestätigt sind.

Nach der Dokumentfreigabe schließen A und B ihr Training ab, C noch nicht. Damit sind zwei von drei erforderlichen Zuordnungen erledigt; eine bleibt offen. Eine zweite Bestätigung von B ändert diese Anzahl nicht. Erst der passende Abschluss von C ergibt drei eindeutige Abschlüsse. Diese Rechnung kontrolliert die Zuordnung, nicht die Qualität des Schulungsinhalts.

Jeder Tabellenfall beginnt mit dem angegebenen Ausgangszustand. Bewahren Sie tatsächliche Beobachtung und Abweichung getrennt vom geplanten Soll auf. Wenn ein Versuch fehlschlägt, bleibt sein Ergebnis erhalten; ein Wiederholungstest bekommt einen erkennbaren Bezug zur Korrektur. Die Tabelle behauptet keine standardmäßig eingebaute Startblockade von Greenlight Guru.

Quellen: [1] [8]

Rechte und Ausgaben am vollständigen Zusammenhang prüfen

Testen Sie mit realistisch zugeschnittenen Rollen: Wer darf eine Anweisung bearbeiten, eine Änderung genehmigen oder die Konfiguration eines Qualitätsereignisses verändern? Ein Benutzer mit Leserechten sollte im eigenen Rechtekonzept keine relevante Entscheidung überschreiben können. Prüfen Sie außerdem, wie ausgeschiedene Personen in historischen Aufzeichnungen weiterhin identifizierbar bleiben.

Der Herstellerbeitrag zu Quality Processes vom Juni 2025 beschreibt zusätzliche Felder und Aufgabenexporte. Ein solcher CSV-Auszug ist nicht automatisch der vollständige Qualitätsdatensatz. Stellen Sie an einem ausgewählten Ereignis fest, welche Anlagen, Bezüge, Entscheidungen und historischen Angaben tatsächlich mitkommen. Eine exportierte Aufgabe ohne ihren fachlichen Kontext kann für die spätere Bewertung zu wenig sein.

Bei einer Migration sind nicht nur Dokumentzahlen, sondern auch Revisionen, Gültigkeit, Verantwortliche und offene Aufgaben abzugleichen. Bestimmen Sie den benötigten Aufbewahrungs- und Zugriffsumfang aus Ihrem Prozess. Ob elektronische Signaturen erforderlich sind und welche Anforderungen greifen, ist gesondert festzulegen; ein angebotener Part-11-Funktionsumfang schafft weder eine universelle Signaturpflicht noch eine automatische Konformität.

Quellen: [6] [4] [10] [8]

Cloudänderungen auf den eigenen Ablauf beziehen

Die Hersteller-Guidance unterscheidet Product Updates, Maintenance Releases und Patches. Verwenden Sie diese Einordnung als Eingangsinformation. Prüfen Sie anschließend, ob der eigene Ablauf oder dessen Nachweise betroffen sind. Eine Änderung der Rollenwahl kann für Ihr Training bedeutsamer sein als eine sichtbar größere, aber ungenutzte neue Funktion.

Führen Sie betroffene Anforderungen, vorhandene Anbieterbelege und ergänzende Aktivitäten zusammen. Bei einer geänderten Zuordnungsregel könnte das Dreipersonenmodell erneut aussagekräftig sein. Bei einer reinen Darstellungskorrektur kann ein anderer, begründeter Nachweis ausreichen. Weder Vollretest noch vollständiger Testverzicht folgt allein aus dem Releaseetikett.

Auch Änderungen durch Ihre eigene Administration gehören in diese Betrachtung: neue Pflichtfelder, andere Genehmiger, geänderte Rollen oder eine zusätzliche Schnittstelle. Dokumentieren Sie den bewerteten Zustand nach der Änderung. Für Ausfälle sollte feststehen, welche kritischen Tätigkeiten fortgeführt werden dürfen, wie vorübergehende Aufzeichnungen später kontrolliert übernommen werden und wer widersprüchliche Informationen entscheidet.

Quellen: [3] [8]

Einführung, Bestand und Aufwand gezielt vorbereiten

Im KMU sollte QA die fachlichen Entscheidungsregeln verantworten, IT die technische Umgebung und Integrationen beschreiben und der Prozessverantwortliche repräsentative Fälle liefern. Die Administration erläutert die Konfiguration; der Anbieter stellt den vereinbarten Dokumentationsumfang bereit. Eine Person kann mehrere Aufgaben übernehmen, solange Verantwortung und notwendige Kontrolle verständlich bleiben.

Vor dem Start benötigen Sie keine künstlich umfangreiche Akte, sondern belastbare Ausgangsinformationen. Aufwand entsteht vor allem durch unklare Prozesse, uneinheitliche Dokumentstände, viele Rollen, zusätzliche Integrationen und schlecht zuordenbare Altdaten. Bei einem bestehenden System kommen offene Ereignisse und bereits getroffene Entscheidungen hinzu. Planen Sie Zeit für deren fachliche Klärung ein, bevor Testtermine festgelegt werden.

Die folgende Liste hilft, eine Einführung oder Änderung überprüfbar vorzubereiten. Markieren Sie jeden Punkt als vorhanden, zu klären oder für den eigenen Scope nicht relevant. Daraus entsteht ein begründeter Arbeitsumfang; aus der Produktwahl alleine lässt sich keine verlässliche Projektdauer ableiten.

• Produktlinie, Module, Version und verantwortlichen Systembetreuer festhalten.
• Regelbereich, führende Aufzeichnungen und betroffene Entscheidungen bestimmen.
• Dokumentrevisionen, Rollen und Trainingsregeln fachlich festlegen.
• CAPA-Maßnahme, Wirksamkeitsbewertung und Abschlusskriterien unterscheiden.
• Passende Anbieterberichte anfordern und Übernahmeentscheide dokumentieren.
• Testpersonen, Ausgangsdaten, Soll und Rücksetzung vorbereiten.
• Migration, Exporte und externe Übergaben am konkreten Datensatz prüfen.
• Offene Abweichungen, Betriebsregeln und Nutzungsentscheidung nachvollziehbar abschließen.

Quellen: [4] [8]