“The Gray Sheet” has an article called CDRH Software Forensics Lab: Applying Rocket Science To Device Analysis. Can it really be true that CDRH is doing static code analysis for detecting software defects in recall investigations?
Static code analysis has been around for a long time. I remember using Lint back in the old days. Nowadays all commonly used computer languages (like C and C++) have fairly advanced analysis tools. For Microsoft .NET languages there are tools like FxCop and ReShaper. These tools are great for spotting trouble areas and maintaining code conventions during the development process.
I just have a hard time imagining a process using these tools that would successfully detect real defects in complex medical device software. Especially software that’s controlling hardware devices, doing communications tasks, and recording sensor data. Also, what about all of the assembly language code for embedded processors and DSPs?
Anyway, from the article:
A recent review in the forensics lab found 180 “questionable constructs” in 100,000 lines of code, but only two turned out to be real design issues, Taylor said.
He also pointed to two other cases where static analysis of the software did not find any bugs, thus clearing software as a root cause candidate in the recall investigations.
These statements beg the following questions:
- Were the two “real design issues” related at all to the device failures?
- Just because no static analysis “bugs” were found, why does that exonerate the software from being the cause of the failure?
I’m not impressed that static analysis has “been embraced by the aeronautical and automotive sectors”. IMHO this approach just seems like it would create a lot of work for very little return. The manufacturer that produced the device should be responsible for tracking down and fixing the software (and/or hardware) defects.
I’ll stop now.
Check out Tim’s post on this subject: FDA Raises Bar on Medical Device Software Testing.