First, when performing validation, I do not begin by mapping out the user requirements, which are the result of large amounts of research and engineering — initially, I do not have any details or specifics. Also, to write the user requirements before the validation plan goes against the general requirements about working against predefined plans. Instead, I start a project based on a customer's idea and, through discussion and refinement, it becomes clear what the project is about. Up until this point, notes are made with no thought of good manufacturing practice, thereby encouraging free thinking without restrictions or limitations. Once the project objective is defined, it is recommended that the customer obtains a quote for its execution. If a serious supplier with knowledge of the pharmaceutical industry delivers a fixed price offer, they will almost certainly want to see the validation plan because this is where more than 50% of the project's time will be spent; they will want to know what documents they will have to produce. From an economical perspective, this suggests that the validation tasks are more important than the user/customer requirements.
If we turn the 'V' into an 'O', the life cycle consideration might actually work because there would be no additions, deletions or modification, just the newest version of the documents (Figure 3). This would solve the problem of document fragmentation because the documents would always be updated and the latest version consistent with the real life system. Instead of creating a new user requirement specification (URS) in a new V-model, modify the old one and save it as Version 2. Based on the modified URS, it is possible to modify the design so that it mirrors what is actually going to be implemented in the real world. The only problem with the reuse of documentation is the manually performed additions to documents; that is, manual comments and manually performed tests. However, FDA's 21 CFR Part 11 may have found a solution to this. Some years ago, FDA (and prior to that Eudralex) permitted electronic signatures.2,3 Rather than seeing these as a hindrance, perhaps we can actually use them to our benefit. These clauses allow us to move any type of electronic raw data (provided we do it in a validated manner). So, provided we make electronic signatures for any modifications manually added to documents, we could move signatures from one version of a document to another. There are, however, some 'minor' technical obstacles about proving that signatures were not compromised, such as proving that they were moved in a validated manner. However, once they are overcome it should be possible to insert new tests of new requirements in the already established test scenarios. This is also possible with paper-based documentation.
Using an O- instead of the V-model would also be far more logical regarding the life cycle considerations because, unlike V-models, O-models constantly evolve. The O-model enables production to continue with little validation interruption because specific versions of validation documentation are available to support any point in an item's life cycle. The method can also be done using multiple V-models, reusing the same documents as developed in the last V-model in every new one.
Christian Stage is director of QA product development at QAtor, Denmark.
References 1. http://www.ispe.org/Template.cfm?Section=gamp