How do you manage the validation lifecycle of a computer system from inception to retirement?

It is important to understand and update the system Validation lifecycle documents with current Business requirements, regulatory expectations and technology limitations.

Managing the validation lifecycle of a computer system from inception to retirement involves a structured approach that ensures the system meets all regulatory requirements, industry standards, and user needs throughout its operational life. The lifecycle typically follows a series of phases, each with specific activities and deliverables. Like Planning Phase, Specification Phase, Vendor Selection and Qualification, Design and Development Phase, IQ/OQ/PQ, System Release, Operational Phase, Revalidation, Decommissioning and Retirement Phase. Throughout the lifecycle, it's essential to maintain thorough documentation, including validation plans, specifications, test protocols, test results, and reports.

It may not be necessary to prepare a Validation Plan for each computer system validation project if the approach to computer systems validation is described in a standard operating procedure (SOP). A Computer System Validation SOP can replace the Validation Plan when it defines the activities to be performed, the deliverables to be produced and the responsibilities for these activities.

Considering that systems are used for a many years, strategy should include ways to make the operational phase easier. If the system design caters for easy maintenance and change control, the business will find it easy to update the process as and when required and reduce time to go live of changes during.the maintenance phase.

It is indeed important to understand the business requirements for any system in early phase and align them with validation lifecycle. Companies has different approach and expectations for validation and hence its important that requirement gathering and validation approach gets defined for smoother execution of the project.

Requirements should include information security aspects to have a secured system. Information and cyber security has gained high prominence and it's imperative that cybersecurity SME is also involved in the requirements gathering phase itself.

“If a man knows not to which port he sails, no wind is favorable.” – Seneca the Younger There are various ways of specifying a solution, but the most important aspect is to do it. No matter how you call or structure it, the specification is the foundation of all steps to follow. Focus more on the overall purpose instead of getting lost in details.

GAMP 5 2nd Edition has combined the appendices for URS and FS into Appendix D1 - Specifying Requirements. The Requirements Specification (RS) 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. I agree with the use of User Stories as requirements with associated Acceptance Criteria, preferably in Given, When, Then format as the basis of testing. The use of 'living' requirements is fine as long as all the requirements associated with the system at the time of release is specified. Hence the concept of a requirements specification is still appropriate.

Document user, functional, and design specifications. 1. Gathering Requirements—Collect all system requirements, including user, functional, and regulatory requirements. 2. Perform a risk assessment based on the above requirements and intended use. 3. Design: Develop detailed design specifications based on the requirements. 4. In an orderly fashion, get the documents developed during the specification phase reviewed and approved by all relevant stakeholders. 4. Record the traceability from the requirements to the Functional and Design Specifications. By nailing the specification phase, you set a solid foundation for the rest of the validation process, ensuring the system meets all necessary criteria and functions as expected.

In my professional experience, shifting from traditional URS and FRS documents to a user-story approach offers more agility and responsiveness. User stories are “living” requirements that adapt to real-world feedback and changing needs. This dynamism allows my team and me to pivot easily, ensuring that the final system remains aligned with both user expectations and business objectives. Acceptance criteria and test cases become integrated parts of the user stories, simplifying management and allowing for continual refinement. Overall, a user-story framework is a highly effective, user-centric method for managing project requirements in fast-paced, evolving industries like Life Sciences.

In my 25 years in Life Sciences and computerized systems, I’ve shifted from traditional ‘validation’ to a focus on software quality, configuration, and user acceptance testing (UAT). The Configuration Specification (CS) document, for instance, is no longer a static checklist but a dynamic tool tailored to user needs and environmental factors. Installation Qualification (IQ) is also elevated, aligning with best practices in software quality assurance. The most significant transformation is the centrality of UAT in Operational and Performance Qualifications. It’s not just about compliance; it’s about exceeding user expectations. This approach mirrors the user-centric, agile world we’re in today, setting a new standard for system development.

From the FDA's own guidance on software validation: For many years, both FDA and regulated industry have attempted to understand and define software validation within the context of process validation terminology. For example, industry documents and other FDA validation guidance sometimes describe user site software validation in terms of installation qualification (IQ), operational qualification (OQ) and performance qualification (PQ). While IQ/OQ/PQ terminology has served its purpose well and is one of many legitimate ways to organize software validation tasks at the user site, this terminology may not be well understood among many software professionals, and it is not used elsewhere in this document. It's OK to use good IT practices.

Focus on quality, not compliance. Keep in mind that testing cannot achieve quality, it can only help to measure the level of quality of your component, application, or system. Achieving quality is a holistic and collaborative task. Apply a risk-based approach and critical thinking, and at least for complex components, start with a test design. This will guide you for all further steps of test specification, execution, etc.

Implementation Build or configure the system according to the design specs. Testing A variety of tests can be performed during the testing phase. 1. The traditional Installation Qualification (IQ), Operational Qualification (OQ), and Performance Qualification (PQ) to ensure the system works as intended. 2. IQ and UAT 3. IQ and FAT 4. Other Each of the above depends on the type of software, as applicable. A summary is required at the end of the testing to account for errors, resolve errors, and provide testing results.

Je ne suis pas s?r que DQ IQ OQ PQ soit adaptées aux logiciels elle est plus adaptées aux équipements infrastructures et utilités.. Mais on peut l'adapter à l'informatique. Dans ce cas la qualification opérationnelle et de performance se font dans l'environnement de validation avec les données de production si possible.

A clear periodic review schedule should be part of this phase to ensure that the system operates per its intended use. The periodic review should include all SW upgrades, patches, bug fixes, deviations, IT tickets, etc...

GAMP 5 outlines five software development life cycle (SDLC) phases: Concept, Project, Operation, Retirement, and Phase-Out. These stages ensure a comprehensive approach to software validation throughout its life cycle.

I concur that the implementation and operation phase is crucial for system deployment and security. However, my perspective emphasizes that today’s focus should extend beyond traditional guidelines to understand system boundaries and data classification. Compliance is non-negotiable, but a dynamic approach is needed. Not all data needs stringent control; some can be more flexible. These ‘docs’ System Release Note (SRN), System User Manual (SUM), and System Maintenance Manual (SMM) can vary greatly depending on vendor and SaaS and Managed service providers models. These documents must go beyond ‘how-to’ guides to explain the ‘why,’ aligning users and decision-makers with the system’s intended use. This approach reduces risks overall.

In the context of GxP applications, the operational phase is the longest and most critical stage. To maintain compliance, a well-established framework of controls and procedures is essential. This phase can span many years and involves continuous adaptation to evolving services, software, hardware, business processes, and regulatory requirements. Data integrity is most important and should undergo routine verification through periodic reviews to ensure ongoing compliance with GxP guidelines

Il est important de faire une étape de validation lors de la mise en oeuvre en environnement de production. Malheureusement pour les logiciels métiers configurables souvent des configuration particulières aux clients ne sont pas présents dans l'environnement de dev et sont causes d'erreurs en production qui nécessite patch et autre correction de bug.

I’ve found the separate VR, VSR, and VAR documents often add confusion rather than clarity. I advocate for a more streamlined approach using standard IT controls and proper change controls, which I believe offer more direct insights into system compliance and performance. While these traditional reports are in place mainly for regulatory and external audit requirements, I think there’s room for improvement. The key is to balance compliance needs with efficiency. My recommendation is to strategically redesign the review and audit phase (which never existed in GAMP separately), integrating standard IT and change controls. This way, we could still meet regulatory obligations but do so in a more effective and less confusing manner.

This is the phase that is sometimes forgotten. Look, it's an imperfect world. No matter how robust your validation testing was, there will always be scenarios or variables that were not considered. Don't try to figure out whose miss it was. Just address the gap and improve the system.

One of the most important steps in keep a computer system validated is the way updates and patch management is handled. Through revision notes, it is assessed what details in the change requests are necessary. The CR will identify risks, mitigation and implementation strategies needed after a thorough gap-analysis.

As a system is formally onboarded it should formally come offline, best initiated by change control. A Retirement Plan will define the roles/responsibilities associated with process including internal /external contributing parties. Consideration will include software uninstall, relinquishing of licenses & decommissioning associated hardware. Record retention & destruction requirements for historic data/records will be a major part. If data is being transferred from one system to another, data modelling & batch upload, verification mechanisms needed. If data is being retained without original software, it should be in a format that provides original context when reviewed including user detail, date stamps and critical audit trail details.

There are many reasons for retiring a system, including -system maintenance issues, -major business process changes, -the availability of a better system for the same function, and -the current system's inability to fulfil regulatory requirements. During the retirement phase, the system is removed from active operation, which means normal operational users are deactivated, and interfaces are disabled. No data is added to the system from this point onwards. A proper retirement plan should be in place, and a risk assessment should be performed to ensure compliance

The retirement or decommissioning phase is much critical as per regulatory/ quality point of view, how we handle the migration / data back up and what is the data archival / rotation philosophy etc.

CSA looks nice at first glance. However, it promises to resolve or avoid issues with CSV that you should not have in the first place - if you follow a risk-based, agile, and quality-focused CSV strategy.

Understanding software engineering, software quality assurance, and risk management are key elements to performing comprehensive software implementation and maintenance. One size does not fit all.

Validation is a tool that helps prove that the system (technology, people, process) is fit for use and fit-for-purpose and stays that way. The risk-based lifecycle approach is key. Never confuse a tool with the desired results.

One thing I've found helpful is to think about computer system validation in terms of the entire computerised system life cycle rather than a validation lifecycle. I suggest it helps focus the attention on the system rather than the validation. Ultimately computer system validation is about ensuring the computerised system is fit for intended use and the validated status is maintained until the system is retired. In the past too much attention was given to a nice set of validation documentation. While records of the validation are important, what matters most is that the system is fit for intended use.

In my experience having a well defined, lean / risk based and regulations complain SDLC process is the key to keep GxP systems in control and fit for intended use. Tools, of cause, can help, but if the process is not lean, making it digital can also add unnecessary complexity.