The inspection can be system-oriented or process-oriented. The validation of a CGS usually starts with the validation plan and/or the validation report. A process-oriented inspection targets those parts of the manufacturing process that are supported by a CS. Thus the validation can be rolled up starting from the process and it can be checked whether the CGS violates a GMP rule or whether the process can be judged to be reliable.

In principle, the validation of computer-aided systems is prescribed by national laws (AMG, AMBO), without more detailed specifications being made about specific requirements. More concretely, but still very roughly, requirements for computer-based systems are formulated in the EU GMP Guide Annex 11. More concretely, an inspector's expectations of a computer-based system are described in the PIC/S Guide on "Computerized Systems in GxP" (www.picscheme.org). This guideline can therefore be recommended as a good orientation for the inspected party. The GAMP guideline is a guideline on how a validation can be performed in the GxP environment, but it is not binding; therefore GAMP is not inspected. The GAMP Guideline, however, was developed by industry representatives in cooperation with European and American authorities and is therefore recommended as a guideline for the implementation of a validation.

The PIC/S Guide contains, among other things, specific requirements for validation from an inspection point of view. The guide also contains specifications for the inspectorates as to how an inspection is to be carried out and which focal points can be set. The document can be obtained free of charge at www.picscheme.org.

An inspectorate cannot and must not give an answer to this question. An inspector must not act as a consultant. Those subject to the law must obtain the knowledge for validation themselves. The task of an inspector is to check the situation in a company against the legal requirements.

A baseline should be created for the system. To do this, the system must be subsequently documented. This means that an experience report with the system and user specifications - at least roughly - should be prepared. The evaluation of the system should take place on the basis of the post-documentation (retrospectively one cannot exactly speak of validation). After completion of the evaluation, change management should be established in order to keep the system valid. A shutdown of an old system is not necessary from the outset if the risk is known. However, a system that is to be regarded as a black box due to a lack of documentation and risk assessment is generally not to be regarded as trustworthy and therefore cannot be validated.

GMP relevance of a system and validation obligation is given if a manufacturing step is supported by a computer system and if a GMP rule is affected. This is independent of who is responsible for the computer system / the software.

The process should be analysed and GMP relevant areas identified. Interfaces should be known and defined, a risk assessment should be carried out. The process steps should be validated, even if a (hospital) system or SAP system outside your organizational unit is used in the process. Hospital systems or SAP systems should therefore not be regarded as black boxes. The validation depth must be adapted to the risk and complexity of the work steps (e.g. simple weight calculations using SAP will not require particularly in-depth validation).

He should at least have a documented quality assurance system that allows his assessment during a supplier audit (see the PIC/S Guide). A life cycle documentation can be expected. Relevant standards listed in the PIC/S Guide or e.g. ISO 15504 may be relevant.

At least at the beginning of a cooperation, the client should clarify whether the supplier knows/understands the requirements of the GxP environment or is able to align his quality assurance system accordingly. In the case of an existing cooperation, supplier audits should be carried out on a case-by-case basis; a rigid period, e.g. annually, does not seem appropriate. The relevant qualification of the supplier auditor is also important.

Off-the-shelf software is a COT software. With a correspondingly wider distribution one can assume that their application risk is more calculable than a bespoken software. If the COT software is used as purchased, without customising (through configuration or co-implementation of macros), a significantly lower validation effort is to be expected. However, the validation effort depends on the application area and the result of a risk assessment. See GAMP4 for software categorisation.

It must be available during an inspection; whether it is stored on site or at the supplier's is up to the user. Contractual arrangements are recommended for outsourcing. Their existence must be known to the pharmaceutical manufacturer and should be taken into account during validation.

The risk analysis should always be performed by the user. When transferring a risk analysis to the supplier, the supplier must be provided with all the necessary information. The form of cooperation must be defined in writing. The plausibility of the service must be given.

Checking whether a handwritten signature is required in accordance with a GMP rule; if so, ensuring that it can be achieved where legal validity is required; if only the representation/traceability of a procedural event is required, access control by means of a user name/password is generally sufficient.

The certification of software is not a GxP requirement. The only thing that matters is whether a software / computer-aided system supports a process in such a way that it is trustworthy (valid). The software used must be qualified. There is no "FDA-certified software", because the FDA, like any other authority, does not carry out any certifications. Nor is there any software that can be rated "Part 11 Compliant" from the outset. Both attributes are widespread errors.