Zeit die Dinge zu ändern
Mitarbeiter haben jetzt die Möglichkeit sich über interne GPT Chatsysteme Informationen aus Betriebshandbüchern, Arbeitsanweisungen oder Prozessbeschreibungen zusammenzufassen oder Fragen zu stellen.
LLMs lokal in Unternehmen einsetzen
Mitarbeiter haben jetzt die Möglichkeit sich über interne GPT Chatsysteme Informationen aus Betriebshandbüchern, Arbeitsanweisungen oder Prozessbeschreibungen zusammenzufassen oder Fragen zu stellen.
Software Validierung
Was ist Software-Validierung?
Software für den Pharma- und Medizinbereich zu entwickeln bedeutet mehr als guten Code zu schreiben – es bedeutet, jeden Schritt lückenlos, nachvollziehbar und regulatorisch abgesichert zu dokumentieren. Von der ersten Anforderung bis zur finalen Freigabe muss die Erstellung von Software durch den kompletten GxP-konformen Software-Lebenszyklus nach GAMP 5, EU-GMP Annex 11 und FDA 21 CFR Part 11 begleitet werden.
Ist hier eine Entwicklung nach agilen Prinzipien der Softwareentwicklung, wie beispielsweise nach dem Projektmanagement-Modell Scrum, möglich? Die Antwort ist ja, aber zusätzlich benötigt werden diverse Dokumentationen und Aufschriebe, die später bei einer Validierung oder einem Kundenaudit notwendig sind.
Im Folgenden wird erklärt, was sich hinter den einzelnen Dokumenten des Validierungslebenszyklus verbirgt, wofür sie benötigt werden und wie sie inhaltlich aufgebaut sind.
Das Lastenheft
URS – User Requirements Specification
Das Lastenheft steht am Anfang jedes Projekts. Hier werden die fachlichen Anforderungen aus Sicht der Stakeholder oder dem Product-Owner beschrieben: Was soll das System leisten, welche Prozesse muss es abbilden, welche regulatorischen Vorgaben sind zu erfüllen?
Die URS beschreibt das Was, nicht das Wie: Sie ist unabhängig von der späteren technischen Umsetzung. Jede Anforderung muss eindeutig formuliert und überprüfbar (testbar) sein, da sie den Ausgangspunkt für alle weiteren Dokumente – bis hin zur PQ (Performance Qualification) – bildet.
Die Formulierung sollte technologieneutral und für alle Beteiligten leicht verständlich sein, damit Stakeholder und Product-Owner unmissverständlich nachvollziehen können, welche Funktionalitäten die Software bieten wird. Als fester Vertragsbestandteil ist die URS nach der Beauftragung ein rechtlich bindendes Dokument.
Das Pflichtenheft
FS – Functional Specification
Das Pflichtenheft beschreibt, wie die zu entwickelnde Software die im Lastenheft definierten Anforderungen konkret umsetzt. Es überführt die Anforderungen des Lastenheftes (URS) in überprüfbare Funktionsbeschreibungen, darunter Eingaben, Verarbeitungslogik, Ausgaben, Schnittstellen zu anderen Systemen sowie Benutzerrollen und Berechtigungen.
Damit bildet das Pflichtenheft die Brücke zwischen fachlicher Anforderung und technischer Umsetzung und dient als Grundlage für das spätere Systemdesign.
Ein sinnvoller Mix aus agilen Prinzipien der Softwareentwicklung kann hierbei unterstützen. Dazu gehört beispielsweise die Erstellung eines Backlogs im Ticketsystem, das anschließend in Meilensteinen oder Sprints in konkrete Arbeitspakete und Tickets überführt wird. Dadurch entsteht ein strukturierter Überblick über Anforderungen, Prioritäten und den Umsetzungsstand.
Konfig-Spec
CS – Configuration Specification
In der Konfigurationsspezifikation werden alle Konfigurationsmöglichkeiten der individuellen Software systematisch dokumentiert. Sie beschreibt, welche Einstellungen innerhalb des Systems vorgenommen werden können, welchen Zweck diese erfüllen und welche Auswirkungen sie auf das Verhalten der Software haben.
Dazu gehören beispielsweise allgemeine Systemeinstellungen, Parametrierungen, Berechnungsformeln, Benutzerrollen und Berechtigungen, Schnittstellenparameter sowie kundenspezifische Vorgaben. Auch Abhängigkeiten zwischen einzelnen Einstellungen sollten beschrieben werden, damit nachvollziehbar bleibt, welche Konfigurationen miteinander in Verbindung stehen und welche Auswirkungen Änderungen haben können.
Ziel der Konfigurationsspezifikation ist es, jede Einstellung eindeutig, nachvollziehbar und reproduzierbar zu dokumentieren. Dadurch wird sichergestellt, dass die Softwarekonfiguration jederzeit überprüft, wiederhergestellt und bei Bedarf kontrolliert angepasst werden kann.
Darüber hinaus bildet die Konfig-Spec eine wichtige Grundlage für die Validierung der Software sowie für regelmäßige Audits. Sie unterstützt dabei, nachzuweisen, dass die eingesetzten Einstellungen definiert, geprüft und freigegeben wurden und dass Änderungen kontrolliert und dokumentiert erfolgen.
Das Design
SDS - Software Design Specification
Die Software-Design-Spezifikation beschreibt die technische Umsetzung der im Pflichtenheft festgelegten Funktionen und Anforderungen. Während das Pflichtenheft definiert, was die Software leisten soll, beschreibt die SDS, wie diese Anforderungen technisch realisiert werden.
Sie stellt damit einen zentralen Bestandteil der Softwareentwicklung dar. In der SDS wird dokumentiert, wie die einzelnen Funktionen, Module und Prozesse technisch aufgebaut sind und wie die im Ticketsystem definierten Arbeitspakete umgesetzt werden. Dazu gehören beispielsweise Architekturentscheidungen, Datenmodelle, Schnittstellen, Programmlogik, Validierungsregeln, Berechtigungsprüfungen, Fehlerbehandlung sowie relevante technische Abhängigkeiten.
Die Software-Design-Spezifikation richtet sich in erster Linie an Entwickler, Tester und Qualifizierer. Sie muss so detailliert beschrieben sein, dass die technische Umsetzung nachvollziehbar ist und daraus überprüfbare Testfälle für die Operational Qualification (OQ) abgeleitet werden können. Dadurch wird sichergestellt, dass die entwickelte Software nicht nur den fachlichen Anforderungen entspricht, sondern auch technisch korrekt, stabil und prüfbar umgesetzt wurde.
Bereits in der SDS werden außerdem Aspekte der Datenintegrität berücksichtigt. Dazu zählen insbesondere die ALCOA+-Prinzipien, also Anforderungen an die Nachvollziehbarkeit, Lesbarkeit, Gleichzeitigkeit, Originalität, Genauigkeit, Vollständigkeit, Konsistenz, Dauerhaftigkeit und Verfügbarkeit von Daten. Diese Prinzipien müssen auf technischer Ebene durch geeignete Maßnahmen unterstützt werden, zum Beispiel durch Audit-Trails, Berechtigungskonzepte, Protokollierungen, Plausibilitätsprüfungen und kontrollierte Datenänderungen.
Damit bildet die Design-Spezifikation eine wichtige Verbindung zwischen fachlicher Spezifikation, technischer Entwicklung und späterer Validierung der Software.
Die Analyse
RA - Risiko Analyse
Die Risikoanalyse ist ein systematisches Verfahren, um Risiken computergestützter Systeme zu bewerten. Sie ist ein zentrales Element von GAMP 5.
Die 5 Kategorien der GAMP 5
- Kategorie 1: Infrastruktur-Software
Sie bildet die Basisumgebung (z. B. Betriebssysteme, Datenbanken). Sie wird nur installiert und versioniert, aber nicht funktional validiert.
- Kategorie 2: Firmware (obsolete / wurde gestrichen)
Wurde gestrichen, weil die technologische Entwicklung sie überflüssig gemacht hat.
- Kategorie 3: Nicht-konfigurierbare Standardsoftware (COTS)
Eine Standardsoftware, die direkt „wie besehen“ genutzt wird (z. B. Waagen-Firmware, Laborgeräte). Der Testaufwand ist gering und hier werden nur die Basisfunktionen geprüft. - Kategorie 4: Konfigurierbare Standardsoftware
Etablierte Programme, die über vorhandene Funktionen an den Prozess angepasst werden (z. B. SAP, LIMS). Es wird kein Code geschrieben; dokumentiert und getestet wird lediglich die Konfiguration. - Kategorie 5: Kundenspezifische Software (Custom / Bespoke)
Komplett neu geschriebene Programme, Schnittstellen. Sie erfordert den maximalen Validierungsaufwand inklusive Code-Reviews!
Aus Sicht der Software-Entwickler unterscheidet sich Kategorie 5 fundamental von allen anderen GAMP-Kategorien: Da man den Quellcode von Grund auf neu schreibt, trägt man die volle Verantwortung für den Software-Lebenszyklus (SDLC).
Der Validierungsaufwand soll risikobasiert und verhältnismäßig zum tatsächlichen Risiko für Produktqualität, Patientensicherheit und Datenintegrität sein. Dazu werden Systemfunktionen bewertet und in Kategorien mit unterschiedlichem Kritikalitätsgrad eingeteilt. Funktionen mit hohem Risiko erhalten einen entsprechend höheren Testumfang, unkritische Funktionen einen geringeren. Die RA beeinflusst damit direkt Umfang und Tiefe von OQ und PQ.
Die Installation
IQ - Installations Qualifizierung
Die IQ weist nach, dass ein System korrekt installiert wurde. Genau so, wie es spezifiziert wurde. Sie ist also der dokumentierte Nachweis, dass ein System bestehend aus Software, Hardware und Netzwerkkomponenten exakt nach den Vorgaben des Herstellers bzw. des Software-Entwicklerteams und den Spezifikationen des Betreibers korrekt installiert und eingerichtet wurde.
Grundlage für die IQ sind in der Regel die in SDS und CS festgelegten Anforderungen an Systemarchitektur und Konfiguration. Die IQ prüft nicht, ob die Software funktioniert. Das ist Aufgabe der OQ. Bei einer Installations-Qualifizierung wird nur geprüft, ob die Software so vorliegt, wie sie vorliegen soll.
Dokumentiert werden dabei unter anderem:
- Hard- und Softwarekomponenten (z. B. Server, Betriebssystem, Datenbank)
- Versionsstände aller relevanten Komponenten
- Netzwerk- und Umgebungsparameter (z. B. Ports, Verzeichnisstrukturen, Berechtigungen)
- Durchgeführte Installationsschritte, im Idealfall als nachvollziehbares Protokoll mit Zeitstempel und ausführender Person
- Abweichungen vom geplanten Vorgehen, sofern welche auftreten, inklusive Begründung und Bewertung
Die IQ wird üblicherweise von der Person durchgeführt, die auch die Installation vornimmt. Bei individuell entwickelter Software ist das oft das Entwicklerteam oder die IT-Abteilung des Betreibers. Im Anschluss wird die IQ von einer zweiten, unabhängigen Person geprüft und freigegeben (Vier-Augen-Prinzip). Das Ergebnis ist ein unterschriebenes IQ-Protokoll, das als Nachweisdokument in die spätere Prüfung eingeht.
Die IQ bildet die Grundlage für alle weiteren Qualifizierungsschritte. Ohne den nachgewiesenen, korrekten Installationszustand lässt sich weder ein Funktionstest (OQ) noch ein Leistungstest (PQ) sinnvoll durchführen. Man würde sonst möglicherweise ein System testen, das gar nicht dem entspricht, was eigentlich geplant war.
Im Idealfall gibt es für eine individuell entwickelte Software ein weitgehend selbsterklärendes Setup, das sich reproduzierbar auf den vereinbarten Betriebssystem-Versionen installieren lässt. Das reduziert nicht nur den Aufwand für die IQ selbst, sondern auch das Risiko menschlicher Fehler bei der Installation.
Die System Validierung
CSV - Computer System Validierung
Die Computer-System-Validierung (CSV) beschreibt den gesamten Prozess, mit dem nachgewiesen wird, dass ein computergestütztes System zuverlässig, reproduzierbar und entsprechend den definierten Anforderungen funktioniert. Dabei wird der komplette Lebenszyklus des Systems betrachtet, beginnend bei der Spezifikation und Planung über die Implementierung, den produktiven Betrieb und spätere Änderungen bis hin zur kontrollierten Außerbetriebnahme.
Die CSV bildet den übergeordneten Rahmen für alle validierungsrelevanten Dokumente und Aktivitäten. Dazu gehören unter anderem die URS, FS, RA, IQ, OQ und PQ sowie die begleitenden Prozesse des Change Managements und Deviation Managements. Ziel ist es, sicherzustellen, dass das System nicht nur einmalig erfolgreich validiert wird, sondern dauerhaft in einem nachvollziehbaren, kontrollierten und nachweislich validierten Zustand betrieben werden kann.
Ein wesentlicher Bestandteil der CSV ist die Beschreibung der erforderlichen IT Infrastruktur. Dabei wird festgelegt, welche technischen Voraussetzungen notwendig sind, um die Software sicher und stabil betreiben zu können. Dies kann sowohl eine Cloud Umgebung als auch eine on-premises Infrastruktur betreffen. Die gewählte Betriebsform muss nachvollziehbar dokumentiert werden, damit eindeutig ersichtlich ist, unter welchen Rahmenbedingungen das System validiert und betrieben wird.
Handelt es sich um eine Client Server Architektur, müssen die eingesetzten Komponenten klar beschrieben werden. Dazu gehören insbesondere die unterstützten Betriebssysteme, die getesteten Versionen der Client Software sowie die relevanten Serverkomponenten. Es muss nachvollziehbar sein, mit welchen Systemumgebungen die Software geprüft wurde und für welche Kombinationen die Validierung gilt.
Zusätzlich kann es erforderlich sein, weitere Basissoftware in die Betrachtung einzubeziehen. Dazu zählen beispielsweise Firewall Einstellungen, Endpoint Protection, Virenscanner, Datenbankserver, Schnittstellenkomponenten oder andere sicherheitsrelevante Systeme. Wenn solche Komponenten Einfluss auf den Betrieb, die Sicherheit oder die Funktionalität der Software haben, müssen sie entsprechend dokumentiert und bei Bedarf in die Validierung einbezogen werden.
Bei webbasierten Lösungen ist zusätzlich zu dokumentieren, mit welchem Browser und mit welcher Browserversion die Anwendung getestet wurde. Auch hier ist wichtig, dass die geprüfte Umgebung eindeutig beschrieben wird, damit spätere Änderungen an Browsern, Betriebssystemen oder Sicherheitseinstellungen bewertet und gegebenenfalls erneut geprüft werden können.
Werden für den Betrieb der Software zusätzliche Hardwarekomponenten benötigt, müssen auch diese Bestandteil der CSV Dokumentation sein. Dazu können Messgeräte, digitale Mikroskope, Scanner, Drucker, Waagen, Sensoren oder vergleichbare Geräte gehören. Neben der genauen Bezeichnung der Hardware sollten auch relevante technische Informationen wie Seriennummern, Treiberversionen, Schnittstellen und installierte Firmwarestände dokumentiert werden.
Die CSV stellt somit sicher, dass alle technischen, organisatorischen und prozessbezogenen Voraussetzungen für den validierten Betrieb eines computergestützten Systems vollständig beschrieben, geprüft und nachvollziehbar dokumentiert sind.
Der Bericht
DQR - Designqualifizierungsbericht
Der Designqualifizierungsbericht (DQR) bildet den formellen und dokumentierten Abschluss der Designphase. Er liefert den offiziellen Beleg dafür, dass die spezifizierten Funktionen und Architekturen exakt den Vorgaben des Product-Owners bzw. den regulatorischen Anforderungen entsprechen.
Im Kern verifiziert die Designqualifizierung (DQ), ob das im System- oder Softwaredesign (z. B. Functional Specification / Software Design Specification) beschriebene System alle Kriterien des Lastenhefts (URS) lückenlos abdeckt. Da dieser Abgleich stattfindet, bevor die funktionale Testphase beginnt, fungiert er als Qualitäts-Sicherheitsnetz: Es wird systematisch sichergestellt, dass keine Anforderung im Design übersehen wurde und gleichzeitig keine Design-Entscheidung ohne geschäftliche oder regulatorische Notwendigkeit getroffen wurde. Durch diese frühzeitige Identifikation von Abweichungen und Lücken (Gap-Analyse) lassen sich teure Fehlentwicklungen und zeitaufwendige Korrekturen in späteren Testphasen effektiv verhindern.
In der klassischen Wasserfall-Methodik gilt der DQR als finale Freigabe für den Bau bzw. die Codierung der Software. In modernen, agilen Entwicklungsumgebungen kann dieser Prozess jedoch flexibler gestaltet werden: Hier ist es durchaus gängige Praxis, dass die Softwareentwicklung bereits startet, während die Designqualifizierung und die Erstellung des DQR parallel und iterativ vorangetrieben werden.
Die Funktionsqualifizierung
OQ - Operational Qualification
Der Funktionsqualifizierungsplan (Operational Qualification Plan, OQ) ist ein formales und verbindliches Prüfdokument im Validierungsprozess. Er beinhaltet eine detaillierte, lückenlose Beschreibung aller zu prüfenden Funktionalitäten der Software.
Die OQ verifiziert systematisch, ob das System unter definierten, kontrollierten Bedingungen exakt so funktioniert, wie es in der Funktionalen Spezifikation (FS) und der Software Design Specification (SDS) spezifiziert wurde.
Struktur und Aufbau der Testfälle
Jeder einzelne Testfall im OQ-Plan folgt einer strengen Logik:
- Eindeutige Referenz: Jeder Testfall bezieht sich über eine Rückverfolgbarkeitsmatrix (Traceability Matrix) auf eine konkrete funktionale Anforderung.
- Präzise Anleitung: Er beschreibt die exakten Testschritte (Inputs) und die vorab definierten, messbaren erwarteten Ergebnisse (Soll-Werte).
- Beweiskräftige Dokumentation: Er protokolliert die tatsächlichen Ergebnisse (Ist-Werte) sowie die erfolgreiche Erfüllung der Akzeptanzkriterien.
- Abweichungsmanagement: Eventuelle Fehler oder Fehlverhalten der Software werden strukturiert als Abweichungen (Deviations) erfasst und nachverfolgt.
Da die OQ die Systemfunktionen isoliert – also unabhängig vom eigentlichen, realen Produktionsbetrieb (der späteren PQ) – testet, bildet sie das fundamentale Sicherheitsnetz für die Softwarestabilität.
Synergien durch softwarebasierte Funktionstests (Functional Tests)
Moderne Software-Entwickler können diesen Validierungsprozess durch programmierte, automatisierte Funktionstests (Functional Tests) massiv unterstützen und beschleunigen. Dies ermöglicht eine hocheffiziente, interdisziplinäre Zusammenarbeit am Funktionsqualifizierungsplan zwischen Entwicklung, Fachbereich und Qualitätssicherung (QA):
- Shift-Left-Ansatz im Application Lifecycle: Hochwertige Funktionstests werden bereits sehr früh parallel zur eigentlichen Entwicklungsarbeit programmiert. Fehler werden dadurch nicht erst in der Validierungsphase, sondern bereits während der Entstehung entdeckt.
- Nachhaltiges Lebenszyklus-Management (ALM): Automatisierte Tests sichern den gesamten Lebenszyklus der Software. Bei zukünftigen Updates, Bugfixes oder Systemänderungen dienen sie als hocheffiziente, automatisierte Regressionstests. Sie weisen per Knopfdruck nach, dass bestehende Funktionen durch Codeänderungen nicht beeinträchtigt wurden.
- Audit-Ready Reporting: Richtig konfiguriert erzeugen diese programmierten Tests bei jedem Durchlauf automatisch lückenlose, manipulationssichere Testprotokolle (inkl. Zeitstempeln und Screenshots), die direkt als OQ-Nachweisdokumente für Auditoren genutzt werden können.
Die Leistungsqualifizierung
PQ - Performance Qualification
Arbeitet das neue System unter realen Belastungen wie erwartet?
Das Problem in der Praxis!
Es ist ein Klassiker, wenn Software während der Entwicklungszeit und gleichzeitigem Testen reibungslos und performant funktioniert, aber unter Last, z.B. wenn morgens in der Rush-Hour mehrere Mitarbeiter gleichzeitig das System verwenden, plötzlich zusammenbricht.
Während die OQ die Funktionen unter kontrollierten Bedingungen prüft, weist die PQ nach, dass das System unter realen Betriebsbedingungen zuverlässig und reproduzierbar funktioniert. Also im tatsächlichen Zusammenspiel mit Anwendern, Prozessen und ggf. weiteren Systemen. Getestet werden reale Prozessabläufe, typische Lastszenarien und ggf. auch Grenzfälle.
Die PQ muss so formuliert und anwendbar sein, dass unabhängige externe Prüfer diese Tests durchführen können.
Auch hier ist die Mitarbeit der Software-Entwickler oder einem separaten Test-Team notwendig, da ein Ablauf von mehreren Anwendungs- und Funktionstests parallel ausgeführt werden muss, um die Performance unter Last zu testen.
Die PQ ist der finale und kritischste Meilenstein des Validierungsprozesses. Erst nach erfolgreichem Abschluss der PQ und der formellen Freigabe (Go-Live-Decision) darf das System für den produktiven Einsatz freigegeben werden.
Das Testprotokoll
TM - Traceability Matrix
Die Traceability Matrix verknüpft alle Dokumente des Lebenszyklus miteinander: Jede Anforderung aus der URS wird bis zur FS, SDS, Risiko-Analyse und schließlich bis zu IQ, OQ und PQ zurückverfolgbar dargestellt und umgekehrt.
So lässt sich jederzeit belegen, dass jede Anforderung umgesetzt und getestet wurde und dass kein Testfall ohne zugehörige Anforderung existiert. Die TM ist meist eine tabellarische Übersicht und wird bei Audits häufig als erstes Dokument angefragt, da sie die Vollständigkeit des gesamten Validierungsprozesses auf einen Blick zeigt.
Beispiel eines Testprotokolls:
| Anforderungs-ID | Anforderung | Design- / Funktionsspezifikation | Testfall Beschreibung |
Test-Status |
| REQ-001 | Der Benutzer muss sich mit E-Mail und Passwort anmelden können. | Authentifizierungsmodul | Erfolgreicher Login mit korrekten Daten. | Bestanden (Passed) |
| REQ-001 | Der Benutzer muss sich mit E-Mail und Passwort anmelden können. | Authentifizierungsmodul | Fehlermeldung bei falschem Passwort. | Bestanden (Passed) |
| REQ-002 | Passwort muss mind. 8 Zeichen, 1 Zahl und 1 Sonderzeichen enthalten. | Passwort-Validierung | Registrierung mit zu kurzem Passwort ablehnen. | Fehlgeschlagen (Failed) |
| REQ-003 | Der Benutzer kann sein Passwort über einen E-Mail-Link zurücksetzen. | Passwort-Reset-Dienst | Anforderung der Reset-E-Mail testen. | Offen (Not Run) |
| REQ-004 | Das System muss nach 3 Fehlversuchen den Account für 15 Minuten sperren. | Sicherheit & Brute-Force-Schutz) | LÜCKE ENTDECKT: Kein Testfall definiert! | Blockiert |
