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):
IEC 62304 has Software Safety Classifications for each
medical device software – A, B and C. This also defines the level of
documentation required for SOUP’s.
SOUP documentation requirements for IEC 62304:
Title | A,B,C |
Manufacturer | A,B,C |
Unique designator (version number) | A,B,C |
Functional Requirements | B,C |
Performance requirements | B,C |
Software required | B,C |
Hardware required | B,C |
FDA 2019 documentation requirements:
Minor Level | Minor Level | Moderate | Major Level |
Hazard | Hazard | Hazard | Hazard |
Basic | Basic | Basic | Basic |
| Hazard | Hazard | Hazard |
|
| Describe and | Describe and |
|
|
| Special |
You see the documentation burden increase based on the risk
level. This makes sense – the more there’s at stake (in terms of patient
safety), the more careful we are.
In the case of IEC 62304, you can imagine having to spend
maybe half an hour per SOUP on documentation. Modern apps can have anything
between 20 and 200 dependencies, so the workload can be up to 100 hours or 2.5
weeks.
For the FDA, the workload increases considerably. Basic
Documentation overlaps with the 62304 documentation mostly. A Hazard Analysis
can also be quite simple. But doing full blown risk management is a lot more
work, as is the Special Documentation. This can easily take a few days per OTS.
As a consultant, I have peeked into many companies’ software
documentation. SOUP and OTS documentation is rarely 100% compliant, and often
our team ends up doing the heavy lifting of getting all that documentation in
place.