Businesses all over the world use Raspberry Pi to build proven and powerful computing into their products, and our network of Raspberry Pi Design Partners can help you integrate our technology into your application. Cambridge, UK-based Design Partner eg technology has specific expertise in medical devices and consumer products. They’ve recently written about using Raspberry Pi as an industrial development platform, and we’ve invited eg director David Warwick over to talk here about how our hardware performs in the highly regulated field of medical devices.

Can I use a Raspberry Pi in my medical device?

At eg technology, we have over 20 years of experience in the design, development and regulatory approval of medical devices and in-vitro diagnostics. That means that every year we get to work with our clients to take their new medical devices through the regulatory approvals process within our ISO 13485 framework, and specifically help them to navigate testing their electronics and software to the IEC 60601 and IEC 62304 standards.

A risk-based perspective

At the heart of medical device development is the risk management process. In a nutshell the most important thing to remember in medical device development is that “the benefits of using the device must outweigh the residual risks”. You might also have heard the popular healthcare philosophy “first do no harm”. Taking and understanding a risk-based perspective is important, because the perception of risk changes depending on the circumstances and that in turn has significant implications for your device development.

I’m a great advocate of taking a holistic approach to medical device risk management. In design and development terms, part of this means selecting the right platform and the right tools for the job in hand. As such, mainstream operating systems and off-the-shelf hardware have their place in medical device development and the risk management process.

Not so long ago, a traditional, risk-averse view of medical device hardware and software development would have been to adopt a bare-metal, ground-up approach. However, this relies on being able to keep the level of complexity in the system manageable to avoid development costs spiralling out of control. As healthcare technology evolves, modern medical devices tend to need communications interfaces, network connectivity, and graphical display screens, all of which require significant electronics and software development. This is only increasing in importance as devices (including medical devices) become more complex and more connected.

Mainstream hardware and software: large user bases, substantial support

Think for a moment about the amount of testing that goes into Windows, macOS, Linux, Android. Then consider how much real-world use this software is getting globally on a daily basis and the size of the development teams developing and supporting them. Yes, we’ve all experienced the occasional problem, perhaps had to reboot or force-quit an application, but overall these really are very stable systems. From a risk-based perspective, it’s therefore valid to ask whether starting from scratch with a bare-metal solution is actually going to get you to the same level of reliability.

I’m not suggesting that safety-critical systems don’t need a higher level of performance and reliability than commercial operating systems, but this really comes into play in the highest-risk medical devices and the highest levels of software safety required by the standards. There is a vast range of devices that can leverage the benefits of tried-and-tested systems, and indeed connected medical devices have reached the point where a strong argument can be made that the appropriate integration of third-party hardware and software into medical devices is of lower overall risk than ground-up development.

A detailed exploration of medical device risk management and design of a system architecture to manage those risks is beyond the scope of this article, but within medical device development and the applicable standards, you are permitted to assign different levels of safety classification to different parts of the system according to the potential risk of that module failing.

Can Raspberry Pi provide the optimum approach?

Linking these ideas back to Raspberry Pi hardware, let’s consider two potential scenarios where an off‑the‑shelf solution might provide the optimum approach.

A standalone safety sub-system

A good way to manage safety is to create a system architecture where the most safety-critical elements are handled by an independent, standalone safety sub-system. This is where the RP2040 microcontroller comes into the equation. While bare-metal may not be optimal for complex graphics libraries or internet connectivity, that tight level of control is useful for monitoring the safety-critical aspects of the system.

The first thing we consider in any project is whether the risks arising from the software can be mitigated in hardware. This is a good approach if you have fixed, easily measurable parameters where a “cut‑out”‑type function ensures the worst risks are mitigated. But in some systems, the determination of an error could require more complex measurement, or there may be more scenarios than you can realistically cover in discrete hardware, so think of the safety processor as a set of software “cut‑outs”.

As you might guess from the name, the safety processor maintains responsibility for ensuring all safety‑critical aspects of performance are maintained if the main processor goes wrong. With careful design choices, the functions of the safety processor can be reduced to only those core safety functions, and this narrows the scope of your most safety critical software, making it easier to code and easier to validate.

With a low-level processor keeping watch on all the safety-critical aspects, you can then use a standard Raspberry Pi to provide all the high-level processing, graphics capabilities and connectivity required for the system. Potentially this software can have a lower safety classification, meaning the integration, verification and validation of third-party components is less onerous.

Achieving connectivity

Secondly, connectivity — whether wired or wireless — requires specific hardware and software modules. The majority of medical device companies will seek to provide this connectivity via third-party modules, taking advantage of optimised hardware, antenna designs and a software stack that provides the necessary interfaces. For interoperability, much of this is built on standard protocols (Wi-Fi®, Bluetooth, IEEE 802 series) and therefore it doesn’t make sense to reinvent the wheel.

Cybersecurity concerns

In addition to the design segregation ideas outlined above, a second increasingly important consideration in medical device design is cybersecurity, with the FDA issuing new guidance earlier this year. This is a good example of how using tried-and-tested third party-hardware and software offers a lower development risk, and reduced costs and timescales, compared with in-house development. Not only do you get the advantage of a tried-and-tested product, but also the ongoing benefits of active support, upgrades and security patches from a reliable supplier.

In conclusion: a capable, reliable industrial development platform for medtech

The design and development of medical devices is complex, multifaceted, and carried out within a highly regulated framework, and the components used within the product must comply with the required standards. For both hardware and software development in the medical device arena, it is imperative to source modules with reliable supply chains, good documentation and, should it be required, high-quality and timely field support from the manufacturer.

With the onus being on configuration management within the medtech sector, Raspberry Pi Compute Module is not only a suitable platform for medical device development, but worth serious consideration. While some associate Raspberry Pi with education and hobbyists, the Compute Module offers all the capabilities and development possibilities of similar modules that are positioned as industrial development platforms. We have successful integrated Raspberry Pi boards into a range of medical devices and in-vitro diagnostics which have then gone on to meet the requirements of IEC 60601, IEC 62304, CE marking and FDA approval. As I said earlier, effective development and medical device risk management is in part about selecting the right tools for the job. Raspberry Pi hardware is part of that toolbox.

For more information on getting your product to market with Raspberry Pi Design Partner eg technology or to chat with one of their team about integrating a Raspberry Pi Compute Module into your medical device development, please contact them via email to design@egtechnology.co.uk, by giving them a call on +44 01223 813184, or by visiting eg technology’s website.