In highly regulated systems environments, it is well understood that software errors can have catastrophic results on regulatory controlled processes if the applications are not properly designed, tested and implemented. While much focus is given to validation testing, governance of the validation process is often overlooked.
Software validation is a process. It is often mandated by regulatory requirements to ensure that mission-critical software applications perform according to their intended use. In highly regulated systems environments, it is well understood that software errors can have catastrophic results on regulatory controlled processes if the applications are not properly designed, tested and implemented. While much focus is given to validation testing, governance of the validation process is often overlooked.
All regulatory processes are governed by standard operating procedures (SOPs) to ensure quality and compliance. In a recent warning letter, a medical device company was cited for 21 CFR Part 11 violations and for the lack of an adequate quality system. These violations resulted in a 21-item 483 warning letter from the FDA. In response to the warning letter, the company stated: "We are in the process of evaluating software validation SOPs with protocols and procedures for validation”. Failure to document and follow validation SOPs could result in warning letters or risk compromising the entire validation effort.
The first step prior to conducting a validation exercise is to have adequate quality procedures in place documented by your company’s SOPs. I am often asked the question, “…which SOPs do I need for software validation and verification…?” The table below highlights the minimum SOPs you need for software validation.
The main SOP you will need is the Non-Product Computer Systems Validation SOP. This is the SOP that provides governance for the entire validation process. This SOP should include key definitions used throughout the validation process within your company, responsible personnel within your process and detailed procedures for each validation lifecycle stage. The figure below illustrates a typical validation process.
During the validation planning phase, it is important to assess the state of your SOPs to ensure that your process is documented across all validation lifecycle stages. GAMP 5 recommends a risk-based approach to software validation, thus it is important to have a risk assessment SOP in place for governance during software validation. Your risk assessment SOP should highlight our risk methodology, documentation requirements and processes. Remember, “… if it is not documented, it did not happen…” therefore a written risk assessment is a key element of your overall quality program. It is recommended that an SOP be in place covering this vital element of validation.
One SOP that is often overlooked is the data migration SOP. Working with many enterprise systems such as Enterprise Resource Planning (ERP), Enterprise Content Management (ECM), and many others data migration is an essential factor during installation and deployment. If a system is validated and requires migration of data (mandated by predicate rules) to be transferred from one system to another, your migration SOP should define the overall process required for validation. When deploying new systems, many IT professionals simply move/transition data from one system to another without confirming the accuracy and validity of this process during validation. If the migrated data is subject to predicate rule requirements, you may want to document in your SOP that this information must be migrated in a specific controlled manner. Best practices for migration during validation require the development of a migration plan, migration test protocols, and acceptance testing to a specific confidence interval. It is important to have a migration SOP in place to ensure accuracy and quality when transitioning from one system to another.
Another important SOP to remember is the Custom Software Development SOP. Many times, when deploying enterprise software applications, customization (programming) is required to meet your specific company requirements. Your Custom Software Development SOP must define the full software development lifecycle stages and required documentation and controls for managing custom code. This is a significant area of vulnerability during the validation process and must be clearly defined to ensure the quality and integrity of your enterprise deployments. Things to remember if you are customizing code for validated systems are:
* Ensure that programmers are properly trained * Start with a clearly defined set of user requirements (this must be clearly outlined in your SOP * Separate the development and testing functions (clearly spell this out in your SOP) * Code must be under strict change control (you need to define the process for this in your SOP) * Clearly define your software development lifecycle methodology (failure to do this may compromise the custom aspects of your validated system) * Conduct vendor audit if software development is outsourced (make sure your vendor follows your internal software development best practices.) * DOCUMENT EVERYTHING (your SOP should define all documentation requirements for customized systems)Finally, you should always have a disaster recovery SOP. This SOP provides governance for processes in case of any type of disaster which may impact your validated system. Many people confuse disaster recovery with backup and recovery. The two are very different. Disaster recovery procedures kick in when you have any type of natural or man-made disaster such as a flood, fire or other such event that results in the loss of the entire system. The disaster recovery policy should provide procedures that clearly state and categorize the type of disaster, key personnel and their detailed contact information, and more importantly specific detailed procedures to recover the system in case of a disaster event. Many times, a disaster recovery policy is developed at the corporate level for validated systems. You should check to see if your company has such a policy and reference it with your validation package. If you do not have one, it is highly recommended that you develop one for software validation. This is good best practice.
In contrast, back up and recovery procedures provide governance over routine system administration tasks related to daily, incremental, and full backups for the validated system during the production phase (after the initial validation exercise). Backup and recovery happens routinely – not as a result of a disaster event. Things you should make your IT team aware of for backup and recovery of validated systems are:
* Restoration of the system must be fully documented (IT cannot simply “restore” a validated system)
* All Backup and Recovery activities and system logs must be documented and kept as part of the validated systems package
* If you have a Test system that mirrors the production environment, all patches must be tested in this environment before they are applied to the production environment.
* DOCUMENT EVERYTHING!The other SOPs referenced above (incident management, backup and recovery, et al) are typical in most companies that conduct software validation. These SOPs provide critical governance to ensure that you have a fully documented validation process that can withstand the scrutiny of an audit. Beyond compliance objectives, having good governance in place makes good business sense. These SOPs help you avoid common errors as well as save you time and money. Good governance for software validation is documented through your SOPs. How is good is your validation governance?