European Conference on Computer Validation - Conference Review -

GMP-News Nr. 41

GMP-News


Conference Review

European Conference on Computervalidation

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 the existing 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 of Computerised 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 the draft, 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 is responsible for submitting a new draft. Ms. Hamilton explained that the new PIC draft will contain 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 requirements for 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 she listed 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 of DP suppliers.

He then described which documents for computer validation an inspector expects. The first document he mentioned was the validation master plan with general information including time-table, responsibilities, references to SOPs, format of the validation plans and protocols as well as acceptance criteria. As special requirements he mentioned the five GAMP 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 the state of development of the system.

Category 5, for instance, requires "customer-specific systems" (i.e. systems written especially for a certain customer) that these systems are to be validated and the software 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 the above 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 of 1998 requires the subsequent elaboration of user requirements here. Dr. Schumacher questioned whether this demand is of any use. He appealed therefore for this item to be deleted when the draft is revised.
From the GMP Trends and the Gold Sheet he cited findings of MCA and FDA inspectors as listed below:

Observations of FDA and MCA during Inspections

  • 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 documents from 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 since these 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. Gill pointed 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 suppliers of the systems be included in the risk analysis. Care should be taken, however, that the team does not contain more than five persons. As regards the criteria of the risk analysis he explained that at first the regulatory requirements must be recorded which exist for a function, e.g. electronic signature or access protection. In addition, the frequency of use (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 impact within the meaning of drug safety)

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

  • Another topic which is currently being very strongly discussed was presented by Dr. Werling from Propack data: "Electronic Signature and Electronic Records".
    Dr. Werling presented the requirements for electronic batch protocols according to 21 CFR Part 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

     

    Requirement System-oriented Concept
    Exact reproduction of a Master Production Procedure Electronic Form
    For each significant processing step:
    • Date and time of activities
    • Identification of Equipment, container, Batches of components
    • Batches of in-process material
    • Identification of operators, controllers and those responsible
    • System generated time stamp
    • Barcode-guided collection of objects with direct transmission into the batch protocol electronic signature

    Requirement

    System-oriented Concept
    For each significant processing step (cont.):
    • Control results
    • In-process controls
    • Verification of packaging and labelling zones
    • Checking lables
    • Material accounting (current and Theoretical quantities, unit of Quantities weight
    • Information regarding collected random samples and/or samples
    • Recording of special problems
    • Electronic checklists
    • System-supported SOP managment
    • Direct download from order data
    • on-line connection to scales/periphery
    • System supported random sample identification and management
    • Electronic log book, eventually mandatory comments
    He then described the two electronic signature methods:

    - 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 currently used 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 smart card.

    The validation of pharmaceutical equipment and in that context the special aspect of computer 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.

        Manufacturing Equipment   Analytical Equipment    
      Cleaning Procedures   Computerised Systems   Calibration  
    Manufacturing Processes   Clean Steam Generation   Compressed Air   Analytical Methods
     

    PW Systeme

          HVAC  
    Therefore there is the question of the mode of procedure. 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 about the 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 the validation 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 9000 or 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. The reason 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 standard but 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. Based on 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 of example.
  • The tests were repeated in the commissioning, computer validation and the equipment validation (e.g. PLCs).
  • Poor documentation generally leads to poor test implementation.
  • Too much data is recorded that is not needed at all for the validation.
  • The approval list is so extensive that coordination is very 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 old systems.

    Author: Oliver Schmidt, Concept Heidelberg

    Cookies help us in providing our services. By using our services, you agree that we use cookies. Further information

    OK

    Go back

    GMP Conferences by Topics

    Cookies help us in providing our services. By using our services, you agree that we use cookies. Further information

    OK