Computer System Validation (CSV) can often feel like a significant speed bump for growing companies looking to transition into the GMP space. It requires resources and considerations that are often not yet taken into account. While this may be more applicable to budding startups, veteran corporations can also find themselves in this situation. In an ideal world, your company has set aside the money, resources, and adequate time to implement a phase-appropriate CSV program in anticipation of any validation needs, but reality is often vastly different. Whether you outsource the responsibility of developing a program to a trusted partner like Assurea or choose to develop your program in-house, there are a few things to consider in order to make the process painless and complete your prerequisites within a tight timeline.

Scope

For the mature company operating in the GxP space, you might have a well-fleshed out and detailed program with supporting work instructions and SOPs.  It’s common to refer to GAMP 5 – often seen as the CSV gospel – for guidelines pertaining to processes and best practices [1].  That being said, it’s a behemoth of a document and far too detailed to follow precisely.  First and foremost, identify an owning entity and define the initial scope of the program.  It’s important to remember that while validation is a regulatory requirement, it’s a framework rather than a specific set of rules.  There is room for continuous improvement in your CSV framework, but it’s recommended to focus on the essentials first and then enact continuous improvement as the company matures.

Computerized Life Cycle

The most important concept within the CSV program is defining your life cycle approach.  At a high-level, this defines all activities from your initial concept to the retirement of a system.  Most commonly, the life cycle consists of four major phases:

  • Concept
    • There exists a business case where the company should consider automating or implementing a computerized system to support a GxP process.
    • What are the requirements for this system?
  • Project
    • Assess the supplier, develop specifications, and define verification activities in order to assess the system’s fitness for use.
  • Operation
    • The validated system is in use and any changes to the system are performed under the company’s change control process.
  • Retirement
    • The validated system is retired and any loose ends are tied up (i.e. potential retention/migration of data)

Ensuring your approach is phase-appropriate.

Just as we want to ensure our computerized systems are fit for purpose, it’s important to ensure our program is also fit for purpose.  A company looking to validate their first computerized system does not need a 100-page program with a whole slew of SOPs and work instructions to follow.  It’s important to focus on what’s necessary to implement your first system.  This means defining your critical deliverables for your concept and project phases based on the criticality and complexity of your system being implemented.  The following is an example of a list of critical deliverables that can be used to validate a GAMP Category 3 or 4 system and are worth defining within a program:

  • System Impact Assessment
    • Categorizing and assessing the GxP impact of the system being implemented.
  • Data Integrity Assessment
    • Assessing a system’s capability to meet data integrity regulations.
  • User Requirements Specification
    • Identifying what the system you are implementing must be capable of
  • Validation Plan
    • Define our system-level approach for validating and releasing a system for GxP use.
  • Risk Assessment
    • Use a risk assessment tool to ensure your deliverables and qualification activities are appropriate based on the risk level of the system being implemented and the purpose it serves.  The risk methodology used is at the discretion of the company.
  • Qualification Protocol/Plan
    • Create test scripts with the intent of generating documented evidence that the system meets the pre-defined requirements
  • Requirements Traceability Matrix
    • Establishes traceability from your qualification testing to your user requirements.
  • Validation Summary Report
    • Summarizes the validation testing and deliverables to document that all pre-requisite deliverables are complete in preparation for GxP release.

This is not a prescriptive list, nor is it exhaustive, but it’s meant to serve as an example of deliverables to focus on defining in your new program.

What can we forego and leave for future improvements?

When developing a phase-appropriate program in a time crunch, it’s valuable to identify what can be done at a later stage.  Again, this is not a situation where we are being non-compliant or foregoing our due diligence, but a way of focusing and prioritizing resources where they are best served to meet the most urgent goals.  Some examples of topics that are best addressed in future iterations of the program:

  • Periodic Review
    • Since we have not validated our first system, we will not have anything to review anytime soon.
  • Validation Templates
    • While it’s valuable to have templates to ensure conformity and standardize documents, it’s oftentimes a luxury that cannot be afforded when under a time crunch and can be established at a future time.
  • Data migration and archival processes
    • While it’s important to maintain control of data regardless of where it lives, this is a topic for after your system is validated and producing data.
  • Retirement
    • Despite being one of the four main phases in a system’s life cycle, one can remain fairly confident that they won’t need to be retiring any systems if they have yet to validate their first system.