Traditionally, validation focuses on validating something, such as a piece of equipment, a computer system, a process, and so on. It generates a lot of documentation (e.g., VP, IQ, OQ, PQ, RTM). Then the validation package is filed away, typically only pulled during an audit.
The problem is that the same things are continually recreated. Inconsistencies arise, and valuable information is lost in the paper pile. However, if you objectify your validation you can reuse elements; this delivers consistency and maximizes efficiency.
How do you objectify validation? First, change the way you think. Rather than validating a thing, think of the logical groups of things you validate. For example, consider an autoclave. How similar are validation packages for your autoclaves? No doubt very similar. In fact, if there are differences, ask yourself, "Why?" Maybe there is a good reason, or maybe not. Most likely, requirements are similar. Also, similarities with risk assessments probably exist. Risk drives rigor; therefore, qualification tests are probably similar. Why not create objects of similar things that can be reused? Now you’re getting the concept of objectification.
Technology to the Rescue
Traditional paper-based validation is limited. Although you can standardize on requirements, risk assessments, and qualification scripts for like entities, it doesn’t deliver maximum benefit for paper-based validations.
The ValGenesis validation lifecycle management system (VLMS) has capitalized on delivering functionality to support object-oriented validation. Here you can create requirements as objects, and these can be shared. Furthermore, you can perform risk assessments on the requirements, thus driving the rigor of qualification testing. Next, you can develop similar qualification tests. In effect, you’re building a library of objects that can be assembled to form a validation package.
Libraries of Objects Drive Consistency and Efficiency
In the example above, we discussed autoclaves, but objects can be created for logical groupings of entities. Validating computer systems have similarities. Take, for example, 21 CFR Part 11 requirements. They’re the same. Why not develop Part 11 requirements that can be used for all computer system validation activities?
If you create objects, you can then build a library of objects that can be pulled to develop validation deliverables (requirements, test scripts, and so on). In a VLMS, this is done through test functions. You can develop test functions for equipment, computer systems, instruments, processes, and more.
When initiating validation, you simply compile all the objects together, and voilà, you’ve just assembled 50% to 80% of your validation package, depending upon how many objects you’ve developed.
A rudimentary form of objectifying validation is being done when you copy and edit documents from prior validation packages. By leveraging technology, you can formalize this practice by creating objects that can be assembled together to comprise a validation package.
Please contact us to learn how other life sciences companies are taking advantage of an object-oriented validation practice.
ValGenesis functionality supports object-oriented validation, allowing you to create requirements as objects that can be shared.
Steve Thompson has worked in Life Sciences for over two decades in both Information Technology and Quality Assurance roles. He’s a certified systems auditor and has audited hundreds of companies globally. A published author, a frequent speaker at industry conferences, on the Board as a Director for PRCSQA, Editorial Advisory Board for ISPE, and Elite Faculty member for KENX, and Adjunct Lecturer, Temple University, School of Pharmacy, RA/QA Graduate Program. He was honored with an APEX 2020 award of excellence for a peer-reviewed article he co-authored for Pharmaceutical Engineering on Blockchain. Currently, as Director Industry Solutions at ValGenesis, Steve helps Life Science organizations realize the potential benefits of advanced technologies, along with inherent risks.