Context

This is a post that is hoping to help understand what the FDA requirements are for Software Validation.

It is not Process Validation, Product Validation, Device Validation (Although I know Software Validation is a component of this), or any other validation – I have seen many instances where there is confusion on this.

FDA Guidance Documents

I have based my understanding on the following FDA Guidance documents:-

General Principles of Software Validation; Final Guidance for Industry and FDA Staff
(Sorry FDA link had to be removed)

Guidance for the Content of Premarket Submissions for Software Contained in Medical Devices
(Sorry FDA link had to be removed)

Having read these documents I feel that the documents are lacking specifics and there are areas that are left to interpretation. Now my concern with this is that people make different interpretations and develop software that it is not adequate for FDA submittal and it may be rejected because it does not meet expectations.

My Baggage

From my software development experience here is my personal definition that I have worked with:

Verification
Ensuring that the Software requirements have been fully implemented by executing a Software Test Procedures.

i.e. Making sure system built correctly

Validation
Ensuring that the Software meets user expectation.

i.e. Making sure the right system is built

Software Validation
I have read many discussions and points of view related to software validation. Some of the information has been misinformed and other has been conflicting. I am hoping to get a response to this post that will help clarify the intent of Software Validation.

So where I have seen a lot of confusion is the terms Verification and Validation. After reading the Guidance documents, this is my take:-

Verification
Ensuring that each software development lifecycle phasees has been completed correctly. I.e the input to the phase have been correctly transformed to the output of the phase.

So for the following phases here is a list of verification activities I can think of (most of them seem to be review based).

Life Cycle Stage ____ Verification Method
Requirements Capture .Review of Document, Traceability
Detail Design ........Peer Review, Review of Document, Traceability, Unit Testing
Implementation .......Code Review, Code Walkthrough, Traceability
Test..................Review of Document, Traceability

Software Validation Activities

Now I know that the amount of documentation depends on:

- Level of Concern
- Risk Assessment

Obviously a Major LOC device will require more that a Moderate LOC. Also I understand that the activities can be determined based on a Risk Assessment. So perhaps only Unit Tests would be preformed on safety critical sections of code – rather than the complete source.

Now I think I would really understand what is expected for software validation if I could see a complete list of all the activities that could be considered when trying to determine how to Validate Software.


I can see that all the verification tasks (as listed above) contribute to “demonstrate by objective evidence” that the software has been validated.

Where do other quality activities fit into the picture – are these considered Software Validation activities?
- Configuration Management
- Source Code Version Control
- Code Coverage and Tools
- Static and Dynamic Code Analysis
- Build Procedures


What are all the other activities help to demonstrate Software Validation?

There is a strong indication that Software Validation should ensure that the software should “conform to user needs”. Can “user needs” be fully defined in Software Requirements? Is it the case that the only way to “confirm by objective evidence” that “user needs” have been met is by allowing the end user to use the device? Does it mean that it can only be done at the end of the development cycle?

One more thing that is a real source of confusion: I have seen many people reference a single document called a Software Validation Procedures. Now from my understanding I do not believe that such a document can be executed and demonstrate that Software has been validated – it has to take much more than that.

I would be very happy for anyone to add to this post to help clarify Software Validation especially anyone who has had experience of making a submittal or who has had FDA software audit experience.

Thanks
Liam

I have moved this post to the forum since it relates to the FDA, even though it is asking about software validation. I think you will get better responses here.

Can anyone provide some help on this?

Since our organization is working through the same challenges right now, I'll be keeping an eye on this thread in hopes that others will contribute any relevant experience or advice.

Anyone?

I dont have experience of FDA Sofware audit experience. I am customer of some softwares in a GLP Lab.

First we will make a yearly validation master plan(VMP) for all the equipment including software validations in our lab. Then we draft specific validation plan for each instrument, usually done by the one who is in charge of the equipment. The plan should be reviewed by QA and management. Then some person carry out validations according to the specific validation plan and related SOPs and make any experiment records of observations and results. After that a validation report shall be prepared including the procedures, results and conclusions. The report will be checked by the Study director and reviewed by QA and the management.

So the validation documents include validation master plan, Specific validation plan, Validation records, and Validation report.

Hi there,

I've been doing some research on this subject myself, and came across this thread: http://Elsmar.com/Forums/showthread.php?t=10867&referrerid=69908

which has been MOST useful...

On Page 5 of the thread, the attachments get VERY helpful if you need templates for Software Validation and general ideas on activities to perform.

Hope this helps!