How can you validate and verify computerized systems for GMP?

Computer system validation is primarily about ensuring systems are fit for intended use. For GxP regulated companies this is required by the regulations, but it also makes good business sense to ensure all computer systems do what they are required to do. Annex 11 states “As part of a risk management system, decisions on the extent of validation and data integrity controls should be based on a justified and documented risk assessment of the computerised system”. It permits a scalable validation process based on risk, so that validation procedures are not overly burdensome. The advantages of introducing computerised systems should not be outweighed or delayed by performing unnecessary amounts of validation.

To validate and verify computerized systems for Good Manufacturing Practice (GMP), it's crucial to first define user requirements, including critical processes and compliance needs. Conducting a risk assessment helps prioritize potential hazards and vulnerabilities. Detailed design specifications for hardware and software are developed based on user requirements. Validation involves ensuring proper installation, operation, and performance through Installation Qualification (IQ), Operational Qualification (OQ), and Performance Qualification (PQ). Implementing data integrity measures, change control, documentation, and periodic review further ensures GMP compliance throughout the system's lifecycle.

In simple terms, computer system validation gives you confidence that the system does what you require it to do. It requires a good understanding of the business process. If you don't know what you want the system to do you can't verify that the system is fit for intended use.

Validation is the evidence that a process or system does what you expect it to do. It proves that the company has a consistent, reliable process in place. In addition to ensuring that any medicinal product produced will be a safe, effective product, validated systems/processes reduce non-compliance events, minimize batch variation and minimize the need for batch rejection. When non-compliant events do occur, the validation data can support the investigation by helping identify where the error was likely to occur.

According to regulatory requirements (FDA 21 CFR Part 11, EU GMP Annex 11, and Annex 15) GxP applications must be validated, and IT infrastructure should be qualified. Validation ensures the application meets organizational requirements and remains suitable throughout its lifecycle. Validation guarantees the application's high quality, reliability, and freedom from defects. Any issues identified during validation are resolved to ensure safe, effective medicinal product production without compromising quality or patient safety. It establishes necessary controls commensurate with the level of risk. Importantly, GxP system validation is integral to ensuring data integrity, maintaining compliance, and upholding pharmaceutical standards.

The User Requirements Specification (URS) is an essential deliverable in computer system validation. It identifies what the users require the system to do and enables verification that the system is fit for intended use. It should not include design or specify how the solution will be developed. It is useful to organise requirements in the order which the functionality is used. For example: - Access control - System setup / Administration - Study set up (if applicable) - Data acquisition - Controls for data integrity (e.g. audit trails) - Calculations / data transformations - Output / reporting This helps with requirements management and subsequent activities including functional risk assessment and testing.

In my experience, CSV spans four key phases: Concept, Project, Operation, and Retirement. Concept: This stage starts with initial requirements and exploring potential solutions. We assess scope, costs, and benefits to decide on proceeding. Project: Here, meticulous planning, supplier assessments, and solution selection occur. It involves specification, configuration, and rigorous verification, leading to system acceptance. Operation: This lengthy phase relies on well-defined, up-to-date operational processes, managed by trained personnel. Retirement: In this final phase, we make important decisions about data migration, retention, or destruction. Throughout, our goal is compliance, optimization, and responsible system operation.

The definition of requirements (user and functional) is certainly important because it supports a good risk-based approach. To me, the system risk assessment that links the requirements to the testing needs (in using risk-based strategy) is key. This is where validation leaders can do a difference and demonstrate that CSV is ensuring compliance with minimal testing and documentation.

The Functional Requirements Specification (FRS) is key to a successful validation and verification of your systems. The FRS outlines the expected observations when going through each of the systems functionality to ensure that the function is performing as intended. As part of the operational qualification (OQ) of the system a defined set of scripts can be used to confirm that the system functioning as expected following the installation qualification(IQ). Once the successful completion of OQ has been achieved real time data and processes can be executed in the system to perform the user acceptance testing or performance qualification (PQ). This completes the validation of the system.

It is important to have the user requirements specification documented to go from there and determine if the asset is according to the intend of use. Thank you Daniela

The challenges I've encountered as a CSV Validation Lead include -complex data migration, when replacing or upgrading systems, migrating data while preserving its integrity and traceability is often a complex and risky process. -ever-changing and evolving requirements, -effective stakeholder communication, -uncontrolled functional changes in SaaS systems, -shortage of CSV expertise, many companies lack personnel with the necessary expertise in CSV across systems and applications. -resource constraints for time-consuming tasks, -tight timelines, -and difficulties validating legacy systems due to outdated documentation and adaptability issues.

In my CSV role, I have tackled various challenges with a well-thought-out plan. Such as, Complex data migration requires a structured plan and validation protocols. Adapting to ever-changing requirements meant establishing robust change control processes. Effective stakeholder communication was essential in fostering collaboration. Controlling unanticipated SaaS system changes involved stringent management procedures. The scarcity of CSV expertise was met with investment in training and hiring experts. Resource constraints were managed by prioritization. Tight timelines were met with realistic scheduling and automation. Validating legacy systems entailed comprehensive testing and considering software modernization.

Some SaaS providers claim their software is fully validated. That unfortunately, is too good to be true. But it is easy to get drawn in especially if the regulated company doesn’t have the knowledge/skills necessary to know that ‘validation’ performed by the SaaS provider does not ensure the system is fit for intended use. Typically, when using SaaS, the regulated company should prepare a validation or test plan which describes how they will leverage the requirements specification and testing performed by the SaaS provider. It should also describe the configuration and user acceptance verification activities that will be performed to ensure the system is fit for intended use.