Can SaMD consist almost entirely of Software of Unknown Provenance (SOUP)?

CharmaineK

Registered
Hi there,

My company currently has software on the market that is a non-medical device and thus has been developed outside the MDR framework. We are now in the process of developing a version of our software that we will have on the market as SaMD. It will have a very similar architecture to our non-medical software besides a few, slight additions.

As we now begin to step into the realm of international standards/QMS/MDR (possibly even FDA regulations) to transition our product to SaMD, I am beginning to wonder if it is at all necessary to transition completely? Could we have a non-medical device on the market that we continue to develop outside of the MDR (but most likely still within our soon-to-be-set-up QMS) and then, when it comes to our SaMD, we use full modules from our non-medical device directly as SaMD SOUP? Meaning our SaMD will then mostly consist of various different SOUPs.

As far as 62304 goes, I see that each SOUP will fall under the "generally available/not developed for a medical device" definition of SOUP. But then, at the same time the software will not necessarily be completely "unknown" as we will obviously be the manufacturer for all of the modules we take from the non-medical device software. It also won't be "legacy" software as we will continue to have this on the market and build/develop it (outside the MDR) alongside our SaMD (under MDR).

There are other reasons I am leaning towards the two products route (broader usage/non-specific audience for example) but I wanted to see if there were any additional precautions we should be taking (as a manufacturer) if we go down this SOUP route? Or can we just treat each module as SOUP as per 62304 and build our SaMD this way?

To clarify - we have spoken to our competent authority about both products and they do not have any objections to our non-medical device software being outside the MDR and likewise, to our SaMD being a medical device.

Thank you in advance for any help/advice :)
 

yodon

Leader
Super Moderator
Since you own the software, I think your best route is through the Legacy software provision.
 

CharmaineK

Registered
Thanks for your response!

I also thought legacy software was a route for us but my understanding of the description of legacy software in 62304 was that it relates to medical device software that was legally on the market. We ruled this out particularly because our software on the market is not a medical device (and indeed, never will be as the SaMD will be on the market as a separate additional product) and we will also continue to have it on the market as a non-medical device (and thus outside the scope of 62304).

We will also make changes/updates to our non-medical device software as the development of our core software progresses. No doubt above the “minor” category of changes accepted for legacy software. So I’m again leaning away from the legacy option.

If SOUP is not the best option for manufacturers, I’m thinking possibly re-engineering our core software is then our most appropriate approach?
 

yodon

Leader
Super Moderator
Good point.

Since it's under your control, though, it can't be SOUP. I still think you'd be in a defensible position by considering it legacy and following that approach. Alternatively, just apply the entire standard. If you're not Class I, the gap assessment / closure may drive that anyway.
 

CharmaineK

Registered
Yes, we’re taking the approach to apply 13485 to all areas of development (both medical and non-medical software) to maintain a uniform approach of working/quality standards so I guess applying 62304 to both products may also work for us too.

Thank you for your input!
 
Top Bottom