Search the Elsmar Cove!
**Search ALL of** with DuckDuckGo including content not in the forum - Search results with No ads.

SOUP anomaly evaluation for MMA

I'm working on an IEC 62304 compliant project for a mobile medical application with mostly class A and some class B elements. The standard requires in clause 7.1.3 that published SOUP anomaly lists be evaluated for contributing to potentially hazardous situations. In this project, many of the software components are open source, so we are looking at issues lists posted online. However some of the open source elements, such as Angular, have hundreds of issues posted online. Does anyone have experience on how to address this 62304 requirement on a practical basis for open source software? This is a startup company so developing an in-house alternative to some of the open source building blocks isn't practical and in my opinion may even introduce more risks since it wouldn't have the established history and user base. Any feedback much appreciated!


Staff member
Super Moderator
Those lists can certainly be painful to deal with. If you can export them, hopefully there is enough information to help you sort / filter. Many times you can exclude large chunks based on revision or functions (not) used or ...

Alternatively, look at trying to isolate SOUP use to non-critical functions. May not be possible but if so, may not require such a big development effort as completely re-writing the SOUP.

Interestingly (and slightly off topic), we have one client (large company) that has decided they will no longer allow SOUP in their applications and are requiring (outsourced) software development to basically copy the SOUP code and adapt to internal standards, etc. The benefits of this approach have been, um, questioned.
This approach makes sense, but I can already anticipate the collective groan from the development team...

We also work with another (large) client that expressly forbids open source software. I can see their rationale. Thanks for the input.
Top Bottom