Utilizing Scripts in Risk Based Software Validation
Part 4: Where are my scripts?
So now that you have your Process Flows, you’ve done our Risk Assessment, and you’ve defined your Functional Requirements you’re ready for the Installation, Operational and Performance Qualification Protocols (IOPQ). You may be thinking, “But this is an Off-The-Shelf software!” So, shouldn’t there be some scripts already developed that you can use for your software validation? Let’s take a further look at utilizing scripts in risk based software validation.
Sure, there may be scripts that your vendor has, and if you’re using the system the exact same way that your vendor did when they developed the scripts they’re offering you, you can go right ahead and use them. But chances are you’ve changed quite a few things in the software configuration and settings to get the system to work the way you want it to work. You may have changed some screens, added some business rules and maybe even had some ‘custom code’ developed to cater for a specific process or methodology.
If that’s the case, then the canned scripts that your vendor may provide just lost most of their value since now you’re going to need to significantly modify and most likely re-write those scripts to match YOUR use of the system. Not to mention that those scripts most likely refer to sections and functionality of the system that you don’t even use. That’s not to say that those scripts, if available, may not be useful, maybe they will. But you need to consider what you may have to do to them to make them useful and pertinent to the way in which you are using the software and the impact that the software has on your business.
By going through the development of the Process Flows, the development of the User Requirements, the Risk Assessment (RA) using the FMEA and from the RA mitigations the identification of the Functional Requirements, you now have the means to more easily develop the Installation, Operational and Performance Qualification (IOPQ) protocols that you need for YOUR system and the way in which you use it. The task that may have looked like it would be the hardest or most intensive part of the validation, just got a whole bunch easier because you did the upfront work to make it so.
Look at it this way, it’s the “pay now or pay more later decision”. ‘Pay now’ with a detailed risk based FMEA and you save time/money on the back end. Skimping on the understanding of the process flows, the development of the User Requirements and using an FMEA with more general themes and assessment, providing a “validate everything” approach, is the “pay more later” decision and is undoubtedly the more expensive decision in the long run.