I’m Phil a Quality Specialist, located in Deeside, UK. I’m mainly involved in ISO:9001 2008 quality management but am making a foray into the GAMP validation domain!
I’ve just stumbled across this forum and am impressed by the wealth of information available.
I was very pleased to see this new GAMP 5 section of the forum as I would like to pose a specific question in this area. I hope you can help!
I work for a software house specialising in pharmaceutical regulatory software and we have recently completed a successful program of validation (following GAMP 5 guidance) of our product suite. This seems to have progressed smoothly and has gone down well with our customers.
My question is, having validated our product line itself I am now focussing on our development environment. We are considering a move to an On Demand issue tracking/change control/ approval workflow environment, such as Jira, to manage our pharmaceutical software development. Does anybody have experience on whether this side of things requires validation and to what extent as essentially I guess we are outsourcing an aspect our development records environment?
There is no risk of losing or divulging any of our development source code as that remains on site but I’m thinking about how we could demonstrate compliance to our issue tracking/change control/ approval procedures if the On Demand application containing our development records were suddenly unavailable to us or during a customer audit for any reason.
Any advice or suggestions for those of you with experience in this area would be gratefully received.
Welcome to the forum and good to have you on board. Nice question.
We have done alot of work with software houses developing apps for the regulated sector and the validation of their issue tracker etc has never come into question.
Your issue tracker is just a tool that helps you to manage the development of the software, it doesn’t form part of the product that will be used in the regulated environment so for me this does not need validation as it does not have a direct impact on patient safety or product quality.
Of course this issue tracker needs to be listed in your overall QMS and perhaps in there you can mention that it is on-demand software and details the companies backup and restore policy to add extra reassurance that valuable information will not be lost.
I’ll play “bad cop” to Graham’s “good cop” response.
I would tend towards validation in your case. As you noted, loss of a record could well impact product quality - not directly, but indirectly. If an issue was reported and then lost, there could well be impact - both on product AND to reportable information.
What I always advise is to have a well defined policy for validation driven by a Validation Master Plan. Your decision to validate a particular component would be risk-based with documented rationale.
Interesting point. One thing I’ve noticed from other threads and again demonstrated here is how subjective the GAMP arena can be!
However, I think that elements from both of your suggestions have provided my solution. Grahams recommendation to document the 3rd party’s backup and restore policies in the QMS seems the right approach to take and I had been considering where the best place to document this information would be.
The obvious place is indeed within our validation series of documents, albeit a slimmed down validation package to focus on issue traceability. As such, I’ll take the following approach:
Our validation master plan is well defined to allow for flexibility between validation packages (depending on the type of project) and this is left to the discretion of the validation team. As such, I’ll initiate a new project and add it to our validation register. A risk-based validation package focussing on the 3rd party company’s backup and restore policies as well as any measures we can take internally (I’ll discuss this with IT) can then be performed to document these considerations. That will give me confidence to make the transition to on-demand and hopefully keep an auditor satisfied to boot.
How does that sound? Many thanks for the inspiration both. Great forum!
Sounds like a good plan. If an auditor doesn’t agree, you can at least show you did due diligence in considering it and they can’t (shouldn’t) ping you too badly. They may disagree with your analysis but that’s a better position to be in.
