L
LiamD
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
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
Last edited by a moderator: