European Conference on Computer Validation - Conference Review -

Recommendation

12-14 December 2023

Stability by Design - Live Online Training
- Stability Testing in Product Design and Method Development- Focus mainly on small-molecule APIs and drug products

From 15- 17 June 1999 the European Compliance Academy organised the European Conference on Computer Validation in cooperation with Concept Heidelberg.

Lilian Hamilton of the Swedish supervisory authority started off with an overview of theexisting GMP requirements for computer-aided systems. In Europe the 11th Supplementary Guideline to the EC-GMP-Guide defines requirements for computer-aided systems. In addition, requirements for the documentation are listed in Chapter 4.9. In September 1998 the PIC/S Draft "Recommendations on Implementation, Validation and Operation ofComputerised Systems" was published. This draft refers to:

References for Relevant Standards and GMP Guides/Codes

• GAMP Guide Version 3.0 1998
• PDA Technical Report No. 18
• Relevant CFR sections
• ISO Standards
• IEEE Publications

When it was submitted in December 1998 thedraft, which was to be passed on to the industry for comments, was withdrawn. At present, owing to a change in the leadership of the PIC working group, Tony Trill of MCA isresponsible for submitting a new draft. Ms. Hamilton explained that the new PIC draft willcontain additional requirements as regards electronic signature and electronic records.
Ms. Hamilton named the following as examples for critical DP systems:

• batch documentation systems

• LIMS

• process applications

• material status control systems

She focussed particularly on two requirementsfor computer systems "Security", i.e. among other things physical security,  access control, etc. as well as "Handling and maintenance" in particular (change control, configurations management, system descriptions, etc.). In the following shelisted the deviations most frequently found during MPA inspections:

Inspection findings

• No validation performed
• No system description
• System description not complete or updated
• Irrelevant software installed
• Temperature in computer room too high
• Cables not labelled
• Passwords not changed regularly
• No self inspections
• Diskettes not stored or handled properly
• Emergency plan eight years old and not updated
• QC/QA not involved in validation
• Not testet if data can be restored
• Routines in computer room not strict enough
• Protection against fire not sufficient

The second talk was held by J.A. Norder of the Dutch GMP supervisory authority. He also described the existing guides and guidelines. He made special mention of GAMP and the PDA Technical Report No. 18. Although these two industrial papers are not legally binding, they are to be regarded as an industrial standard, since the papers were compiled by representatives of the pharmaceutical industry. He also mentioned the British "TickIT- Scheme and Guide" which is interesting both for users as well as for suppliers ofDP suppliers.

He then described which documents for computer validation an inspector expects. The firstdocument he mentioned was the validation master plan with general information includingtime-table, responsibilities, references to SOPs, format of the validation plans andprotocols as well as acceptance criteria. As special requirements he mentioned the fiveGAMP categories which define how extensively a specific system is to be validated. Here the computer systems are evaluated as a function of the degree of utilisation and thestate of development of the system.

Category 5, for instance, requires "customer-specific systems" (i.e. systemswritten especially for a certain customer) that these systems are to be validated and thesoftware manufacturer audited.

According to the two points of view of the inspectors, Dr. Schumacher of Asta Medica presented the statements of the industry concerning the international computer validation guidelines. He also talked about the GAMP Guide which requires in accordance with theabove categories an audit of the software suppliers for the software of stages 4 and 5.The necessity of this audit was then discussed in detail by the participants from the industry and the authorities. Share audits, i.e. joint audits of several companies may surely be a way out here. Dr. Schumacher finally discussed old systems. The PIC/S draft of1998 requires the subsequent elaboration of user requirements here. Dr. Schumacherquestioned whether this demand is of any use. He appealed therefore for this item to bedeleted when the draft is revised.
From the GMP Trends and the Gold Sheet he cited findings of MCA and FDA inspectors aslisted below:

Observations of FDA and MCA duringInspections

• Missing system specification
• Responsibilities not defined
• User training not documented
• No systematic data backup
• Charts of data flow not existing
• No internal audits of the system by QA unit
• No documentation of deviations

The last talk of the first day was held by Dr.J. Gill of Tanvec, UK, who has already been involved in computer validation since 1990, also as an employee of Zeneca and Novo Nordisk. He presented the most important documentsfrom the Life Cycle Concept:

• System Register
• Vendor - Audit Report
• User System Requirements
• Functional specification
• System Test specification (test which proves that the software meets the functional specification)
• Validation Report

He stressed the necessity of detailed and very extensive user system requirements sincethese are the foundation for the additional validation activities and it is only in this way that one can verify whether the system does what it is supposed to do. Dr. Gillpointed out that in old systems the life cycle concept can only be conditionally used. He also questioned whether subsequently elaborated user requirements are really of any benefit.

The first talk on the second day was held by Mr. Nehls from Novartis. He described the techniques, criteria and advantages of risk analyses.

On the topic of techniques he explained that the risk areas comprise four sectors:

• security

• environmental conditions

• protection of the DP systems (e.g.access protection, data integrity) and, of course,

• quality
  

He recommended that, in addition to the DP department, the user (process expert), the QA department and, if possible, the suppliersof the systems be included in the risk analysis. Care should be taken, however, that theteam does not contain more than five persons. As regards the criteria of the risk analysishe explained that at first the regulatory requirements must be recorded which exist for afunction, e.g. electronic signature or access protection. In addition, the frequency ofuse (100 times a day or once a month) must be recorded. The "technical risks" include, e.g. interfaces and possibly calculations carried out by the system.

Finally the "user risks" (e.g. manual data input necessary?) must be recorded. Not forgetting the last two criteria for the risk analysis:

• Consequence of the error (error impactwithin the meaning of drug safety)
  

• Business risks, i.e. what costs does apotential error cause?
  

Another topic which is currently being verystrongly discussed was presented by Dr. Werling from Propack data: "ElectronicSignature and Electronic Records".
Dr. Werling presented the requirements for electronic batch protocols according to 21 CFRPart 11 as shown below. He described these requirements by comparing the GMP requirements with a possible implementation:

Requirements of a Batch Protocol According to FDA and EU/PIC

He then described the two electronic signaturemethods:

- Biometric method
- Non-biometric method

The biometric methods include:

a. Fingerprint
b. Voice recognition
c. Dynamic signature (automatic recognition by the DP  system)
d. Eye/iris identification) etc.

In some cases, however, non-biometric methods are currentlyused more frequently. But this requires two security mechanisms. For instance a logical key (password and access entitlement concept) and a physical key, e.g. barcode or smartcard.

The validation of pharmaceutical equipment and in that context the special aspect ofcomputer validation was presented by Mr. Reines of Novartis, Barcelona. He explained that in elaborating a validation master plan one soon realises that in almost every validation activity computer-aided systems must also be taken into account.

Therefore there is the question of the mode ofprocedure. There are two options:
Computer validation of PLC, process control engineering, etc., is part of the equipment qualification, or the computer-controlled systems are considered in a comprehensive plan only for these systems. This is the option that Novartis in Spain has chosen.
During the course of his talk he then presented a practical example. He then talked aboutthe necessity of verification and possible revalidation of computer systems.

There are two options for this:

1. Time-dependent verification of the system
2. Event-dependent verification

Event-dependent verification is controlled by a suitable change control system which evaluated how extensive the intervention in the process and/or the system is. On the basis of this data a decision is made concerning the necessity of a revalidation.

Dr. Schumacher from Asta Medica then reported on thevalidation of a storage management system. He stressed at the beginning of his talk the advantages of a vendor audit. Here it is absolutely necessary to conscientiously plan, implement and - one must not forget this - also document all steps of such an audit. He named the following seven points as a precondition:

1. Vendor audit
2. Select audit team ( IT, QA, user)
3. Generate specific checklist (contains target, scope, detailed questions)
4. Ask for audit, submit checklist to auditee
5. Carry out audit
6. Write audit report with follow-up activities
7. Evaluate response of auditee
8. Make contract with supplier

In case of a systematic analysis of the existing quality assurance measures one can, provided the suppliers have a good documentation, identify many documents which can be used as part of the validation. He explained that the ISO 9000or Tick IT certification of the supplier is not equivalent to the validation, but:

it is at least an indication of a reliable documentation and the certification increases confidence in the suppliers (fulfilment of the promised qualities)

A critical question is whether testing should take place with "dummy batches" or"real" products. For reasons of safety "dummy batches" (empty bottles) were chosen for this system.

Mr. Wright then described the GAMP Guide in detail. There as on for the development by a group of company representatives and MCA inspectors were considerable losses which various companies had suffered because the FDA had no confidence in the validation of the systems but at the same time it gave no exact indications for implementation. He described the essential documents according to GAMP from the V-model for the computer validation. These are:

- User requirements specification
- Functional specification
- Hardware design specification
- Software design specification
- Software module design specification
- Application software production
- Software module test specification
- Software integration test specification
- Hardware acceptance test specification
- System acceptance test specification

Mr. Wright explained that GAMP is not a standardbut a guideline. In his opinion the advantages are inter alia lower validation costs owing to better management of the validation activities as well as the widespread acceptance. Not only the MCA inspectors but the FDA has commented on GAMP on several occasions. Basedon these positive experiences a 4.0 version is to be worked on until 2001.
Dr. Gill of Tanvec then held the talk "Computer validation: a value added process". According to his opinion, the test phase is probably the most cost-intensive part of the validation. The following may be given as reasons by way ofexample.

• The tests were repeated in the commissioning, computervalidation and the equipment validation (e.g. PLCs).
• Poor documentation generally leads to poor testimplementation.
• Too much data is recorded that is not needed at allfor the validation.
• The approval list is so extensive that coordination isvery time- and therefore cost-intensive.

This and a number of other reasons illustrate that an extensive planning as, for instance, defined in GAMP is necessary since otherwise activities are performed which are neither useful nor necessary.

The conference made clear that the inputs for validating DP systems is enormous. The requirements increase and there is no end in sight, even as regards the validation of oldsystems.

Author: Oliver Schmidt, Concept Heidelberg