The Need and Steps to Perform CSV (Computer System validation)

When a new system is introduced in the GxP area, the category is checked by filling the GxP assessment form. In addition, there are a set of questions answered by the IT team based on the recommendations of the Quality Assurance (QA) team that identifies the category of the computerised system.

Computerised systems that fall under Category-1 and Category-3 need less documentation as these are non-configurable and may not have much impact once these get validated by the subject matter expert (SME). The changes in their hardware and software are done directly by the OEM/Manufacturer after checking all validation aspects. These systems are validated again when a change is done in the system.

We need to pay special attention to the computerised systems that fall under Category-4 or Category-5. These systems are configurable and customisable, which means by doing some change in their logic, systems can be re-designed. This is a very serious thing from a compliance perspective. Any minor changes in the GxP application trigger a requirement to re-validate the process by SME.

In such scenarios, the user requirement specification of the change should be unambiguous. The development changes should be done correctly, and very rigorous testing must be performed. All changes need to be appropriately recorded, and a change control document should be initiated as per the QA’s recommendation.

Small changes in categories 4 & 5 can impact the entire business process and maintain subsequent parameters in these systems. In such scenarios, the need for an audit trail comes into the picture. Audit trail features are now used in almost all computerised systems. If there is an option in the system to activate/deactivate these settings, it should always be activated by default.

When a transaction is performed, the system should be able to generate an audit trail along with the “User ID, Date and Timestamp etc”. This will help identify what has happened in the past with a transaction and who had done it. That’s the reason why one should never share his/her password with anyone if he/she possesses a very critical transaction that may impact or compromise the entire process. This is a serious offence from a “Pharmaceutical” point of view.

When a system impacts the quality of the product directly by maintaining some critical parameters, rigorous testing and documentation are required as per the process flow. There is no hard and fast rule on how many documents one should generate for justifying a process. GAMP 5 provides a set of guidelines one should follow in such circumstances. The organisation should plan a set of documents generated when a new system is introduced and validate the system as per this SOP or policy.

The relevant stakeholder should also check the risks associated with the System. Identification of the risk plays an important role and needs to be addressed before introducing a new system. The list of risks should be prepared and a proper evaluation should be done to see the impact on the computerised system. All risks should be validated, and relevant controls should be activated, or a mechanism should be designed to mitigate the risk if the system is not capable enough to address these anticipated risks. GAMP 5 emphasises on “risk-based approach”. The risks are identified from a compliance perspective and incorporated into the test script and recorded results. During the validation process, we intend to check all the risks areas and document them properly. The testing intends to minimise the impact of the identified risks.

All the documents are assigned a unique number range series and these are linked with each other. This document is called a relational traceability matrix. When all the documents are verified and approved by the QA team along with the various stakeholders, the QA team verifies that the designed functionality does not affect the existing business process. The computerised system is then upgraded, and documents are kept in the custody of the QA department for future usage. A system release certificate is provided to the machine and other IT related compliances such as Data Backup and periodic review schedules are prepared to meet further compliances.