Latest 'Ask eg' column for Med Tech Innovation

The choice of software development tools is particularly important in the context of medical device development. Any software elements need to be considered within the context of the device as a system, particularly when carrying out risk assessment exercises. In this article we outline how to ask the right questions and make the right choices from the start of your project. Understand and confirm software safety classification Because medical device software must be developed in accordance with ISO 62304 it is essential that you ensure that the software safety classification has been correctly estimated before coding even starts. The FDA publish a helpful questionnaire relating to the level of concern for a device, and we advise our clients to document a rationale for the safety classification before software development work starts. The act of documenting this rationale can be useful in teasing out the high level risks (or current unknowns) in the software. Consider software as part of the whole Obvious though it may seem, much time and money can be saved by ensuring a device’s software development is considered in conjunction with the mechanical and electronics programmes. Ensuring that all areas of your development team talk to each other at planning and specification stage minimises the risk of costly turnarounds or patches. For ISO 62304 it is also important to consider software safety as part of the overall device risk assessment. In many cases the software will be working in conjunction will mechanical/electrical fail-safes that in turn will have an impact on the overall safety of the device. Pick the right platform The choice of electronics platform, operating system and software development tools are interlinked and must be considered as a whole. There are plenty of development kits and modules available on the market, but not all are created equal. If you are looking to use third party protocols or communication stacks it’s always worth obtaining and reviewing the design documentation before you start work. Bought-in modules can save significantly on development time, but any saving can be quickly eaten up if the support provided by the manufacturer isn’t up to scratch. At the other end of the spectrum, it’s also worth making sure that the processors/modules you want to use in your design are freely available. It’s not uncommon to come across modules which look great on paper, but aren’t available from the manufacturer in low volumes.. Since testing could take over a third of the overall development time it’s also important to ensure that there is good debugging support for embedded devices (ICE/TRACE/JTAG), simulations, and/or development boards that can be used in place of the real electronics while it’s developed in parallel. Is an OS the right way to go? It’s tempting to look at Android/iOS and think it would be convenient to use all of the code that’s already written for you, but all too often our clients require some kind of hardware interface, or modifications to an existing interface that aren’t supported by the OS out of the box. Use the strengths of the OS and leverage the benefits it gives, but understand the limitations. It might be better to design a piece of custom electronics that has a standard interface (e.g. USB/Bluetooth) as a bridge, then use the existing interfaces available in the operating system. It’s also common that many devices don’t need the raw processor power of the latest smartphones or PCs. In this case there are smaller, lighter-weight OSs and GUI libraries for embedded systems. While they don’t offer the power and sophistication of the latest commercial operating systems it is possible to achieve a finer level of control over the whole system and less reliance on SOUP (software of unknown provenance) is attractive for many medical device manufacturers during verification and validation. Plan for the Future Perhaps the biggest difference between software engineering and electronics or mechanical engineering is that it is often an on-going process after the initial launch of the product. Software is frequently used as the mechanism by which new and improved features and workflow can be added to a device after launch. Updates post-launch present their own risks, which is why ISO 62304 talks about the software development life-cycle rather than just the development process. It’s important to consider up-front what the on-going support costs will be. Creating a software roadmap and planning future releases at the beginning of development can allow a manufacturer to reduce the time to initial market launch by staggering the introduction of new features. However, you also need to remember that medical devices are regulated and new features introduced by subsequent software updates might require reassessment by a notified body.