Risk Based Approach to Validation

Posted on Thu, Jan 05, 2012

The GAMP guide provides guidance and examples on the application of the principles and framework of GAMP 5: A Risk-Based Approach to Compliant GxP Computerized Systems to a wide range of systems, from basic instruments to large, complex, distributed control systems.

The main objective of GAMP guide is to ensure that suppliers are more easily able to clarify customer’s objective and hence assure more straightforward cost-effective validation. Five categories are defined with the appropriate validation procedures:

Category 1 – established operating systems for which it is required to record version and control change;
Category 2 – standard instruments, controllers and smart instruments for which configuration and control change procedures should be specified;
Category 3 – standard software for which to validate the application;
Category 4 – configurable software packages – that is, DCS, SCADA and some LIMS systems – running on mature platforms for which it is required to audit the supplier and validate the application;
Category 5 – custom-built systems for which it is required to audit the supplier and validate the complete system.

In essence, the higher the category of software, the higher the risk of the system. Therefore, one must realize that categories can exist in the same time. To mitigate this risk, it is important to identify these categories and to specify them and validate them as required.

Several legacy systems may work satisfactorily, though, this does not exclude them from a prerequisite for validation. The validation exercise for ongoing evaluation of legacy systems should entail inclusion of the systems under all the documentation, records, and procedural requirements associated with a current system.

Download our New White Paper:

Validation - New Principles and Practices

Once a new system is in place, there is frequently a need to migrate legacy data from the old system or systems. Over time, with system upgrades, data in the existing database will need to be converted into a new database structure. Any successful data migration must begin with proper planning.

The purpose of the plan is to accomplish the following:

Define the project scope – what is the target data for migration (e.g., how many years of data, which fields, which dates, coded or not coded, what is the volume, data similarities and differences, etc.)?
Analyze cost and alternatives – Data migration is costly and resource intensive.
Review business processes – the migration team must have a clear understanding of how the conventions for entering the old data differ from conventions of data entry into the new system, as well as differences in how the systems handle the data. This requires both functional and technical analyses.

Although the acquisition of OTS Software requires significantly less effort than in-house software development, the amount of work and management involvement needed should not be underestimated. Detailed requirements gathering and a rigorous selection process would need to be followed.

The standard states that the vendor’s life cycle documentation, such as “testing protocols and results, source code, design specifications, and requirements specifications can be valuable in establishing that the software has been validated”. The standard however states that documentation may not be available from the product vendors as they might not be willing to share proprietary information. The standard suggests a number of practices which could be adopted by the device manufacturers given the lack of available documentation from the vendors.