Software Validation & FDA Inspections

For Life Science Companies

Is your organization ready for an inspection of your Software Validation program? In this article, I will offer some key tips on how to prepare for an inspection of your computer system validation (CSV) program. Often times, the FDA comes to inspect your facility for reasons other than your CSV program. However, because so many of our business processes are governed by electronic systems, the topic of Software Validation inevitably comes up during the course of an inspection. As a result of an increase in federal investigators, investigators are able to inspect more facilities and dig deeper into areas such as Computer System Validation.

As a result of an increase in federal investigators, investigators are able to inspect more facilities and dig deeper into areas such as Software Validation.

The very first item you can prepare is a system inventory list. The list itself should be organized by GxP (GCP, GLP or GMP) so you can sort the list accordingly during an inspection or for analysis purposes. Next, the list should include a system owner for each system so you know who is responsible for the system and who to call upon during an inspection. Another important piece to include is the location of the software validation documentation, as this is not only important from a storage aspect, but also an access point of view. Under everyday operations, one should have easy access to this documentation. During an inspection, it is key to have quick access to such documentation, as investigators do not like to wait too long for documents they request. The last attribute to include in your system inventory list is an indicator of whether or not a system is critical. To determine criticality, it is wise to determine whether or not a system is used for regulated purposes or used to make decisions as they pertain to regulatory requirements. Flagging these can not only help you better prepare for an inspection, but also better allocate your resources more effectively for the inspection preparation activities.

The second item you should ensure you have in place is governing Standard Operating Procedures (SOPs). You should have the following SOPs in place for compliance and operational purposes as well as inspection purposes. The first important SOP to have in place is the Computer System Validation SOP. This SOP should outline and detail the Validation Lifecycle. It should include requirements for key areas such as Intended Use, Validation Master Plan, User and Functional Requirements Specification, System Design Specification, Traceability Matrix, Installation Qualification, Operational Qualification, Performance Qualification, Validation Summary Report, and System Release Memo. Investigators will want to see that you detailed the requirements for all of your deliverables in the Validation Lifecycle. Furthermore, they will look to ensure the deliverables have the right dependencies and are in the correct order.

The second SOP to have in place is the Software Development Lifecycle (SDLC) SOP. This SOP should outline the steps needed to perform the SDLC for custom applications and should handshake with the Computer System Validation SOP.

The third SOP to have in place is a Change Control SOP. The Change Control SOP should describe the process for controlling both software and hardware in the production environment. Furthermore, the SOP should require a Change Control Board that is responsible for reviewing and approving all changes.

It is also important to include a classification of change. For example, there should be three classifications: Minor, Major, and Emergency. Classifying the changes helps manage the change control process more effectively. Assembling a Change Control Board and classifying changes gives inspectors a good sense that your process is in control, as it shows you are well organized when assessing changes. It is notable to mention there are an increasing amount of 483s and Warning Letters for companies failing to exercise change control and perform computer system validation for their respective systems.

The fourth SOP to have in place is a Bug and Issue Tracking SOP. This SOP is becoming increasingly important, as regulators are asking more questions when it comes to how bugs and issues are handled. Therefore, it is important to have a mechanism in the Bug and Issue Tracking SOP to handle whether or not validation is required as a result of fixing a bug or an issue. Investigators often look for this mechanism.

A fifth SOP that is an important aspect of inspections is a Good Documentation Practices SOP. It is very important to have a structure in which to document your evidence of validation activities. Deploying good documentation practices helps ensure the integrity of your computer system validation and change control documentation. Investigators are quick to point out documentation errors when reviewing documentation, therefore, it would be prudent to have a sound Good Documentation Practices SOP in place. Please remember there is a good amount of documentation when it comes to computer system validation. Another SOP to have in place is a Security SOP. This SOP should address physical access to buildings and data centers, networks, and passwords. FDA investigators are inspecting the security of buildings; data centers, and networks more frequently. They are also looking for the inclusion of a password policy in the security SOP or a stand-alone password policy. Furthermore, they are digging deep into data centers. For example, they are asking questions about servers and if they are shared between regulated and non-regulated systems. Investigators like to see dedicated servers to regulated systems; therefore, it would be wise to be careful when using the same server for multiple systems regardless of whether or not virtual environments are used.

One last important SOP to have in place is a vendor audit SOP. FDA investigators are asking more and more questions about the integrity of software vendors and their respective quality systems. Furthermore, investigators are asking to see objective evidence of audits so it is therefore important to document all of your audits as well as any follow-up corrective actions. Training records of software suppliers are being scrutinized, as it is important the FDA knows the people with the right amount of experience and education are involved in the development and implementation of software applications. Investigators are particularly interested in corrective actions, their details and timelines for closure. Therefore, it is important to ensure that corrective actions from audits are monitored for closure in a timely and reasonable manner. Furthermore, it is key to ensure that corrective actions do not carry too much risk. In other words, most companies will move ahead and select a vendor even though there are corrective actions. The point here is to ensure the corrective actions do not carry too much regulatory risk; otherwise, the integrity of the electronic records of the application the software supplier is providing may be compromised.

The vendor audit SOP should include a checklist as an Appendix to the SOP itself. The checklist should be a list of items that are used to evaluate a software supplier. These items include, but are not limited to the following: 21 CFR Part 11 Requirements, Security, Escrow, Software Development Lifecycle (SDLC), Training, and Organization Chart and Personnel Responsibilities. It is important to have the following in your Vendor Audit SOP: Frequency of audits, Audit Team Responsibilities, Corrective Action Details and Timelines, and of course the audit checklist, which should be an Appendix to the SOP. There are other SOPs that are considered to be an important part of any Computer System Validation Program. These SOPs include: Disaster Recovery, Backup and Restore, Deviation, and Documentation Management.

An important aspect of preparing for inspections is to prepare critical documentation for review by an investigator. How do you determine what is critical? Well, a good first step to determining what is critical is to determine what system are used for regulatory purposes or to make decisions as they pertain to regulatory requirements. For example, an obvious application is your Adverse Event Reporting System, which handles Adverse Events that are reported to the FDA.

A Documentation Management System is another example of a critical system, as it is often used to manage and store regulated documents. What validation documents for your critical systems should you be reviewing? There are some documents that are prone to mistakes so I would recommend these types of documents be reviewed first. An example of a document that is error prone is your test scripts. There are two important points to look for here. First, you want to ensure the test scripts are legible and free of errors. Secondly, you want to ensure the test scripts have the appropriate objective evidence attached to them. This is a very important point to bear in mind, as investigators often like to see objective evidence.

What do I mean by objective evidence? Objective evidence is evidence that a test script has met its objectives. A great example of how to capture objective evidence is through screen shots. However, be careful where to require screenshots, as you only want screenshots that prove the test script met its objective. Otherwise, you end up with too many screenshots that do not necessarily prove the test script has met its objectives.

Another important document to review prior to an inspection is your Traceability Matrix. Your Traceability Matrix ensures your intended use of the system has been tested through test scripts that map to a set of approved requirements. Investigators are now reviewing Traceability Matrices to ensure the system is tested effectively against it s system requirements. I encourage the review of this document during the end of your validation efforts and prior to approving the Traceability Matrix. However, it is a good idea to double-check your Trace Matrix before an inspection, as an investigator can find one requirement that was not tested and therefore declare that your system has not been validated per its intended use and therefore is not validated. As you can see, the Trace Matrix is a very important document.

The last document to review before an inspection is your System Release Memo. The System Release Memo signifies the system has been released into production. Some important point s to check here are the dates. It would be advantageous to ensure your signature date of your System Release Memo is after the signature date of your Validation Summary Report. Small items like these are often overlooked by companies, as there is usually a rush to release systems into production and sometimes it happens before the documentation is complete. There is no explanation for errors like these, as it shows you are not following your SOPs and that will be the nature of the 483 observation if an error like this is found by an investigator.

In conclusion, there is much to consider about your Software Validation program prior to an inspection. Remember to have a system inventory list in place, the proper SOPs in place, and to inspect your critical systems and their documentation prior to an FDA inspection. Again, just because the FDA may be inspecting your facility for other reasons, doesn't discount the possibility they will want to audit your Computer System Validation Program. As stated, so many of our respective business processes are carried out by way of electronic systems in this age of technology. Therefore, it would be prudent to assess your Computer Validation Program whether you foresee an inspection or not. Having an efficient Computer System Validation Program in place helps ensure the integrity of your electronic records, allocates resources more effectively and therefore can yield long term cost savings to your company.