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. Next, I discussed the terminology used by validation professionals to describe those SDLC activities that causes so much agita among IT professionals. And in the last post I explored the scope of computerized systems validation. This final post about why validation is more than just testing focuses on maintaining the validated state in production and demonstrating that the computerized system is in control.
Emphasis on maintaining the validated state
Validation is not a one-time event. Validation is part of the complete life cycle of a computer system that includes planning, specification, programming, testing, commissioning, documentation, operation, monitoring and modifying. Once testing is complete and the computerized system is known to be controlled, it’s important to maintain its validated state during the operational life span of the computerized system. This, of course, is achieved by correctly following the written procedures and maintaining the system.
However, if maintenance or a change is required to a validated system, it must be subject to change control. A change control system should be in place to document all changes to facilities, equipment, processes, or procedures that may have an impact on the product quality. The impact of every change should be evaluated and the extent of re-validation defined and performed.
For example, if you make changes to a computerized system after it has been validated how do you know whether it is operating in a controlled and consistent manner? Without a formal evaluation of the impact of the change and re-validation of the system, you have no way of knowing the answer to this question.
Change control and re-validation only address changes to the computerized system. Another key element of maintaining the validated state of a computerized system is to provide evidence that the written procedures are being followed. In order to do this, you must conduct a periodic review (aka an audit). It is a good practice to undertake an internal audit several times a year to target different processes and procedures each time. While periodic reviews are necessary, they aren’t sufficient, you must also have a Corrective Action and Preventative Action (CAPA) system to manage and fix anything found during an audit.
“If it’s not written down, it didn’t happen.”
The importance of good documentation and record keeping cannot be over emphasized. There is much to say about record keeping and good documentation practices, but I’ll save that for a future blog post.
For now you must recognized that documentation and records demonstrate compliance with requirements, standards, procedures, and regulations. The word I like to use is “evidence” because it puts me in a legal frame of mind months after the activities occurred. In other words, what evidence can you show me that the system that was implemented two years ago was in control at the time of its implementation and maintained in control thereafter. Good records enable you to track all activities and provide a history of those activities.
In Conclusion
While the terminology of computerized systems validation may cause confusion, many aspects of it are “good practice” and incorporated into current methodologies. Its emphasis on demonstrating the system will consistently produce information that meets its specifications is balanced between the development of the system and the operation and maintenance of the system. The concerns of validation are not limited to a technical demonstration that design specifications are met, but include the assessment of vendors, development of procedures, training, change control, and audit – in short, more than just testing.
No comments:
Post a Comment