R validieren: Pakete, Daten und Auswertungen nachvollziehbar prüfen

Zuerst klären: Welche Entscheidung unterstützt Ihre Auswertung?

Beschreiben Sie den Weg von der Eingabe bis zur fachlichen Verwendung. Berechnet R einen Trend für eine Qualitätsbewertung, verarbeitet es Prüfdaten oder dient es einer unverbindlichen Exploration? Entscheidend ist, welche Folgen ein falscher, unvollständiger oder nicht nachvollziehbarer Bericht haben kann. Ein später verwendeter Export gehört zu dieser Betrachtung, auch wenn die eigentliche Entscheidung außerhalb von R fällt.

Dieser Leitfaden betrachtet den Einsatz im Humanarzneimittel-GMP-Umfeld. Annex 11 ist eine GMP-Leitlinie für computergestützte Systeme; der aktuelle EudraLex-Index führt weiterhin die Revision von Januar 2011. Klinische Prüfungen, Medizinprodukte und US-Anforderungen brauchen eine eigene Einordnung. Ein R-Dokument mit FDA im Dateinamen ist keine behördliche Bestätigung einer klinischen oder GMP-Anwendung.

Formulieren Sie den Zweck so konkret, dass ein Fachverantwortlicher das Ergebnis beurteilen kann: Welche Grundgesamtheit, Einheiten, Zeiträume und Ausschlüsse gelten? Wer darf den Bericht verwenden? Daraus entstehen Anforderungen an Daten, Berechnung und Nachweise. Eine pauschale Kategorie oder feste Testzahl aus dem Namen R wäre dafür zu grob.

Quellen: [7] [8] [2]

R, Zusatzpakete und Entwicklungsoberfläche auseinanderhalten

R ist eine freie Umgebung für statistisches Rechnen und Grafiken. Der hier verwendete Release-Bezug ist R 4.6.1 vom 24. Juni 2026. Eine Entwicklungsoberfläche kann das Schreiben und Ausführen erleichtern, ist aber nicht mit der R-Laufzeit gleichzusetzen. Halten Sie die tatsächlich eingesetzte Kombination fest, einschließlich Betriebssystem, relevanter Erweiterungen und Ausführungsweg.

Das R-Foundation-Dokument vom 12. März 2026 behandelt die offizielle Distribution mit Base R und Recommended Packages. Andere Zusatzpakete sind von diesem Dokumentumfang ausdrücklich ausgenommen. Ihre Veröffentlichung auf CRAN oder ein bekannter Autor erweitert diesen Umfang nicht. Für zusätzlich genutzte Funktionen benötigen Sie daher passende paketbezogene Informationen.

Ordnen Sie die Belege den tatsächlich verwendeten Funktionen zu. Eine dokumentierte Entwicklungs- und Testpraxis kann sinnvoll übernommen werden; sie muss nicht ohne Grund nochmals vollständig nachgestellt werden. Offen bleibt, ob die konkrete Version, Konfiguration und fachliche Nutzung abgedeckt sind. Diese Lücken bestimmen Ihre ergänzenden Prüfungen, nicht die bloße Anzahl installierter Pakete.

Quellen: [1] [2] [8]

Die ausführbare Umgebung erfassen, nicht nur eine Versionsnummer

R kann Pakete aus unterschiedlichen Bibliotheksverzeichnissen laden. Site- und Benutzerbibliotheken sowie Suchpfade beeinflussen den verfügbaren Bestand. Bei kompilierten Paketen können zusätzlich Compiler und externe Bibliotheken relevant sein. Zwei Rechner mit derselben R-Version sind deshalb noch keine nachgewiesen gleichwertigen Analyseumgebungen.

renv unterstützt projektbezogene Paketbibliotheken und eine Lockdatei. Das Werkzeug erfasst die R-Version, verwaltet R selbst jedoch nicht. Auch Betriebssystembibliotheken, Compiler oder externe Werkzeuge werden damit nicht vollständig bereitgestellt. Verwenden Sie eine Lockdatei als Teil Ihres Nachweises und prüfen Sie gezielt, ob der vorgesehene Wiederherstellungsweg tatsächlich funktioniert.

Die folgende eigene Matrix hilft beim Abgrenzen. Nicht jede Zeile verlangt ein separates Dokument. Sie soll verhindern, dass ein relevanter Bestandteil zwischen Entwicklung und Betrieb verloren geht. Die fachliche Bedeutung entscheidet, wie genau ein Stand dokumentiert und überprüft wird.

Quellen: [3] [4]

Importregeln sind Teil der fachlichen Berechnung

Eine Datei kann erfolgreich eingelesen werden und dennoch falsch interpretiert sein. Die R-Funktionen read.table und die CSV-Varianten besitzen Parameter für Trennzeichen, Dezimalzeichen, fehlende Werte und Spaltentypen. Stimmen diese nicht mit der Datenspezifikation überein, kann sich bereits vor der eigentlichen Statistik die Bedeutung der Eingabe verändern.

Prüfen Sie deshalb bekannte Normaldaten und bewusst abweichende Eingaben. Dazu gehören eine unerwartete Textspalte, ein fehlender Probenwert, eine zusätzliche Zeile und ein doppelter Schlüssel. Beschreiben Sie vorab, ob der Prozess einen Fehler zurückweist, eine kontrollierte Umwandlung erlaubt oder eine fachliche Klärung verlangt. Eine automatische Reparatur ist keine neutrale technische Entscheidung.

Auch Fehlwerte benötigen eine begründete Regel. Bei mean steuert na.rm, ob fehlende Werte vor der Berechnung entfernt werden; der Standardwert ist FALSE. Das Setzen auf TRUE kann rechnerisch sinnvoll sein, ersetzt aber keine Aussage zur Datenvollständigkeit. Lassen Sie im Ergebnis erkennen, wie viele Werte erwartet, verwendet und ausgeschlossen wurden und weshalb.

Quellen: [5] [6] [8]

Methode, Skript und Ergebnis getrennt beurteilen

Ein korrekt implementierter Algorithmus kann für die fachliche Frage ungeeignet sein. Umgekehrt kann ein geeignetes Verfahren im Skript falsch parametrisiert werden. Lassen Sie deshalb die Methodenauswahl fachlich beurteilen und prüfen Sie anschließend ihre konkrete Umsetzung: Einheiten, Filter, Gruppierung, Rundung, Ausschlüsse und die Interpretation des Ergebnisses.

Für eine kleine deterministische Berechnung eignet sich ein unabhängig hergeleitetes Soll. Bei komplexeren statistischen Verfahren können geeignete Referenzdatensätze, analytisch bekannte Eigenschaften oder begründete Vergleichsverfahren erforderlich sein. Ein zweites Skript ist nur dann hilfreich, wenn es denselben Fehler nicht einfach kopiert. Der gewünschte Grad der Übereinstimmung muss zur Berechnung passen.

Betrachten Sie auch die Aufbereitung des Berichts. Eine Tabelle kann den richtigen internen Wert in der falschen Einheit oder unter dem falschen Probennamen zeigen. Prüfen Sie deshalb den fachlich verwendeten Endpunkt. Diese Arbeitshilfen schreiben keine universelle Prüfmethode vor; sie sollen die relevanten Fehlerfolgen Ihrer Auswertung sichtbar machen.

Quellen: [8] [9]

Illustratives Prüfbeispiel: gleicher Mittelwert, anderer Datenbestand

Das folgende Beispiel ist vollständig konstruiert; es ist kein ausgeführter R- oder Kundentest. Ein Bericht soll die vier Proben A01 bis A04 enthalten. Als eigene Beispielregel gilt: Ein vollständiger Bericht benötigt vier gültige Messungen mit eindeutigen IDs. Die Werte sind 98, 100, 102 und 100 in derselben festgelegten Einheit. Ihr Mittelwert beträgt 400 / 4 = 100.

Im Fehlerfall fehlt der Wert für A04. Werden nur gültige Werte gemittelt, ergibt sich erneut 300 / 3 = 100. Der identische Mittelwert darf die fehlende Probe nicht verdecken. Das vorab festgelegte Soll verlangt jetzt die Kennzeichnung als unvollständig: vier erwartet, drei gültig, ein Wert fehlt. Daraus wird keine Aussage über eine reale Produktqualität abgeleitet.

Jeder Tabellenfall beginnt mit einer eigenen Kopie des definierten Ausgangsbestands. Stellen Sie nach dem Fall die Eingabe und Parameter zurück. So verdeckt eine vorherige Veränderung nicht den nächsten Fehler. Die Sollwerte wurden unabhängig nachgerechnet; ein tatsächlicher Produktlauf ist anschließend mit seinen beobachteten Ergebnissen zu dokumentieren.

Quellen: [6] [5] [8]

Bei Zufallsverfahren den Vergleich bewusst festlegen

Bootstrapping, Simulationen oder andere zufallsbasierte Verfahren benötigen zusätzliche Angaben. R bietet set.seed für einen Startwert sowie RNGkind und RNGversion zur Wahl der Generatorvorgaben. Ein gespeicherter Seed ist deshalb ein sinnvoller Bestandteil eines reproduzierbaren Laufs, aber kein Beweis für die fachliche Angemessenheit des Verfahrens.

Legen Sie fest, was die Wiederholung zeigen soll. Soll derselbe kontrollierte Lauf dieselbe Ausgabe liefern, oder wird eine statistische Eigenschaft innerhalb begründeter Grenzen geprüft? Diese Fragen sind nicht austauschbar. Dokumentieren Sie die verwendete Methode, relevante Parameter und die Vergleichsregel, bevor Sie ein beobachtetes Ergebnis bewerten.

Behaupten Sie keine allgemeine Ergebnisidentität zwischen beliebigen Paketständen, Rechnern oder Ausführungsvarianten. Ändern sich solche Bedingungen, untersuchen Sie ihre Bedeutung für den konkreten Algorithmus. Ein plausibel aussehendes Diagramm und ein gespeicherter Startwert reichen dafür allein nicht aus.

Quellen: [6] [8]

Den Zusammenhang zwischen Eingabe und Entscheidung erhalten

Für eine entscheidungsrelevante Auswertung sollte erkennbar bleiben, welche Daten mit welchem Code und welchen Parametern zu welchem Ergebnis geführt haben. Kapitel 4 verlangt eine geregelte Dokumentation; bei elektronischen Aufzeichnungen ist der Rohdatenumfang zu bestimmen. Ein fertiges PDF kann einen Teil der Auswertung darstellen, bewahrt aber nicht automatisch den vollständigen fachlichen Zusammenhang.

sessionInfo liefert Informationen über R, Plattform und geladene Pakete sowie weitere Sitzungsmerkmale. Das ist nützlich, aber kein unveränderbares Archiv. Die Dokumentation nennt sogar eine Grenze bei parallel veränderten Paketinstallationen. Ergänzen Sie den Sitzungsbericht deshalb durch die für Ihre Auswertung benötigten Eingaben, Skriptstände und bewerteten Ergebnisse.

Regeln Sie, wer Daten, Code und freigegebene Berichte verändern darf und wie zulässige Korrekturen nachvollziehbar bleiben. Ein R-Protokoll ist nicht automatisch ein vollständiger regulatorischer Audit Trail. Prüfen Sie erforderliche Kontrollen entlang des tatsächlichen Aufzeichnungsprozesses. Zugriffsschutz, nachvollziehbare Änderungen und Wiederherstellung müssen in der gewählten Umgebung zusammenpassen.

Quellen: [9] [5] [8]

Updates an den betroffenen Auswertungen prüfen

Eine Änderung kann aus einer neuen R-Version, einem Paketupdate, einer geänderten Importdatei oder einem anderen Betriebsrechner entstehen. Erfassen Sie zunächst, welche Funktionen und Datenwege betroffen sind. Ein nicht verwendetes neues Merkmal kann anders zu bewerten sein als eine Änderung an der verwendeten Berechnungsfunktion.

Wählen Sie daraus passende Wiederholungen und ergänzende Fälle. Für das Mittelwertbeispiel wären insbesondere Vollständigkeit, Fehlwertbehandlung und Ergebniszuordnung relevante Anker. Ein Vergleich bisheriger Berichte kann nützlich sein, ersetzt aber keine Prüfung neuer Fehlerwege. Eine pauschale Vollrevalidierung nach jedem Paketupdate ist aus diesem Vorgehen nicht abzuleiten.

Prüfen Sie auch die Rückkehr zu einem benötigten früheren Stand. Eine Lockdatei genügt nicht, wenn erforderliche Binärpakete oder externe Voraussetzungen fehlen. Entscheiden Sie begründet, welche Bestandteile vorgehalten werden und wie historische Auswertungen lesbar bleiben. Wiederherstellung der Software und Aufbewahrung eines bewerteten Ergebnisses sind dabei unterschiedliche Ziele.

Quellen: [4] [3] [8] [9]

Was vor dem Start bereitstehen sollte

Für den Einstieg brauchen Sie eine konkrete Auswertung und einen Ansprechpartner, der ihre fachliche Bedeutung erklären kann. Die folgende Checkliste unterstützt das erste Arbeitsgespräch. Fehlende Unterlagen werden als offene Aufgaben sichtbar; sie müssen nicht durch einen möglichst großen Dokumentensatz ersetzt werden.

Der Fachbereich verantwortet Zweck und Methodeneignung, die Programmierung erläutert Code und Abhängigkeiten, IT den Betrieb und QA die Einordnung in das Qualitätssystem. Aufwand entsteht vor allem durch unbekannte Skriptvarianten, viele Datenquellen, fehlende Referenzergebnisse und unklare historische Stände. Eine Aufwandsschätzung wird belastbarer, sobald diese Faktoren konkret sind.

• Verwendungszweck, Ergebnisempfänger und mögliche Fehlerfolgen benennen.
• R-, Paket- und Umgebungsbestand mit verfügbaren Belegen zusammenstellen.
• Skriptstände, Eingabestruktur, Einheiten und Fehlwertregeln festhalten.
• Normal-, Grenz- und Fehlerdaten mit unabhängigem Soll vorbereiten.
• Zugriffe, Änderungen, Ergebnisbewertung und Aufbewahrung zuordnen.
• Wiederherstellungsweg sowie betroffene Auswertungen bei Updates bestimmen.

Quellen: [8] [9]