Menu
Menu
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.
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:
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.
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:
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.
With our medical device software course selection, you can choose between Software for Medical devices and IEC 62304 and SaMD, IEC 62304 and IEC 82304-1 depending on your interest and need.
The courses are suitable for anyone working with software development, such as R&D engineers, quality assurance department and auditors of software development. The courses do not cover actual coding.
Or if you’re looking for a tailored training to align with your company’s specific needs – contact us for inhouse training options.
Christian Kaestner is a consultant and entrepreneur with a wealth of knowledge about the medical device industry. He is an expert member of the project team authoring IEC62304 and also actively participated in the creation of IEC82304-1.
He has extensive experience of medical device development and, as a software developer, a strong dedication to software development. In the software domain he has worked in many roles such as software developer, project manager, auditing and quality management.
Receive FREE templates and quarterly updates on upcoming courses that can help you in your career! Subscribe to our newsletter now.
When you submit this form, you will be sending personal information to medicaldevicehq.com. To comply with GDPR requirements, we need your consent to store and use the personal data you submit. Take a look at our Privacy policy for more details.
Important! Please be advised that there will be scheduled downtime across our platforms from 13:00 CET Apr 26th to no later than 16.00 CET Apr 28th. During this period you will not be able to access the website or your account. For more information, please contact us at support@medicaldevicehq.com
