Prepare your systems for FDA inspection
By Michael J. Gregor
Is your organization ready for an inspection of your Computer System 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 business processes are governed by electronic systems, the topic of computer system 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.
 |
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 computer system 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, Perform-ance 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 one for Software Development Lifecycle (SDLC). 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 that for Change Control. 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 one. 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.
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 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 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 is “objective evidence,” in this case? Objective evidence is evidence that a test script has met its objectives. A great example of how to capture objective evidence is through screenshots. However, be careful where you require screenshots, as you only want those 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 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. The System Release Memo 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, 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.
There is much to consider about your Computer System Validation program prior to an inspection. Remember to have a system inventory list and the proper SOPs in place, and to inspect your critical systems and their documentation prior to an FDA inspection. Again, even though the FDA may be inspecting your facility for other reasons, don’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 thatit would be advantageous 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, allocate resources more effectively and can therefore yield long-term cost savings to your company.
