LESSONS LEARNED FROM IMPLEMENTING THE FDA’s CSA GUIDANCE: PART 1 – PLANNING

After several years of conversation with drug manufacturers and consultants about the state of computer system validation, the FDA issued a draft of the Computer Software Assurance guidance in September 2022. Since that time, I have used this guidance to reduce the effort and cost required to complete two large computer system validation projects. This blog shares some of my findings from these validation efforts and may help you avoid some of the issues that we encountered while implementing this “new way” of verifying computerized systems used in performing GMP functions. After listing the lessons learned during the project execution, it seemed logical to separate them into three areas: planning, executing, and summarizing. This led to three articles, with the first one focused on planning. It describes the lessons learned during the planning stage of the project that help alleviate the growing pains associated with changes made to the tried-and-true validation process that most companies are familiar with.

Lesson 1: Have a thorough understanding of the FDA guidance.

• One of the issues that complicated our verification effort was that several of the vendors, developers, and protocol writers had different understandings of the FDA’s CSA guidance and how it applies to software verification. The guidance did not turn the regulatory landscape into the “wild, wild west,” where all testing can be used in the formal verification validation process. The guidance provides specific information on the FDA’s thoughts about manufacturers’ use of vendor testing, other ad-hoc testing, and electronic data collection to verify the installation and operation of the software. Before taking the project down the CSA road, make sure everyone on the team understands the different requirement categories and the type of testing promoted by the FDA for software verification. Spending time to develop the team’s understanding of the new approach and the guidance’s requirements for verification deliverables is imperative in realizing the increased efficiency of a CSA based software verification effort, as it will eliminate significant rework of unacceptably documented deliverables.

Lesson 2: Create a robust risk assessment and mitigation process.

• It is essential that you identify the amount of rigor needed to verify the various requirements extremely early in the project. Conduct a detailed risk assessment to identify potential risks associated with the software verification, then develop mitigation strategies based on the results to address all identified risks in the most efficient manner possible. This provides a roadmap for what requirements and systems can be verified more efficiently with a CSA-based verification strategy and which high-risk requirements must be verified with a complete set of validation lifecycle deliverables. Include QA and Validation as part of this process to gain their input on the verification decisions to prevent issues with these groups later in the project. Communicating early in a project is crucial for preventing problems and saving time. This approach allows for better coordination and understanding among team members, leading to a more successful project outcome instead of trying to remediate them later. The validation plan should define the risk assessment and mitigation process, or it can reference an SOP or company policy, but it must be in place early and used as a living document and tool to create a path for verifying all software and requirements. Delaying or minimizing this effort will create misunderstandings and conflict during the executing phase of the project!

Lesson 3: Identify a documentation strategy for the project.

• Establish a robust documentation strategy that can handle not only the formal validation files of a standard validation effort but one that can handle records from vendors that may come in several formats, electronic records generated by a multitude of sources, manufacturer’s information, and other data that may be required to complete the validation. The process must include a way to review, approve, store, retrieve, and revise the assortment of documents. This can be quite different from the company’s normal data management system and procedures since it is an integral part of the validation of any GMP system.

Lesson 4: Generate a comprehensive Validation System Project Plan

• The validation plan lists the procedures being used in the validation, including the risk-based approach and document management processes mentioned above. It defines the scope and deliverables of the validation project, identifies responsibilities for the deliverables and the deliverable’s review/approval process, and provides for changes to be made to the project if needed. The validation plan is extremely important on these types of verification efforts, it must clearly define the CSA-based process and help guide team members who are not familiar with the deliverables required when using this type of verification process. The approved plan ensures that operations, IT, engineering, quality, validation, and other relevant stakeholders understand and agree to use the CSA-driven validation process mapped out in the plan. This is especially important because a CSA-based validation effort requires a roadmap that stakeholders familiar with document-driven validations can understand and support. A good validation project plan that defines the CSA-based project verification effort can and will eliminate many meetings and confrontations during the project.

Planning has always been an important and often overlooked phase of a validation project. Implementing the CSA guidance in a validation effort places even more importance on this phase, as many resources on the project will be exposed to a different philosophy of validating software than they have become accustomed to using. The deliverables from the planning phase are the cornerstone for a successful CSA-based validation effort, keeping the resources and deliverables on the right track during each stage of the project execution.