Die Inspektion kann systemorientiert oder prozessorientiert sein.  Bei Einstieg in die Validierung eines CGS wird üblicherweise mit dem Validierungsplan und/oder dem Validierungsbericht begonnen.  Eine prozessorientierte Inspektion zielt auf jene Teile des Herstellprozesses, der von einem CS gestützt wird. So kann ausgehend vom Prozess die Validierung aufgerollt werden und überprüft werden, ob das CGS eine GMP Regeln verletzt bzw. ob der Prozess als vertrauenswürdig zu beurteilen ist.

Grundsätzlich ist gemäß nationaler Gesetze die Validierung der Computergestützten Systeme vorgeschrieben (AMG, AMBO), ohne dass nähere Vorgaben über konkrete Anforderungen gestellt sind. Etwas konkreter, aber immer noch sehr grob, sind Anforderungen an Computergestützte Systeme im EU GMP Guide Annex 11 formuliert.  Wesentlich konkreter sind die Erwartungen eines Inspektors an ein Computergestütztes System im PIC/S Guide über “Computerized Systems in GxP” beschrieben (www.picscheme.org).  Diese Leitlinie kann daher für den Inspizierten als gute Orientierung empfohlen werden. Die GAMP-Leitlinie ist eine Leitlinie, wie eine Validierung im GxP-Umfeld durchgeführt werden kann, sie ist jedoch nicht verbindlich; nach GAMP wird daher auch nicht inspiziert. Die GAMP Leitlinie wurde allerdings von Industrievertretern unter Mitarbeit europäischer und amerikanischer Behörden erstellt, sodass sie als Leitlinie zur Umsetzung einer Validierung empfehlenswert ist.

Der PIC/S Guide beinhaltet u.a. konkrete Forderungen an eine Validierung aus Inspektionssicht. Der Guide beinhaltet auch Vorgaben an die Inspektorate, wie eine Inspektion durchgeführt werden soll und welche Schwerpunkte gesetzt werden können. Das Dokument kann unter www.picscheme.org gratis bezogen werden.

Eine Antwort darauf kann und darf ein Inspektorat nicht geben.  Ein Inspektor darf nicht als Berater auftreten.  Rechtsunterworfene müssen sich das Wissen für eine Validierung selber beschaffen.  Aufgabe eines Inspektors ist es, die Situation in einem Betrieb gegen die rechtlichen Vorgaben zu prüfen.

Für das System sollte eine Basislinie geschaffen werden. Dazu muss das System nachdokumentiert werden. Das heißt, es sollten ein Erfahrungsbericht mit dem System und Anwender­spezifi­kationen - zumindest grob - erstellt werden. Auf Grundlage der Nachdokumentation sollte die Evaluierung des Systems erfolgen (von Validierung kann man retrospektiv genau genommen nicht sprechen). Nach Abschluss der Evaluierung sollte das Change Management etabliert werden, um das System valide zu halten. Ein Shut Down eines Altsystems ist bei entsprechender Kenntnis des Risikos von vornherein nicht erforderlich.  Ein System, das jedoch mangels Dokumentation und Risikoeinschätzung als Black Box zu betrachten ist, ist im Regelfall nicht als vertrauenswürdig und daher nicht als validierbar zu beurteilen.

GMP Relevanz eines Systems und Validierungs­pflicht ist dann gegeben, wenn ein Herstellungsschritt mittels Computersystem gestützt wird und wenn eine GMP-Regel betroffen ist.  Dies ist unabhängig davon, wer für das Computersystem / die Software zuständig ist.

Der Prozess sollte analysiert und die GMP-relevanten Bereiche sollten identifiziert werden. Schnittstellen sollten bekannt und definiert sein, eine Risikobe­trachtung sollte durchführt werden. Die Prozess­schritte sollten validiert werden, auch dann, wenn ein außerhalb der eigenen Organisationseinheit liegendes (Krankenhaus-)system oder SAP-System im Prozess Verwendung findet. Krankenhaussysteme oder SAP-Systeme sollten daher nicht als Black Box betrachtet werden. Die Validierungstiefe ist dem Risiko und der Komplexität der Arbeitsschritte anzupassen (z.B. werden einfache Gewichtsbe­rechnungen mittels SAP keiner besonders tief­gründigen Validierung bedürfen).

Er sollte zumindest ein dokumentiertes Qualitäts­sicherungssystem haben, das seine Beurteilung bei einem Lieferantenaudit zulässt (siehe dazu den PIC/S Guide). Eine Life Cycle Dokumentation darf erwartet werden. Eventuell können einschlägige Normen, die im PIC/S Guide angeführt sind oder z.B. ISO 15504 von Bedeutung sein.

Zumindest zu Beginn einer Kooperation sollte sich der Auftraggeber Klarheit darüber verschaffen, ob der Zulieferer die Anforderungen des GxP-Umfeldes kennt/versteht bzw ggf in der Lage ist, sein Qualitäts­sicherungssystem danach auszurichten. Bei einer bestehenden Kooperation sollten Lieferantenaudits anlassbezogen durchgeführt werden; ein starrer Zeitraum, zB jährlich, erscheint nicht zweckmäßig. Bedeutend ist auch die einschlägige Qualifikation des Lieferantenauditors.

Software von der Stange ist eine COT Software. Bei entsprechend weiter Verbreitung kann man unterstellen, dass ihr Anwendungsrisiko kalkulierbarer ist, als eine bespoken Software. Wenn die COT Software wie gekauft, ohne Customizing (durch Konfiguration oder Mitimplementierung von Makros) eingesetzt wird, ist ein deutlich geringerer Validierungsaufwand zu erwarten.  Der Validierungs­auf­wand hängt jedoch vom Einsatzgebiet und vom Ergebnis einer Risikoeinschätzung ab.  Siehe GAMP4 bezüglich Software-Kategorisierung.

Sie muss bei einer Inspektion greifbar sein; ob sie vor Ort lagert oder sich beim Zulieferer befindet ist dem Anwender überlassen.  Bei Auslagerung sind vertragliche Regelungen empfehlenswert. Deren Existenz muss dem pharmazeutischen Hersteller bekannt sein und sollte bei der Validierung Berücksichtigung finden.

Die Risikoanalyse sollte immer vom Anwender durchgeführt werden. Bei Übertragung der Durchführung einer Risikoanalyse an den Zulieferer muss dieser alle nötigen Informationen bereitgestellt bekommen. Die Form der Zusammenarbeit muss schriftlich definiert sein. Die Plausibilität der Dienstleistung muss gegeben sein.

Prüfen ob eine handschriftliche Signatur gemäß einer GMP-Regel erforderlich ist; wenn ja, sicherstellen, dass dort, wo Rechtsverbindlichkeit gefordert ist, diese auch erreicht werden kann; ist lediglich die Abbildung/ Nachvollziehbarkeit eines prozessualen Geschehens gefragt, reicht in der Regel die Zugangskontrolle mittels Username/Passwort aus.

Die Zertifizierung einer Software ist keine Forderung der GxP.  Von Bedeutung ist lediglich, ob eine Software / ein computergestütztes System einen Prozess so stützt, dass dies vertrauenswürdig (valide) geschieht.  Die verwendete Software muss qualifiziert sein.
„FDA-zertifizierte Software“ gibt es nicht, da seitens der FDA, wie von jeder anderen Behörde auch, keine Zertifizierungen durchgeführt werden.
Ebensowenig gibt es Software, die von vornherein als „Part 11 Compliant“ bewertet werden kann.
Beide Attribute sind weit verbreitete Irrtümer.