Computer System Validation And FDA Inspections

By Michael Gregor

Often, the FDA comes to inspect your facility for reasons other than your computer system validation (CSV) program. However, because so many of our business processes are governed by electronic systems, the topic of CSV inevitably comes up during the course of an inspection. Because of an increase in the number of federal investigators, they are able to inspect more facilities and dig deeper into areas such as CSV.

The very first item you can prepare is a system inventory list. The list itself should be organized by GxP (e.g. GCP, GLP, or GMP) so you can sort it 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 each and who to call upon during an inspection. Another important piece to include is the location of the CSV 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 not only can help you better prepare for an inspection, but also allocate your resources more effectively for the inspection preparation activities.

The Sops You’ll Need
The second item you should ensure you have in place is governing SOPs. You should have the following SOPs in place for compliance and operational purposes as well as inspection purposes. The first is the CSV SOP. This SOP should outline and detail the validation life cycle. 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 life cycle. 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 life cycle (SDLC) SOP. This SOP should outline the steps needed to perform the SDLC for custom applications and should handshake with the CSV SOP.

The third SOP to have in place is a change control SOP. This SOP should describe the process for controlling both software and hardware in the production environment. Furthermore, it 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, because 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 CSV for their respective systems.

The fourth SOP to have in place is a bug and issue tracking SOP, which 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 this 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 CSV 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 CSV.

A sixth 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, such as if they are shared between regulated and nonregulated 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.

A seventh and final important SOP to have in place is a vendor audit SOP. FDA investigators are asking 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 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 that 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 life cycle (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 CSV program. These SOPs include: disaster recovery, backup and restore, deviation, and documentation management.

Prepare Your Documentation For Review
An important aspect of preparing for inspections is the assembling of critical documentation for review by an investigator. How do you determine what is critical? Well, a good first step is determining what systems 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 one of these documents 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. Second, 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 (i.e. evidence that a test script has met its objectives). A great example of how to capture objective evidence is through screenshots. However, be careful when 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, which 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 its 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 thus 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. This document signifies the system has been released into production. Some important points 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 — 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 CSV program prior to an inspection. Remember to have a system inventory list in place, the proper SOPs in order, 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, don’t discount the possibility they will want to audit your CSV 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 CSV program whether you foresee an inspection or not. Having an efficient CSV 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.

About The Author
Michael Gregor is president of Compliance Gurus Inc., a compliance consulting and software solutions provider. Prior to forming his own company, Michael acquired over 20 years of experience in the FDA-regulated industry. His areas of compliance expertise include: biological, OTC and pharma drugs, cosmetics, dietary supplements, foods, and medical devices.