The regulations around external software components are mostly risk-averse and safety oriented. This negates the benefit of updating components frequently. In this article, we look into this contradiction.

Currently, when developing software for medical devices, there are two sets of rules that deal with external software components: IEC 62304 and the FDA guidance from 2019 (‘Off-The-Shelf Software Use in Medical Devices’).

IEC 62304 defines SOUP as follows:

So it’s really part of the software – a package, a dependency, a module linked in.

The FDA casts a wider net with their definition of Off-The-Shelf software (OTS):

These definitions already give you a sense of what the regulators are afraid of: software developed outside the building where the strict rules don’t apply. It makes sense – everything developed under IEC 62304 is very strictly controlled and documented from start to finish, and as such can be traced and audited.

But let’s look at the reality. Any modern app, web, mobile or otherwise, written in a language like Python, PHP, .NET or JavaScript uses tons of open source libraries. Open source claims to be more secure because of the ‘many eyeballs’ principle. In practice, this is often proven to be correct.

To make matters worse, the frequent and useful updates to these open source libraries are not easily integrated into the medical device software. Because any update to the SOUP’s, like an update to the latest version, triggers a full new software release, with all the testing (verification) that comes with that.

So why are all these open source libraries treated with such disdain? Part of it is healthy pessimism – it assumes that software not created under the strict rules is inferior, or at least unproven. This is true certainly for closed-source software, but much less so for open source.

The FDA is often the pioneer when it comes to new regulations in software for medical devices. The IEC 62304 standard is completely outdated, but the attempts to modernize it have recently failed again, setting back any new version by at least five years.

If you want to get an insight into the FDA’s thinking, check out the draft guidance on  cybersecurity for medical devices. In it, they borrow a principle that comes from the telecoms industry – a Software Bill of Materials (SBOM). You publish what OTS is in your software in a machine readable format, including version numbers. This can be propagated (in an automated way) through the entire supply chain. There are tools that can scan these SBOM’s and detect known defects and report on them. This way, there is full transparency and the users (clients/patients/HCP’s) can know what potential defects the medical device has.

You can imagine hospital IT teams keeping a very close eye on this as part of their cybersecurity defense.

This guidance is in draft status, meaning you don’t have to follow it. The FDA has a history of taking guidance documents from draft to final without major changes. That means this rule could go into effect in a year or two, upsetting the medical device software market profoundly.