Should you “just fix your medical device in software”?

The medical software development process

It is important to consider that medical device software is developed under a risk-managed process – every feature must be assessed against the potential risks it introduces or controls. Fixing a problem in software requires more than changing a few lines of code. The following areas are all impacted when implementing changes to software:

• Requirements: detailed requirements must be generated to describe the functionality, to ensure that it is verified and working as expected.
• Risk analysis: every new feature is assessed to determine its risks to the user, environment and other factors. This process includes evaluating the potential impacts to existing software features. Risk analysis takes time to do thoroughly, particularly towards the end of a development cycle.
• Design documentation: the design of your software should be recorded and accurate. Even small features can take time to adequately design, implement and document.
• Change the code: this is an essential step and making changes in code safely takes time.
• Testing:there must be new software verification tests, perhaps even automated test cases. These tests must adequately assess the changes to software. Software developers then need to execute any tests which relate to the new function.
• Release and distribute: software engineers are required to formally release the software and then distribute it to users and to manufacturing. This again takes time to do properly.

Every change is risk-managed and your software will follow a development process which is based on the potential hazards the software can cause. Based on external risk control factors, your developers may be able to reduce the overall software risk category, dramatically lowering the regulatory burden associated with your software. If the original problem relates to a risk control which has been applied to software, you may find that the overall risk profile increases and therefore, regulatory requirements increase with it.

Depending on how our software is architected and how the features are distributed, software changes may have limited effects in other areas. In other cases they can cause subtle and unexpected changes to the performance of other software modules. There is a real risk that by changing the software, additional problems can be uncovered and critical functions impacted. Whilst processes can identify these issues, the additional time spent to resolve the new issues can quickly add up!

Finally, we need to consider whether we’re simply kicking the proverbial can down the road and storing up problems to resolve later. Many software changes will simply mask the problem, rather than resolving it outright. We’re going to need to solve the problem eventually, so often it’s better to just tackle the challenge head on.

What should you try to avoid fixing in software?

Knowing that medical software is developed in a risk controlled, process oriented environment, it should be considered that there are some cases where trying to fix a problem via software
is inappropriate.

Understanding the root cause of a software problem
Software takes inputs, performs a series of operations and derives outputs. The behaviour of your software is very well defined. This means that unless your software engineers fully understand a problem, they may miss important components of its definition, leading to further issues in the future if the problem changes.

Say you’re developing a diagnostic device, examining a signal and getting a spectral pattern which doesn’t make sense for a reagent that you are measuring. If we simply filter out the pattern in software, are we ignoring the root cause? If something else changes within your system, will it re-appear in
a new way?

In these circumstances, teams should take a pause, understand the root cause of the problem and only then change the software (if it’s the right thing to do).

Working around hardware faults
If you have a hardware component which fundamentally does not work as it should, why should it be hidden by working around it in software? We wouldn’t expect to use only the front brakes in our car because the rear ones don’t deliver enough braking force!

Equally, if your device is experiencing fault conditions due to noise, EMC, then (beyond reasonably practical measures) these sensitivities should be resolved, rather than finding workarounds. Again, your engineers may have planned to solve these problems using software, but if not, it’s unduly burdening software to solve issues and building technical debt which you will still need to address at a later date.

Understanding the code

What starts to happen to your software if these principles are ignored?

Software engineers design software to meet specific requirements. The code is written to meet the specifications of the software system and anticipated future changes. It may be flexible and adaptable to change, but additional ‘fixes’ will not have been factored into the initial code design. You may find that over time your beautifully designed software has turned into Frankenstein’s monster.

Perhaps unexpectedly, ‘ugly’ code will be harder to maintain in the future and will become increasingly difficult to change. If we can’t understand the code, how do we fix its problems?

As additional requirements are placed on the software and bolt-on solutions are added on to the design, it can become more brittle to changes. Of course, well designed software should be reasonably robust to this, but it’s still possible that by fixing one problem another is created!

All of these factors also impact on timescales. We’ve already seen the process impacts of software changes – these all add up to push project timelines further out. If this means that critical features are pushed backwards, then your overall project timelines are shifted. Often, this will mean that there’s no overall time saving to fix the problem in software.

What can software fix?

All of this is not to say that software shouldn’t be used to fix problems observed elsewhere, but it is important to consider if software is the most effective way to solve a problem or not.

The following are a few examples of where software can be used to fix challenges:

Adding and unlocking new functionality
This is the big win of software, adding and unlocking new functionality in an incremental way. So long as teams have planned for the software to be the mechanism for delivering new features or to adapt to the changing needs of other systems, your developers can design it to do so.

Fixing well-understood software issues
A problem understood is a problem solved. If the root cause of a problem is understood, your engineering team can create requirements for your software to resolve it. They can thoroughly test the solution and see that it is working as expected. Without well structured requirements, you may be coming back to fix the problem sooner than you think!

Fixing an issue in software when you’ve already considered other options
If we had a perfect understanding of our system, and the problems to come, would we want to solve the problem in software? If yes, it makes sense to fix the problem in software. Sometimes, you’ve exhausted all other ways of solving a problem and the only mechanism that can reliably solve your problem is in software. That’s OK – by this point you will likely understand what the problem is, how to resolve the issue and if it introduces any additional risks. Your software engineering teams only ask that, rather than expecting them to fix every issue, you’ve considered other options as well.

I hope this article has been useful in understanding why your software team may push-back on making unexpected changes. Software is exceptionally adaptable, but it’s important that we explore other options and understand the impacts of any design changes we make. Doing this could reduce your overall project timeline.