eg technology writes:
The software development life-cycle, and the choice of development tools to support it, is particularly important in the context of medical device development. The software needs to be considered as part of the system as a whole, and when carrying out risk management close attention needs to be paid to how other parts of the device and users interact with the software. In this article, we focus on how selecting the right development platform is a key element of success and must be considered at the start of your project.
Understand and confirm the software safety classification
Because medical device software must be developed in accordance with IEC 62304, it is essential that you ensure that the software safety classification has been correctly determined before coding starts. We always document a rationale for the safety classification prior to any software development work. The discipline of writing it down ensures you are able to present a clear, well thought out approach to the software safety classification and from there develop the software architecture in a way that ensures safe operation. Determining your software safety classification early can also be a useful process to tease out the high-level risks (or current unknowns) in your software development.
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. A holistic view of the device also ensures that user-related aspects and human factors are considered throughout the development process. Ensuring that all members of your development team talk to each other at planning and specification stage, minimises the risk of costly rework or trying to compensate for sub-optimal operation of the hardware with software patches.
For IEC 62304, it is also important to consider software safety as part of the overall device risk management. In many cases, the software will be working in conjunction with mechanical/electrical fail-safes, that in turn will have an impact on the overall safety of the device. Software has an important part to play in risk mitigation but needs to work as an integral part of the system, not be used as a back stop.
Pick the right platform
The choice of electronics platform (microprocessor), operating system and software development tools is interlinked. 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 datasheets and any design documentation before you start work. Bought-in modules can save significantly on development time, but that saving can be quickly eaten up if you are trying to adapt them to a use not intended by the manufacturer. Make sure you are leveraging the benefits of off-the-shelf designs, not being constrained by them.
It’s also worth making sure that the processors/modules you want to use in your design are freely available. Notwithstanding the current global electronics shortages in 2021, it’s not uncommon to come across modules which look great on paper, but aren’t available from the manufacturer in low volumes or prototyping. The opposite is also true; ensure you can get hold of production stock and if necessary, schedule critical stock purchases into your project planning. You will need components/devices for prototyping, development, testing and then transition to production volumes. A delay due to supply at any point could be costly.
Since testing could take over a third of the overall development time, it’s also important to ensure that the toolchain you select offers good debugging support (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 a proprietary 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. Whilst 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 being less reliant on SOUP (software of unknown provenance) is attractive for many medical device manufacturers during verification and validation.
Finally, don’t forget the on-going support overhead, particularly for the popular commercial operating systems. Android, iOS and the major desktop operating systems all have upgrade cycles that mean the OS will receive a major revision each year and it’s not easy to avoid these (particularly on mobile devices). This means potentially 2 or 3 major revisions before market launch and on-going maintenance each year. As mentioned above, make sure you are leveraging the genuine benefits of using the OS not being constrained by it.
Plan for the future
Perhaps the biggest difference between software engineering and electronics or mechanical engineering is that it is typically an on-going process after the launch of the product. Software is frequently used as the mechanism by which new and improved features can be added to a device. Updates post-launch present their own risks, which is why IEC 62304 emphasises the whole software development life-cycle, rather than just the initial development. 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 market 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.
Kickstarting the development roadmap with standards - an example
Unhindr are a startup formed at Imperial College London, who have designed the world’s first AI adjusted prosthetic device. Devised of a wearable robotic liner that uses Artificial Intelligence to learn the wearer’s comfort settings, the device then adapts to them automatically throughout the day. Unhindr had already developed a prototype, but they required help in determining a regulatory pathway & roadmap for their route to market. They approached us with the challenge of identifying potential issues within the software and formulating a development process to create a robust, safe and effective end product, within the required standards. Read the full case study here.
For more information on our software process or to chat with one of our team about your product design and development requirements, please contact eg technology:
via email on design@egtechnology.co.uk
by giving us a call on +44 01223 813184
or by clicking here