Congratulations … the new automation system has been successfully validated. Regardless of the validation methodology employed, the Project Team has invested countless hours completing the validation, employing the system into its Operational Phase of a system Life Cycle.
The next big question is …
How is the new system maintained in a manner to ensure it remains in a validated state?
I would like to highlight several processes that I feel will need to be in place and operating well to mantain a validated system.
One doesn’t need to go far within industry publications, such as the Pharmaceutical Online Newsletter, to see repeated articles on the rising trend of computer system validation violations noted in regulatory observations. Concerns are generally expressed regarding the assertion that systems have not been validated to their intended use. This is usually driven by the conclusion of the inspector that system documentation is not sufficient to demonstrate the system is operating as intended.
For systems entered into their Operational Phase the cause of this observation is commonly due to deficiencies in the system documentation package. Two primary documents demonstrating that a system is operating as intended are the User Requirements Specification and the Testing Traceability Matrix. System change control is generally driven by formal procedure, detailing the change, testing required, deliverables, and approvals needed for implementation. Revision of these validation documents can be easily overlooked during the change control process.
Problem / Incident Reporting
The second element to maintaining the validated state of an automation system is a formal and robust problem / incident reporting procedure. The primary focus of such a procedure is to establish a mechanism for reporting and tracking incidents and system problems as they occur.
If the number of incidents or problems reported is on the rise, this may be an early sign of impending system issues. If incident reports are specifically on a repeated issue, this may indicate that there is something wrong with the system operating software, or possibly with the system use procedures.
Generally, the incident/problem report will also include an investigation into the event, usually resulting in some type of mitigation to address the cause of the incident or system problem. This process is closely tied to another area which has seen a rising occurrence on regulatory citations, specifically, the failure to fully investigate an atypical event to determine the root cause of the event and provide suitable corrective actions to address the cause of the incident. Caution should be taken against focusing directly on the incident or problem noted and potentially ignoring the full validated system or process. It is very easy to become narrowly focused on correcting the current incident, then moving on to the next problem analysis and corrective actions. As this cycle continues the eventual outcome may result in a non-compliant system.
The third element to maintaining a validated system is the periodic review and reporting process. The process is intended to provide a review and report on the system performance, generally on an annual basis beginning at the initiation of the operational phase of the validated system.
Periodic review and reporting may have the same construct as the Annual Product Reviews conducted in pharmaceutical manufacturing areas. Key Performance Indicators may be established for areas such as change control implementation, incident and problem reporting and subsequent corrective actions, and system maintenance, to name a few. The reviews should also include a look at System Procedures revisions or updates, and any non-compliance with SOPs (past experience has identified several SOP problems, i.e. User Account Management, Annual Review of System User Accounts, Backup and Restore activities).
The final report should provide details on any adverse findings and provide recommendations and/or agreed corrective actions to address these findings. The report should determine the next review period, and final approval of the report should be reviewed and approved by Management.
An internal audit of the validated automation system can be very effective to demonstrate that the system is being maintained in a validated state and that associated processes and procedures are operating in an efficient manner. This is best accomplished if the Auditor is not part of the user or engineering community, thereby providing a “2nd set of eyes” not familiar with the subject system.
The starting point of the audit should include a request of the Validation Documentation Package listing, and a list of the current system SOPs. Although the intent of the audit is not to review the validation of the system, the documentation list should provide an overall view of the associated documents, including the current revisions and effective dates. Of specific interest, the Quality Assurance Plan Summary report, the current User Requirements Specification(s), and the current Traceability Matrix.
The QAP Summary report should provide the details of the completed validation activities, and establish the starting point for the Operational Phase of the validated automated system. The User Requirements and Traceability Matrix will be needed to verify the change control process and incident and problem reporting process are operating efficiently.
Richard D. Schlabach is a Quality Assurance professional with over 37 years of pharmaceutical industry experience in Quality Assurance, Quality Control, and Validation functions for a wide variety of product categories. Richard’s technical competencies include extensive knowledge of worldwide regulatory requirements; equipment, utility, process, and cleaning validation; specialization in automation validation; compliance auditing and training; and preparation of SOPs and related documentation. He holds Merck certifications as an Automation Auditor, Non-Sterile Product Auditor, Sterile Product Auditor, and API Auditor. He is currently the VP of The Catalyst Group’s QA Division.
Mr. Schlabach can be reached at the following contact information: