Software in Medical Devices, by MD101 Consulting

The IMDFR organization published in January 2024 a new document on Medical Device Software: Considerations for Device and Risk Characterization
Say briefly, this document is a gem!

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.

Usability is a requirement, which has been present in regulations since a long time. It stems from the assessment of user error as a hazardous situation. It is supported by the publication AAMI HE75 standard, FDA guidances, and the publication of IEC 62366 in 2008 followed by IEC 62366-1:2015. Although usability engineering is a requirement for the design of medical devices, most of people designing software are not familiar with this process. This article is an application of the process described in IEC 62366-1 to software design.

The FDA released one week ago a new draft guidance on Postmarket Management of Cybersecurity in Medical Devices.
This guidance is the sister of the guidance on Content of Premarket Submissions for Management of Cybersecurity in Medical Devices released in 2014. Both guidances address cybersecurity at different steps of software lifecycle: the 2014 guidance is about cybersecurity during design and development, the 2016 draft guidance is about cybersecurity during post-market surveillance.

At last! The FDA has published last October a guidance about cybersecurity that matters!
Not that the guidance previously published about Off-the-shelf software cybersecurity wasn’t worth reading it (Guidance to Industry: Cybersecurity for Networked Medical Devices Containing Off-the-Shelf Software), but its scope was more than reduced.

Validating the compiler used in software development is a recurring issue. To what extent a compiler should be validated, when, how and why?
In the same vein, we can extend the question of validation to all tools used in the software development environment: integrated development environment, configuration management tools, compiler (and linker), automated test tools.

Risk matrixes are a useful way to show graphically the ranges in which risks are acceptable, tolerable and unacceptable. Here is an excel sheet that automates the computation of ranges.

This is today the last article of this series about SOUP.
SOUP is a concept that we find elsewhere than in the IEC 62304 standard. Namely in the FDA guidances.

After having discussed about frameworks and runtimes in the last article, we continue today this series about SOUP with the case of open-source software.

We've seen in the last article, what is a SOUP and what is not a SOUP, according to IEC 62304.
We've also seen that a lot of 3rd party software are SOUPs, to begin with OS, drivers, runtimes, Just-In-Time (JIT) compilers and frameworks.
How to deal with those to be compliant with IEC 62304?