OTS and SOUP Software Documentation Requirements

Hello everyone,

I am a software manager for a company which produces a Class III medical device. I am extremely curious about what other companies are doing with regards to the level of documentation required to use OTS/SOUP software in these types of devices. I am getting serious push back from team members who think we are making a mountain out of a mole hill.

We are purchasing an OTS component which we incorporate into our device. It contains HW and SW. The first step we did was to classify the level of concern of the SW in the OTS component as a Major Level of Concern. From that I used the FDA guidance for OTS software as a framework.

Because the level of concern is major we must produce "Special Documentation" which includes:
Provide assurance to FDA that the product development methodologies used by the OTS Software developer are appropriate and sufficient for the intended use of the OTS Software within the specific medical device. FDA recommends this include an audit of the OTS Software developer's design and development methodologies used in the construction of the OTS Software. This audit should thoroughly assess the development and qualification documentation generated for the OTS Software.

I read this as requiring us to have very close to the same level of documentation as if we developed it ourselves. I have stated that we need (at a minimum):

• Software requirements
• Software design document
• Verification protocol and report
• Traceability from requirements to test

I am looking for a sanity check to see if I am requiring too much for a major level of concern OTS item.

Any feedback is greatly appreciated.

A Quick Bump!

Can someone help?

Thank you very much!!

I don't think that you are overdoing it. Your device is class III and you have identified the component as a major concern: Of course you should be thorough and cautious.

You will need to have as close to the same documentation as you would yourself generate as possible, otherwise you will lack security for the performance of the software. Ideally you would have access to the code, and submit that to independent review too.

Word of caution; be careful not to confuse OTS with SOUP. Generally OTS is considered to be a standard item that is available for purchase by anyone. SOUP does not fall into that category - SOUP can be legacy software that is proprietary to you, it can also be software that you have had developed by somebody else who is not willing to show the coding or transfer the coding and design to you - it may even be software developed by somebody.who is no longer in business.

In addition to your issues related to the specific documentation don't forget that you will also need to address the issues regarding change management at the SOUP supplier and also their competency and training procedures (I am assuming that you will need to have more than one supply of this item).

The landscape for what companies are doing for OTS validation varies from doing absolutely nothing to dedicate a reasonable time of their valuable resources for this purpose.

Actually I would caveat using any non mandated guidance as a mandated one.
On the other hand as long as you do not receive a lovely warning letter or non conformity from external auditor, people may consider this subject as a little or no need exercise, so it is pretty difficult to find the right way.

If you can do an audit on your supplier site, it is okay, but as the guidance points it out, you can apply risk mitigation measures for this purpose too. Moreover it is not likely you can do it in most of the cases. And there is a bunch of other cases when there is no meaning of such audit, because the supplier is not dedicating its development life-cycle to medical devices, so there is no or minimum benefit having such audit.

The other angle on OTS softwares is the case when OTS is a freeware/shareware/opensource. In these cases you also should make sure that not to incorporate something subject to intellectual property rights into your device.

As regard to the necessary documentation I am not pretty sure you can do that comprehensive exercise in all cases.

For me the emphases should be on the safety and effectiveness aspect of the OTS, how it does interfere with you finished medical device, how these principles are affected if affected at all.
When you identify the cases based on the use of the particular OTS that could affect the safety and effectiveness of you finished device you can define the causes to set measures to mitigate them.
Basically I think you pretty well can utilize your risk management process already have for a Class III device.
Effectiveness is another question, you should do some analysis I guess, or at least rationalize why not considering it necessary.

Cheers!

Thanks to everyone who replied! Here is a bit more information.

1. The vendor is willing to let up come down and do an audit of their systems but they are unwilling to give access to their source code even under an NDA. I have a very strong feeling that they will not pass the audit. They are not a medical device company and as such do not have the quality systems or design controls in place.

2. We have done a hazard analysis with regard to the OTS software and included any mitigations possible. Even after mitigations the OTS software is a major level of concern.

Sagai, thank you for the clarification of SOUP vs. OTS. This is definitely OTS as the overall device is a commercial off the shelf part. The software is not Open-Source but rather custom firmware for their piece of hardware.

Without any documentation from the OTS software vendor and no knowledge of what the software is doing, is it acceptable for us to generate requirements detailing what the device (as opposed to the software alone) is required to do and test against that? To me the standard is pretty clear that you must have almost the same level of documentation for the SW as our SOP's call for otherwise everyone would outsource software development to avoid some of the documentation work.

Thoughts?

Actually that credit is for Gert, but I am happy to invite him having a beer as a compensation and keeping your credit.
However ... hang on a minute ... I should be careful with Danish guys, they can come full armored without having the invite, ... oh ... bullocks ... they may already gave up that historical habit.

ssseeeriously ...

I definitely suggest to use common sense rather than being lost in the letters of any standard.
Only would ask a pretty simple question ...
"Did we accomplished everything sensible to ensure the device will be safe and effective and at the end the device is still worth to be used for curing patients ?"
our a very simple question ...
"Would I let my relatives to be cured with that device?"

In a nutshell that would be all.

and at last ... sorry Sir ... how did you evaluated your Supplier and their deliveries if you have not already completed those requirements and tests you referred at the end of your post?

Cheers!

Hi Anderson,

I'd like to add my 2 pennies to sagai and gert's perfect answers.

Auditing a SW/HW supplier which is not in the medical devices field is somewhat not relevant. They probably don't know anything about FDA guidances and the like and won't have a chance to pass an audit.

This OTS has to be thought from the point of view of risk management. If your OTS is a major level of concern, I suggest to adapt your design process and documentation to focus on what it does to better define the consequences of its failures.
Suggested design steps are:
1.system-level requirement specifications, with all what your medical device shall do
2.component-level requirement specifications, split in two documents, with:
a-HW/SW requirement specifications of your COTS
b-HW/SW requirement specifications of your home-made components
Both having traceability with document #1
3.architecture design of the whole, with traceability with #1
4.detailed design of your home-made components, with traceability with doc #2
5.HW/SW tests, split in:
a-HW/SW tests of the COTS, with traceability with document #2.a
b-HW/SW tests of your stuff, with traceability with document #2.b
6.HW/SW tests at system level with traceability with document #1

Doing this, you can insulate what your COTS does and the impact of its component-level functions on the system level functions. It helps to go into the details of risk assessment of COTS failures.
Based on this, you may also define additional requirements in your own components to define fault tolerance or auto-recovery functions in case of HW/SW failure of your COTS.

To sum-up, an audit is the best way to annoy your supplier with a poor level of return. And it won't prevent any HW/SW failure. Deep design is the good solution, it helps defining what the COTS shall do, define detailed technical requirements that your supplier can understand and, perhaps (dreaming?), customize its product to your needs.


Regards.

Mitch.

c.mitch said:

To sum-up, an audit is the best way to annoy your supplier with a poor level of return. And it won't prevent any HW/SW failure. Deep design is the good solution, it helps defining what the COTS shall do, define detailed technical requirements that your supplier can understand and, perhaps (dreaming?), customize its product to your needs.

Click to expand...

I beg to differ

I think that an audit may bring a lot of good, to both the supplier and to Andersons company. However, the audit should not focus on IEC 62304 or FDA's gudiance. The audit should focus on the suppliers procedures for development, documentation, training, etc. This should give a good insight in to the company and identify if there are any week spots that needs adressing. This is where Andersons company may be able to help the supplier improve, and thus bring benefit to both companies.

I agree with you eventually.
I experienced both situations (being in supplier company and being in purchaser company) and I was thinking about the kind of audit where the purchaser is not here to help the supplier but only criticize, or the kind of audit made by a NB.
But doing an audit like the one you propose is definitely the right way. I even see it more like a training to help a supplier which doesn't have a clue of medical devices constraints.

Regards.
Mitch.

Can anyone help me with SOUP labeling and version control procedure for software in medical device?