I think the GAMP 5 forum is the best place to post this query as it relates specifically to risk assessment following the GAMP guidelines.
When validating software that falls under the GAMP category 4 (configurable) and category 5 (custom) classifications, there is an increased emphasis to assess risk from the business process perspective.
To what extent can a software designer be expected to make decisions on business process criticality if they are not subject matter experts in the field for which the software is being designed?
If it is not obvious from the user requirements which areas a customer may deem more critical than others, is it appropriate to ask the customer to provide this information?
Would it be possible to get the Client to do a Risk Assessment on the initial set of User Requirements so they could give a high level overview of what aspects are critical to business and what are critical to patient safety?
Yes that would be the ideal scenario, but is it appropriate to make such a request to a client? It would obviously require some work on their part and they may assume that the requested information should already have been considered.
Lets say for example, we are talking about retrospective validation for a product that is already being used by a dozen or so customers, do you think that such a request be viewed in a positive way by each of the clients; after all the long term goal is to reduce their own validation efforts?
yes, we have a very comprehensive understanding of the process and we have already carried out risk assessments for previous versions of the system but they have so far been written from our own perspective with a focus on the areas which we consider to be the most complex/critical.
We are very keen to improve future iterations of the product and the associated risk assessments by placing an increased emphasis on a clients area of concern and whilst we have a great understanding of the process in general, we feel that our clients may have differing views of what they consider to be critical areas of functionality based on their own specific individual requirements. As such we’d like to include their considerations when performing functional risk assessment.
I’m just considering whether a client would find a request for this kind of information unnerving given that the system is already in use or whether it would be received as a positive action and demonstrate our commitment to continual improvement. The upshot would be that their specific concerns would already have been addressed so in theory their “performance validation” efforts would be greatly reduced.
I have experience of this exact situation and I would say that the companies in question would be delighted to know that you are considering them at all times…in fact once your solution is out there and you have clients I would even say it is more important that they have a strong input into the products future road-map…after all they are the people who matter most in terms of the success of your product.
in the meanwhile, experts take over the discussion…
for a retrospective validation, the purpose is to establish a baseline of product related aspects such as performance, complaints/bugs, backup archival or product release sequence, etc., etc.,
so real question is…would you expect traceability matrix (URS vs DS and URS / DS vs Test case)to be part of retrospective validation…
if yes, then URS is mandatory.
its difficult to justify to w/o URS…
[quote=v9991]in the meanwhile, experts take over the discussion…
.[/quote]
Thanks for the response…Really? Did you just say that in your response to me V9991? How rude. I didn’t realize this was such an elite string. Please excuse the ignorance of my question.
I concur - that was a perfectly reasonable note and provides a good opportunity to discuss a closely related topic:
Although the product was already successfully marketed (and you could argue that the retrospective validation was simply a box ticking exercise) the functional specification (a combination of our URS/DS) was indeed used to draw up a trace matrix to form the basis of the validation package.
Moving forward, as the user requirements evolve I was suggesting that we should be asking our customers to provide their risk considerations as well as their requirements and whether this was an appropriate stance for us to take.
I’m very new to the field of GAMP validation so appreciate all advice/ suggestions/ different opinions on this site and an open discussion should only be encouraged!
First, an unconditional apologies for this situation…
I would like to place on record the context of that phrase…
I am responding on couple of projects i handled on automation etc.,
have limited exposure to first hand FDA-audit review/exposure in that area;
and the phrase, is surely was not intended to indicate anything beyond my background.
gokeeffe :- I acknowledge the concern of unintended & unforseen situation which my psot(phrase) has created…and would keep in mind about same in all future posts…
thank you .
No problem V9991…thanks for the clarification…I understand what you meant now
I’m sure the other guys feel the same
[quote=v9991]First, an unconditional apologies for this situation…
I would like to place on record the context of that phrase…
I am responding on couple of projects i handled on automation etc.,
have limited exposure to first hand FDA-audit review/exposure in that area;
and the phrase, is surely was not intended to indicate anything beyond my background.
gokeeffe :- I acknowledge the concern of unintended & unforseen situation which my psot(phrase) has created…and would keep in mind about same in all future posts…
thank you .[/quote]
to the extent of URS being sought from customers is fine and is anyways be part of customer’s quality systems as well;
and, on risk-considerations of customers being shared with supplier/manufacturer…unless this is an customized-bespoke kind of product, risk may may not always be shared across/between the organizations.
in fact as supplier(manufacturer of the s/w) we might need to provide inputs and participate in the customer’s risk assessment.
