How to de-risk medical software development

When you’re working in the detailed design phases of projects, rigour is essential to ensure patient and operator safety. However, in the earliest development phases, design changes are common. At this stage of medical device development, the requirements are malleable and each new iteration of the prototype may lead to discovering new requirements, features or issues.

This degree of flexibility is crucial for early-stage medical devices or start-up companies. Innovation has to happen quickly to test new concepts – the software has to adapt to the project’s evolving needs. So how do you balance the need for agility with the need for robust systems in IEC 62304?

At Team Consulting, as part of our project lifecycle, we often start by developing proof of principle devices. These devices help us de-risk key technical functions, fully define the system’s requirements and identify potential safety risks. Development teams in this phase of a project will keep design and change controls ‘lightweight’ and focus on key technical items that pose the most risk. The level of control may be tailored to the device being developed, applying more rigour where the risk of harm is the greatest.

The exact same principles can be applied when designing these types of healthcare software for these proof of principle devices. The key is to ensure that you can show you were in control of your software development at all stages.

Here are our suggestions on how you can show this within your software development process.

It starts with your software development plan

Your software development plan is where you state how you will design, develop and manage your software throughout its lifecycle. During this stage, you also define the lifecycle for your software development project.

Start by identifying to what ‘level’ you will design the software. At this stage, the level of design is likely to be no deeper than a high-level software architecture.

Define how the key software items will interact, any workflows for data exchange and any key algorithms you will need to implement. During this process, you can also identify to what level you will apply software risk management. This is also likely to be high level, focusing on activities which are likely to impact the function of the software.

Accept that your software’s source code can’t be used directly

While it’s very likely that the software you’ve written is of good technical quality, having followed lightweight development processes, you’re unlikely to have implemented all the risk controls you need. You may find that there are design compromises in place or that the functionality could be optimised.

You should therefore take the assumption that you can’t use source code developed before the start of detailed design. However, you can use the code as a design reference, taking some of the code’s components and modifying the files to better suit your requirements, adding risk controls as needed.

While the source files, in their current form, can’t be used directly, they have helped you to learn about and understand your product. You may be able to use the source code files for the product if you:

• Review all source code and identify any improvements needed
• Fully risk assess the software which is designed and implemented
• Determine appropriate controls and improve the software
• Document the design of the software and make appropriate changes to the design.

In many cases, you may find it easier to re-implement your source code and take references from the original implementation. You may also find significant areas of the codebase which only need minor improvements.

Identify and assess Software of Unknown Provenance items

It can be easy to integrate Software of Unknown Provenance (SOUP) items in proof of principle phases to perform simple tasks which you would otherwise have to write yourself. Integrating SOUP items can save you time in the early stages of development, but you may find that the SOUP evaluation process costs more time than initially saved. Take the opportunity to review the SOUP items you have used and replace them if necessary.

Implement software tests during proof of principle phase

Hopefully, by the end of the proof of principle phase you have created a prototype that meets your functional requirements. You understand what is needed of the device and its software. By implementing software tests at this stage, before you make potentially significant changes, you have a suite of regression tests which will be able to identify a loss of performance!

Wrapping up

By ensuring that you implement your software with some of the requirements of IEC 62304 in mind, even in the early stages of your project, you’re laying the foundations to rapidly transition your software from ‘proof of principle’ into fully functional, safe, medical devices. It minimises any ‘wasted’ efforts and helps us to leverage the knowledge built during the project lifecycle.