How to document discontinuation or end of life for a software version ?

[jradford]

I do not see anything in the 62304 standard about discontinuing or end of life a software version?? Is there a guidance out there to help with this?

So, we manufacture medical devices. They are operated through software we design and code. This same version of software runs our whole family of medical devices. When we made a change to one of the devices, so we had to make changes to the software. It was determined to increase the version level of the software from version 7 to version 8. So basically version 7 is obsolete and no further upgrades would be made to it. There was not an end of life for the medical device product.

So I would believe there needs to be some report about ending maintenance on version 7 software. Anyone else run into this?

Thanks

 

[Stijloor]

A Quick Bump!

Can someone respond?

Thank you very much!!

 

[c.mitch]

Hi,

There is no formal requirement in IEC 62304 about that. You may rely on problem resolution procress, which tells you to inform parties about problems.
However, this is more at the ISO 13485 level, or US QSR level, that obsolescence should be treated, by informing users of the SW obsolescence and the need to upgrade it.
Depending on how you manage the traceability of sold products, this could be very easy, or a nightmare!

There was not an end of life for the medical device product.

This is very astonishing. Most of regulations require to define a device shelf life (even for standalone software, but this is another subject). If there is a shelf life, then all products older that their self life shouldn't be upgraded. Unless you upgrade them as a goodwill gesture.

 

[Spazz]

When we made a change to one of the devices, so we had to make changes to the software. It was determined to increase the version level of the software from version 7 to version 8. So basically version 7 is obsolete and no further upgrades would be made to it.

While I'm not an IEC 62304 expert, this sounds like a revision of existing software and not an end-of-life. It could be handled through your change control procedure and software maintenance plan.

 

[Mga_MD]

do IEC 62304 and IEC 82304 have any requirement that states which activities should be performed when a Software is discontinued?

many thanks!

 

[Tidge]

do IEC 62304 and IEC 82304 have any requirement that states which activities should be performed when a Software is discontinued?

The only direct requirement I am aware of per 62304 is that as part of the Software Maintenance Plan it is necessary to consider obsolesence.

Indirectly, I think a case can be made that the Configuration Management Plan ought to include specific mechanisms for control of obsolete software.

 

[Mga_MD]

hi tridge, thanks a lot!

may I take advantage to also ask the following:

- if the Software (SW) is discontinued and we have evidence that users are no longer able to access the SW, it is necessary to keep doingPost Market (PMS) activities?
-do we have to inform the NB about the MDSW discontinuation?
-do we have to keep the QMS, Technical Documentation stored for five years as per MDD administrative provisions (our SW is currently under MDD certificate)

thanks!

 

[Tidge]

I saw your question in another (revived) thread. This is a regulatory question, and the answer depends on which regulations you intend to comply with. Software (SaMD or as a component in a Medical Device) ought to be treated like other medical devices. In the case of the USA, I would be conservative and leverage 21 CFR 820.180(b):

Record retention period. All records required by this part shall be retained for a period of time equivalent to the design and expected life of the device, but in no case less than 2 years from the date of release for commercial distribution by the manufacturer.​

If it is SaMD, you should be keeping all records for at least 2 years after you formally obsolete all versions of the SaMD. I would also recommend that you still allow for the normal life-cycle activities like complaint intake during this period as well. My recommendation is that you leverage the existing Risk Management Plan and its regularly scheduled Periodic Risk Reviews to guide you in the End-of-Life phase.

I suppose it is possible that you may precisely know where all instances of the software is, and could have objective evidence that its use has been everywhere discontinued (akin to a recall)... and that you may be tempted to argue that the "clock started" sometime in the past. Even if you believe a case can be made that "everyone stopped using our software five years ago", and even if you think you have airtight evidence of this, I would still recommend that you formally implement and EoL plan consistent with previously existing RM plans. If you've never done a periodic risk review for it before, I would say that you ought to plan on adhering to the full length required by regulations.

Other regulatory authorities may have different periods of time, depending on the nature of the device. DHF/DMR records for SaMD should be pretty inexpensive to keep around. Sales/service/ERP/complaint records may be a different matter. I would consult with your regulatory affairs officer/NB representative.

 

[Mga_MD]

thank you so much for the clarifications.

I add more context related with the situation below:

-we don't want to sell anymore a SaMD that it is not yet on its EoL, but we only want to do that discontinuation in one country

Do you think your previous answer would change based on these? do you forsee any difference on the answer you provided before?


thanks a lot in advance!

 

[Junn1992]

discontinuation in one country

You would need to zoom in on the country specific regulatory requirements then.