Acquiring software from 3rd party company

[Luk35]

Hi All,

In my company we are considering to acquire software with source code and all copyrights and put it on the market under our brand. This software has intended medical purpose and now is available on the market. How can we do it to be compliant with IEC 62304? Is it even possible?
I know that in case outsourcing software development, 3rd party company needs have 13485 and introduce software lifecycle in accordance with IEC 62304. I know that whole software can't be SOUP.

I will be appreciated for any help!

 

[shimonv]

My advise to you is to first audit the company and its records and then develop a quality plan (which may warrant additional development and testing) with the aim of bringing the software to compliance with IEC 62304 followed by regulatory submission.

Shimon

 

[Luk35]

I have two scenarios based on audit:
1 Company has followed IEC 62304 properly but have different procedures and rules in ISO 13485 than our company. Can we continue maintaining software with our quality management?
2 Company is not complaint with IEC 62304 or can't prove it. Can we use IEC 62304 Legacy software track?

 

[shimonv]

1. Yes.
2. Not sure what you mean by legacy track, but for sure you will need to build a complete DHF for the software.

 

[Tidge]

I have two scenarios based on audit:
2 Company is not complaint with IEC 62304 or can't prove it. Can we use IEC 62304 Legacy software track?

For scenario (2), do you foresee treating the entire software system as SOUP? Since you describe also acquiring the source code and that it is already on the market... I don't think that would be particularly viable, for reasons.

 

[Luk35]

Tidge, definition of SOUP says: "Medical Device Software System in itself cannot be claimed to be SOUP" so I think it is not the way to go.

1. Yes.

Some report with differences can be needed? Or special procedure in ISO 13485?

2. Not sure what you mean by legacy track, but for sure you will need to build a complete DHF for the software.

I meant legacy software track from IEC 62304 4.4. DHF could be the most difficult challenge. I think good code repository will be the most important to make it.

 

[yodon]

I think a lot will come down to the software safety class. If Class A then yeah, you might be able to skate around some things. If Class C and they didn't comply with the standard, even taking the legacy track will be difficult at best, but that might be the only path!

Do bear in mind that documentation is a snapshot and the standard defines a lifecycle. Changes, etc. going forward would need to be done in a compliant manner so you'll need to ensure all the controls are in place.

I agree with @shimonv that an audit is your first step and find out what the gaps are, based on the software safety class.

 

[Luk35]

Software safety class is confirmed - A.
With class C, in my opinion, documentation must be almost prefect.

 

[yodon]

With class C, in my opinion, documentation must be almost prefect.

All documentation should be perfect! Class C documentation is just more extensive.