Designing safety-critical devices – using the right methodology

16 May 2012 3min read

Team Discussion

Multiple authors

Offering enhanced usability and functionality may run the risk of compromising patient safety, but by using a structured development methodology developers can help ensure that safety-critical devices remain safe.

Although good design plays an important role in the market success of electronic devices, users often confuse good design with increased functionality. However, as discussed in the last issue of Insight, it’s well known that increased functionality can increase user error – acceptable perhaps in a mobile phone, but not in a safety-critical device. To address this problem, Team has created a methodology specifically designed to deliver safety-critical products which both enhance the user experience and ensure patient safety.

Our methodology encompasses the entire design lifecycle, from requirements definition through to eventual manufacturing support, and begins with a thorough analysis of the end user. The aim is to identify – and then to separate – the functions users desire from those they need, while also determining the user interface design that best fits the eventual application.

We then introduce our medical system architecture (above) to the design process. This architecture deliberately separates safety-critical and user-focused functions in order to minimise the risk of failure caused by user error or technical malfunction. For example, users may say they want a touch screen, even though such a screen makes it much easier to ‘press’ the wrong ‘button’; touch screens also require power, and if the screen should fail then users may not be able to access essential controls. Our system architecture makes sure that such controls are not affected by the failure of less important functionality, or compromised if such functionality causes user error, perhaps due to mishandling or stress. In the example of the touch screen, this means providing additional, physical buttons with independent power supply, memory and output.

The regulatory framework for safety-critical devices is particularly demanding and so must also be acknowledged early in the development process, with a system in place for continuous documentation and reporting. SOUPs, or software of unknown provenance, can be an area of specific concern. These often feature in multifunctional devices, and although not necessarily a problem in isolation, when combined may result in unexpected outcomes which regulators want to see thoroughly researched and tested.

This provides just a brief snapshot of the extensive process we use in the development of safety-critical devices, a process we find is becoming increasingly relevant as many such devices move out of the clinically controlled environment and into the home. Greater patient freedom, however, brings greater patient risk; our methodology aims to minimise this risk from the outset in order to deliver devices designed with regulatory approval in mind, and which users will find desirable, functionally appropriate and – above all – safe.

Join the conversation

Looking for industry insights? Click below to get our opinions and thoughts into the world of
medical devices and healthcare.