Validation approach for systems designed to meet international standards

 

The life cycle approach involves systematically defining and implementing activities from the stages of design, understanding of requirements, development, release for use, operation, until system retirement.


FIVE is a company that specializes in the development of full cycle Computerized Systems Validation, and Equipment and Utilities Qualification, meeting all the standards and requirements of the main international regulatory agencies such as ANVISA, FDA and EMA.

Even when an industry chooses to acquire Validation or Qualification document packages are usually partial, and that it is the responsibility of the industry review that was delivered by the supplier and that much of the cycle that is needed to complete the Validation or Qualification, as recommended by regulators, has yet to be developed. In these cases, FIVE also presents itself as a partner of the industry, placing itself at the disposal of the client to assist it in the technical review of documentation provided by the supplier, as well as for completing the Validation or Qualification cycle. Approximately 40% to 50% of all Computerized Systems Validation cycle is focused exactly on the initial and final phases of the process, as shown in below image, for a Category 4 system, according to GAMP5®.

GAMP5® Category 4 system Documents Life Cycle

The Validation Plan dictates the standards, methods and personnel involved to ensure quality through the development life cycle of a system, and establishes the adequacy of their performance. The validation plan should be started at the earliest opportunity, subject to adjustment and updated in subsequent stages of the project.The validation plan size should be proportional to the complexity of the project. All documentation used during the validation work has to be mentioned here, and be subject to revision history records and approvals.
The User Requirements Specification defines clearly and objectively all the necessary requirements that a computerized system must meet and can be used as a contractual document. It is usually prepared by the user, but can be prepared in conjunction with the system manufacturer, being reviewed and approved by the system users involved, and Quality Assurance. When it comes to computer systems already in place in the company (legacy), this document may be prepared in the form of a functional specification to integrate the requirements of users, according to system operation history or even consolidate the improvements that the system must undergo to reduce (or mitigate) the high and medium risks identified in the Risk Analysis.
Risk Management is the main strategy provided by GAMP5 which includes a risk analysis over the impact caused by the system in the process that is being controlled, gathering evidence of implemented controls (or mitigation) and execution of continual risk reviews through the system life cycle until its retirement.
The Functional Specification should define clearly and completely what the computer system does and what functions and facilities should be provided to meet the needs described in the User Requirements. The functional specification is typically produced by a supplier, whether internal or external to the company and should be reviewed and approved by the contractor and may be considered a contractual document.
The Hardware Design document (also known as "Technical Specification") should detail the design and the related technological infrastructure component requirements in which the computer system needs to be installed for use. This document shall include the system's planned and appropriate specifications, covering all components and software that make up the infrastructure. The Hardware Design is based on the technical requirements for the installation and configuration of a computer system, in order to ensure its integrity, security and performance in your testing and operational environments. This document should be referenced in other documents involving the validation project, as well as the strategy and methodology adopted by the company.
The Installation Qualification (IQ) aims to verify and document system installation conditions and if it complies satisfactorily with the requirements previously approved in the technical specification. This protocol should ensure the compatibility of technical components with technical specifications and prove their installation, control possible updates of components and versions of the system, and make sure that all the infrastructure needed to operate the system is qualified. Furthermore, it should prove, at least, the existence of approved procedures for: Operation, Backup and Recovery, Access Control, Change Control, and other applicable.
The Operation Qualification (OQ) aims to reference, verify and document the system operating conditions and if it complies satisfactorily with the predefined requirements for its operation. This protocol must provide proof of compliance with functional specification, assuring the existence of approved procedures for the features with GxP impact, system security and maintenance, checking the compatibility of its components with the functionality to be qualified, enabling the verification of technological capacity and permitting compliance verification with GxP and other technical standards. It demonstrates that the system is working and properly documented through challenges based on risk analysis.
The Performance Qualification (PQ) still aims to reference, verify and document that the computer system, after being installed on production and properly parameterized environment, satisfactorily meets the predefined requirements by the User Requirements Specification and / or Functional Specification. This protocol must provide proof of compliance with user requirements and / or functional specification, confirm the existence of approved procedures for the features with impact on GxP, allow for verification of compliance with the rules of GxP and other technical standards, enabling security management.
The Traceability Matrix establishes the relationship between two or more documents that are developed during the validation process. The Matrix ensures that requirements are met and can be traced to their settings and / or design elements of the system and the test that checks that the requirements have been met. A matrix can also enable greater effectiveness in managing risks, facilitate the assessment of the potential impact of a desired change, and contribute to risk management for a desired change. The Traceability Matrix must be approved and must be integrated into the system life cycle.
The system Final Validation Report should be prepared taking into account the results obtained in the tests applied in the installation qualification, operation and performance. It should also include the regulatory requirements as established in the Validation Plan. From the Validation Report approval on, the system should only undergo to any modification with change control procedures.

Reference: Computerized Systems Validation Guide - GAMP5®

GAMP5® is a guide that has its intellectual rights reserved by ISPE™. Available for purchase at ispe.org