Software in Medical Devices, by MD101 Consulting

Type of legacy software

The type of legacy software may have a huge impact on the way it will be managed in a software development.

Legacy software wasn't in the same class of risks

Software development usually begins by determining the class of software. It's interesting to determine in which class the legacy software would have been, if IEC 62304 had been applied when it was developed.
If both cases are in the same class (eg software in old device and software in new device are in class B) then this is consistent to reuse software in a new device. But if both cases are not in the same class, things can be more tricky:

• Old = class A, new = class B or C: raises a red flag, does this legacy software match the high standards of the new context?
• Old = class C, new = class A: raises a red flag, does this legacy software match the low standards of the new context?
• Old = class C, new = class B, or Old = class B, new = class A or C: very context-dependent.

In other words, if there is a difference of class in the old and new contexts, then the question whether the software matches its new context is relevant.
That said, this analysis is preliminary to other questions and should be made at first.

Legacy software is a framework

This is the worst case. Legacy software is a framework which offers a long list of services. They are used by newly developed software but are not documented. Doing the documentation would be a tedious task, especially for software in class C.

Treat it as a SOUP?

We saw in the last post that legacy software can be treated as a SOUP. The problem with a framework, is that the SOUP is bigger than the new software. Even if IEC 62304 doesn't define any criteria on the size of SOUPs, it is conceptually difficult to have a SOUP bigger than own-developed software.
If the framework is supposed to be changed during the new development cycle, then cases described in my previous post are there to define an action plan.

Don't treat it as a SOUP?

If the framework was tailor-made for a family of devices, it may be worth doing reverse engineering and document the framework to be reusable in any future device of the manufacturer.
If it's worth doing it, then the framework documentation shall be compliant with the expectations of the standard for the highest expected class of risk in the family of devices.
For example, if the family of devices contains class A and class B software, then the framework shall be documented with the level of scrutiny required for class B devices.
By the way, the framework should benefit from this reverse engineering. It's probable that risk mitigation measures were already implemented but left undocumented. A new round of risk analysis can unveil pitfalls in these risk mitigations. As a consequence, new mitigation actions will be implemented and the framework will be seen as more secure.

Treat it as a SOUP!

However if the framework is used as is, the black-box SOUP approach should be feasible. This is what everybody does with frameworks developed outside medical field, like C++ or java general-purpose frameworks.
Like any other SOUP, the necessary tasks are focussed on risk assessment:

• Identify functional and technical requirements managed by the framework,
• Do a risk analysis of these functional and technical requirements,
• Do a risk analysis of framework integration in the medical device,
• Do a risk analysis of known bugs in the framework,
• If necessary, add a mitigation layer between the framework and newly developed software.

Testing

Since a framework delivers a lot of services, it may be necessary to add a step of validation of the framework alone. For mission-critical software, it may be deemed necessary to validate a SOUP alone. In the case of a framework, a test plan should be created where every service and/or function used by the device is tested alone. The framework is verified as a black box with this test plan and validated once the tests pass.
The next step is to verify the newly developed software + the framework with an adequate test plan.

Legacy software is not a medical device

This is not a problem. It is 100% aligned with the SOUP concept.
Short answer: Treat it like a SOUP.

However, if is it a framework with existing modules, where new modules are added with medical intended use, the problem is not so simple to solve.
The solution may be architectural, to isolate new medical device module and legacy modules. I already talked about this solution and the problem of risks propagation through the framework in another article about standalone software.

Legacy software is a prototype

There are dozens of prototypes that are designed by R&D teams, without any consideration to quality and regulatory. That's OK because, they design a prototype, which purpose is to be a proof of concept. But when it happens that the concept can be turned into a medical device placed on the market, trouble begins!
Not so much trouble, though. A prototype always requires lots of changes before it is placed on the market. The prototype is one big input data of the development cycle: input R&D prototype, output validated device.

Conclusion

The principal underlying idea behind these cases is risk assessment. What are the risks brought by the legacy software, are they already mitigated, how can they be mitigated. The cases I described are classic, if not theoretical. Cases in real life are all different. The cases above are just here to provide clues to define the right action plan for real cases
Edit: see next post for some more information.