Good Morning,

Firstly apologies if this has been answered before or am in the wrong place - this is my first thread.

Have recently started in QA for a medical device company and have found that there are some small gaps in the validation of our software. Have read the general principles document and am still unsure on a couple of issues -

1) can the the software be retrospectively validated - ie can I say it has worked thus far and so has no problems?

2) How do you validate off the shelf software? does a simple excel spreadsheet used as a log, or an access database, that merely generates a unique number and the date, need to be validated?

Thank you very much indeed for your help, and any general help would also be most welcome.

Thanks :D

RK

Do you have a Master Validation Plan? That's always a good place to start. If you don't have one, you probably should. Searches in this forum should provide good information.

For your #1, I would not want to try that 'excuse' in front of an auditor. If the software can affect quality, it needs to be validated. A risk analysis can be used to scope the extent of validation. You might want to trigger the validation through a CAPA and you should probably do some sort of analysis describing why product released prior to validation has no quality issues.

For #2, you open a very mixed bag. Does a simple excel spreadsheet used as a log require validation? Maybe, depending on its use (there may be security issues, part 11 issues, audit trail issues, etc. that need to be considered). Again, the decision should be guided by your Master Validation Plan and a risk assessment.

Hope that helps.

1- No. In my opinion the only option is to "reintroduce" validation in the design process - see for example the paper "Retrofitting software safety in an implantable medical device", on IEEE Software It gives an example on how to "fit" safety in an already designed software (in fact it uses the risk management principles backwards :-)). The issue for validation is the same.

2- Take a look at the guidance "Off-The-Shelf Software Use in Medical Devices" - http://www.fda.gov/cdrh/ode/guidance/585.html

I got the impression from the examples (spreadsheet, access db to generate a number) that the software wasn't part of the medical device. So maybe this guidance on general principles of software validation is more approprate: http://www.fda.gov/cdrh/comp/guidance/938.html

As an ex-FDA investigator, validation comments like "it worked so far and has no problems", "we dont conduct prospective validation, but retrospective validation", or "how does one validate off-the-shelf software" get me excited- be it design controls (device has or is software) or process validation (automated process)... it shows 1) the person may not fully understand validation (i.e. a training &/or management controls issue) and 2) the company may not understand the importance of software validation (i.e. it costs too much).

Basically- with software validation- it is like a design study... one has to take into consideration the intended users and user needs (be it internal or external). It uses the traditional prospective validation concept (IQ/OQ/PQ/PPQ)- however, risk management is needed because if testing is the major criteria- one would be trying out endless conbinations- and the process/product study would never be closed. These are a few tips. FDA & GHTF also have lots of guidance documents re software validation.