Revalidation is part of keeping your system in a validated status. It can be Time-Driven or Event-Driven. It is recommended that a revalidation SOP be generated to cover the determination of the need for, and the documentation requirements of, any revalidation effort.

A full validation effort encompasses a systematic and comprehensive testing of all cGxP screens, fields, functions, error messages, and utilities within a computerised system. In addition, enough functional and stress testing is executed to achieve a level of confidence that the system performs as it was intended, and will continue to do so in the future.

The term “Revalidation” refers to re-execution of some or all of the existing Validation Protocol. That is, revalidation can range from a few simple tests, if a system modification is of low impact to a full validation if time or system impact dictate that necessity, but in either case, the existing Validation Protocol will be executed with few significant changes. This type of re-execution of existing tests is called “Regression Testing”, but here we call it “Revalidation” to highlight the fact that the testing is supplied by the validation protocol and to distinguish the higher level of formalisation and approval necessary for this type of testing versus ordinary Regression Testing.

There are two type of revalidation, distinguished by the manner in which they are initiated: Event-Driven and Time-Driven Revalidation.

Event Driven Revalidation

Your change control SOP should mandate that for each change, (either fix or enhancement), to a validated system some amount of revalidation is required. The extent of revalidation required for each change should be determined by the Project Team or Validation Committee, and must be approved by scope of Quality Assurance. Once the determination has been made, the scope of revalidation for the change in question should then be recorded on the Change Control form, in order to ensure that this needed testing is carried out. Prior to formal upgrade to the system, the Project Team or Validation Committee must review and document the various portions of the system that must be re-tested, and from this determine the extent of revalidation necessary. Their consideration should include:

  • The number of changes since the last validation
  • The time expired since the last full validation
  • The nature and extent of changes to the system

The decision to revalidate, along with the extent of revalidation required, must be determined by the entire Project Team/Validation Committee and must be documented in the Scope and Justification section of the Revalidation Protocol.

[polldaddy poll=”6721814″]

Time Driven Revalidation

Your SOP on Revalidation should state that if a computerised system receives no modifications or enhancements for the period of two years and therefore, no validation/revalidation has taken place during that time period, then QA shall initiate a time-driven revalidation to ensure the integrity and reliability of the system. Time-driven revalidation should be handled as a full validation, in compliance with current industry and regulatory standards. The reason why this is needed is that the integrity of your validated system could be compromised without you even knowing it.

For example, take a system that had been validated and only one minor change (handled by Change Control) was made to it for several years. When it was revalidated using the same Validation Protocol, some of the tests that passed before were not passing, but it was very strange as sometimes the tests did pass, and then a little later sometimes the tests did not pass.

Investigation identified that RF interference from cell phones in use on the warehouse floor was interfering with the signals of the scanners that were used for reading product and location bar codes. When the warehouse system was first validated, the average cost of a cell phone was $3,000, and not many were in use. Several years later, the size and cost of cell phones had come down to the point where employees were starting to carry them around. Once the problem was found, a policy was installed to prohibit cell phone use inside the building and the problem went away. However, it might never have been found if revalidation had not highlighted it.

Revalidation is also a great opportunity to resolve all the little non-compliances that have been identified in your current validation effort. Since you don’t have to create a whole barrage of new tests, you can afford to spend some time to beef-up your existing tests or ensure that important procedural practices are followed carefully.

Conclusion

Overall revalidation should be performed on a periodic basis to ensure all of your computer systems are working accurately and as intended within your operating environment. The cost involved is minimal compared to the cost that might be incurred to patient safety if your systems go out of control and out of compliance.