ERP System Software Validation - ISO13485 2016 4.1.6

Hi ,
Any advice or guidance from any one on ERP system software validation.
ERP software was purchased of the shelf.
Very low risk associated with it as its used to record stock but we also have a paper based system so it more of a back up.

Need to validate as per ISO13485 2016
4.1.6
"The organization shall document procedures for the validation of the application of computer software used in the quality management system. Such software applications shall be validated prior to initial use and, as appropriate, after changes to such software or its application.
The specific approach and activities associated with software validation and revalidation shall be proportionate to the risk associated with the use of the software."

Might anyone have a template or sample validation or a validation protocol for the like?

Have been googling but found nothing of any use.

Thanks in advance

Have you reviewed ISO 80002-2?

I also like Wolf.K's answer on this thread however I am not sure if it is sufficient. Contact the vendor of the software and see if they have any validation scripts or tools. If you are only using it as a backup, then I would think the validation requirements are low..


Thread: elsmar.com/elsmarqualityforum/threads/iso-13485-2016-validate-our-use-of-software-that-impacts-on-the-qms.71197/

Hi KARENMARY,

did you find any reliable ERP-software validation template. We are using ERP-software collmex and need to validate this software.

Do you have a SOP template for software validation (i.e validation of quality relevant software)

Hi there,
I do not think that you have to actually do anything for ERP in the context of ISO13485.

This software tool validation quite often goes kind of viral for whatever reason, my thoughts mostly because some companies have a business in there and generating some not really valid needs.

Are you really want to test an ERP system?
Why?
To what extent an ERP can have an effect on patient safety?
(I have some extreme example in my mind though, would not think that is mostly the case)

The other thing on this that testing is not for proving software correctness is to find software errors.

Hope this help

Regards
Saby

Dear All,

The information on this thread has been very helpful and I have a similar question but would like to clarify. My company would also like to use an off-the-shelf system for training and CAPA. The software itself has already been validated but our company needs to conduct an application validation to ensure it meets ISO 13485 4.1.6 and its intended use in our company. I do not have a copy of ISO the 80002-2 so not sure if this standard is relevant? I would like to understand what stages our company needs to consider for compliance. Apologies in advance if this information has already been posted elsewhere on Elsmar.

80002-2 basically just tells you how to validate your software, and provides examples. Its lengthy.
If the software is already validated by the company, and you are not modifying it, I think that greatly reduces your 'risk'. Especially if your vendor can provide scrips or a certificate that shows it is validated to perform the requirements you have outlined for your software.

Jeffbbt said:

80002-2 basically just tells you how to validate your software, and provides examples. Its lengthy.
If the software is already validated by the company, and you are not modifying it, I think that greatly reduces your 'risk'. Especially if your vendor can provide scrips or a certificate that shows it is validated to perform the requirements you have outlined for your software.

Click to expand...

Jeffbbt said:

80002-2 basically just tells you how to validate your software, and provides examples. Its lengthy.
If the software is already validated by the company, and you are not modifying it, I think that greatly reduces your 'risk'. Especially if your vendor can provide scrips or a certificate that shows it is validated to perform the requirements you have outlined for your software.

Click to expand...

Thank you Jeff. Are you saying that if we can show evidence the software provided by the vendor has been validated in general for our intended purpose and if we do not modify this too much that validation of the application could be mitigated with a risk assessment?

If you did not modify it at all, or if you can only validate the parts you modified.

If you can justify the your software is a low risk of affecting product quality (ie, risk has been mitigated by the validation of the vendor), then it should be easy to explain.

Classic example (although not perfect): You have a custom excel macro that determines if your product passes some metric. You would need to validate the macro, but not all the rest of the excel functions. (its not a perfect example because excel is so ubiquitous).

Its a really good idea to get in touch with the software vendors and see what they have in terms of validate certificates or scripts. If they are installing it in your system and can provide a 'certificate of conformance' after installing that helps.

Thanks Jeff, I’ve done some more research had a look at ISO 80002-2 basically tells you how to validate your software (not applicable to us) and the application itself. You're right it is lengthy! The software is already validated by the company, and we are not modifying the software which greatly reduces our 'risk'. All we are doing is changing the workflows to suite our needs and therefore its more of a process validation and for this we have identified the following documentations:

• Software requirements
• Software validation plan
• Validation protocols for tests
• Overall report
• Process for the above, including when to re-validate and change control of any workflows.

Does this sound about right?

Fat Larry said:

Thanks Jeff, I’ve done some more research had a look at ISO 80002-2 basically tells you how to validate your software (not applicable to us) and the application itself. You're right it is lengthy! The software is already validated by the company, and we are not modifying the software which greatly reduces our 'risk'. All we are doing is changing the workflows to suite our needs and therefore its more of a process validation and for this we have identified the following documentations:

• Software requirements
• Software validation plan
• Validation protocols for tests
• Overall report
• Process for the above, including when to re-validate and change control of any workflows.

Does this sound about right?

Click to expand...

Hi, would it be possible to share above listed documentation?