CSV 2024 - Definition of Verification

I received a note from a follower on my post last month on the use of GAMP V Edition 2 for CSV in 2024 related to Verification?. I would like to expand on what I have referred to as “Verification” as this is defined in Gamp V Edition 2.

When carrying out software validation, you typically have a large number of technical and functional requirements for your software. You carry out tests to confirm that the requirements are met.

Verification though differs.

With Verification, you are assuming that something will do what is asked of it, in our example, a tested / validated product. Let me elaborate with an example;

Let’s imagine I have a configurable Randomization and Trial Supply Management System (RTSM). In this tool, I am able to state that a Titration should be decreased when Condition A and Condition B are both true. With a verified solution, I do not need to check that the Titration will decrease - that is validated by the software testing - what I need to verify is that my definition of Condition A and of Condition B are correct and that I have indeed checked a box to decrease titration.

Now, we have 2 methods for this. I can independently verify that the configuration states this OR I can prove through Functional Verification that I achieve the results. Both are valid methods. The complexity of the configuration typically defines whether you go down the first approach or the second as well as the risk if the function fails. In this particular example, I would want to see for myself that titration went up, went down and did not go anywhere in functional tests.

Interactive Review

One of the test methods that I championed back in my Medidata days was the use of Interactive Verification to confirm a configuration. The principle was that you take an auto-generated configuration specification and then use this as 'part of' a walk-through of the functions of a complete solution. As the software that produces the spec is validated, then the system will do what the spec says. The question we are asking is whether that is what is actually wanted.

?A formal interactive walk-through with the requirement owner is the important part with the requirement owner actually operating the system. In?a 21 CFR Part 11 compliant solution, this creates an audit trail of interactive review activity inside the system. There is a well accepted rule that a person that either programs or configures a system should not solely be the person that carries out testing or verification of that system. In our example, the Interactive Reviewer is performing these step, with some support guidance. ?An electronic audit trail is better proof than screenshots IMHO. In GAMP V Ed 2 terms, Interactive Review is a form of Verification.

To record the evidence of the use of an audit trail when performing Interactive Verification, an extract should be prepared. For EDC and eCRF testing, an Archive PDF with audit trail is normally sufficient. It should be (digitally) signed if used as formal CSV test evidence. If you choose not to extract it, and instead use the system itself as proof, then it must be maintained & archived.

Conclusion

The use of verification is a balance risked based approach to ensuring what was asked for in the form of requirements are met. The systems are already validate to perform a set of function, but, are the configuration of the functions actually doing we want. ?I would recommend understanding and applying GAMP V Edition 2 when planning and designing CSV processes within clinical research.