How to implement a legacy software gap analysis as required by IEC 62304-2015?

Legacy software that was not built in line with IEC 62304 is often a tough nut to crack for many medical device manufacturers, especially when there’s a need to design a new version of a medical device or implement changes to the existing one.

What’s the most convenient and recommended way to approach legacy software? How to implement a legacy software gap analysis required by IEC 62304? Krzysztof Minicki, our Director of Healthcare and Life Sciences, discusses the issues and explains possible ways to align legacy software with the requirements of IEC 62304.

What is legacy software?

Legacy software is the kind of software that already exists in a medical device introduced to the market before 2006 when the first version of IEC 62304 came into force and is still marketed today. Even though it’s been already 15 years, such situations can still be encountered.

Legacy software vs SOUP

Sometimes legacy software is mistaken with SOUP (Software of Unknown Pedigree). The confusion results from the fact that both were developed without following and documenting software life cycle processes.

How to bring legacy software into line with IEC 62304?

There are a few approaches you can take when dealing with legacy software, depending on whether it will be affected by changes or not.

1. There will be no changes to the medical device software, including legacy software

First of all, as long as you don’t change anything regarding the medical device software that the legacy software is a part of, there’s no need to take action. Suppose the legacy software isn’t affected by changes. In such a case, the most straightforward and recommended approach is to treat it like a SOUP, external software that you have no control over, and follow the appropriate steps required by the IEC 62304.

Things get complicated when you want to make changes to the legacy software part, and the medical device software as a whole, not necessarily including the legacy part. Imagine your medical device software as a circle, where legacy software is just a slice of it. You can take a few approaches, depending on whether you want to make changes to any part of that circle that isn’t that one slice or you want to make changes to the whole.

Let me illustrate it with an example. Let’s say 15 years ago, some company released a medical device used to visualise data, like an ECG monitor. The driver for this device wasn’t built according to the requirements of IEC 62304 because the standard was not yet in force. Now there’s a need to change the colours it displays. In such a case, you don’t have to make any changes to the driver because it will communicate with the monitor in the same way, simply the commands regarding the displayed colours will be different. Such a driver can be treated as a SOUP.

However, if you’d like to eliminate margins on the screen, it won’t be possible without changing the display mode. That in turn, leads to making changes to the driver, or in other words our legacy software. In such a case, you have to align it with the IEC 62304 requirements. We’ll describe how to do it in the following paragraphs. For now, let’s get back to the strategies for a minute, as there are at least two more you can apply in this case.

2. There will be changes to the medical device software and/or the legacy software

Firstly, you have to answer yourself a question: is the change significant and broad enough to affect the legacy software or not. If it’s the former and the change impacts the legacy software, it can no longer be treated as a SOUP, but a full redesign is needed and the IEC 62304 standard must be applied in full. Otherwise, there would be too many difficulties and it will be tough to maintain.

Another possibility is that we divide legacy software into components that will be changed and those that won’t, but they make less than 10-15% of the whole. Then, we approach the revised part of legacy software like a SOUP, just like we’ve already explained. Additionally, we can build an extra Risk Mitigation Integration Layer that will give us protection against possible negative consequences of integrating a SOUP with a medical device. The risk associated with such integration must be assessed to determine if there’s a need to implement additional control measures. This approach is quite frequently used when dealing with legacy software.

Another approach is to analyse and assess the legacy software according to the IEC 62304 standard, precisely chapter 4.4. It says that you can make a full design development according to all the requirements described in chapters 5-9 and hence nothing else should be done about the legacy software. There’s one significant disadvantage to this approach, though: it generates very high costs.

Now that we have the most common strategies described, let’s move on to the how-to part.

How to align the legacy software with IEC 62304?

Step 1: Legacy software risk assessment

First of all, according to the risk management requirements, we have to analyse the architecture of our solution and determine legacy software’s risk class. There are three risk classes: A, B and C. If our medical device belongs to one of these classes, especially the high-risk C class, then we should check if a decomposition can be performed.

Once the decomposition is done, we can determine if the legacy software is responsible for non-medical functions of lower risk to the patient, for example, data transmission, or it’s a critical component of class B or C. Based on that, we have to determine whether we can treat our legacy software as a SOUP or it’s not an option, for example in a situation when the medical device belongs to class C and our legacy software belongs to class C too, while other components qualify to lower risk classes.

The first thing that we should consider doing the risk analysis are the potential problems that our software causes based on user feedback. In our risk assessment, we have to describe all activities that impact the device, organisation, processes and patients.

Another thing is to assess the risk associated with the integration of our legacy software with other components of the medical device, no matter if they are also part of the legacy software or not. We have to check if there were any risks already described for our medical software and what control measures were implemented to lower or limit these risks and validate if our legacy software impacts these control measures. If it does, we have to assess the possible risk and check if these measures will still be effective.

If we now refer to our ECG monitor example, the margin on the screen might have been implemented as a risk control measure so as no important information gets cut off, so if we removed it, there might be a risk that such information is missed. In such a case, additional risk control measures should be defined and included in the Risk Management File.

The next step is to conduct a gap analysis.

Step 2: legacy software gap analysis under IEC 62304

When the risk class of our legacy software is determined, we should conduct a gap analysis and check if we don’t miss any required documentation as per chapter 5.2 (Software requirements), 5.3 (Software Architecture Design), 5.7 (Software System Testing) and 7 (Software Risk Management Processes).

At the minimum, our legacy software should:

• fulfil the requirements regarding functionality, efficiency, safety, etc. as described in chapter 5.2;

• be included in the software architecture documentation with a clear description of its limits, the isolation and integration elements are as well as the plan of integration with other components including possible risks associated with their respective classes, as per chapter 5.3;
• have all the necessary tests performed and documented according to chapter 5.7;
• have the risk management processes implemented as required by chapter 7.

The gap analysis helps us determine what documentation elements regarding the legacy software miss some vital information that needs to be complemented. Also, it gives us a better picture of the potential risks and how important legacy software is for medical device software as a whole.

Based on our findings, we can prepare a plan that includes the gap analysis results as well as thoroughly described steps that we’re going to take to fix the identified issues. The timeline for implementing the steps depends on how critical the risks are and how severe the consequences for the end users may be. You should also remember to justify why you want to continue maintaining the legacy software, for how long and if you’re planning to discontinue using it in the future.

To sum up

If you don’t plan on introducing any changes to your medical device software, the most convenient and recommended approach is to treat it as a SOUP, if possible. This way, legacy software will be much easier to maintain. However, no matter what approach you choose, you always need to do your due diligence: test the legacy software, assess the risks, validate the control measures, determine the missing requirements and describe your plan of action.

For more information on conducting a legacy software gap analysis, please refer to IEC 62304.

If you need help choosing the right approach to your legacy software or conducting the gap analysis, don’t hesitate to reach out to Krzysztof Minicki using the form below.