Software in Medical Devices, by MD101 Consulting

Decommissioning

Decommissioning software can happen at the expected end of life of the SaMD, or earlier. In both cases, the end-user or a technician in charge of the device have to be informed. Users are supposed to cease using the SaMD. If no provision is taken by the legal manufacturer, end-users will continue to use it, for sure!

Case 1: Warning the user

The bare minimum is to send a mail (either paper or electronic) to the end-users to warn them that the device has reached its end-of-life. Doing this is what is required from a legal point of view, the responsibility of the legal manufacturer ends with this letter. It will work with professional users like health care providers. But, from a risk-based approach or a usability engineering approach, that won't work with the general public or lay persons.

Case 2: Software Licence

A more strigent solution is to have a license manager included in the SaMD. When the SaMD is installed, a license is allocated to the software instance or several software instances, depending on the license scheme. The license is valid until one of the following two terms is reached: either the end of license contract, or the SaMD end-of-life (which will also be part of the contract anyway).It means that that the licenses are managed by some operations department of the manufacturer, with a license generator and a registry of all licenses.
The way the software behaves when the license expires can be assessed with risk management. Having a stubborn SaMD refusing to open when the license expires can be a hazardous situation in some clinical contexts. Then, it will be preferable to display a warning to let the user continue use the SaMD anyway. Patient safety is one thing, legal matters are another.
Some licensing librairies don't require an internet connection. This is something better within a HCP network. But it requires to have periodic maintenance of the SaMD, with updates of the licenses when the contract is renewed.

Case 3: User account

A third solution, suitable with the general public, with lay persons, but also with mobile apps, is to manage user accounts. When the software starts, it sends a request to a server managed by the SaMD manufacturer, to verify whether the user can use the SaMD or not.
The server will answer "no" when the user account license expires or when the SaMD reaches its end of life. Then a warning can be displayed to the user with, if appropriate, an invite to update the SaMD version.
It means that the manufacturer has to implement and maintain such server. It means also that this server is subject to an exciting and joyful QMS software validation.

Recall

Recall of hardware devices is easy to understand. The manufacturer takes actions to either ship back the devices to their premises to decommission them (removal) or to fix the problem by maintenance operations (correction).
With SaMD, correction is the preferred way. The manufacturer makes the users or technicians install a bug fix, a new version. Users are informed that this new version exists, either by mail (cases 1 and 2), or by server notification (case 3).
In some rare cases, a removal is required. Then, case 3 is a lot easier than cases 1 or 2, which require manual interventions. In case 2, if the license manager isn't connected to the internet, it cannot be informed of the removal. Taking FDA wording, an effectiveness check will surely give better results in case 3.

Remark: in all cases, a recall requires some paperwork, and at least a recall letter of the manufacturer to the users. A fully automated solution like case 3 isn't enough, unless a function to display such letter and manage user's acknowledgment exists in the SaMD. Remark in the remark: Such function will be interesting to validate, at the border of QMS SW and SaMD, with electronic records management and probably some other traps.

Removal or Withdrawal

This is the decision of the SaMD manufacturer or the regulatory authority to remove a device from the market. The regulatory difference between the two:

• Removal the device is defective,
• Withdrawal the device is not necessarily defective.

Technically speaking, both are equivalent. Case 3 will be more effective than cases 1 and 2.
In all cases, the manufacturer has to send letters to the users to inform them of the withdrawal. In case 1, they cannot do anything else. In case 2, if the license manager is not connected to the internet, they cannot do anything else either. In case 2 with internet connection and in case 3, it is possible to inform the software of its status.

SaMD product specifications

If we are in cases 2 or 3, we can draft the following product specifications about lifecycle management:

• Case 2:
  • Lifecycle requirement 1: A license manager is present in the SaMD,
  • Lifecycle requirement 2: If an internet connection is present, the SaMD requests the license server about license status,
  • Lifecycle requirement 3: At startup the SaMD checks the license. When the license expires, the SaMD displays a warning to the user (or something else, choose your behaviour).
• Case 3:
  • Lifecycle requirement 1: At startup, the SaMD send a request to a server to know the current user account status and software status: valid license, expired licence, expired version, software update required, device recall,
  • Lifecycle requirement 2: When a software update is required, the user has to download and update the version prior to using it,
  • Lifecycle requirement 3: if the device is in recall, then a recall letter is displayed to the user. it is possible to send the letter to another device (mail, BT...) to let the user store it elsewhere or print it,
  • Lifecycle requirement 4: if the software version has expired, a message is displayed to the user with the reason of the expiration (enf-of-life, withdrawal...)
  • Lifecycle requirement 5: if the user account is not valid, a message is displayed to the user with an invite to renew it.

These kinds of product specifications are mostly suitable for mobile apps connected to the internet. But we could imagine that a SaMD manufacturer installs such server on the HCP network, with control on the server.
Then we have to consider whether this server is a SaMD or not. If yes, it is quite a good option to reorganize its architecture to isolate the license server software items from other software functions qualified as medical device.
We end with the requirement to validate that server as a QMS software, installed in the client premises (beware of IQ!). Such a valdilation is worth the effort, only if allows to ease all the processes described above.


Anyway, SaMD decommissioning, recall, removal and withdrawal can be performed like any other devices. This article proposed some other solutions taking the opportunity to use communication capabilities of software. They ease the process, once validated but they’re not mandatory.