Skip links

Retrospective Validation: PIC/S and legacy systems

For this edition of Call in for a Coffee we look at topic that is becoming increasingly important for Asia’s Pharmaceutical manufactures in order to upgrade their compliance standards.

How to manage non-validated, but productive computer systems is an area of particular focus for the ASEAN (Association of Southeast Asian Nations) group due to their adoption of PIC/S requirements as a common Good Manufacturing Practice standard as PIC/S requires computer systems to be validated.

As reported in our last edition of Call in for a Coffee, the latest edition of the Good Automated Manufacturing Practice Guide (GAMP5) has been released to provide updated practical help for the validation of computerized systems. For this edition of ‘Call in for a Coffee’ we take a closer look at validating old but still functional GxP computer systems using GAMP5 as a basis to address the increased awareness of manufactures in the region;

Legacy Systems: What are they?

Legacy Systems are any computerized system(s) that are used in a GxP environment that either have not been validated or were validated to a regulatory level now considered insufficient.

Issues with legacy systems are typically that little system documentation may be available, changes may have been made or occurred without following formal change control procedures and there may be little or no verification of the system requirements and specification leading to a unknown status of the system and data integrity.

Often one area of importance with Legacy Systems is a low level of security and maintenance- including the backup and archiving of data. Lastly, but critically for manufactures in the ASEAN region, a lack of funds,  resources and expertise with which to remediate such systems- particularly complex business and transaction systems such as ERP, LIMS and MES has left many manufactures with un-validated legacy  systems.

Benefits: Why should we validate?

The purpose of validation is to ensure and demonstrate fitness for use. This means that documented evidence must exist to support the usage of the system functionality.

Benefits of validation for computerized systems include improved reliability due to the implementation of Good IT Practice. This can lead to decreased operating cost and overall cost of ownership of validated systems. In addition successfully upgrading to and achieving, higher regulatory compliance has resulted in new lucrative markets being available for regional manufactures.

Approach: What to do?

One major barrier to pass when undertaking the validation of legacy systems is to determine and understand how much verification is required- In fact this can be called the ’million dollar’ question of computer validation!.

What is very clear is that the assessment, definition of scope and methodology used requires considerable experience and expertise, particularly for legacy systems as inherently different situations are found with regard to; functionality, system history, operating environment and the documented usage of the system.

However despite this complexity, it is possible to use the powerful concepts detailed in GAMP5 to provide a generalized practical, approach:

1. Determine the scope of the validation

To define exactly what systems and functional areas will be included in the retrospective validation. This should also cover any impact to the regulated companies Quality Management System.

2. GAP Analysis and Risk Assessment

      Gap Analysis:

  • To perform reviews and assessments of the existing system and documentation to determine deficiencies; the following areas should be included;
    • Design documentation
    • Test results
    • Change Control log
    • Issue tracking/maintenance
    • Operating procedures
    • The output of the above analysis should be documented

Risk Assessment:

  • Risk Assessment for retrospective validation should be used to determine which aspects, areas, documentation and functions require verification and the depth of the verification (scope of testing).

3. Responsibilities & Planning

  • A Validation Plan should be produced that documents the activities determined by the assessments above. Importantly the Validation Plan should state who is responsible for completing the activities.

4. Requirements, Specification & Design

  •   After assessment it may be determined that revision of, or new documentation is required to sufficiently detail the requirements and design of the system.
  •  One area of confusion is the belief that such documents should not change, best practice however is that documents must reflect the actual system and use. System documents are ‘live’ and should be up-to-date using typical change control procedure to make required draft, reviews and approvals.

In the case of insufficient or no system documentation being available, a current and up-to-date package should be developed. Minimally this package should state the critical requirements, functional design and any required operating procedures

5. Verification & Reporting

  • Formal verification of the system requirements and functionality is required.
  • It may be that after evaluation, it is determined that the existing documentation does not sufficiently support the productive use of the system.
  • Verification is formal testing of the system to document its fitness for use against the system requirements and design. The Risk Assessment and Gap analysis are used to exactly highlight which functions, areas and requirements need to be verified.
  • Upon completion of the verification activities the results and final approved state of the system should be described in a Validation Report.

6. Maintaining the validated state

  • Importantly once the verification has been completed and approved via Validation Report the system is considered fit for use, however the system must be kept in the validated state.
  • This is managed by applying typical change control and configuration management procedures:
  • Changes should be assessed by considering the impact of the change (Risk Assessment), applying the changes, carrying out any verification required for the change and lastly the change must be documented.

Conclusions & Considerations

The validation of computerized systems is not only a regulatory requirement for all PIC/S countries, but when applied correctly we consider validation is good business sense.

This is due to the negative impact on organizations that may occur from failures in IT systems which are the critical infrastructure of modern business.

The validation approach outlined here is for legacy systems as often these older systems are running operations and managing data to a high degree of performance and reliability.In order to ensure compliance for such systems it is not necessary to replace them with a large investment however the balance between retrospective validation and replacement must be addressed.