Inhaltsverzeichnis
Das Wichtigste vorab
Was bedeutet FreeWeigh.Net validieren?
FreeWeigh.Net validieren bedeutet, seine Eignung für den vorgesehenen Qualitätskontrollprozess nachzuweisen. Dazu gehören die richtige Zuordnung von Messwert, Produkt, Charge, Einheit und Prüfkonfiguration sowie nachvollziehbare Auswertung und Datenhaltung. Umfang und Prüftiefe folgen den Prozessrisiken. Softwareprüfung, Eignung der Waage und gesetzliche Füllmengenbewertung beantworten unterschiedliche Fragen; ein passender Messwert oder ein vorhandenes Modul ersetzt den Gesamtnachweis nicht.
- FreeWeigh.Net unterstützt statistische Qualitätskontrolle; der konkrete Einsatz bestimmt die GxP-Relevanz.
- Tara, Einheit und Prüfkonfigurationsversion gehören zum Kontext eines Messwerts.
- Ein rechnerisch richtiger Bericht kann durch Zuordnung oder Datenauswahl irreführen.
- Gerätenachweis, Softwarevalidierung und rechtliche Füllmengenbewertung bleiben getrennt.
FreeWeigh.Net ist SQC-Software: den installierten Umfang bestimmen
METTLER TOLEDO beschreibt FreeWeigh.Net als modulare Software für statistische Qualitäts- und Prozesskontrolle. Ein zentraler Anwendungsfall ist die stichprobenbasierte Nettofüllmengenkontrolle. Je Ausstattung können weitere Messgrößen und Qualitätsattribute hinzukommen. Der Gegenstand dieses Artikels sind solche Prüf- und Datenprozesse, kein vollständiges MES und kein Chromatographiedatensystem.
Beginnen Sie mit der installierten Kombination: Softwarestand, lizenzierte Module, Prüfplätze, angeschlossene Geräte, Datenbank und Übergaben an andere Systeme. Die öffentliche Modulbroschüre 30313138 beschreibt unter anderem Batch Handling, Release Criteria, Test Item Versioning und XML Link. Ihre Seiten tragen teilweise einen Stand von 2016. Diese Beschreibung ersetzt deshalb nicht die aktuellen Unterlagen zu Ihrer Installation.
Eine aktuelle numerische Releaseversion wird hier nicht behauptet. Lassen Sie sich insbesondere bei einem Upgrade bestätigen, welche Funktionen, Geräte und Datenformate zum vorgesehenen Stand passen. Ein angebotenes Modul ist nicht automatisch in Ihrer Lizenz aktiv. Aus einer Verbindungsmöglichkeit folgt auch noch keine geprüfte Kopplung mit Ihrem konkreten Waagentyp.
GxP, Nettofüllmenge und Messrecht getrennt einordnen
Eine Füllmengenanwendung ist nicht allein wegen ihres Produktnamens GMP-relevant. Beschreiben Sie zunächst, welche Entscheidung mit ihren Daten getroffen wird. Dienen Ergebnisse beispielsweise einer Inprozesskontrolle in der Herstellung von Humanarzneimitteln, ist der betreffende GMP-Prozess die Grundlage der Bewertung. Eine rein betriebswirtschaftliche Auswertung hat einen anderen Zweck.
Im Humanarzneimittel-GMP-Kontext ist Annex 11 die einschlägige Leitlinie für computergestützte Systeme. Der aktuelle EudraLex-Index führt weiterhin die Revision von Januar 2011. Gesetzliche Fertigpackungsanforderungen, Messrecht und deren konkrete Anwendbarkeit müssen separat bestimmt werden. Aus den Zahlen dieses Artikels ergibt sich keine zulässige Unterfüllung und keine Freigabe einer realen Packung.
Ein Modul mit der Bezeichnung 21 CFR Part 11 klärt ebenfalls nicht den FDA-Geltungsbereich. Dafür sind die einschlägigen Aufzeichnungspflichten und die tatsächliche elektronische Verwendung maßgeblich. Halten Sie die begründete Einordnung fest, bevor Sie zusätzliche Kontrollen oder Dokumentationsumfänge festlegen.
Welche Entscheidung muss Ihr Prüfprozess tragen?
Die folgende Matrix ist eine eigene Arbeitshilfe. Sie verbindet eingesetzte Funktionen mit einer fachlichen Frage. Erfassen Sie nur tatsächlich genutzte Funktionen und ergänzen Sie, wer das Ergebnis benötigt. Dadurch wird sichtbar, ob ein vorhandener Herstellerbeleg genügt oder ein betrieblicher Übergang noch offen ist.
Priorisieren Sie nach Fehlerfolge und vorhandener Kontrolle. Eine unscheinbare Einheitenumrechnung kann wichtiger sein als ein komfortables Diagramm. Fehlende Informationen sind kein Argument für ein geringes Risiko. Klären Sie zuerst, welche Datenquelle und Entscheidung betroffen wären.
| Prüffeld | Fachliche Frage | Konkreter Nachweisbedarf |
|---|---|---|
| Prüfplatz und Gerät | Woher stammt der Einzelwert? | Gerätekennung, Übertragungsformat und Zuordnung zur tatsächlichen Probe. |
| Produkt und Charge | Gehört die Stichprobe zum richtigen Auftrag? | Normalfall sowie falsche oder fehlende Identität mit festgelegter Behandlung. |
| Prüfkonfiguration | Welche Tara und Einheit galten? | Gültiger Stand bei Erfassung sowie nachvollziehbare frühere Werte. |
| Lokaler Ergebnisstatus | Welche Entscheidung löst der Status aus? | Befugnis, Kriterien und Übergabe; keine stillschweigende Gleichsetzung mit vollständiger Chargenfreigabe. |
| Bericht und Export | Welche Daten wurden ausgewählt? | Abgleich von Grundgesamtheit, Filtern, Einzelwerten und Empfängerzuordnung. |
Waageneignung und richtige Datenverarbeitung gesondert prüfen
Eine kalibrierte Waage kann einen richtigen Wert liefern, der anschließend dem falschen Datensatz zugeordnet wird. Umgekehrt macht eine korrekte Übertragung ein ungeeignetes Messgerät nicht geeignet. Kapitel 3 der EU-GMP-Leitlinie behandelt passenden Messbereich und Präzision sowie Kalibrierung und Prüfungen. Diese Gerätenachweise müssen zum Einsatz passen.
Für die Softwareprüfung legen Sie zusätzlich fest, ob Brutto- oder Nettowerte übertragen werden und an welcher Stelle Tara abgezogen wird. Eine zweimalige Taraabziehung ist ebenso falsch wie eine ausgelassene. Dokumentieren Sie Einheit, Dezimalformat, Auflösung und gegebenenfalls Umrechnung. Der angezeigte Wert allein zeigt nicht, welche Bearbeitung bereits im Gerät stattgefunden hat.
Prüfen Sie den Weg mit bekannten Eingaben vom Ursprung bis zum gespeicherten Datensatz. Ein manuell eingespielter Testwert kann eine Auswertelogik prüfen, aber keinen echten Geräteanschluss belegen. Wenn Sie beide Prüfarten verwenden, kennzeichnen Sie ihre Reichweite. Der Nachweis soll später erkennen lassen, welches Risiko durch welchen Test abgedeckt wurde.
Tara und Prüfkonfiguration ändern, ohne den Verlauf zu verlieren
Die historische Herstellerbroschüre beschreibt Test Item Versioning als Möglichkeit, neue Einstellungen anzulegen und frühere Roh- und Statistikdaten weiter verfügbar zu halten. Prüfen Sie diese Funktion am tatsächlich eingesetzten Stand. Entscheidend ist nicht nur, ob eine neue Versionsnummer erscheint, sondern welche Stichproben welchem Parameterstand zugeordnet sind.
Eine sinnvolle Anforderung benennt den Wechselzeitpunkt: Gilt die neue Tara ab einer neuen Charge, einem neuen Prüfauftrag oder einem ausdrücklich bestimmten Zeitpunkt? Was geschieht mit einer bereits begonnenen Stichprobe? Diese Regeln kommen aus Ihrem Prozess. Sie dürfen nicht erst aus einem zufällig beobachteten Softwareverhalten abgeleitet werden.
Erhalten Sie den ursprünglichen Kontext. Eine fachlich notwendige Korrektur braucht eine nachvollziehbare Behandlung und Bewertung ihrer Auswirkungen; sie darf frühere Ergebnisse nicht stillschweigend umdeuten. Verwenden Sie für den Vergleich einen unabhängig dokumentierten Sollstand. Eine Kopie der aktuellen Konfiguration erklärt nicht automatisch, mit welchem Stand der ältere Bericht entstand.
Illustratives Prüfbeispiel: zwei Tarastände, ein nachvollziehbarer Datenweg
Dies ist ein konstruiertes Software-Prüfbeispiel, kein Kundenfall und kein durchgeführter Produkttest. Das eigene Soll lautet: Für Testcharge A gilt Konfiguration V1 mit Tara 10,00 g. Für Testcharge B gilt V2 mit 10,40 g. Die Software erhält hier ausdrücklich Bruttowerte; eine Taraabziehung im vorgeschalteten Gerät ist ausgeschlossen. Alle Werte haben zwei Dezimalstellen. Es werden keine Akzeptanzgrenzen für ein reales Produkt festgelegt.
Jeder Fall beginnt mit seinem dokumentierten Ausgangszustand. Die Eingaben und Sollwerte liegen vor Ausführung außerhalb der zu prüfenden Anwendung fest. Für die Auswertung wird jeweils Brutto minus gültiger Tara gerechnet. Die Tabelle beschreibt erwartete Ergebnisse, keine zugesagten Herstellerfunktionen. Fehlerbehandlung wird vor dem Test als lokale Anforderung festgelegt.
Der Reviewer vergleicht Eingabe, gespeicherten Wert, Chargenzuordnung und Parameterstand. Beim historischen Fall bleibt A unter V1 erhalten. Wird V2 fälschlich rückwirkend angewendet, entsteht 99,80 g statt 100,20 g. Diese Differenz von 0,40 g ist im Beispiel ein Nachweisfehler, keine Aussage über gesetzliche Füllmengentoleranzen.
| Fall und Ausgangslage | Eingabe | Unabhängiges Soll | Zu sichernder Nachweis |
|---|---|---|---|
| 1 · A unter V1 | Brutto 110,20 g; Tara 10,00 g | Netto 100,20 g | Datensatz A, V1 und beide Ausgangswerte. |
| 2 · B unter V2 | Brutto 110,20 g; Tara 10,40 g | Netto 99,80 g | Datensatz B verwendet den neuen Stand. |
| 3 · Zweite Probe B | Brutto 111,00 g; Tara 10,40 g | Netto 100,60 g; Mittelwert der beiden B-Proben 100,20 g | Genau zwei vorgesehene B-Werte, ohne A. |
| 4 · Historie nach Wechsel | Gespeicherte Probe A erneut aufrufen | Weiterhin 100,20 g unter V1 | Vergleich mit dem erhaltenen ursprünglichen Beleg. |
| 5 · Unbekannte Charge X | Neuer Testeingang ohne gültige Chargenzuordnung | Nach eigenem Soll nicht als reguläres Ergebnis buchen; zur Klärung zurückweisen | Fehlermeldung oder kontrollierte Behandlung; keine verdeckte Zuordnung zu A oder B. |
| 6 · Wiederholung von B-Probe 2 | Identischen Testeingang nochmals senden | Nach eigenem Soll keine dritte reguläre Messung; Wiederholung erkennen und behandeln | Bestand bleibt zwei B-Proben; Rückmeldung und Bearbeitung nachvollziehbar. |
Schnittstellen mit fehlenden und wiederholten Daten prüfen
Die Modulunterlagen nennen XML Link und Data I/O als Möglichkeiten des Datenaustauschs. Daraus folgt noch keine garantierte Erkennung doppelter Daten. Vereinbaren Sie für jede tatsächlich eingesetzte Übergabe ein Datenmodell: fachliche Kennungen, Werte, Einheiten, Parameterbezug und die Bedeutung einer Rückmeldung.
Eine erfolgreiche Übertragung beantwortet zunächst eine technische Frage. Für den Prozess zählt zusätzlich, ob der Empfänger den richtigen Datensatz vollständig und sinnvoll verarbeitet hat. Testen Sie einen fehlenden Pflichtbezug, eine unterbrochene Verbindung und einen erneuten Eingang. Bestimmen Sie vorher, ob ein Fehler zur Zurückweisung, zur Warteschlange oder zur kontrollierten manuellen Klärung führt.
Bleibt ein Fehlerfall unklar, darf der Test nicht lediglich mit einem richtigen Normalwert abgeschlossen werden. Erfassen Sie Befund, betroffene Daten und weitere Verwendung. Nach einer Korrektur prüfen Sie gezielt die Fehlerursache und die plausibel mitbetroffenen Wege. Bei manueller Ersatzübertragung wird auch die zusätzliche Verwechslungsmöglichkeit bewertet.
Berichte, Auswahl und Rechte als Teil der Ergebnisprüfung behandeln
Die Free-Reporting-Beschreibung zeigt, dass Daten für Berichte gezielt ausgewählt werden können. Ein übersichtlicher Bericht beweist deshalb noch keine Vollständigkeit. Definieren Sie für den jeweiligen Zweck, welche Stichproben, Zeiträume, Konfigurationsstände und auffälligen Werte dazugehören. Eine zulässige Detailansicht und ein vollständiger Entscheidungsnachweis können unterschiedliche Ansichten sein.
Prüfen Sie mit einem bewusst auffälligen Testwert, ob seine Behandlung sichtbar bleibt. Werden Daten ausgeschlossen, braucht der Reviewer die fachliche Begründung und den ursprünglichen Zusammenhang. Eine günstiger aussehende Statistik ist keine Begründung. Ebenso wenig darf die Auswahl einer anderen Charge das eigentliche Ergebnis unbemerkt ersetzen.
Ordnen Sie Rechte den Aufgaben zu: Messwerte erfassen, Parameter pflegen, Daten bewerten und Benutzer verwalten. Prüfen Sie sowohl erlaubte als auch abgewiesene Aktionen. Der Umfang von Änderungshistorie und Review wird anhand relevanter Daten festgelegt. Aus der bloßen Existenz eines Audit-Trail-Moduls folgt keine nachgewiesene Vollständigkeit aller benötigten Ereignisse.
Geeignete Belege nutzen und den geprüften Stand erhalten
Fordern Sie verfügbare Hersteller- und Implementierungsbelege an und ordnen Sie sie Ihren Anforderungen zu. Ein Test ist nutzbar, wenn unter anderem Version, Funktion, Voraussetzungen, Soll und Ergebnis ausreichend nachvollziehbar sind. Offene kundenspezifische Zuordnungen werden ergänzt. Das ist weder eine pauschale Übernahme aller Anbieterunterlagen noch eine Pflicht, jeden Test zu wiederholen.
Bewerten Sie spätere Änderungen nach ihren Auswirkungen: neue Waage, geänderter Treiber, anderer Taramechanismus, Berichtsvorlage oder Schnittstellenmapping. Die Begründung legt fest, welche bisherigen Belege weiter gelten und wo zusätzliche Prüfungen nötig sind. Schulung, Arbeitsanweisung und Zuständigkeiten gehören zur betriebsfähigen Übergabe.
Ein Wiederherstellungstest sollte zusammengehörige Werte, Konfigurationsstände und Historie prüfen. Die bloße Verfügbarkeit einer Sicherungsdatei reicht dafür nicht. Legen Sie Aufbewahrung und Prüfzyklen passend zum Prozess fest. Auch beim historischen Zugriff muss erkennbar bleiben, wie das damalige Ergebnis zustande kam.
Vorbereitung und Checkliste für QA, Produktion und IT
Für ein kleines Team ist die früh geklärte Arbeitsteilung entscheidend. Produktion oder Fachbereich beschreibt Messaufgabe und Entscheidung. QA grenzt die relevanten Qualitätsanforderungen ab. IT erklärt Datenwege und Betrieb. Der Anbieter liefert passende Produktunterlagen. Diese Beiträge können in einer gemeinsamen Arbeitsmappe zusammenlaufen; getrennte Dokumentensilos sind nicht erforderlich.
Der Aufwand steigt vor allem mit unterschiedlichen Gerätekopplungen, wechselnden Parameterständen, manuellen Zwischenwegen und fehlenden historischen Belegen. Zählen Sie deshalb nicht nur Module. Ermitteln Sie, wie viele wirklich unterschiedliche Entscheidungs- und Fehlerwege nachzuweisen sind. Folgende Checkliste hilft vor dem Start:
- Verwendung der Daten und betroffener Regelbereich dokumentiert.
- Softwarestand, Module, Geräte und Datenbank erfasst.
- Brutto-/Nettowert, Tara, Einheit und Umrechnung eindeutig bestimmt.
- Produkt-, Chargen- und Prüfkonfigurationszuordnung festgelegt.
- Unabhängige Sollwerte sowie Normal- und Fehlerfälle vorbereitet.
- Berichtsfilter und Behandlung auffälliger Werte geklärt.
- Zugriffsrechte und fachlicher Review zugeordnet.
- Passende Lieferantenbelege und verbleibende Lücken benannt.
- Änderungsverfahren, Sicherung, Wiederherstellung und Verantwortlichkeiten festgelegt.
Häufige Fragen zu FreeWeigh.Net
Ist FreeWeigh.Net ein MES oder ein Chromatographiedatensystem?
Der Hersteller beschreibt FreeWeigh.Net als statistische Qualitäts- und Prozesskontrolle mit einem Schwerpunkt auf Füllmengen. Einzelne Chargen- und Prüfplanfunktionen machen daraus nicht automatisch ein vollständiges MES. Chromatographische Peak-Integration gehört nicht zum hier belegten Zweck. Stellen Sie für Ihr Projekt die tatsächlichen Mess-, Zuordnungs- und Entscheidungsabläufe dar; daran richtet sich der Nachweis aus.
Wann muss FreeWeigh.Net im GMP-Umfeld validiert werden?
Entscheidend ist, ob und wie die Anwendung eine GMP-regulierte Tätigkeit unterstützt. Beschreiben Sie beispielsweise, ob ihre Daten für Inprozesskontrollen oder Qualitätsentscheidungen verwendet werden. Daraus bestimmen Sie relevante Funktionen und Risiken. Die reine Installation, der Produktname oder die Verwendung in einem Pharmaunternehmen beantwortet die Umfangsfrage nicht. Andere gesetzliche Zwecke werden zusätzlich und getrennt eingeordnet.
Reicht die Kalibrierung unserer Waage für den Nachweis aus?
Sie beantwortet eine Gerätefrage, nicht alle Fragen der Datenverarbeitung. Zusätzlich prüfen Sie, ob Gerät, Probe, Charge, Einheit und Parameterstand richtig zusammengeführt werden. Eine korrekt kalibrierte Waage verhindert keine doppelte Taraabziehung in einem nachgelagerten Datenweg. Umgekehrt ersetzt ein richtiger Schnittstellentest weder den geeigneten Messbereich noch die erforderlichen Gerätenachweise.
Müssen wir bei jedem Tarawert eine vollständige Revalidierung durchführen?
Nicht jede Parameteränderung verlangt dieselbe Prüftiefe. Bewerten Sie, welche Berechnung, Zuordnung, Historie und Entscheidung betroffen ist. Nutzen Sie weiterhin passende Nachweise und ergänzen Sie gezielt offene Auswirkungen. Wenn sich etwa die Art der Taraermittlung statt nur eines Werts ändert, kann der Prüfbedarf breiter sein. Der dokumentierte Änderungsentscheid begründet den Umfang.
Beweist Test Item Versioning bereits eine vollständige Historie?
Die Herstellerbeschreibung nennt die Erhaltung früherer Roh- und Statistikdaten. Für Ihren Einsatz kontrollieren Sie dennoch, welche Parameter, Werte und Zuordnungen tatsächlich rekonstruierbar sind. Vergleichen Sie einen alten Datensatz nach einem kontrollierten Wechsel mit seinem unabhängigen ursprünglichen Beleg. Ob diese Funktion in Ihrer Lizenz und Version enthalten ist, klären Sie anhand passender Unterlagen.
Dürfen auffällige Stichproben aus einem Bericht ausgeblendet werden?
Eine gezielte Detailansicht kann einen anderen Zweck haben als der vollständige Nachweis einer Qualitätsentscheidung. Für Letzteren müssen Auswahl und Ausschlüsse sachlich begründet und nachvollziehbar sein. Prüfen Sie, ob ein Reviewer die betroffenen Daten und ihren Kontext erkennen kann. Ein besserer Mittelwert allein rechtfertigt keinen Ausschluss. Benennen Sie den Berichtszweck und seine Grundgesamtheit ausdrücklich.
Ist der Status „freigegeben“ gleichbedeutend mit einer Arzneimittel-Chargenfreigabe?
Nicht ohne eine entsprechende, nachgewiesene Einbindung in den geregelten Prozess. Definieren Sie, was der lokale Status bewertet und wer welche weitere Entscheidung trifft. Die Beurteilung ausgewählter Füllmengenkriterien ist nicht automatisch eine vollständige Chargenbewertung. Wird ein System zur Aufzeichnung der Zertifizierung und Chargenfreigabe verwendet, enthält Annex 11 dafür gesonderte Anforderungen.
Wie prüfen wir eine wiederholte XML-Übertragung?
Legen Sie zunächst fest, wie eine fachlich identische Probe erkennbar ist und wie Wiederholungen behandelt werden sollen. Senden Sie dann einen bereits verarbeiteten Testeingang erneut und vergleichen Sie Rückmeldung, Datenbestand und Statistik. Der Test muss zeigen, dass die vereinbarte Behandlung funktioniert. Die Bezeichnung XML Link allein verspricht weder Dublettenerkennung noch eine bestimmte Fehlerreaktion.
Belegt das Beispiel eine zulässige Nettofüllmenge von 99,80 g?
Nein. Der Wert entsteht ausschließlich aus der konstruierten Rechnung 110,20 g minus 10,40 g. Das Beispiel enthält weder eine rechtliche Toleranz noch eine Produktspezifikation. Es prüft, ob die vorgesehene Tara angewendet und der Kontext erhalten wird. Für reale Packungen müssen die einschlägigen Anforderungen und fachlichen Annahmekriterien unabhängig festgelegt werden.
Was braucht ein KMU vor einer belastbaren Aufwandsschätzung?
Hilfreich sind Systemstand, Modulliste, Geräte- und Schnittstellenübersicht, relevante Prüfpläne sowie ein Beispielbericht mit zugehörigen Einzelwerten. Ergänzen Sie vorhandene Lieferantenbelege und bekannte Nachweislücken. Daraus lässt sich der Umfang unterschiedlicher Prüfwege bestimmen. Eine feste Dauer allein aus dem Produktnamen wäre wenig aussagekräftig; entscheidend sind Konfiguration, Nutzung und verfügbare Mitwirkung.
Quellen & fachlicher Stand
Stand 6. Oktober 2026. Produktbeschreibung und historische Modulunterlagen von METTLER TOLEDO bilden den Herstellerbezug; eine aktuelle numerische FreeWeigh.Net-Version wird nicht behauptet. Regulatorische Einordnung: Humanarzneimittel-GMP, FDA-Bezug nur bei zutreffendem Geltungsbereich. Fertigpackungs- und Messrecht werden nicht im Detail bewertet. Tabellen und Sollwerte sind eigene illustrative Arbeitshilfen, keine Produkt- oder Kundentestergebnisse.
- FreeWeigh.Net — Software for Statistical Quality Control
- FreeWeigh.Net — Software Modules
- FreeWeigh.Net Datasheet — Multifaceted Quality Control
- Europäische Kommission: EudraLex Volume 4
- EU-GMP Annex 11: Computerised Systems
- EU-GMP Kapitel 4: Dokumentation
- EMA: ICH Q9(R1), Step 5, Corr.2
- FDA: Part 11 — Scope and Application
- Europäische Kommission: EU-GMP Kapitel 3 – Premises and Equipment
Zuletzt fachlich geprüft am 06.10.2026.
Den tatsächlichen Mess- und Entscheidungsweg prüfen
Wir unterstützen Sie dabei, Geräte- und Softwareumfang abzugrenzen, vorhandene Nachweise zu bewerten und die offenen Prüfungen für Ihren Qualitätskontrollprozess auszuarbeiten.
- IT-GxP-Audit →
Vorhandene Belege, Datenwege und konkrete Nachweislücken bewerten.
- IT-GxP-Consulting →
Anforderungen, Sollfälle und betriebliche Übergabe gemeinsam umsetzen.
