Testers and Approvers?
Your Computer System Validation (CSV) project is underway.
Or is it?
The Items checked above, in addition to a few other documents, are key to the success of your CSV project. However, within those items, there are crucial details that can easily be overlooked or oversimplified opening your organization to risk.
Keep in mind the FDA’s general definition of validation is “Establishing documented evidence which provides a high degree of assurance that a Computer System will consistently produce results that meet its predetermined specification and quality attributes.’ Listed below are common mistakes that companies make during their CSV project without being aware they are making them. We’ll go into some detail about each and offer advice on how to avoid making these mistakes on your next CSV project.
In order to save time and/or to get the project started as quickly as possible, some companies will try to get by using a generic validation plan or by taking a minimalistic approach. Your Validation Plan (VP) should reflect CSV best practices based on your Quality Culture. Create your plan based on knowledge of regulatory policies, validation, and technology (i.e. informatics software, instruments, etc.). Your plan should satisfy all regulatory policies and industry best practices (e.g., GAMP). One important tip would be to have the Validation Plan set and approved at the start of the project.
Due to time constraints or availability, a company may add members to the project who lack experience with CSV. The heart of creating and implementing an exceptional validation plan and project is having an experienced team of people who are knowledgeable in regulatory practices, validation, laboratory practices and technology (i.e. instrumentation, informatics software, etc.). Furthermore, depending on the size and scope of your project, the number of team members is crucial. You want to ensure that you have the correct number of individuals on your team so no one has too much on their plate and you have the needed subject matter experts to fill any gaps.
You may have a sufficient number of the correct individuals on your team but unfortunately, this project may not be their priority. One of the keys to a successful CSV project is not only time/resource availability but that team members have the CSV project designated as one of their main priorities. Having a plan in place that lays out tasks for each team member and the approximate time needed to complete the tasks will also be critical to success. Distributing the plan and schedule can greatly assist management with determining how much time is needed from individuals and if their normal, daily tasks will need to be reassigned to someone else.
If your test scripts only assess the base system requirements (i.e. vendor executed test scripts), you are likely missing other areas of importance specific to your implementation that need to be tested for the successful validation of your informatics software. If you rely solely on the vendor executed test scripts, they will not reflect your user or system requirements and you will, therefore, not be truly validating your intended use. Your test scripts need to reflect your user and functional requirements.
You’ve spent weeks, possibly even months, working on your validation project and it is just about time to execute your test scripts. But, due to tight deadlines, no time has been budgeted for dry running your scripts. Dry running your test scripts can ensure that the steps make sense, that all of the needed requirements (based on your risk assessment) are tested, and see if there are any bugs in the system. An important tip would be to make sure that when the project schedule is drafted that time is added for the dry running of your test scripts.
This mistake could cause you to fail an FDA audit. Confirm that your documents for your validation project are clear and concise, and that they demonstrate the CSV process which will all help ensure that you pass the audit. As mentioned in point #2, having the right validation team members who have knowledge of regulatory practices will be advantageous in writing and reviewing documents.
Do not waste time on low-value testing activities (e.g., out of the box functionality that has already been tested in OQ). Concentrate on high-risk areas such as configured or custom areas. Your validation efforts should include accurate and informed risk assessments that identify your required test cases and the optimized level of testing for each.
It is clear from the mistakes listed that CSV is complex, time-consuming, costly, and risky. Not properly validating your informatics software can result in:
Fortunately, using the above recommendations and logic can help ensure a successful CSV project.
What mistakes have you made during your CSV project? What is your validation pet peeve?