Using existing software when developing a medical device; a gift from the gods or a Trojan horse?

Are you developing software for a medical device?

Then you probably know about IEC 62304 -“Medical device software – Software life cycle processes”. This standard describes what is expected of you when building software for your medical device. As it covers the entire device life-cycle, it specifies not only the development requirements but also covers maintenance, risk management, configuration, and problem resolution activities necessary for compliance.

This article will not analyze the IEC 62304 activities in detail (should you be looking for a more general overview of software development according to IEC 62304, I can highly recommend this presentation.).

Instead, we shall focus on a specific situation: you have an existing piece of software. It was not developed according to IEC 62304, but you want to use it in a device.

What are your options? Can you use that software at all? Is complete re-development the best, or even the only option?

Before answering these questions, it is necessary to step back and consider why this software was not developed according to the IEC 62304.

Is it a SOUP?

Let’s say the software was developed by a 3rd party, commercially or as open source. If so, this case is covered by treating the software as SOUP (Software of Unknown Provenance) according to IEC 62304.

“Unknown” in this context is not about the identity of the maker, but rather the lack of knowledge about the procedures used to develop the SOUP. As a consequence, there is an issue of trust regarding the software’s quality, its level of safety, and its potential risk of failure.

How does IEC 62304 let you get to grips with this lack of trust?

Start out by documenting all the functional/technical requirements that your use of the software results in. This gives you a good basis for writing the corresponding test cases that verifies correct functionality. It also serves as a starting point for identifying and assessing the risks associated with the functions of the SOUP.

After having analyzed the functional risks, you should proceed with identifying and assessing any risks from the integration of the software into your device. As a further risk identification source, you should, if available, get hold of a list of all the known bugs of the SOUP.

For all the identified and assessed risks, derived from the requirements, the integration, and the list of known animalities, you need to reduce the risks by applying appropriate measures.

Now, this might get a bit tricky. In many cases, modifying the SOUP itself might not be a viable option.

One known way forward is to provide dedicated error-handling and comprehensive, over-arching software risk mitigations in the software that uses the SOUP, which itself must be developed according to IEC 62304.

If you can foresee the reuse of this SOUP in other devices, you should consider designing an “insulation layer” around the SOUP. As a result, you get a wrapped SOUP which, in the context of your products, is safe to use.

However, note that all risk analysis activities described above to create a valid, safe SOUP, are conducted with a particular device's particular intended use and a particular risk acceptance profile in mind.

Thus, re-use of the SOUP, leveraging the SOUP documentation described above, is only valid if the target devices have similar intended uses and near-identical risk acceptance profiles. Using the SOUP in an HIV detecting device (Class C) requires a different risk assessment than when used in an allergy detecting device (Class A).

Is it Legacy Software?

Another scenario is that the software was developed in-house and put on the market before IEC 62304 was released.

If you now want to modify the software or use it in a different context, say with updated hardware, you can consider the software as “legacy software”. Amendment I to IEC 62304, released in 2015, describes the necessary steps.

Start out with a risk assessment. As the software is already on the market, you will have Post Market Data to include. Leverage this data as best you can. If your identified risks do not show up in years of carefully collected Post Market Data, you have a strong case for declaring your identified risks as acceptable! Truly a nice shortcut!

On the other hand, if you find reported risks that are not sufficiently addressed, you need to perform the necessary risk mitigation process steps described in 4.4.3 of the standard.

If you plan to modify the software before the next release, the changes must be part of the risk analysis. These modifications need to be made according to your IEC 62304 maintenance process, described in chapter 6 of the IEC 62304.

Amendment I to IEC 62304 can be your friend, especially if your risk assessment concludes that the risks originating from the use of this software are acceptable.

Is it a Prototype?

The most common scenario for having to bring an existing software into the folds of IEC 62304 is this: you developed a software prototype and, let’s be honest, you cut some quality corners during the rapid proof of concept phase.

Now it turns out that management loves your work! They are truly impressed by its dazzling features and, moreover, how fast you were able to achieve such great results! Just quickly make it IEC 62304 compliant and get it to the market!

Do you really have to start all over again? If your prototype is really just a prototype, then you should. But what if it turns out to have a clean architecture, modules separated by interfaces, and even have some unit tests in place? Wouldn’t that be good enough for IEC 62304?

No, not strictly speaking. IEC 62304 is a process standard. It is concerned with _how_ you develop your software, not the software itself. Since it is not possible to alter the past, “retrofitting the software into IEC 62304 compliance”, is formally not a way forward.

BUT. Let’s be a bit more pragmatic here.

It is rarely the case that software development is performed in the exact prescribed order defined by a software development process. Therefore, more often than not, there will be a set of remaining development and documentation tasks to finalize after your software is up and running. It could be those additional tests to write, a code review to add, or updating that detailed design document.

This is not specific to the IEC 62304 but applies to any software development or more general software lifecycle process. At times, the actual development and the process are simply slightly out of synch. As long as everything runs well in the end, all tests are passed, the process is largely followed and the documentation is complete and consistent, there is a good case for claiming compliance.

It would therefore be possible to argue that a prototype “catching up” with IEC 62304 is just an extreme case of this “getting back in synch” scenario.

Are there any downsides with this “catching up” approach?

Yes, potentially. IEC 62304 recognizes that the standard requires an extensive testing and documentation effort by the developers. It also recognizes that some parts of the software are less risky than others. As a result. IEC 62304 provides an opportunity to do a little less testing and documentation for the lower-risk parts, as long as you are rigorous about the high-risk parts. If this separation can be made, a lot of work can be avoided.

Why is this a problem for existing software? Can’t I just do a risk analysis on existing parts and then divide them into “safe” and “risky” ones?

Well, not quite. You will discover that a software architecture being efficient and easy to maintain, which is what most software developer intuitively implement and strive for, is not the same as an architecture which separates high and low-risk parts from a patient safety perspective.

If grouping of safety-relevant functionality into dedicated parts is not done from the start, the riskiness tends to spread out and “contaminate” all parts of the software. An architecture with many high-risk software items (parts) and very few low-risk items will ensue.

You can of course accept this situation and do the additional required steps. The IEC 62304 will allow it. But it is a foregone opportunity compared to designing your software with the IEC 62304 in mind from the very start.

Conclusion

Bottom line, is using an existing software not developed according to IEC 62304 worth the trouble?

As described above, depending on the situation, there are definitely options. It all boils down to comparing the inherited risks of the software to the benefit of using it. A very complex software, being hard to rewrite, but does not introduce significant risk is a good candidate for re-use.

However if the number of inherited risks are high and the offered functionality could also be realized by developing and documenting a new software according to an IEC 62304 compliant process, you should strongly consider doing just that.