Inhaltsverzeichnis
Das Wichtigste vorab
Wie wird eine SAS-Auswertung im GMP-Einsatz validiert?
Grenzen Sie die konkrete SAS-Auswertung mit Datenquellen, Programmen, Produkten und Betriebsumgebung ab. Prüfen Sie, welche vorhandenen Installations- und Entwicklerbelege passen und welche fachlichen Nachweise noch fehlen. Ein unabhängiger Ergebnisvergleich braucht festgelegte Schlüssel, Vollständigkeitsregeln, Fehlwertbehandlung und angemessene Toleranzen. Dokumentieren Sie den ausgeführten Stand und die bewerteten Ergebnisse. Ein erfolgreicher Job oder ein IQ/OQ-Bericht bestätigt allein nicht die gesamte Kundenanwendung.
- SAS 9.4, Viya, Compute und CAS dürfen nicht als ein einheitlicher Funktionsumfang behandelt werden.
- Installations- und Komponentennachweise sind von der fachlichen Richtigkeit einer Kundenanalyse zu unterscheiden.
- Ein Ergebnisvergleich muss Schlüssel, Vollständigkeit, Fehlwerte und numerische Kriterien berücksichtigen.
- Ausgeführtes Programm, Datenstand, Protokoll und bewertetes Ergebnis benötigen einen nachvollziehbaren Zusammenhang.
Welche SAS-Auswertung muss verlässlich funktionieren?
Beginnen Sie mit der Entscheidung, die aus den Ergebnissen folgt. Eine Qualitätsauswertung kann Daten filtern, Kennzahlen berechnen und einen Bericht für die weitere Beurteilung erzeugen. Dabei sind nicht nur Formeln relevant. Ein falscher Datenstand oder eine vertauschte Identität kann einen rechnerisch richtigen Wert fachlich unbrauchbar machen.
Dieser Artikel betrachtet statistische Programmierung und Datenauswertung im Humanarzneimittel-GMP-Umfeld. Annex 11 ist eine GMP-Leitlinie; zusammen mit Kapitel 4 bildet er hier den regulatorischen Bezug. Klinische Forschung, Medizinprodukte und US-Anforderungen benötigen eine eigene Einordnung. Weder der Einsatz von SAS noch seine Verbreitung in regulierten Branchen bestätigt automatisch einen bestimmten Anwendungsfall.
Beschreiben Sie Eingaben, Verarbeitung, fachliche Kriterien und Ergebnisempfänger. Legen Sie fest, welche Fehler eine vorgesehene Verwendung verhindern. Diese Angaben helfen beim Begrenzen des Prüfaufwands. Der Leitfaden behandelt keine pauschale Validierung sämtlicher SAS-Produkte und ordnet dem Produktnamen keine feste Softwarekategorie zu.
SAS 9.4 und Viya getrennt aufnehmen
Die SAS-Installationsseite nennt SAS 9.4M9, ausgeliefert im Juni 2025. Zusätzlich gibt es produktspezifische Wartungsstände und Hotfixes. Ein Eintrag „SAS 9.4“ allein beschreibt deshalb nicht den vollständigen Bestand. Ermitteln Sie, welche Produkte und Schnittstellen tatsächlich installiert und lizenziert sind und welche davon Ihre Auswertung verwendet.
Viya arbeitet mit einem anderen Versionsmodell. Der Hersteller unterscheidet Stable- und Long-Term-Support-Kadenzen, Jahres-/Monatsversionen und konkrete Releases. Die Supportübersicht vom September 2026 reicht bis 2026.09. Die technische Programmierbeschreibung dieses Artikels hat dagegen den ausgewiesenen Bereich 2020.1 bis 2026.06. Daraus wird keine Aussage über ungeprüfte spätere Funktionen abgeleitet.
Verwenden Sie die folgende eigene Matrix als Bestandsaufnahme. Eine Entwicklungsoberfläche, ein statistisches Zusatzprodukt und ein Ausführungsserver erfüllen unterschiedliche Aufgaben. Auch wenn ein Programmtext übernommen werden kann, bleiben Datenzugriff, Berechtigungen, Laufbedingungen und Ergebnisspeicherung konkret zu prüfen.
| Ebene | Konkret festhalten | Offene Prüffrage |
|---|---|---|
| SAS 9.4 | Produkte, Maintenance, Hotfixes und Plattform | Welche Belege passen genau zu diesem Bestand? |
| Viya | Kadenz, Version, Release und Betriebsform | Welche Update- und Betriebsbedingungen gelten? |
| Ausführung | Compute, CAS und relevante Datenreferenzen | Wo werden die verwendeten Schritte ausgeführt? |
| Datenzugang | Quellen, Schnittstellen, Berechtigungen und Stände | Kommt der vollständige richtige Datenbestand an? |
| Analyse | Programm, Parameter und fachliche Methode | Welche unabhängige Erwartung gilt? |
| Ergebnis | Bericht, Datensatz, Log und Speicherort | Was bleibt nach dem Lauf erhalten und bewertbar? |
Was vorhandene IQ-/OQ-Berichte tatsächlich abdecken
Das SAS-9.4-Handbuch zu Qualification Tools beschreibt zwei unterschiedliche Prüfungen. Das IQ-Werkzeug vergleicht installierte Dateien anhand von Prüfsummen. Änderungen durch Konfiguration oder Lizenzpflege können dabei erklärbare Unterschiede erzeugen. Ein auffälliger Befund muss deshalb in seinem konkreten Zusammenhang bewertet werden.
Das OQ-Werkzeug führt vom Komponentenentwickler bereitgestellte SAS-Programme aus und berichtet deren Ergebnisse. Der beschriebene Umfang betrifft Windows und UNIX; OQ für z/OS wird dort nicht unterstützt. Das hier verwendete Handbuch stammt aus 2021 und bestätigt nicht allein die Passung jedes darin beschriebenen Testbestands zu einer heutigen M9-Installation.
Fordern Sie für Ihr Vorhaben die tatsächlich verfügbaren, passenden Belege an. Prüfen Sie Version, Konfiguration, Testumfang, Ergebnisse und offene Abweichungen. Geeignete Fremdbelege können die eigene Arbeit unterstützen; sie müssen nicht automatisch dupliziert werden. Gleichzeitig ersetzen Komponententests nicht den Nachweis Ihrer Filter, Berechnungen oder Ergebniszuordnungen. Die verbleibende Lücke muss konkret benannt werden.
Den Datenbestand vor dem Wertvergleich verstehen
Ein fachlicher Datensatz besitzt mehr als eine Zeilenanzahl. Für eine Qualitätsauswertung können Probenidentität, Zeitpunkt, Einheit und Datenstand entscheidend sein. Bestimmen Sie, welche Kombination einen Datensatz eindeutig macht. Prüfen Sie anschließend, ob erwartete Einträge fehlen, mehrfach vorkommen oder unerwartet zusätzlich vorhanden sind.
PROC COMPARE ordnet Beobachtungen ohne ID-Anweisung nach ihrer Position zu. Mit ID-Variablen lässt sich die Zuordnung an Schlüsselwerten ausrichten. Die Dokumentation behandelt dabei Anforderungen an Typen und Sortierung. Ein vorhandenes ID-Feld allein bedeutet noch nicht, dass Ihr Vergleich dieses Feld richtig verwendet.
Bereiten Sie beide Bestände passend vor und kontrollieren Sie die Eindeutigkeit. Eine fachlich gleichwertige Datei mit anderer Zeilenreihenfolge soll nicht wegen der Reihenfolge als geändert erscheinen. Umgekehrt darf ein Vergleich der noch vorhandenen passenden Zeilen fehlende Datensätze nicht verdecken. Stellen Sie Vollständigkeits- und Wertprüfung als getrennte Ergebnisse dar.
Toleranz und Fehlwertregeln vor dem Lauf festlegen
Ein Ergebnisvergleich benötigt eine klare Erwartung. Für Identitäten oder Kategorien ist eine andere Regel sinnvoll als für numerische Ergebnisse. PROC COMPARE kennt unterschiedliche Vergleichsmethoden. Bei METHOD=ABSOLUTE wird die absolute Differenz mit CRITERION verglichen; eine größere Differenz wird als ungleich beurteilt.
Wählen Sie die Toleranz aus der Bedeutung der Größe und dem Berechnungsverfahren. Eine Grenze darf nicht nachträglich erweitert werden, nur damit ein beobachteter Unterschied verschwindet. Achten Sie auch auf die tatsächlich gesetzte Methode: Eine Zahl bei CRITERION allein beschreibt noch nicht ausreichend, welches Vergleichsmaß Sie beabsichtigen.
Fehlwerte verdienen eine gesonderte Entscheidung. Die Option NOMISSING kann einen fehlenden Wert mit beliebigen Vergleichswerten gleichsetzen. Verwenden Sie diese Wirkung nicht unbemerkt als Vollständigkeitsnachweis. Ob ein fehlender Wert fachlich zulässig ist, muss aus Ihrer Daten- und Auswertungsregel hervorgehen. Untersuchen Sie außerdem die Logmeldungen; ein beendeter Lauf ist noch keine dokumentierte fachliche Entscheidung.
Illustratives Prüfbeispiel: drei IDs und eine absolute Grenze
Das Beispiel ist konstruiert und kein ausgeführter SAS-Test. Der Referenzbestand enthält die eindeutigen IDs 101, 102 und 103 mit den Werten 10,00, 20,00 und 30,00 in derselben Einheit. Das Soll lautet: genau diese drei IDs, passende Datentypen und höchstens 0,01 absolute Differenz je Wert. Die Grenze gilt nur für dieses Lehrbeispiel und ist keine allgemeine Validierungstoleranz.
Beide Datensätze werden vor dem ID-basierten Vergleich passend sortiert. Eine NOMISSING-Ausnahme wird nicht verwendet. Die Vergleichsdatei darf zunächst eine andere Reihenfolge besitzen. Nach korrekter Zuordnung stimmen alle Werte überein; ihre Summe beträgt 60,00. Wird der Wert zu 103 auf 30,02 geändert, beträgt die Differenz 0,02 und damit mehr als die festgelegten 0,01.
Jeder Fehlerfall beginnt erneut mit einer Kopie des vollständigen Normalbestands. Sichern Sie den Ausgangszustand und halten Sie die erwartete Reaktion vorab fest. Die unabhängige Dezimalrechnung bestätigt die Zahlen; sie behauptet keinen SAS-Lauf. Einen numerisch genau auf der Grenze liegenden Fall müssten Sie zusätzlich unter den vorgesehenen Darstellungs- und Rechenbedingungen beurteilen.
| Fall | Gezielte Eingabe | Unabhängiges Soll | Erwartete Bewertung |
|---|---|---|---|
| Andere Reihenfolge | 103/30,00; 101/10,00; 102/20,00 | Nach Sortierung und ID-Zuordnung keine Wertabweichung; Summe 60,00 | Normalfall besteht |
| Geänderter Wert | 103 erhält 30,02 | Absolute Differenz 0,02 > 0,01; Summe 60,02 | Numerische Abweichung beurteilen |
| Fehlende ID | 103 entfällt vollständig | 2 statt 3 erwartete IDs; 103 fehlt | Kein vollständiger Ergebnisnachweis |
| Doppelte ID | Zusätzliche Zeile 102/20,00 | 4 Zeilen; 102 doppelt; Summe 80,00 | Eindeutigkeitsfehler vor Freigabe klären |
| Fehlender Wert | 103 vorhanden, Wert fehlt | ID-Bestand vollständig; ein Wert nicht beurteilbar | Nach Fehlwertregel klären, nicht still gleichsetzen |
In Viya Ausführung und Speicherung ausdrücklich prüfen
Die Viya-Dokumentation unterscheidet SAS Compute Server und Cloud Analytic Services, kurz CAS. Nicht jeder Schritt wird in demselben Kontext ausgeführt. Code, Datenreferenzen und unterstützte Funktionen beeinflussen den Ausführungsweg. Eine Übernahme eines Programms aus SAS 9.4 ist deshalb kein Nachweis identischer Lauf- und Speicherbedingungen.
Das Programmierhandbuch beschreibt CAS als Umgebung für In-Memory-Verarbeitung und parallele Verarbeitung. Es unterscheidet außerdem sitzungsbezogene Daten von ausdrücklich gespeicherten oder anderweitig bereitgestellten Ergebnissen. Prüfen Sie für Ihren Ablauf, welcher Datenstand eingelesen wurde und was nach Ende der Sitzung tatsächlich verfügbar bleibt.
Ein praktischer eigener Prüffall beendet die vorgesehene Sitzung und lässt eine berechtigte Person das bewertete Ergebnis anschließend erneut aufrufen. Stimmen Datenstand, Zuordnung und Inhalt? Dieser Vorschlag unterstellt keine automatische Archivfunktion. Er prüft den benötigten Übergang zwischen Berechnung und späterer Nutzung. Auch ein technisch zugänglicher Datensatz ist nicht ohne Weiteres ein freigegebener Bericht.
Programm, Log und Bericht zu einem verständlichen Nachweis verbinden
Halten Sie den ausgeführten Programmstand, wesentliche Parameter, Eingabebezug und Ergebnis zusammen. Ein Log kann für die Beurteilung des Laufs wichtig sein. Es ersetzt aber nicht automatisch eine nachvollziehbare Historie aller relevanten Datenänderungen. Welche zusätzlichen Kontrollen erforderlich sind, ergibt sich aus dem konkreten Aufzeichnungsprozess.
Kapitel 4 fordert eine geregelte Dokumentation und die Festlegung relevanter Rohdaten bei elektronischen Aufzeichnungen. Bestimmen Sie deshalb, was für die spätere Beurteilung der Auswertung benötigt wird. Das kann neben dem Bericht insbesondere Eingaben, Zwischenstände mit fachlicher Bedeutung, Bewertungsnotizen und kontrollierte Korrekturen umfassen. Eine pauschale Speicherung jedes technischen Zwischenobjekts folgt daraus nicht.
Definieren Sie außerdem den Umgang mit abgebrochenen oder wiederholten Läufen. Warum wurde erneut gerechnet, welcher Lauf wurde verwendet und welche Abweichung wurde geklärt? Die ursprüngliche Information darf bei einer zulässigen Korrektur nicht still verschwinden. Prüfen Sie Zugriffs- und Aufbewahrungsmaßnahmen in der tatsächlichen Plattform, ohne aus dem Namen SAS eine Signatur- oder Audit-Trail-Garantie abzuleiten.
Maintenance, Viya-Updates und Programmänderungen bewerten
Eine Änderung an Datenzugriff, Programm oder Ausführungsumgebung kann andere Nachweise erfordern als ein nicht genutztes neues Merkmal. Erfassen Sie den Anlass und die betroffenen Abläufe. Ordnen Sie Herstellerinformationen und vorhandene Regressionen zu; ergänzen Sie Fälle für neu entstandene Fehlerwege.
Bei Viya sind Version und konkreter Release zu unterscheiden. Die Supportübersicht nennt zusätzlich Voraussetzungen der Kubernetes-Plattform und unterstützte Updatepfade. Ein technisch unterstützter Pfad ist jedoch kein fachlicher Eignungsnachweis Ihrer Analyse. Umgekehrt bestimmt nicht jeder Patch automatisch den Umfang einer vollständigen erneuten Validierung.
Bei einer Migration sind insbesondere Datenbedeutung, Schlüssel, Format und Ergebnisverwendung zu untersuchen. Ein Vergleich ausgewählter Zahlen reicht nicht, wenn Einheiten oder Zuordnungen verändert wurden. Planen Sie auch, wie frühere bewertete Ergebnisse erreichbar bleiben. Der Abschluss hält fest, welche Prüfungen durchgeführt wurden und welche offenen Punkte die vorgesehene Verwendung beeinflussen.
Mit einem konkreten Programmlauf beginnen
Wählen Sie eine relevante, überschaubare Auswertung als Einstieg. Die folgende Checkliste macht sichtbar, welche Informationen bereits vorliegen und wer fehlende Angaben liefern kann. Eine große Sammlung allgemeiner SAS-Unterlagen ersetzt diesen konkreten Ausgangspunkt nicht.
Der Fachbereich bestimmt Zweck und Akzeptanzkriterien, die Programmierung erklärt Verarbeitung und Vergleich, IT den Betrieb und QA die Einbindung in das Qualitätssystem. Aufwandstreiber sind vor allem heterogene Produktstände, viele Datenquellen, unklare Schlüssel, fehlende Referenzdaten und historische Ergebnisse ohne eindeutigen Programmbezug. Daraus lassen sich Arbeitspakete ableiten; pauschale Projektdauern wären vorher wenig belastbar.
- SAS-Produkte, Maintenance/Release, Hotfixes und Betriebsverantwortung erfassen.
- Einen tatsächlichen Datenweg mit verwendeten Programmen und Parametern auswählen.
- Vorhandene IQ-/OQ- und Entwicklerbelege auf ihren passenden Umfang prüfen.
- Eindeutige Schlüssel, Vollständigkeit, Fehlwerte und Vergleichsmaß festlegen.
- Unabhängige Sollwerte sowie kontrollierte Normal- und Fehlerbestände vorbereiten.
- Ergebnisspeicherung, Bewertung, Korrekturen und Wiederherstellung zuordnen.
Häufige Fragen zu SAS
Ist SAS bereits validiert, weil es in regulierten Unternehmen eingesetzt wird?
Verbreitung ist kein Nachweis Ihrer konkreten Anwendung. Vorhandene Herstellerbelege können wertvoll sein, müssen aber zu Produkt, Version und Verwendungszweck passen. Für Ihre Daten, Programme, Parameter und Betriebsbedingungen bleiben möglicherweise eigene Nachweise erforderlich. Entscheidend ist die begründete Abdeckung Ihrer Anforderungen, nicht eine pauschale Aussage über die Marke SAS.
Kann ein Validierungsansatz SAS 9.4 und Viya gemeinsam behandeln?
Die übergeordnete Methodik kann gemeinsam sein. Der technische Bestand und die konkreten Prüfungen müssen die Unterschiede jedoch sichtbar machen. SAS 9.4 verwendet Maintenance- und Produktstände, Viya zusätzlich Kadenzen und konkrete Releases. Ausführungsserver, Datenzugriffe und Speicherung sind gesondert zuzuordnen. Ein gemeinsames Dokument ist möglich, solange die Nachweise nicht zwischen unterschiedlichen Konfigurationen unklar vermischt werden.
Ersetzt ein erfolgreicher SAS-IQ/OQ-Lauf unsere fachlichen Tests?
Er kann passende Teile des Nachweises abdecken. Prüfen Sie dafür den tatsächlichen Testbestand, seine Version und die Ergebnisse. Das beschriebene IQ prüft Dateien; OQ führt bereitgestellte Komponentenprogramme aus. Daraus folgt noch keine Prüfung Ihrer kundenspezifischen Filter oder Probenzuordnungen. Umgekehrt müssen ausreichend passende Anbieterprüfungen nicht allein wegen ihrer Herkunft nochmals identisch ausgeführt werden.
Warum kann PROC COMPARE trotz gleicher Daten Unterschiede zeigen?
Ohne passende Zuordnungsregel werden Beobachtungen nach ihrer Position verglichen. Eine geänderte Reihenfolge kann dann unpassende Zeilen miteinander vergleichen. Mit geeigneten ID-Variablen lässt sich der Vergleich an Schlüsseln ausrichten; Typen und Sortierung müssen dazu passen. Untersuchen Sie zuerst die Vergleichsvoraussetzungen und anschließend echte Wertabweichungen, statt jedes Ergebnis vorschnell als Berechnungsfehler zu deuten.
Quellen: [3]
Wie wählen Sie eine zulässige numerische Vergleichstoleranz?
Begründen Sie sie anhand der Größe, des Rechenverfahrens und der beabsichtigten Verwendung. Halten Sie außerdem die Vergleichsmethode fest. Eine absolute Differenz ist etwas anderes als ein relatives Maß. Die Beispielgrenze 0,01 darf nicht ungeprüft übernommen werden. Bewerten Sie Auffälligkeiten anhand der vorab festgelegten Regel und verändern Sie diese nicht allein, um ein unerwünschtes Ergebnis als passend erscheinen zu lassen.
Kann ein Vergleich fehlende Werte versehentlich übergehen?
Ja, die gesetzten Optionen sind dafür relevant. Die dokumentierte NOMISSING-Wirkung kann fehlende Werte mit beliebigen Vergleichswerten gleichsetzen. Außerdem beantwortet ein Vergleich vorhandener Zeilen nicht automatisch die Frage nach fehlenden IDs. Prüfen Sie daher Wertinhalt, erwartete Identitäten und Eindeutigkeit getrennt. Ob ein Fehlwert zulässig ist, muss aus Ihrer fachlichen Datenregel hervorgehen.
Quellen: [3]
Sind Compute und CAS in Viya austauschbar?
Die Dokumentation beschreibt unterschiedliche Ausführungszusammenhänge. Code und Datenreferenzen beeinflussen, wo Verarbeitung stattfindet und wie Ergebnisse bereitgestellt werden. Eine allgemeine Gleichheit sämtlicher Funktionen oder numerischer Ergebnisse wird daraus nicht abgeleitet. Prüfen Sie den vorgesehenen Ablauf mit seinen Daten und Kriterien, insbesondere wenn sich der Ausführungsweg gegenüber einem bisherigen Verfahren verändert.
Quellen: [4]
Welche Unterlagen sollten vor einem SAS-Projekt bereitstehen?
Hilfreich sind eine konkrete Auswertung, die Produkt- und Versionsliste, Datenbeschreibung, Programmstand und bekannte fachliche Erwartungen. Ergänzen Sie vorhandene Installations- oder Testberichte und die Regeln für Betrieb und Ergebnisbewertung. Fehlende Informationen werden als Arbeitsaufträge festgehalten. Ein klarer repräsentativer Ablauf ist für den Start meist aussagekräftiger als eine unkommentierte Sammlung sämtlicher Herstellerdokumente.
Wer muss mitarbeiten, wenn intern nur wenige SAS-Spezialisten verfügbar sind?
Benötigt werden Fachwissen über die Auswertung, Verständnis der Programme, Plattformkenntnis und Qualitätssicherung. Die Rollen können passend zur Organisation verteilt werden. Insbesondere die unabhängige Sollbewertung darf nicht allein aus dem beobachteten Programmausgang entstehen. Planen Sie die Mitwirkung dieser Personen früh ein und klären Sie, welche konkreten Arbeiten ein Dienstleister übernimmt und welche Entscheidungen beim Unternehmen bleiben.
Quellen: [8]
Was treibt Aufwand und Dauer der Validierung oder Migration?
Wesentliche Faktoren sind die Zahl relevanter Programme, Datenquellen und Plattformvarianten sowie die Qualität vorhandener Referenzbelege. Unklare Schlüssel, historisch gewachsene Parameter und nicht zuordenbare Ergebnisse können zusätzliche Analyse erfordern. Ein geplanter Wechsel zu Viya bringt weitere Fragen zu Ausführung und Speicherung mit. Erst nach dieser Abgrenzung sind belastbare Arbeitspakete und Termine sinnvoll; der Produktname liefert dafür keine pauschale Zahl.
Quellen & fachlicher Stand
Stand 6. Oktober 2026. SAS-9.4-Bezug: M9 sowie Prozedurenhandbuch mit Titeldatum 15. September 2026; Qualification-Tools-Handbuch von 2021 mit gesonderter Passungsprüfung. Viya-Funktionsbezug: Programmierhandbuch bis 2026.06; Supportübersicht bis 2026.09. Regulatorischer Beispielscope: Humanarzneimittel-GMP. Tabellen und Sollrechnungen sind eigene Arbeitshilfen, keine ausgeführten Produkt- oder Kundentests.
- SAS 9.4 Maintenance Releases and Product Upgrades
- SAS 9.4 Qualification Tools User’s Guide
- Base SAS 9.4 Procedures Guide, Seventh Edition
- SAS Viya Platform Programming: Getting Started
- Updating SAS Viya — SAS Viya Forge
- SAS Viya Platform Operations: Versions in Standard Support and Update Paths
- Europäische Kommission: EudraLex Volume 4, Humanarzneimittel-GMP
- EU-GMP Annex 11: Computerised Systems, Revision Januar 2011
- EU-GMP Kapitel 4: Dokumentation, Revision Januar 2011
Zuletzt fachlich geprüft am 06.10.2026.
Daniel Herrmann Consulting
Den Nachweis für Ihre SAS-Auswertung aufbauen
Wir unterstützen Sie bei der Abgrenzung von Plattform, Daten und Analyse sowie bei der Bewertung vorhandener Belege und der Umsetzung konkreter Prüfungen.
- IT-GxP-Audit →
Bestehende SAS-Nachweise und offene Risiken im tatsächlichen Analyseprozess bewerten.
- IT-GxP-Consulting →
Vergleichskriterien, Testbestände und Nachweise für Änderungen oder Migrationen ausarbeiten.