Software in Medical Devices, by MD101 Consulting

The FDA published in July the final version of the Guidance on Multiple Function Device Products. Despite the absence of the word "software" in the title, it addresses at first software medical devices. It also addresses hardware devices, but we will focus on software in this post.

We saw in the last post how to validate a software development tool. But we saw also that validating a compiler this way is not a satisfactory task.
Then: Why, when, and how to validate a compiler?

We saw in the first article of this series, what is a SOUP and what is not a SOUP, according to IEC 62304.
Then we continued in the second article by having a look at OS's and drivers.
Let's now see how to deal with runtimes.

In the last two posts, we've seen what a software unit is, and when to do software detailed design, according to IEC 62304 and FDA Guidances.

In two previous articles, I talked about the differences of bugs, software failures, and risks.
I left the discussion unfinished about the probability of occurence of a software failure or a defect.
I think that assessing the probability of occurence of a software failure is a hot subject. I've already seen many contradictory comments on this subject. It's also a hot subject for software manufacturers that are not well used to risk assessment.

A bug can lead to a software failure.
Having bugs is a risk.
Having a software failure is a risk.
A software failure is not necessarily a bug!

Do you follow me?
If not, let me give you some more explanations.