SOUP anomaly evaluation for MMA (Mobile Medical Application) IEC 62304 clause 7.1.3

PaulG

Starting to get Involved
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!
 

yodon

Leader
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.
 

PaulG

Starting to get Involved
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.
 

pmg76

Starting to get Involved
Hi PaulG, so what was your approach to solving this situation. We are dealing with the same problem and I don´t see a way around of listing all anomalies and analyze each one of them (which will be very time consuming).
Where did you put the list of anomalies?
How often do you check for new reported anomalies?
 

PaulG

Starting to get Involved
It was a challenge to implement this in practice. Every single SOUP item (numbering in the thousands) is tracked through a version-controlled list of dependencies required by the software. Each dependency has a corresponding repository which tracks issues through open source collaboration. If required to provide the anomalies, we could scrape these issues from every single repository; a process that would have to be automated as the total number of issues likely number in tens of thousands if not more over the entire collection of dependencies/SOUP items. We could also comb through each of these dependencies' issues tabs to identify issues that likely directly impact the software, but we found it far more efficient to take a holistic approach and test the software using our QA system. If the app as a whole works and passes QA, then the issues of the sub-components (the SOUP) are not as irrelevant in my opinion. If required by a regulator to provide them with the list we would make the decision of either putting together a list of specific issues from the SOUP repositories (a time consuming process that produces a list of relevant issues that quickly becomes out of date) and providing our rationale as above, or scraping every single issue in some automated way and providing it to the regulator.
 

ayedo

Registered
Hi PaulG, thanks for you post, we are dealing with the same issue, and it was helpful to us. I like the idea of using QA to verify that your SOUP works, but isn't it too big of a risk if the regulator asks you to comb through tens of thousands of issues and analyze them? Have you passed your audit, with the provided QA rationale?
 

PaulG

Starting to get Involved
We have passed our IEC 60601 audit including IEC 62304. This rationale was also provided to FDA in a 510k submission and no flags were raised.
 
Top Bottom