Software Validation – Clause 4.1.6 of ISO 13485:2016

S

SteveK

Right, I’ve put together a procedure – so I meet the first requirement of this new clause in ISO 13485:2016. I am familiar with IQ, OQ and PQ having conducted various process validations. There are the software validation guidelines from the FDA and there is AAMI/TIR 36, but these seem far too complex for off-the-self stuff. It is how far do you go down the rabbit hole? For example we have new labelling software which produces text and barcodes for our products/packaging, so this obviously has an impact on our QMS. We have barcode verifiers (1D and 2D) which I can use as part of the print validation exercise. However, these verifiers also run on software which in turn has therefore an impact on the QMS – so how do I validate this software I use in part to validate?

Also, CAD software is part of our QMS since it produces the drawings which we manufacture to. How do you validate this? Then there is our accounting software which produces a bill of materials which we manufacture to – further impact on our QMS – how to validate this? It can then get a bit silly when you then consider operating systems, Adobe, Word, Excel (though in Excel I do understand the issues with macros and formulas and the examples in TIR 36).

I do have a number of ideas how to conduct such software validation based on input and output, risk, fitness for purpose, specification meeting OQ, screen capture, test printouts etc., but would appreciate anybody else’s experience and thoughts.

Steve
 

Candi1024

Quite Involved in Discussions
Re: Software Validation – Clause 4.16 of ISO 13485:2016

Software Validation for off-the-shelf software could be done as part of the PQ. You are looking to verify that the functions you require, work as expected.

If the CAD software doesn't do any calculation, then there is no reason to validate. Some with word and Adobe.
 

Pads38

Moderator
Re: Software Validation – Clause 4.16 of ISO 13485:2016

Hi Steve,

Sounds like you are further ahead than me on this.
I did start to think about this, specifically the use of spreadsheets, as we are hoping to speed up our test processes using "smart" test equipment and auto-complete spreadsheet forms.

Original Links:

Software Validation – Clause 4.1.6 of ISO 13485:2016


Couldn't find current links.
 
Last edited by a moderator:
S

SteveK

Re: Software Validation – Clause 4.16 of ISO 13485:2016

Hi Pads,

Thanks for the feedback - I'm hoping to avoid anything complex with spread sheets. As to the other software I'm probably overcooking the requirements. Ideally I will keep the validation very simple - after all an auditor is unlikely to be an expert in such matters as software validation.

Steve
 

yodon

Leader
Super Moderator
Re: Software Validation – Clause 4.16 of ISO 13485:2016

Have you looked at this FDA Guidance: (broken link removed)

Then that jumps to this one for COTS (although the link in the doc appears broken): https://www.fda.gov/downloads/medic...onandguidance/guidancedocuments/ucm073779.pdf

Bear in mind that all software validations are framed around your intended use and should be commensurate with the risk of using the software. If the output of the software is 100% reviewed (such as Word documents), you can justify not validating.

I recommend setting up a master validation plan where you can establish your risk criteria and thresholds. Then take an inventory of all your software and use the risk criteria to determine the level of validation required. For many out-of-the-box systems, we JUST do an IQ to confirm we have installed it according to manufacturers requirements and to assess any known (published) issues.

The master validation plan can also address how you maintain the validated state. For example, if an OS update is made, in theory, the validated state of any application under that OS would need to be considered.
 

love02eat

Involved In Discussions
Right, I’ve put together a procedure – so I meet the first requirement of this new clause in ISO 13485:2016. I am familiar with IQ, OQ and PQ having conducted various process validations. There are the software validation guidelines from the FDA and there is AAMI/TIR 36, but these seem far too complex for off-the-self stuff. It is how far do you go down the rabbit hole? For example we have new labelling software which produces text and barcodes for our products/packaging, so this obviously has an impact on our QMS. We have barcode verifiers (1D and 2D) which I can use as part of the print validation exercise. However, these verifiers also run on software which in turn has therefore an impact on the QMS – so how do I validate this software I use in part to validate?

Also, CAD software is part of our QMS since it produces the drawings which we manufacture to. How do you validate this? Then there is our accounting software which produces a bill of materials which we manufacture to – further impact on our QMS – how to validate this? It can then get a bit silly when you then consider operating systems, Adobe, Word, Excel (though in Excel I do understand the issues with macros and formulas and the examples in TIR 36).

I do have a number of ideas how to conduct such software validation based on input and output, risk, fitness for purpose, specification meeting OQ, screen capture, test printouts etc., but would appreciate anybody else’s experience and thoughts.

Steve
Hi Steve, I am on the same boat as you needing to figure out what needs to be validated for our software. We are using also 2 off the shelf software. Visual for manufacturing and then we use another module with in it for Visual Quality. Our Documents are done in TMS web. We are a plastic extrusion company that provides contract manufacturing only No design involved. We manufacture to customer specifications. We do measurements and testing as required by the customer before shipping and also we send them a Final inspection sheet to show all results. So do I still need to validate our on line in process since , the component is inspected right at the line with our QC then when the results are passed using of course the AQL requirement QC bags and labels final product and goes right into the shipping inventory? Also by chance have you done a master list for validation and would you mind sharing? Very very limited resources had a few layoffs just recently so we are wearing many HATS!! Any help would be great.
 
S

SteveK

Not really moved on since my post in May. I’m still trying to get my head around this (and other quality/regulatory issues). As to a master validation plan/list, nothing in place I’m afraid, other than identifying the items I originally covered in the first post. So sorry, I cannot offer any help.

Steve
 
W

WilBryan

So we leverage a lot of vba functions in Excel specific to our inspection reporting and automation for tracking our engineering change process.

Anyone out there figured out an easy button for validating excel vba marcos? Just test and document, or something more robust?
 

MC Eistee

Starting to get Involved
Since you wrote excel macros you must have had requirements for that.
So a good start would be writing them down.
Do not take excel into consideration. Just your requirements for that specific case. Using Excel is just a way to achive that.

When you wrote your requirements down you have your requirements / software specification.
Do a risk assessment on your requirements. You might link them for traceability purposes.
Your risk assessment indicates what kind of actions are necessary based on the overall risk of a specific requirement not fulfilling its purpose.
Then you should write test cases. What is your interaction with the excel tool to test a requirement. That is what should be document. When you are done with that you can actually start to test you excel tool. Do not forget to collect objective evidence. And there should be a final approval.

Do not forget to document and approve all your actions.

Hope that might help a bit getting started.
 
W

WilBryan

That is a really well written approach. thanks for the great advice!
We have a lot of this information but formalizing it as an approach to meet the validation requirements is the link we were missing.

Sincere appreciation MC!
 
Top Bottom