Documentation is a crucial process in essentially everything you do – it serves as a piece of evidence, and it also helps you keep track of everything that has been done and has to be done. The same goes for SOUP and OTS within medical device software.
The video below deals with this topic more in-depth than this blog post, so make sure you watch it. It is the second part about SOUP/OTS and is a part of our online course on Software for medical devices and IEC 62304 for which you can register by following the link.
Time to get technical. Just to clarify, although if you are reading this you are probably familiar with the terminology, SOUP stands for Software of Unknown Provenance, whereas OTS stands for Off-The-Shelf software. So basically, this post provides an overview of how to document the software you do not develop yourself. The term SOUP originates from the standard IEC 62304 while OTS is used in FDA guidelines. The definitions are slightly different but for the sake of simplicity, OTS will be used for the rest of this blog post.
Requirements for OTS
First and foremost, the use of OTS software shall be documented. This is because OTS software can be seen as any other item in your software system. But, since it typically has been developed for a non-medical device purpose, there is a need to compensate for the lack of appropriate medical device development. Hence a requirement that needs to be done.
You are expected to provide basic documentation for all OTS software. The documentation needs to consist of several points which basically answer the questions:
- What is it?
- What are the computer specifications for the OTS software?
- How will you assure appropriate actions are taken by the end-user?
- What does the software do?
- How do you know it works?
The first one, ‘’what is it?’’, is a general description that consists of the title and the manufacturer, and it also includes release information and associated documentation when possible. Here, you need to explain why this is appropriate for the particular medical device. You need to list potential design limitations, too.
When answering the third point, ‘’how will you assure appropriate actions are taken by the end-user’’, you may need to take actions to control, or even limit, how a user might change the properties of an OTS software. For example, if your software is dependent on a particular version of a graphics driver, then it would be inappropriate to allow the user to update the driver whenever there is a new release available.
Other documentation requirements
The FDA guideline about using OTS software goes beyond the requirements found in IEC 62304 and adds additional documentation requirements. In order to determine the additional requirements, you need to review the risk analysis to determine the level of concern for every OTS item in your software system.
When it comes to risk evaluation, consider OTS software items as any other items in your software system and make sure they are included in the software risk assessment, and assess how they can contribute to hazardous situations.
There are two additional requirements in the FDA OTS software guidance:
- Describe and justify the residual risk.
- Have special documentation when an OTS software, after mitigations, is still considered to be of major level of concern.
So, you need to be aware that you will need to invest some effort in qualifying these items before they can be released as a part of the software system.
In conclusion, OTS items will appear as any other item in the software system but need some special attention when it comes to documentation. But, when qualifying an OTS through for example verifications, you can apply the same procedures as the ones you use when developing the code yourself. Leverage what you already have and apply your existing toolbox to these items.
When it comes to maintenance, the main difference between OTS and software maintenance is that you need to go outside of your organization for bug fixes, patches, and updates.
Finally, make sure you include OTS software maintenance, including their cybersecurity aspects, in your software maintenance plan. In the plan, you can define the frequency for how often OTS maintenance information should be reviewed, for example quarterly.
If you think you learned something new from this blog post, see our other posts here.
Would you like to learn more about Medical Software Development?
The course is suitable for anyone working with software development, such as R&D engineers, quality assurance department and auditors of software development. The course does not cover actual coding.