via flickr by megapiksel
Never report incidents as ‘Deviations’ during a validation
This is a common mistake encountered during a validation when an error is discovered in the system, method, equipment, software (or whatever item is being validated) is that the incident / error is documented as a ‘Deviation’. I can’t stress this enough…you should NEVER write a deviation during a validation. Only in a single instance would I consider using a deviation during this process which I will discuss as part of this post. This post is relevant if a validation is being performed and for those companies, organizations, and consultants learning about the proper way to perform a validation for a quality perspective.
Case Study of Software Validation: Why deviations are a bad idea during validation
While working for a previous employer during a software validation for a State-run laboratory, I was required to document all errors encountered during the process using a combination of deviation forms and their deviation process. I was unsuccessful in my repeated attempts to explain the Risk involved with capturing all errors within the client’s deviation process. Unfortunately, the EDMS software vendor had some OQ protocols that were poorly written (this incident finally convinced them to improve their quality process) coupled with the client’s strict interpretation of deviations, led to over 100 deviation entries into their production system and 50-75hours worth of downtime processing these records. If I was an inspector, this would definitely raise a red flag. I told them that when they utilize their deviation system (within their live, production process); they will encounter the following:
1) It artificially increases the importance of the encountered errors beyond what they should be for a non-validated system.
2) Adding non-validation systems to the deviation process greatly increases the overall number of deviations within the system.
3) Large delays occur during the validation as the deviations are handled in a time consuming, formal process versus an incident report process.
4) Deviations are a common inquiry and therefore will lead inspectors directly to the validation process for the system which might have otherwise been ignored during the audit/inspection.
5) Questions arise about the system selection process if there are many formal deviations during validation.
6) It greatly increases the cost of the validation project when formal deviations are entered into the system under strict guidelines versus an informal incident process which typically takes less time to process.
Costly Outcome
The overall outcome was a significant delay of the validation process, and a huge cost in terms of employee hours from IT, QA, System Owner, and client personnel involved in testing process. Because of the lengthy and formal deviation process, the number of individuals involved in the process was typically five or more, including myself, System Owner, IT, QA, and the client personnel assisting me (and some meeting that were required to close the deviations). Calculating all the individual’s salary costs and our per hour costs, at least 10K was wasted during this process. Sadly, this might not be the most costly part of the project.
Regulatory Impact
The regulatory impact of entering deviations encountered in the process for non-validated system may be more costly that the immediate monetary impact. As stated earlier, many validations entered into the deviation system will flag that system as a potential problem (even if these are merely validation related errors). Again, deviations always targeted by inspectors from regulated agencies, your regulated customers, and your internal QA audits. The best ways to avoid these issues are to report system errors during validation as ‘Incident Reports’ instead of deviations.
Incident Reports
Incident Reports are segregated from the deviation process. Incident Reports are similar to Deviation Reports where the issue is identified, root cause discovered, and issues documented and resolved. Incident Reports differ in the way these are resolved versus Deviations. Typically, Incident Reports do not require the same level of documentation or formal process to address. Errors encountered as part of the execution of validation testing should always be handled using this method. There is never a need to include this type of issue within the deviation process for a non-validated system. I have yet to be a part of a validation where issues did not occur. In fact, it is not only typical but expected to see many more incidents early on during the validation process when the ‘bugs’ are being worked out of the system. The one exception to handling these issues in Incident Reports would be if there is a need to deviate from the validation process in terms of already approved procedures. For instance, if a different validation method was to be utilized or a new protocol was to be issued during validation, a deviation against the process would be justified. Again, this would best be positioned against the validation procedure, not the specific system being validated.
Segregation of Validation is Vital
Once again I want to stress the importance of keeping your validation documentation separate from your ‘live, production’ system. There is no need to make an auditors life easier by giving them a clear path into your validation process via your deviation system. Equally, you should not spend all the time, money, and effort on performing a proper validation only to have the efforts questioned because of a simply lack of quality process understanding. Keep Incidents Report contained within each validation project and make sure that deviations are NEVER part of your validation process.
If you are interested in how my expertise can contribute to your validation project or company, please contact me at greggsalomon @ yahoo dot com.
Seems to me that your client needs to revisit their development process if they are getting that many errors. My experience is that this is a symptom of rushing into validation before the development of the system is really complete. These kinds of shortcuts usually backfire and add more time to the project.
Thanks for the comment Norm. I agree that too many ‘errors’ can indicate a system that isn’t ready for the production environment. The point for this post is to define the process for handling the ‘errors’. Even a small number of ‘deviations’ can lead an auditor directly into the system validation which might otherwise not have been exposed. My advice is for containment of the validation process as the best method. Bottom line, never utilize deviations where incident reports should be used.