Configuration and maintenance
If you are planning to release a medical device, you are required to collect information about device failures and issues in the field post-market surveillance. These include issues commonly known as ‘bugs’. Before releasing health software and SiMD, you must plan how you will maintain your software once it is in the field.
- How do I collect information about failures?
- How do I assess the risks posed by these failures?
- How do we implement fixes?
- How do I release fixes or patches to users when needed?
These questions form part of your maintenance process and are things that you should be doing, even if your application is not part of a medical device. You should be considering these questions early in your development cycle to ensure that the software has been designed with these maintenance requirements in mind.
As with all medical software development activities, you need to follow a risk-based approach. Each time a bug is fixed, there is the possibility that a new bug is introduced with unknown consequences. Your maintenance and development processes will need to focus on testing your product adequately and risk assessing all changes before implementing them. By doing this, you reduce the risk of failures on release and ensure that your products are well received by users.
Similarly, your software will rarely exist in complete isolation, even SaMD. For example, it may integrate with an independent cloud system that provides input data. What happens if the format of this input dataset changes? How will your product adapt to this? Can it adapt without being updated? What if a new partner wants to integrate your software into their system? Will you be able to update your product to support their interface definition?
For this reason, you must understand all the items that can impact your software (known as configuration items). You will need to record the versions of items and understand what makes them so important. That way, when these configuration items are updated, you can risk assess changes that have occurred and determine which ones (if any) are needed.
These configuration items can include Software of Unknown Provenance (SOUP) libraries, which you use to reduce your development timelines. If the owner releases an important security update, you will need to be aware that the change has happened, respond to the change and release your updated software in a reasonable time frame.