ISO 13485:2016 - Validate our use of software that impacts on the QMS

[andesite]

Hi All,

We're in the process of transitioning to the 2016 version of ISO 13485, and one of the biggies for us is the requirement to validate our use of software that impacts on the QMS. I've justified what needs assessing based on risk and need to start writing the validation protocols for it now, but it's something I have absolutely no experience in. I think I could fumble through a new validation but the retrospective need to validate is throwing me completely as we have nothing to work off like a URS etc. Can anyone point me towards any guidance which would give me an idea of what paperwork would be the minimum we need and perhaps a decent way of laying it out? Any suggestions gratefully received.

 

[yodon]

A couple of things:

First, validation is not a one-time event (so just having "paperwork" may be a misconception). Once you complete validation, you need to maintain the system in a validated state throughout its use life. Your validation program (usually captured in a Master Validation Plan) should address the complete life cycle.

Second, the concept of non-product software validation isn't new, it was there for software used in production and service provision. The updated standard does, in fact, expand the scope and emphasis.

You will certainly need to establish requirements for the applications. Just no way to validate something if you can't articulate what its intended use is.

As far as the retrospective aspect goes, you'll just need to generate enough evidence to be able to assert that whatever you have done in the past with the software is valid.

This is a pretty big subject and hard to express in a few lines on a discussion board.

 

[pkost]

The US/FDA have focused considerably on validation of electronic records. The FDA have issued the following guidance:

https://www.fda.gov/downloads/regulatoryinformation/guidances/ucm125125.pdf

 

[kreid]

If you do not have a URS for your legacy software, maybe you have a work instruction or training materials on how to use it?
If so you can use this as the input to your validation process, they can be used as a surrogate URS.

 

[MC Eistee]

I would advise you to read the new ISO/TR 80002-2 that was just published in June this year.
It is a guide for validation in an ISO environment. Nothing really new in there but it might be a good start for you as it comes with some examples and is easy to read.

If you are also FDA regulated you might also look at the link of pkost.

As yodon said, validation is not a one time event. You need to keep it in a validated state. Simple example: Initial validation and then you need to judge each change on the software (also its environment if there is any impact) whether you have to validate again or not.

 

[pkost]

Thanks MC Eistee, I was unaware of an ISO standard relating to this

 

[Wolf.K]

Hi,

We have the same issue. Our QMS is totally paper-based, that is, all documentation is printed out and filed in folders. But of course we have computers, and our contract manufacturers use software in the production.

So, what I did was:

I wrote a SOP "Validation of QMS software"...

This SOP just requires to write a validation plan, a validation report, and list the validated software in a software validation log (all controlled documents) and statement if it is released for use or not. As applicable, failure modes have to be defined, then a decision has to be made, and the rational for the decision has to be stated.

Validation log
Headlines of the columns:
ID number - Software name, version, date - Description (what is the software used for) - Failure mode (short version of the report) - Validation required? - Rationale (short version from the report) - Software validation report (yes, n/a, not available yet) - Software released for everyday use? (yes/no) - Decision made date / by

So, we fulfill now the requirement of a documented procedure. Is it a good procedure, or a bad one? I don't know, I have never done a software validation before. The new ISO standard did not help me much, though. But: we have a procedure. After the audit I will know, if it is good enough...

I had to think about the software we use and which has to be validated. I came up with the following list:

1. Office. As we print all our documents, so no need to validate. Except:

1.1 Spreadsheet calculations

For our spreadsheet calculations I ask our people who program spreadsheet calculations to write a short report of the algorithm, and test it a bit. That is, plug some (also extreme) values in it and see, if the results are correct. I referenced the FDA requirements/recommendations in the SOP.

2. Our statistics program

We use it for calculating e.g. numbers to treat and else (for our clinical studies). The good thing is: all formulas are already validated by the manufacturer. So, no need for us to validate it.

3. The data retrieval software of our data loggers (to record temperature and humidity)
Our products are manufactured by contract manufacturers and distributed by distributors. But we have a small storage room to store products to be used by our product managers e.g. for clinical trainings. So we have to prove that the sterility of the products is not compromised. SOP Storage Room requires documentation of environmental parameters. We have a data logger and log the parameters. But are the numbers I see on the computer the real ones, or does the import of the data from the logger change the values? So: validation required.

Next year we get a ERP, and I have to learn something about GAMP 5...

Hope this helps!

 

[bcoolnow]

I am also fairly new to the software validation requirements and may have a large one coming up soon, excel spreadsheets used for final inspection. If these are used for data acquisition during final inspection, does this need to be validated? And if so, to what degree? I would assume that any cell where a calculation is done would need to be proven out, even though the formulas themselves may be pre-proven by the manufacturer. We are contemplating going this route so would like to know what all may be involved.

 

[yodon]

Short answer is yes.

FDA has posted this: https://www.fda.gov/downloads/scienceresearch/fieldscience/laboratorymanual/ucm092179.pdf

Section 4.5.3 talks about spreadsheet validation and provides a good overview:

General guidance for design and validation of in-house spreadsheets and other numerical
calculation programs includes the following considerations:
• Lock all cells of a spreadsheet, except those needed by the user to input data.
•Make spreadsheets read-only, with password protection, so that only authorized users can alter the spreadsheet.
•Design the spreadsheet so that data outside acceptable conditions is rejected (for example, reject non-numerical inputs).
•Manually verify spreadsheet calculations by entering data at extreme values, as well as at expected values, to assess the ruggedness of the spreadsheet.
•Test the spreadsheet by entering nonsensical data (for example alphabetical inputs, <CTRL> sequences, etc.).
•Keep a permanent record of all cell formulas when the spreadsheet has been developed. Document all changes made to the spreadsheet and control using a system of version numbers with documentation.
•Periodically re-validate spreadsheets. This should include verification of cell formulas and a manual reverification of spreadsheet calculations.

 

[Haresh]

Short answer is yes.

FDA has posted this: https://www.fda.gov/downloads/scienceresearch/fieldscience/laboratorymanual/ucm092179.pdf

Section 4.5.3 talks about spreadsheet validation and provides a good overview:

General guidance for design and validation of in-house spreadsheets and other numerical
calculation programs includes the following considerations:
• Lock all cells of a spreadsheet, except those needed by the user to input data.
•Make spreadsheets read-only, with password protection, so that only authorized users can alter the spreadsheet.
•Design the spreadsheet so that data outside acceptable conditions is rejected (for example, reject non-numerical inputs).
•Manually verify spreadsheet calculations by entering data at extreme values, as well as at expected values, to assess the ruggedness of the spreadsheet.
•Test the spreadsheet by entering nonsensical data (for example alphabetical inputs, <CTRL> sequences, etc.).
•Keep a permanent record of all cell formulas when the spreadsheet has been developed. Document all changes made to the spreadsheet and control using a system of version numbers with documentation.
•Periodically re-validate spreadsheets. This should include verification of cell formulas and a manual reverification of spreadsheet calculations.

Dear Sir,
I have one question that is it necessary to validate the MS word and excel sheet as a GMP point of view as suppose we maintain soft copies of SOP and preparing purchase order in excel sheet.
Awaiting your reponse.