Software in Medical Devices, a blog by MD101 Consulting

To content | To menu | To search


How to bring legacy software into line with IEC 62304? - part 3

We've seen in the two previous posts several solutions on how to treat legacy software according to IEC 62304.
But there is nothing equivalent to this discussion in IEC 62304. The standard is silent about these situations.

IEC 62304 2nd Edition

The next edition of IEC 62304 is supposed to have a new section about legacy software. Unfortunately, this new revision is still in draft and should be available only by 2014.
If we want to find further information about legacy software, we have to look at standards and guidances outside the field of medical devices.
We don't have plenty of possibilities, the most obvious is to see how things are supposed to happen according to the good manufacturing practices in the pharmaceutical industry (the production infrastrucure that contains software).

GAMP about Software

The ISPE GAMP define the good manufacturing practices of the pharmaceutical industry. The GAMP is a set of guidances, some of them being about IT systems and laboratory computerized systems.
Like FDA guidances, ISPE GAMP has sections that focus on validation of software.
But this was not enough and the ISPE published in Pharmaceutical Engineering Vol 23, No 6 November / December 2003 a Good Practice Guide: The Validation of Legacy Systems. This document is charged by the ISPE but it's worth it.
In a few words, it contains the good practices about validation of legacy systems, from the most simple case (reuse) to the most difficult case where software has to be reverse engineered to align its design with the good practices.

Retrospective Validation

Another source of information is the concept of Retrospective Validation defined is this FDA Document.
Retrospective validation applies to anything that is legacy process. It is interresting to have a look at how the FDA expects thing to be. It focusses on the availability of historical data and on their characteristics.
IMHO, having legacy software data like those requested by the FDA is a good start. In case legacy software can be treated as a SOUP, the risk analysis is easier with such data.

Futher information

Besides the two sources of information I quoted above, the cupboard is getting bare. There is not much about legacy software in official guidances. There is possibly more to eat outside the medical industry, like in airborne or automotive. But that overpasses the field of this blog.
If you have some more information I would be glad that you share it!



Add a comment

Comments can be formatted using a simple wiki syntax.

This post's comments feed