The first part of this series introduced the Validation V-Model, an overview of a validation methodology, and compared it to the Waterfall SDLC methodology. And the second part discussed the terminology used by validation professionals to describe those SDLC activities that causes so much agita among IT professionals. This post is about the scope of computerized systems validation – specifically the activities that differentiate it from the SDLC.
Scope of validation
Whether you call it validation, verification, or testing the activities performed in the testing phase of the SDLC generally refer to the dynamic testing of a system by exercising it against its specifications – the system design, functional requirements, and user requirements. However, validation takes a broader view that includes static testing, vendor assessment, development of procedures, training, and the operation of the system in production.
Static testing goes by many names – design review, peer review, code review, inspection, walkthrough. An essential part of the SDLC, static testing is a means of verifying the requirements and design of software without actually exercising the software. It involves a manual review of documents for errors to ensure they are complete, appropriate, and consistent (both internally and with related documents). It is a cost-effective way of building quality into a system because bugs discovered at the early stages of development are less expensive to fix.
When key software, computer systems, or services impacting the user’s product quality are purchased from vendors, the user is still responsible for the overall validation. This aspect of validation involves assessing the vendor to establish assurance that the vendor’s development and delivery processes meet the requirements of the user’s company for quality. Vendor assessment as part of the RFP process may be included in certain methodologies and is an essential part of computerized systems validation when vendor products and services are used.
The development of operational procedures is another key differentiator between the SDLC and CSV. The fundamental purpose of procedures is to ensure operational production processes are properly guided by management, performed in a consistent way, and capture and communicate important related information and data. However, procedures are also part of the internal control system and are used not only to ensure key activities are performed consistently, but also to manage risk and demonstrate compliance.
A well written procedure will manage risk in two ways. First, procedures mitigate risk by describing reasonable measures to prevent foreseeable risks from occurring and how to recover if such a risk occurs. And second, they reduce risk by capturing organizational knowledge to mitigate the loss of key personnel.
Procedures themselves do not demonstrate compliance, but a well-defined and documented process will generate records that demonstrate process capability and demonstrate an effective internal control system and compliance with regulations and standards.
And finally, training is also in the scope of validation. Operating a system in production requires not only that the right equipment be installed correctly and that procedures be written and followed to ensure consistent performance, the employees must also have the skills and knowledge of the operation of the equipment and the procedures. Training involves both basic training on the theory and practice of GMP as well as specific training relative to their role. (For application developers and other IT staff, this requires specific training relative to computerized systems validation.) Training should also be highlighted as part of the change control system. If new equipment or systems are installed or procedures change, then the employees must know how to use it.
Next
Validation is not a one-time event. In the final part of this series, I’ll discuss the maintenance of the validated state of a computerized system and the importance of good record keeping.
No comments:
Post a Comment