Hi all:

I found that FDA is very concerned about the software. So i want to ask you here, did you establish a software validation procedure specially to meet the requirement of QSR820?

If so, how did you establish this procedure?


Thanks a lot!

did you establish a software validation procedure specially to meet the requirement of QSR820?

Whether you incorporate intended-use-controlling software into your products or use software in your business-operational systems such that its functionality may affect product safety or effectiveness, the answer is yes.

If so, how did you establish this procedure?

That would require a complex multi-stage answer.

You might start with http://www.fda.gov/cdrh/comp/guidance/938.html. (http://www.fda.gov/cdrh/comp/guidance/938.html)

Hi all:

I found that FDA is very concerned about the software. So i want to ask you here, did you establish a software validation procedure specially to meet the requirement of QSR820?

If so, how did you establish this procedure?


Thanks a lot!

The answer should be YES if the software is

your software is validated per 21 CFR Part 11 requirements
if the software impacts the quality of the product

i doubt if we can address the CSV as a procedure; i would prefer to call it as an process; I am sure you have already google'd on the subject; nevertheless heres an token [most appropriate] for that you are seeking some info on USFDA; http://www.fda.gov/ora/compliance_ref/part11/

1. for pharma industry, software validation is essential wherever its associated/relied-upon in the product/process perspective. [generally speaking, of all the organizational processes, i guess only accounting/finance/marketing have been left out of the ambit of the need for validation!]
2. "...how did you establish this..." i agree with MIREGMGR, its complex multi staged answer... let me try to get started... essentially what is expected is SDLC life cycle [all the activities involved from requirements through release...] with whole lot of flavor of documentation requirements.


hope that helps.
valiveti.

Is there anyone who can give me a template of software validation procedure?

Then i can take it as a reference!

Thanks a lot!

let me once again emphasize that the its not a single procedure; its a combination of all processes through which we establish the evidence that software fit for intended use. [validated]

we are used-to referring that as validation plan & report, of which each steps are defined in individual procedures . now if you are asking for procedure... which part of the following steps are you referring to?

a quick search of net throws up the following documents.. 1 for plan and 1 for report. now all the associated steps/contents of the document can be deemed to be a individual procedure... all falling in place to certify a product to be validated.

http://www.aero-scratch.net/Dissemination/Image/DS5_1.pdf
http://www.nordicinnovation.net/nordtestfiler/tec535software_validation_report1.doc[with a little more refinement /exploration you will certainly come up with the more precise referencess appropriate for your sitaution...]


even if you are referring to a retrospective validation; i guess its not possible to cover all the above steps of software validation into single procedure.

hope that helps.
valiveti.

Questions run through my head when I read this... Quality System, Process, or Device software? If device, is it part of an IDE? 3rd Party or custom software? What's the FDA concerned about? Your software or software, in general?

Who am I? Where am I? Sorry, all the question marks left my head spinning...

Chris Ford

GAMP-5 by ISPE can be a very good source guide for software validation.
added to that FDA's guideline as 21 CFR Part 11 has to be implemented.. and also as given in ICH .

The following can be of use;

Good practices for computerised systems in regulated 'GXP' environment from PIC/S.
Computer validation guide by CEFIC
GAMP Special interest group (21 CFR Part 11) from ISPE.
provided, one is using computer system automation as a support process for processing and submissions.

GAMP-5 by ISPE can be a very good source guide for software validation.
added to that FDA's guideline as 21 CFR Part 11 has to be implemented.. and also as given in ICH .

The following can be of use;

Good practices for computerised systems in regulated 'GXP' environment from PIC/S.
Computer validation guide by CEFIC
GAMP Special interest group (21 CFR Part 11) from ISPE.
provided, one is using computer system automation as a support process for processing and submissions.

They're all good sources of information, but 21 CFR 11 pertains to electronic records and systems. There still is no clear indication what software needs to be validated or what software validation systems need to be established. If this is software is a component of a medical device, or if the software is a medical device, there would be other standards involved.

Thank you for your observation. I will come back in a day or two about 21 CFR part 11 in more detail.

We are NOT a software manufacturer, but we use software in our daily business to track information. I would like to know how others validate their software for this purpose.

For example, we use a simple spreadsheet to track our CAPAs. How do we go about validating the spreadsheet? Do we just need to be able to prove that we can restore the information from our backup data tapes if our server crashes? Or is there more we need to do?

At this point, we print EVERYTHING because we have never validated any of our systems, but I think we need to start moving in that direction. We have piles and piles of paper!!

I have looked for information and it seems that are all geared towards software manufacturers.

Thank-you!!

It's hard to tell how this piece fits in here, but I am currently charged with writing validation master plans and protocols for automation that will produce medical devices. The automation in project after project is controlled by programmable logic controllers (PLCs) and human-machine interfaces (HMIs, otherwise known as screens with buttons).
The question is whether and how much validation is required for software in applications like this. The software definitely controls the machinery, and it sometimes controls quality (application times, valve operations, etc.).
In past validations we have tended to do one of two things, depending on customer review and approval of the validation documents:

We have a work instruction and form for source code review. We do what appears to be a fairly shallow review in accordance with the work instruction.
We do a risk analysis for each custom software application and determine that the risk is low enough to allow us to validate the software as a "black box". The validated operation of the assembly machine validates the software.
These approaches come from a cursory understanding of GAMP 5, where we can quantify the risk to the patient, data integrity, and product quality as low or non-existent.
Does anyone else have validation experience with this kind of software validation?
Best-- Norris