Understanding FDA requirements for Software Validation

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

Coury Ferguson

Moderator here to help
Trusted Information Resource
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?
 
S

szohar

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?
 
M

min1999

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.
 
M

MichaelL

I am brand new to the forums (as of right this minute). The company I work for and the project I am directing is facing the same issue. We make MR coils so we need to meet FDA in all our validated processes. i am using the same General Principles document as guidance, and our internal Regulatory Affairs and Product Quality groups as reference and for assistance in designing the systems. These systems will take over manual test of our product.

I have already gone through some of the validation and we had to create an I/O matrix, have that reviewed (with documentation). We also had to have security covered, version control (we use a QMS system, so I shoehorned the software into it) and a review process already in place. We have another stage rollout coming up. I can try to answer questions, but if I had more details I might be able to answer more intelligently. I am also here to learn. This is my forst time with an FDA system - I come from military systems test, specifically torpedos, which I did test engineering on for 20 years.

No, it's definitely not the same.
 

yodon

Leader
Super Moderator
Indeed, guidance docs are less than obvious. IEC 62304 is a recognized consensus standard (FDA) and is a good resource. LiamD: you have a good list (configuration management, etc.) started and yes, those do contribute to validation (. The one thing I see missing is addressing SOUP (Software of Unknown Provenance). At a minimum, it's highly likely that your build tools (compilers) are adding (library) code to the binaries so that needs to be considered. If you use any external software packages (image processing, math libraries, etc.) then those need to be addressed. They are both a source of potential error / failure AND a potential cybersecurity entry point. So an assessment of known issues with SOUP and ongoing monitoring of the SOUP (for new issues reported) is part of validation.

I mentioned cybersecurity and that's now very much a focus. The UL 2900-1 standard is good as well as the FDA guidance on cybersecurity (there are 2, one for premarket and one for postmarket).

Another thing you'll need to consider is postmarket surveillance. Any bugs, usability issues, etc. need to feed back into your software management process.

You hit on a good point with Risk Management. Indeed, if you look at 62304, risk is considered throughout. Part of the risk management activities will be to consider incorrect and/or misuse (and this also ties into usability). Software should be sufficiently robust to ensure users can't do something that would enable patient harm. These are usually expressed as risk mitigations / controls which are also software requirements and subject to verification.

It's a big subject, difficult to encapsulate in entirety in a post like this. If you have specific questions, will be glad to help.
 

v9991

Trusted Information Resource
Guidance for Industry Part 11, Electronic Records; Electronic Signatures — Scope and Application
https://www.fda.gov/downloads/regulatoryinformation/guidances/ucm125125.pdf

234 For further guidance on validation of computerized systems, see FDA’s guidance for industry 235 and FDA staff General Principles of Software Validation and also industry guidance such as the 236 GAMP 4 Guide (See References).
343 1. The Good Automated Manufacturing Practice (GAMP) Guide for Validation of 344 Automated Systems, GAMP 4 (ISPE/GAMP Forum, 2001) (GAMP 5 Guide: Compliant GxP Computerized Systems) 345
346 2. ISO/IEC 17799:2000 (BS 7799:2000) Information technology – Code of practice for 347 information security management (ISO/IEC, 2000)

GAMP 5 Guide: Compliant GxP Computerized Systems

My experience with FDA's audit interaction is on pharmaceutical side, and with laboratory softwares and approach outlined in the GAMP-5 is more than adequate to ensure and reflect the systems and controls. of the development-controls-maintaining for operationalizing same.
 
Top Bottom