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.