I'd appreciate any guidance that could be offered with regard to the onus for validation on a Pharma company who utilises Software as a Service (SaaS) or Commercial Off-the Shelf (COTS) solutions.
I'm trying to establish guidelines within our organisation for the various teams who opt to use these routes, rather than have their systems custom-built by our internal IT function. However, we have differing views internally as to the extent of validation that should lie with our user/business function.
In the traditional model, our users would document their requirements, a bespoke system would be created and tested by the IT function, before being subject to UAT and release into production. The whole process would follow a validation lifecycle process, with the business users and IT function fulfilling their respective roles in that lifecycle. As end users, our approach to UAT would be risk-based, but we would never take the IT function's claim that "the system is ready for production" at face value - especially on a GxP, critical system. We would conduct UAT to some degree and post-go-live, we would follow the same approach with changes to the system - whether these are bug-fixes, or enhancements.
But in this new era of SaaS and COTS, what should our approach be? Why is there an apparent mind-set that all we need to test is how a system is "configured"? We would never trust our own internal IT function in this way, over whom we have more control and insight, so why should we trust some external vendor more? (In all this I am not suggesting that we functionally retest a system in the way system testing by IT is conducted - but rather, the risk-based testing from the user perspective)
I recognise that when we follow the SaaS model, we have to be robust in our vendor selection and that we effectively hand over the IT delivery to an external partner. But in this arena, the vendor will be attempting to provide a solution that will tempt many customers - thus, the system may be enhanced more often than an internally developed, bespoke system. Similarly, with a COTS solution - new features will be released in an effort to keep the system current and marketable.
With these things in mind then, how should we scope our validation and testing on the business side of this model? As end users, should we be ignoring the fact that the IT provider is external as opposed to internal? i.e. should we approach re-validation from our end-user perspective as we would with an internally developed system? And what if we are not intending to use the new functionality? Should we accept a system version containing functionality that we have not tested, especially as we may decide to adopt it at some future point?
I have had people say to me "we are buying a product", so when a vendor introduces enhancements and bug-fixes to a system we should accept them as is. Another arguments made to me is - "well, the solution is in general use by other companies". But, I struggle with this, as I know in two cases last year where we were the first customer to use a SaaS and COTS solution, which to me elevated the risk. And, if something fails with any system, I cannot see this argument about general use holding any weight with a regulatory body as we are ultimately responsible for any system we decide to use.
Your recommendations appreciated!