What We Can Learn From Bluetooth Medical Device Recalls

Randy Horton

Published on: June 15th, 2023

When working on the cutting edge of technology and healthcare, mistakes are going to be made. It’s our job as Software as a Medical Device (SaMD) and connected medical device manufacturers not to make the same old mistakes, but to learn from the errors and missteps that came before, both in our own organizations and across our industry.

One of the great things about our industry is that a broad set of information is available through databases on the FDA’s site as well as through search providers such as Basil Systems. This public sharing of information allows us to proactively seek lessons learned from our competitors to collectively improve our device safety and effectiveness.

Bluetooth enables the creation of powerful and accessible connected medical devices, but adds complications in connectivity and security (like the SweynTooth exploit documented in 2020). That being said, our research uncovered just a handful of instances where Bluetooth was the reason for device recall. Though they are few in number, these recalls highlight important lessons for developing Bluetooth-enabled medical devices.

Let’s go over what we can learn from these recalls and how we can avoid the same issues with our devices.

Note: Searching the FDA’s public databases is an imperfect science. If you know of any other relevant recalls we didn’t include in this blog, we’d love to hear about them!

_________________________________________________________________________

Recall #1: Why testing for edge cases around losing Bluetooth connectivity is so important

Recall Date: April 21, 2022
Type of Device: Active Implantable
Primary Function: Cardiovascular Monitoring and Therapy
Device Risk Classification: Class III
Manufacturer: Abbott
Devices Recalled: Gallant VR, DR and HF Implantable Cardioverter Defibrillators (ICDs)

gallant dr hf hero — *Source: Next Generation ICD and CRT-D Solutions I Abbott*

Implantable devices, like these ICDs from Abbott, connect via Bluetooth to an app for remote patient monitoring. But if that device loses Bluetooth connectivity, it regresses to an earlier, less patient-friendly functionality.

That’s what happened in these recalls, where certain models in the VR, DR and HF product lines entered an induction-only telemetry mode when they lost Bluetooth connection. As induction-only telemetry is something only a clinician can do, this meant that patients could only access the device’s full range of features at their doctor’s office.

What we can all learn from this recall
This recall reminds us of how important it is to test edge cases around losing Bluetooth connectivity. You need to understand what happens when a connection is lost, as well as the external factors that can cause a device or app to drop the connection.

Recall #2: What happens when you don’t prepare for all possible signal interference issues

Recall Date: November 26, 2021
Type of Device: Active Implantable
Primary Function: Ventricular (Assist) Bypass
Device Risk Classification: Class III
Manufacturer: Abbott
Device Recalled: HeartMate Touch Communication System

hf heartmate touch communication system — *Source: https://www.cardiovascular.abbott/us/en/hcp/products/heart-failure/left-ventricular-assist-devices/heartmate-3/about/system-overview.html*

We live in an environment with many different Bluetooth-enable devices broadcasting on the same wavelength in the same geographic area. This cumulative radio traffic can cause signal interference, which can impact the proper functioning of a device. Given the pervasiveness of Bluetooth-enabled devices, signal interference is an important edge case to test for. What makes it unique among edge cases is that high-fidelity simulations of real-world situations are not a DIY affair. Rather, these tests must be performed in a certified lab and also meet the Federal Communications Commission’s (FCC) standards for wireless and radio devices.

In this recall, signal interference caused issues for two different medical devices that were designed to work in tandem. The HeartMate Touch Communication System is used by clinicians in a hospital setting. This system interfaces with another medical device, the HeartMate 3 Left Ventricular Assist System (LVAS), to obtain system performance data. However, it was discovered that if another nearby Bluetooth-enabled device was advertising for connection (e.g. Airpods or a printer) while the LVAS was trying to connect to the Communication System, the HeartMate Touch Communication System’s app would unexpectedly close or fail to properly launch.

What we can all learn from this recall
Your Bluetooth-enabled medical device will be used in a variety of physical and radio traffic environments, so it’s important to understand the range of possible situations where the device will be put into use, and to stress test your device against them. As for security threats, we recommend validating all data passed between the app and the device using cyclic redundancy check validation.

Recall #3: How to detect bugs brought on by OS updates before they impact your app

Recall Date: May 22, 2020
Type of Device: Continuous Glucose Monitor System
Primary Function: Diabetes Management
Device Risk Classification: Class III
Manufacturer: Medtronic
Device Recalled: Guardian Connect Mobile App

When distributing a medical device via patient smartphones, you need to conduct adequate testing of smartphone OS updates before the updates are put to use on devices running your medical device’s apps. Medtronic’s Guardian Connect Mobile App encountered this problem, where an iPhone OS update caused the app to make more frequent than specified Bluetooth calls to the system’s wireless transmitter, prematurely draining its rechargeable battery and reducing the device’s intended time between recharges .

What we can all learn from this recall
It’s hard to keep up with the shifting landscape of the Bring Your Own Device (BYOD) market, but it’s necessary to do so to reap the benefits of fast-paced deployment and scaling of your solution. To address OS changes, we recommend automating testing on representative hardware and software combinations. This makes it easier to identify and address issues before they reach the BYOD market.

We also highly recommend implementing a field-level self-validation check on your device. This test runs when an app is launched to make sure it’s working correctly. In the event something does happen on the OS side that causes issues, the app will detect that and take appropriate steps per its designed functionality (the options for what a device can do in this scenario could be the subject of another blog). This extra layer of safety features gives the device manufacturer a chance to send out a patch ASAP before the issue impacts treatment.

The alternative is to give smartphones to patients to use with the device peripheral. This cuts down on the scalability of your device, but allows for much tighter control of OS updates by managing devices under Mobile Device Management.

Recall #4: Why you need to keep all components of your medical device in sync

Recall Date: January 27, 2012
Type of Device: Radiologic Imaging System
Primary Function: Angiography
Device Risk Classification: Class II
Manufacturer: Siemens
Devices Recalled: AXIOM Artis and AXIOM Artis Zee Modular Angiographic Systems

card artis zee floor mounted — *Source: https://www.siemens-healthineers.com/en-us/angio/artis-interventional-angiography-systems/artis-zee*

When designing a connected medical device system with multiple components, it’s important to keep the versions of the device’s technologies (e.g., firmware, OS, applications and hardware) in sync and properly functioning as any one component is updated. Otherwise you might run into the issue seen in this recall for two angiography systems. It was discovered that a malfunction could occur if either the remote foot switch or stationary unit was equipped with improper firmware in the Bluetooth interface that performed communication between the two.

What we can all learn from this recall
Maintaining version control to ensure compatibility between all components of a medical device is critical not just for Bluetooth but also for cybersecurity risk management.. You need predefined, robust mechanisms for managing and testing changes to the system, such as when new hardware is introduced or operating systems evolve.

_________________________________________________________________________

Looking for a partner to develop your Bluetooth enabled medical device? Orthogonal’s extensive library of edge cases, testing methods and mitigations will help you get the most out of Bluetooth communication for connected medical devices.

Get in Touch

Back to Insights