Medical Device Software Tool Validation - Compilers!

[Dobby1979]

Hi.

This is my first post to Elsmar, have always looked on with great admiration at the replies and assistance people give.

For this reason i was wondering is someone could advise / is a guru on Software Tool Validation, namely compilers!

The FDA guidance on the general principles of software validation implies (to a degree) that they should be validated. In reality this (to me) is a monstrous task with such little value, especially if your V&V is very robust.

Would love to hear your thoughts, experience on this as i am having strong discussions for and against. I am totally for validating tools that have an impact / where the tool output is giving a result but i just cannot get my head around validating a compiler or even how this task would be took on!

Background Info: Class II Medical Device

Thanks in advance and apologies if i have posted in the wrong category.

Dobby

 

[Pads38]

Hi Dobby and welcome to the forums.

Strictly, this is the 62304 sub-forum and that standard does not address validation. But that's not important really.

I cannot begin to suggest how to validate a compiler. But, of course, google can supply some links. Try these (the first 2 are directly related to medical devices).

http://blog.cm-dm.com/post/2014/03/13/Validation-of-compiler-and-IDE-Why,-when-and-how-to-Part-1
http://blog.cm-dm.com/post/2014/03/28/validation-of-compiler-and-IDE-Why,-when-and-how-to-Part-2
https://en.wikipedia.org/wiki/Compiler_correctness
http://processors.wiki.ti.com/index.php/Compiler_Validation

 

[Celtic-Tiger]

Hi Dobby! There is nothing really 'implied' about software validation and to that end it has sneaked in to ISO13485:2016 with a direct reference to 62304 (says you shall, but not how) in the same way that 14971 sneaked in. But before you loose the will to live, 14971 is actually your biggest friend here - what is identified as requiring validation and to what extent is foremost driven by risk; is the software a 'medical device' in its own right, or is it a component of the finished device, or just used in the manufacture of the device? I'd never suggest Wikipedia as a reliable source of credible info for anyone, but the links that Pads38 has provided to cm-dm-com are as good a place to start as any. What FDA go to great lengths to emphasise is that safety is not one and the same as effectiveness (14971 does not address effectiveness), and to be legitimately on the market the device must meet both its safety and effectiveness claims/requirements, so be very mindful of the 'fail safe' results in a device failing because of a software glitch and exposing the patient/user to unacceptable risk.

 

[yodon]

We have a fairly robust debate on that subject here where I work. I'm more in the camp that any "testing" is of little added value. As Celtic-Tiger points out, you do have the ability to scope the validation to what makes sense.

My typical approach is that you're going to test your software (the output of the compiler) anyway so any issues would most likely (risk based decision!) be identified in those test efforts. Thus, I recommend that compiler validation is essentially limited to:
* installation qualification - is it set up per manufacturer's recommendations
* analysis of known issues - are there any that might impact your product
* monitoring - periodic review of the published list of issues and review of any infrastructure changes that may impact (did you apply an OS patch that may not be compatible with your version of the compiler)

We've had no push-back on this approach. You would want to document the rationale and approach (and all activities done).

 

[mihzago]

Previous posters already provided great suggestions, that I agree with. I would add that you could probably also leverage how widely used a compiler is and/or if it's from a well established vendor. For example, if you use Xcode, you can be fairly certain that plenty of people used it before and identified most bugs or issues. Additional validation by you, other than making sure that it meets your requirements, won't probably add much value.

I would also suggest taking a look at TIR36 Validation of Software for Regulated processes; it provides validation framework and some examples. One of the examples is for C/C++ compiler.

 

[glork98]

Solid info above. It's reassuring that different organizations come up with very similar approaches:

Review the bug lists.
Track bugs that are discovered. (And put that in your plans)
Show it's validated as it's widely used and the defects don't affect the use.
Control the version in your configuration management system.

One thing my organizations have done is to run the compilers with optimization turned off. When looking over bug lists, I find that optimizations are often flagged as having problems. Makes debugging tougher, too, with variables discarded and that jumping around as you step through the code. With more powerful processors and larger, cheaper memory, gaining back those bytes and clock ticks isn't the priority it was.

 

[Dobby1979]

Thanks for the replies and helpful information guys. It is good to know that i am not the only one who has had these dicsusions.

We will need to validate but like previous posts said, it is up to us to determine that level and to weigh up the benefit. So many other validations to worry about / get validated so this one will have to sit down the list a little!

 

[Peter Selvey]

Similar theme to the previous posts, but would add that "validating" a compiler is not just time consuming and with limited value, but actually impossible and therefore not something that (any reasonable, experienced) regulator would expect.

As has already been said, just keep records of the compiler used, review any installation/use instructions, keep an eye on bug lists, periodically review.

Finally, for high risk devices never put too much faith in any single system, whether it is processor, your software or the compiler. Use a separate protection, different processor, engineer, compiler, i.e. independence/diversity. But only for the stuff that can really do direct serious harm.