Die Bezeichnung „Validierung“ ist über die Jahre nicht direkt ein IN-Begriff geworden – die Gründe hierfür sind teilweise vielschichtig oder hausgemacht. In manchen Fällen hat einfach die komplexe oder fehlende verständliche Darstellung von Prozessen oder Systemen eine nachhaltige Unsicherheit bei fachfremden Entscheidungsträgern erzeugt, die dazu geführt hat, dass Qualitätsprozesse etabliert wurden, die extrem unflexibel oder dokumentatorisch überzogen sind. Auch hier will die GAMP®5 Leitlinie entgegenwirken und hinterfragt vorsichtig bestehende Konzepte mit dem Fokus auf das Patientenrisiko. Der Begriff Validierung wird daher teils mit neuen Begrifflichkeiten wie Verifikation oder Designprüfung ersetzt; Ansätze über Prototyping-Konzepte und moderne Projekt- und Entwicklungsmethoden werden explizit genannt.
Die Ansätze für die Qualitätssicherung müssen auch mit den rasant wachsenden IT Lösungskonzepten und Plattformen standhalten. Vor zwanzig Jahren wäre das Verhältnis zwischen Hardware- und Softwarekosten im Verhältnis 10:1 gewesen, heute ist das Verhältnis 1:10, da die Hardwarekosten deutlich gesunken sind. Dabei sind aber auch die diversen Serviceleistungen um die IT Projekte mit ihrem Funktionsaufwand und der Architekturauslegung (W-Lan, Bluetooth) gestiegen. Heutzutage sind IT Produkte eher als konfigurierbar anzusehen – selten wird eine Lösung einzeln komplett neu entwickelt oder als Einzelplatzlösung betrieben. Ein Blick in die Zukunft zeigt hoch konfigurierbare Systeme bzw. anwenderorientierte Plattformen, die durch ihre einfache Anpassungsmöglichkeiten nahezu durch den Endanwender (Prozessexperte) selbst gestaltet werden können. Diese Plattformen können dann sogar als „open source“ Applikationen ohne Kosten beschafft werden – damit wären dann die IT-Projektkosten zum größten Teil im Bereich des Projekt-, Prozess- und Qualitätsmanagements für die Implementation und Integration hineingerückt.
Aktuell sind die beiden großen Herausforderungen aus dem bekannten und klassischen V-Modell zum einen der Informationsfluss im linken Spezifikationsast von der Anforderung zur Realisierung und zum anderen die Wederhol-Zyklen für gewisse Iterationsschritte im IT-Projekt selbst. Der erste Teil ist entscheidend für die funktionale Qualität – die Transformation des Prozesswissens in die Softwarelösung an sich. Hier entstehen circa 80 Prozent der Softwarefehler, die eigentlich keine sind, sondern auf Missverständnisse oder mangelnder Kommunikation bzw. Spezifikationstiefe zurückzuführen sind. Ein IT-Projekt braucht hier sehr oft eine praktikable Methode für diese Wissenstransformation und eine Art von „Dolmetscher“ zwischen Prozessexperten und Entwickler. Bei einer falschen Auslegung oder Gestaltung des projektspezifischen V-Models können hier erhebliche Probleme auftreten.
Der zweite Punkt ist die teilweise unhandliche Auslegung des V-Modells als Projektmethode: Die GAMP®5 Leitlinie hat hier skalierbare Alternativen nun als Vorschlag angedacht. Das V-Modell hat sich in der Projektdurchführung teilweise als zu komplex erwiesen, da die Projekt-, Entwicklungs- und Testphasen iterativ und gegebenenfalls zyklisch wiederholend aufgetreten sind. Auch bei geplanten Änderungen (Anforderungen, Funktionen, Technik) oder negativen Testergebnissen endete das V-Modell in einer Dokumentationslawine mit diversen Freigabe-Zyklen, die betriebswirtschaftlich untragbar sein können und im Gegenzug einen mäßigen oder keinen qualitativen Zugewinn bedeuten.
Die GAMP®5 Leitlinie beinhaltet verschiedene skalierbare Methodenansätze, die durch andere IT-Systemlebenszyklen oder Entwicklungsmodelle gestützt werden können. Die Softwareentwicklungsmethode rückt dabei ebenso in den Vordergrund wie das Qualitätsrisikomanagement. Für die Softwareentwicklung werden verschiedene Standards und Normen benannt, die wiederum spezielle Fachkenntnisse zwingend voraussetzen. Die Disziplinen dort sind unter anderem diverse (auch agile) Softwareentwicklungsmethoden, Standards wie CMMI oder Normen (ISO 12207). Durch diese Vorgaben oder Vorschläge will der GAMP®5 gerade auch die Anbieter tiefer in die resultierende Software-Qualität mit einbinden und den Projekterfolg damit sicherstellen.