Process Validation of QMS Software ISO 13485: 2016 Cl. 4.1.6

[A1S2H3I4T5H]

Hello Guys,

4.1.6 in ISO 13485: 2016 calls for Process Validation of QMS Software.

1. What does QMS software mean ??
2. Does it mean SAP, Company Intranet etc ??
3. If yes, How do we validate such softwares.

Also please suggest any ideas about how to validate CNC software ??

Any templates if available would be really helpful !!

Thank You.

 

[yodon]

Any software used in support of the QMS is a candidate for validation. Without knowing how you use the applications in question 2, it's not possible to say.

You can take a risk-based approach to validation; i.e., for those applications that pose minimal risk, you can take a very minimalist approach to validation; whereas an application that has high risk should be rigorously validated.

It's not a trivial subject (there are courses galore on software validation) and not possible to fully describe here. Similarly, each application is unique so a one-size-fits-all template is not the best approach. In general, define the requirements for how you use the system and then take the actions to demonstrate the application meets those. A good resource is the GAMP 5 Manual (which, at over 350 pages, is another indication that the subject matter isn't trivial!).

 

[mihzago]

Another good resource is ISO/TR 80002-2:2017 Medical device software - Part 2: Validation of software for medical device quality systems.
It has a good description of the validation approach and informative appendices with examples.

 

[Mortalis]

You can contact the supplier of the software. They may already have some validation scripts and can help you with the validation.

 

[Wolf.K]

This is really not that trivial!

We had our 13485:2016 certification audit a few weeks ago, and already implemented the software validation issue. We wrote a SOP "Validation of QMS software", which includes 3 forms: validation log, validation plan, validation report. On the log we list all software we think can have an impact on the QMS and/or product safety. As we have production/manufacturing outsourced, we have only some software packages on the log.

The log is a spreadsheet with the colums:

- ID number
- Software name/version/date
- Description (what does the software do)
- Failure mode(s) (what could go wrong)
- Validation required (yes/no)
- Rational for validation decision
- Software validation report available (yes/no)
- Software released for everyday use (yes/No)
- Decision made date /by

If validation is required, a validation plan is prepared - how to validate the software. If the validation is finished, the validation report is prepared, and the log is updated.

Currently we have only three different software packages on the log - our QMS is still paper-based, that makes it simple. We have a data logger for a storage room for products (temperature/humidity), excel spreadsheets with home-brewed algorithms, and a statistical software for number needed to treat calculations for clinical study planning.

For excel we use the FDA recommendations (I will write a work instruction for our personnel), the statistical software (G*Power) does not need validation as all algorithms are already validated by the manufacturer (take a look on the manual), and the data retrieval software of the data logger needed validation (is the retrieved logged data similar to the true environmental conditions).

Next year we get an ERP. The manufacturer will validate the software! EXPENSIVE!!! But necessary.

Hope this helps!

 

[locutus]

That is really nice info Wolf. Just to further along with what Yodon stated earlier, considering adding another "column" to your spreadsheet called "Risk Impact." You already kind of that in Failure Mode and Validation Required along with the rationale. Only advice is to specifically call it Risk and/or Risk Assessment because section 4.1.6 uses a risk-based approach. So A1S2: Wolf has a very nice structure there, just make sure to include the whole risk-based approach to determining what needs to be checked, verified, or validated - and make sure to include a review period .. especially when the software changes. What?!? Software changes?!? lol

 

[Wolf.K]

Yes, we, that is, I add the risk impact in the column "Failure mode" - it is more like "failure mode and effects analysisFMEA" like style - but I had not enough space for another column... But of course you are right - the impact needs to be evaluated!

Next year we get an ERP - in December I will read the GAMP 5 manual, and then I will decide if it is necessary to visit a seminar...

As we are a small company, our notified body is always very nice to us. We don't hide anything from him, and for him it is important that he can see that we (a) observed /noticed a possible problem and (b) thought about the impact it could have. So, a bad SOP is a not so good thing, no SOP at all is a bad thing, because then he sees that we acted on some issue. We did not ignore it. If we did not do enough, he will tell us...

 

[A1S2H3I4T5H]

Thanks Wolf..

The information is very useful.. I'm now following the similar template for Mapping the Software validation..

I'm able to map the Roles & Responsiblity (who should do what) for Process Validation of Mechanical processes like Welding, Painting, Heat treatment etc.. Is there a similar kind of Matrix for Software validatiion

Thank You.

 

[Lorlee]

Wolf - Terrific information! Would you be willing/able to share your SOP "Validation of QMS software"?

 

[kd7074]

If anyone is interested, we found a company that specializes in SW Validation. Their name is Ofni Systems in Raleigh, NC. Their prices are very reasonable for what we needed done for a few spreadsheet validations, at least compared to another quote we received. We just aren't staffed with resources to get these done in time for our certification audit.