On the topic of computer validation, a great number of regulations and guidelines were published during the past years. The most recent documents were published by the American FDA on "Electronic Records/Electronic Signatures" and by the pharmaceutical industry: "GAMP 4." Just as the FDA provides its inspectors with interpretation guidelines in the form of the "Guides to Inspection," PIC/S (Pharmaceutical Inspection Co-operation Scheme) also furnishes its members' inspectors with such guidelines, i.e. the PIC/S Guidances. The interpretations are based on the EU GMP Guide and, particularly, on Annex 11 "Computerised Systems."

In September 2003, the PIC/S Guidance "Good Practices for computerised Systems in Regulated 'GXP' Environments" came into force, which is primarily directed at the authorities' inspectors, but which also points out the state of the art and knowledge to the pharmaceutical industry and its suppliers. It is perfectly clear that the authors of this guidance did not intend to reinvent the wheel. Their intention was to set out in detail the state of the art and knowledge by referencing current documents, e.g. GAMP 4 and 21 CFR Part 11.

The Guidance is divided into the 3 parts:

• Preamble
• Implementation of Systems
• System Operations / Inspection / References

Above all part 3 is very interesting because it contains checklists and aide-memoires that can be used by inspectors during inspections.

Within the framework of the Computer Validation Conference 2004, the PIC/S Guidance and its interpretations by representatives of the German supervisory authorities were the definitive documents. Members of the German expert group "computerised systems" demonstrated the applicability of this document to the most diverse partial aspects of the validation of computerised systems. Representatives from the pharmaceutical industry commented on this guidance and its applicability from an industry viewpoint. Here, it became clear that above all the topics risk analysis/risk management or change management have meanwhile assumed a pivotal role in the regulations, but also in daily practice.

While the broad outlines of the correct validation of computerised systems have in the meantime become generally known in the industry and are also observed (especially GAMP 4 should be mentioned here as a standard), a great number of partial aspects still gives rise to uncertainty as to their implementation. The conference also included a panel discussion, during which a variety of such questions was debated.

In the following, we would therefore like to repeat some of the questions and the respective answers given by the representatives from authorities and the industry.

In which intervals do systems have to be validated?

Generally, concrete intervals are not defined in the regulations, whereas an interval of 5 years is considered to be definitely too long. The companies should set their own intervals, above all with regard to change management. In this context, a yearly assessment is recommended - e.g. within the framework of the required self-inspections - during which the changes are again assessed (many small changes that do not give cause for revalidation individually may in their sum be reason enough for revalidation). In the case of major changes (e.g. an upgrade to a new SAP release), a revalidation must however be carried out.

Does a software supplier have to be audited at all events, or would it be sufficient if the supplier filled in a questionnaire which would then be assessed by the QA unit?

A software supplier has to be assessed at any rate. This can be done by means of an audit, but it is not absolutely necessary. The question whether a questionnaire is sufficient should be answered by the pharmaceutical entrepreneur in dependence on the criticality of the software, but also on experiences with the supplier. If the supplier "only" provides personnel working according to SOPs created by the customer, an audit is not necessary. However, it must be proved that these persons have been trained.

Is it necessary to approve hardware and software suppliers formally?

A formal approval of the hardware and software suppliers is not necessary. However, it has to be ensured that orders are placed only with suppliers that have before been assessed and accepted.

Specifications always define the desired quality. Therefore, they have to describe the requirements so that they can be used as the basis for the tests. Thus, they have to be testable, i.e. the customer should be able to test whether he has received what he had ordered. For commercial reasons alone the customer will describe in sufficient detail what he expects/orders.

What is standard software? Does standard software have to be validated?

GAMP 4 classifies standard software as category 3 and requires for it: recording of the version (and of the environment configuration) and verification of the performance against the user requirements. Here, it has to be determined whether the requirements laid down by the software provider coincide with the customer's own requirements. In the end, a risk assessment has to decide about the question which scope of validation is necessary (certainly the scope will be narrower than for category 4 software).

Traceability matrix – what is necessary? Must an end user have a traceability matrix, administrate it and validate it?

The user has to be able to show that his user requirements were checked during the validation. A traceability matrix is an instrument for proving this. What is essential in this context is that the requirements can be traced from the specification via the risk analysis to the test. It should be seen as a checklist that asks whether the specified requirements have been implemented and where the proof can be found.

Which significance do the PIC/S Guidances have?

The PIC (Pharmaceutical Inspection Convention) was founded in 1970 between the EFTA states as a treaty for the mutual recognition of inspections of the manufacture of pharmaceutical products. Little by little, further European and non-European countries entered into this agreement. Owing to the European interpretation of the law, from the beginning of the 90s, it has not been possible any more for member states of the European Union to become members of this convention. For this reason, the PIC was developed further to become the PIC/S in 1995 (Pharmaceutical Inspection Co-operation Scheme). The PIC/S is no longer an agreement between states, but a less formal and more flexible co-operation between inspection authorities for the purpose of information and experience exchange. The main basis for official inspections is the EU GMP Guide, and for the field of "computerised systems," Annex 11. Both of them use basically the same wording as the respective PIC documents. With the "Good Practice Guidance," the PIC/S wants to provide the inspectors with background information and recommendations for the inspection of computerised systems. It is meant to reflect the state of the art and knowledge and should not hinder technological progress either. This guidance is not mandatory for the pharmaceutical industry; however, fulfilling these requirement is generally considered to be sufficient. It is to be expected that, in the future, European inspectors will keep very close to the requirements of this guidance as to questions concerning the inspection of computerised systems.
  

Source:
GIT LITUS - Laboratory IT User Service 1/04, GIT VERLAG, Darmstadt, Germany