Software in Medical Devices, by MD101 Consulting

Lifetime in hardware medical device

Hardware parts can rust, degrade, fatigue, any kind of ageing phenomenon that you can imagine. For example, the lifetime of an electromedical device can be based on the weakest component impossible to change, like capacitors soldered on the printed circuit board.
Remark: batteries are actually the weakest component, but they can be changed during maintenance operations.

SaMD Lifetime

Nothing rusts or degrades in software. Degradations of performance can be seen more as bugs than ageing. E.g.: if a software slows down, it’s because the memory or hard drive are full. It can be corrected by maintenance (emptying the HD) or by bug fix (fixing the memory leak).

Lifetime of software shall then be based on the context of use: when this context changes, the software turns out to be unusable.

Hardware

SaMD runs on hardware. When this hardware is obsolete, namely when the hardware manufacturer ceases its support, the software running on this hardware cannot be used any more. That rationale can be used with specific off-the-shelf hardware, like a medicalized PC, made to be used in the operating room.

SaMD also runs on consumer electronics hardware. In this case, the obsolescence can be estimated, based on hardware generation lifetime. E.g.: the technical characteristics of a PC of today can still be found in a PC in five years’ time.

SOUP, OS, browsers

SaMD needs SOUP to run. When the SOUP versions used by SaMD are obsolete, this SaMD cannot be maintained any more by its manufacturer. This is especially the case with security issues that won’t be fixed by the SOUP vendor or the open-source project.
SaMD can live with an obsolete version of a SOUP as long as there is no critical issue published on this SOUP. However, when that SOUP is an OS or a browser, it is almost impossible to continue using the SaMD on a new major OS/browser version, without revalidating the SaMD.

Clinical practice, clinical data

Hardware and SOUP obsolescence are classical rationale to define SaMD lifetime. Clinical practice is a newcomer in this domain.
SaMD is designed with the help of clinicals, where their practice is translated into a SaMD intended use and products requirements. Practices can evolve quite quickly in the world of digital health.
Thus clinical practice can be a good reason to limit the lifetime of a SaMD to something shorter than hardware or software obsolescence. This is the case for machine learning algorithms. Clinical practice generates clinical data, which ML algorithms aren’t trained to. Then, the ML needs to be retrained and revalidated.

Usual lifetime

The usual lifetime that can be defined for SaMD depends on the technology used:

• SaMD running on a Windows PC could have a lifetime of 3 to 5 years,
• SaMD running on a Linux LTS distribution could have a lifetime of 5 to 10 years (10 is optimistic),
• SaMD mobile application lifetime could be limited to 2 years.

Mobile apps

IT could be even more tempting to define a shorter lifetime for mobile apps, like 1 year. This is not appropriate for SaMD, when the time needed to CE mark it with a Notified Body can be more than 1 year! Given how burdensome CE marking SaMD can be, less than 3 years means being in a perpetual conformity verification process.

Lifetime vs Release

Lifetime and release versions aren’t equal. The lifetime starts when a major version is released. Then, you can have several minor release versions within the lifetime of a SaMD. You can refer to that article on release to see what a release is and when it happens.

Regulation vs technology

Medical device regulation isn’t well adapted to the frantic pace of technology changes. OS’es are updated with major changes on a yearly basis, browsers are continuously updated (can you remember the last major update of Firefox?).
The regulatory life rhythm looks like geological times, from a software point of view!

As a consequence, defining a lifetime compatible with regulatory ages requires monitoring SOUP, their updates, their obsolescence, in order to assess if SOUP changes trigger major SaMD updates and revalidation.
This is what you find in clause 6.1.f of IEC 62304.

Cloud software

What you read above is even more subject to interpretation with cloud software. Updating cloud software monthly or quarterly is necessary, to follow the pace of continuous changes of the underlying cloud infrastructure.
However, lifetime is still a requirement for cloud software. The only solution is to define a major version, a milestone in the cloud software lifecycle. All subsequent versions will be minor changes, until a new major version is released.

The game is to validate, CE mark and launch this new major version before the end of life of the previous one!