Software Validation Guidance Suggestions

Mark Meer

Trusted Information Resource
Trusted
#1
I'm looking for suggestions of guidance on how best to plan, execute, and document software validation - for both OTS software we use at our facility, as well as software we develop.

Major consideration is that we are a small company with limited resources, and the requirements/intended-use of all software we use/develop have low risk profiles. For the most part it's pretty simple stuff - excel calculations (maybe some macros), OTS micro-controller flash programming, document storage/retreival...

I'm familiar with the FDA's "Principles of Software Validation" guidance (as it's free), and I've looked at some other threads, where the following suggestions come up:
- GAMP 5 Manual
- ISO/TR 80002-2:2017 (yes, we are a medical device company)

Question: Given our pretty basic needs (uncomplicated/low-risk & OTS software, limited resources), are documents such as GAMP 5 & ISO 80002-2 useful (over-and-above free guidances such as the FDA's)? If so, what do they offer? Have people found these particularly useful for their own practices? Are there any other guidances you'd recommend?

Any feedback/advice much appreciated!
MM
 

Marcelo Antunes

Addicted to standards
Staff member
Administrator
#2
My opinion is that GAMP is too much for most of the medical device industry. ISO TR 80002-2 was created to specifically deal with the new "risk based" activities of ISO 13485:2016, meaning you can tailor the process depending on the risk.

There's several other guidances, general and for other industries. One example are the IEEE standards (which are usually usable together with ISO documents). I don't think they are that welcoming (most that I know are more complicated, in fact).

PS.: I was a member of the team that created ISO TR 80002-2, but I'm not suggesting it because of that :p
 

Mark Meer

Trusted Information Resource
Trusted
#3
My opinion is that GAMP is too much for most of the medical device industry. ...There's several other guidances, general and for other industries....I don't think they are that welcoming (most that I know are more complicated, in fact).
Thanks Marcelo, the "welcoming" part is certainly a consideration. Someone posted in another thread that GAMP 5 manual is in excess of 350 pages! ...probably overkill for us.

But to your general statement that it is "too much for most of the medical device industry", I would have thought that, in principle, a more thorough coverage of the topic would be MORE appropriate to the medical device industry due to its generally higher risk, no?

ISO TR 80002-2 was created to specifically deal with the new "risk based" activities of ISO 13485:2016, meaning you can tailor the process depending on the risk.
If ISO TR 80002-2 treads a lot of the same territory as ISO 14971, then I'm dubious as to its utility (for our organization). We've got a pretty good handle, IMO, on risk-based processes. Like I say, I'm more interested in guidance on the execution and documentation. The (free) FDA guidance, seems to have a lot covered (including risk), so I'm curious what these paid standards such as ISO TR 80002-2 offer? Does it, for example, provide any real-world examples?
 

Marcelo Antunes

Addicted to standards
Staff member
Administrator
#4
Thanks Marcelo, the "welcoming" part is certainly a consideration. Someone posted in another thread that GAMP 5 manual is in excess of 350 pages! ...probably overkill for us.

But to your general statement that it is "too much for most of the medical device industry", I would have thought that, in principle, a more thorough coverage of the topic would be MORE appropriate to the medical device industry due to its generally higher risk, no?
Not exactly (and the "higher risk" is debatable :p). The point is how ISO 13485:2016 handles software validation. It was decided to require validation to all application of software (and remove the old "that affects the product"or something like that), so ALL use of software in the QMS needs to be validated. On the other hand, so as not to create an overburden requirement, we introduced the requirement of risk-based approach and activities for the software validation, which let's you tailor the software validation effort (and which is mirrored in ISO TR 80002, which has a toolbox with several activities, some mandatory, but most voluntary, to be chosen depending on the risk).


If ISO TR 80002-2 treads a lot of the same territory as ISO 14971, then I'm dubious as to its utility (for our organization). We've got a pretty good handle, IMO, on risk-based processes. Like I say, I'm more interested in guidance on the execution and documentation. The (free) FDA guidance, seems to have a lot covered (including risk), so I'm curious what these paid standards such as ISO TR 80002-2 offer? Does it, for example, provide any real-world examples?
Sorry, I did not understand you did not know ISO TR 80002-2. I was talking about the approach and activities of software validation being based on risk, as I mentioned above. ISO TR 80002-2 also has several examples of application in the annexes (14 examples, in fact).
 

somashekar

Super Moderator
Staff member
Super Moderator
#5
If I am using an ERP s/w and the same is under annual maintenance contract with upgrades, does it meet the requirement of validation of the ERP s/w...
 

Marcelo Antunes

Addicted to standards
Staff member
Administrator
#6
If I am using an ERP s/w and the same is under annual maintenance contract with upgrades, does it meet the requirement of validation of the ERP s/w...
Nope. Validation is a confirmation that your intended use of the software is fulfilled. Upgrades have nothing to to with that.

On the other hand, after any update, you need to verify the need for re-validation. This can be very resource-consuming...
 

somashekar

Super Moderator
Staff member
Super Moderator
#7
Nope. Validation is a confirmation that your intended use of the software is fulfilled. Upgrades have nothing to to with that.

On the other hand, after any update, you need to verify the need for re-validation. This can be very resource-consuming...
I understand what you mean now. But the ERP customization project was the purpose to make the ERP meet our intended use. Without affecting our intended use, there would be upgrades to add a feature, which may or may not be used by us. It may be considered as an improvement in the MIS.
So is my ERP by virtue of the customization and effective use stand validated...
 
Top