Bluetooth is an important tool used to make increasingly sophisticated connected medical device systems. To get the most out of the technology, a background on what it is and what context it works in is critical. This blog will serve as the introduction to a future Orthogonal white paper on Bluetooth for connected medical devices. For more in-depth discussions on Bluetooth from medical device experts, visit our page on our Bluetooth Low Energy for Medical Devices Webinar Series, co-presented by MedSec.

Part 1: Introduction

In Part 1 of this white paper, we introduce Bluetooth, discuss how it is commonly applied in connected medical device systems, and outline the issues that medical device developers need to address to create a safe and effective Bluetooth-enabled medical device. Those issues will be discussed in depth in future installments.

What is Bluetooth?

Bluetooth is a short-range wireless communication protocol that supports the connection of smartphones, computers and other electronic devices. Since its launch in 1999, it has become the global standard for simple, secure device communication and positioning.¹ Bluetooth technology enables audio streaming and data transfer between paired devices; some of the earliest and most familiar Bluetooth devices are Bluetooth earbuds, headsets and headphones.

Bluetooth is included in the cost of the Bluetooth-enabled device itself, and doesn’t require a subscription to use. As a wireless communications protocol, Bluetooth is more secure and requires less battery power than cellular or Wi-Fi connections, but has a shorter range and lower bandwidth.

Like other software products, the Bluetooth standard is consistently updated by its steward, an industry consortium called the Bluetooth Special Interest Group (SIG). The most recent flagship Bluetooth version is Bluetooth 5.0, which, according to the latest Mobile Overview Report from ScientiaMobile, has penetrated 91% of the combined Android and iOS markets in the U.S. as of Q1 2023.

How is Bluetooth used in the medical device space?

Bluetooth is used in the medical device space to communicate between medical device hardware and companion software applications on devices like consumer-level smartphones and tablets, base stations or hubs, as well as devices found in a hospital setting. This arrangement is known as a connected medical device system. Connected medical device systems are used across a wide variety of clinical domains, and help improve the functionality and usability of traditional medical device diagnosis, monitoring and treatment. Common applications of Bluetooth in medical devices include continuous glucose monitors (CGMs), pulse oximeters, neurostimulation and heart monitoring.

Bluetooth has facilitated the transfer of device intelligence from the device hardware to the companion software, reducing device production costs and increasing scalability. The addition of AI algorithms within companion software gives connected medical device systems the ability to recommend personalized treatment settings and passively collect and analyze patient data.

Example A: Point of Care Diagnostics

The Quidel Sofia 2 is a device used in doctor’s offices, hospitals and clinics to diagnose conditions such as COVID-19 and strep throat. The device’s software analyzes swab samples through a lateral flow assay and provides results within 10 minutes.

A next generation version of this device, the Quidel Sofia Q, is much smaller, lighter and more accessible. A companion smartphone app controls the physical hardware over a Bluetooth connection. By scanning a barcode on the assay, it can instruct the device on what test to run, capture and analyze the resulting data, and send results both to patients and to the cloud.

Example B: Implantable Spinal Nerve Cord Stimulators

Implantable devices are by nature “headless devices” – they lack a physical user interface, such as a display or touchscreen. Early implantable spinal nerve cord stimulators came with a simple external remote control, containing no more than a few buttons and lights. These satisfied patients’ needs at the time, but they were very rudimentary in the customization of care.

Later, St. Jude Medical came out with a device that used the rich interface of an iPod Touch to control the implantable spinal nerve cord stimulator. This enabled much finer controls as well as a more detailed user interface. St. Jude supplied users with the iPod Touch – they could not use their own iPods or iPhones to control the device.

A more recent innovation in this category of medical devices came from Nevro. Nevro’s device uses Bluetooth to communicate between the implanted hardware and the software on a mobile device. However, the software can be installed on a patient’s own personal smartphone.

Nevro’s app improves on the rich control interface with an AI algorithm that analyzes patient data to provide personalized therapy setting recommendations. Patients can use the app to put their implants in and out of MRI Safe Mode, an incredibly handy feature.

How does Bluetooth Low Energy Work?

Bluetooth Low Energy (BLE) is a form of Bluetooth that is separate from Bluetooth Classic. Though they share the same name, they have distinct functionality.

Bluetooth Low Energy compared to Bluetooth Classic.
Source: https://www.bluetooth.com/learn-about-bluetooth/tech-overview/

With the data from the table, we can make the following comparisons:

• Bluetooth Low Energy transmits data over 40 channels at a rate of 2Mbps; Bluetooth Classic uses 70 1Mbps channels.
• Bluetooth Low Energy supports point-to-point, broadcast and mesh communication topologies; Bluetooth Classic only supports point-to-point.
• Bluetooth Low Energy supports a wider range of bit rates than Bluetooth Classic.
• Bluetooth Low Energy uses less battery power than Bluetooth Classic.
• Bluetooth Low Energy has advanced positioning features not present in Bluetooth Classic.

BLE became standardized with Bluetooth 4.0, with all subsequent Bluetooth versions supporting it, making it easier to adopt for device manufacturers.

Peripheral and Central

Bluetooth Low Energy is constructed using the model of a peripheral device and a central device. The peripheral device is the one that advertises its availability. The central device listens for those advertisements and sends a connection request. Once connected, the central device becomes the “parent” device and the peripheral device becomes the “child” device. Both devices can act as the client or the server.

In most connected medical device systems, the smartphone assumes the role of the central device and the hardware assumes the role of the peripheral device. This works well when both devices are active, but adds complications when the smartphone application is dormant. Bluetooth Low Energy, unlike Bluetooth Classic, does not support the functionality of the peripheral device waking up the central device.

Foreground and Background

As a consequence of not allowing the peripheral device to wake the central device, connected medical device system manufacturers must contend with the differences between foreground and background processing.

An app is considered to be running in the foreground on a mobile device if it is currently visible on the user’s screen. Both Android and iOS prioritize processing power for the app in the foreground. When a user is done using that app, and moves onto another one without closing it (i.e., by swiping up on it on an iPhone), it enters the background. Apps idling in the background receive limited processing power. This is not ideal for connected medical device systems that require continuous data refresh between hardware and software.

As mentioned above, when an app is in background mode, its companion hardware cannot use BLE to wake it up. Therefore, medical device manufacturers must program scheduled wakeups into the software itself to perform necessary tasks (e.g., a CGM app that wakes up every two minutes to retrieve data from the CGM device peripheral).

This strategy, while effective, is not infallible. Background apps have a short window of time in which they can run tasks. Background processing power is decided by the smartphone OS, and has a narrower throughput than in foreground mode. It is also dependent on the device battery. When a device enters Low Power Mode, background app refresh and processing is disabled. Users can also manually disable background app refresh through their smart device’s settings.

Even when Bluetooth background mode connectivity works, it is not meant to work for an indefinite period of time. It’s likely something will happen that causes the app to no longer work in background mode. This is why user engagement is critical to medical device app development. Developers must give users an incentive to regularly open the app. When user engagement is done right, it has the added benefit of getting information from the patient that may be relevant to therapy/monitoring and that can augment the data gathered from the device. We’ll discuss user engagement in a later chapter.

Pairing

Pairing is the process by which two Bluetooth-enabled devices link up together. In the case of BLE, it occurs when the central device’s connection request is accepted by the advertising peripheral device. When two devices are paired, they can start using the Bluetooth connection to send and receive data. Paired devices can store pairing information so that they will automatically establish a connection when they are in close proximity; this is called bonding.

There are a variety of methods to pair devices over BLE. Some are more secure than others, and may require extra steps from the user:

• Just Works: The default and least secure method of pairing. Devices connect using a temporary key set to zero. This method is used when either Man in the Middle (MITM) protection is not needed or one of the devices does not have input/output capabilities.
• Numeric Comparison: Both devices display a six-digit number. The user authenticates by selecting “YES” if both devices are displaying the same number.
• Out-of-Band (OOB): A key is generated and exchanged by an additional wireless technology, such as Near-Field Communication (NFC). This method is recommended if at least one device with OOB capability already has cryptographic information exchanged out of band. Here, protection against MITM depends on the MITM resistance of the OOB protocol used for sharing the information.
• Passkey: The user inputs an identical passkey into both devices, or one device displays the passkey and the user enters that passkey into the other device. Exchange of the passkey one bit at a time in Bluetooth 4.2 is an important enhancement over the legacy passkey entry model.
• LE Secure Connection: A single long-term key is generated and exchanged using Elliptic Curve Diffie Hellman (ECDH) public key cryptography.

Most instances of pairing in connected medical device systems are one-to-one, but BLE is capable of connecting one-to-many (e.g., a mother monitoring multiple children’s insulin pumps on a single smartphone) or many-to-many (e.g., multiple nurses’ smartphones connecting to multiple medical devices around a patient’s hospital bed).

Common Use Cases

Orthogonal has commonly seen Bluetooth Low Energy connections used for the following cases:

• Single data fetch: In the foreground, the device hardware and the smartphone software connect and exchange data. The data is then displayed to the user on the smartphone. Example: A CGM app retrieving and displaying current blood glucose levels.
• Device settings change: In the foreground, the user uses the software interface to make changes to the treatment parameters given by the device hardware. Example: Adjusting the intensity of stimulation on an implantable spinal cord nerve stimulator.
• Over The Air (OTA) firmware updates: In the background, the physical medical device receives firmware updates from the manufacturer. Example: Updating the firmware on the medical device to patch an identified bug. (Note: This is a critical feature that the FDA is increasingly requiring as part of device manufacturers’ cybersecurity risk management.)
• Periodic data collection and alerts: In the background, the software tells the smartphone to launch it briefly to retrieve data from the device hardware. Example: A CGM collecting data and sending alerts in case of a hyper- or hypoglycemic event.
• Streaming data: In the background, the software pulls data continuously from the device hardware. Example: A cardiac monitoring device retrieving waveform data and analyzing it through an algorithm to monitor for potential risks or anomalies.

What are the challenges to using a smartphone in a connected medical device system?

Smartphone technology has enabled the evolution of increasingly sophisticated connected medical device systems. Its ubiquity, convenience and familiarity to patients makes it an obvious choice for a connected system. But incorporating a smartphone into a connected medical device system presents additional challenges that are not present when only developing device hardware.

Control

A medical device manufacturer controls all aspects of their medical device: hardware, firmware and software. They can build a device that is tailor made with the right amount of memory and processing power to give the best treatment.

Smartphones, on the other hand, are consumer devices whose construction and maintenance is overseen by manufacturers like Apple, Samsung, Google and Motorola. These companies’ primarily focus on developing smartphones that are convenient for consumers, which involves frequent OS updates and the release of more powerful models.

A connected medical device companion app is one of the many apps on a user’s smartphone. Despite its critical health function, it does not receive priority from the smartphone’s OS.

Due to these factors, using a Bring Your Own Device (BYOD) smartphone in a connected medical device system means relinquishing control over a significant portion of the device. While it is a significant drawback, many medical device manufacturers consider it a worthwhile tradeoff for the scalability, familiarity and more powerful processing afforded by smartphones.

Device Variety

Apple’s iOS and Google’s Android are the two main operating systems (OS) for smartphones in the U.S. But there are far more than two kinds of smartphones on the market. The number of OS version and smartphone model combinations, or device profiles, is over 18,000 in the U.S. alone.²

This presents a significant problem for verifying a connected medical device system. Connected medical device companion apps need to be verified to ensure they function as intended when installed on a device. But it is impossible to test and verify compatibility for every unique device profile. Medical device manufacturers will need to adopt BYOD testing and validation strategies to ensure their app works on a representative majority of devices.

OS Updates

Apple and Google release periodic updates for their iOS and Android systems. These updates go through multiple beta and developer testing periods before they are publicly released. But the rollout and adoption of OS updates are not consistent across all devices. And when the update does reach users, there’s no guarantee they’ll install it immediately. They may delay updating their OS, or may find that it doesn’t support their older model smartphone.

As a result of Apple’s forced upgrade path, a majority of iPhone users quickly get to the latest version of iOS. On the Android side, what OS updates are available to users varies by smartphone vendor and by phone model, and their nudges are far less effective at getting users to upgrade. As a result, there is an increased variance of smartphone OS versions among Android users – thousands for Android, versus dozens for iOS.

Both Google and Apple allow you to set a minimum OS version for downloading your app in their respective app stores. You can require updates to a newer version in order for the app to work. This is one way to enforce app and OS updates. However, because of the aforementioned issues, you will need to cover far more older Android versions for a longer period than iOS.

New iOS and Android releases can introduce bugs that negatively impact the performance of connected medical device systems. In a worst-case scenario, updates can break essential features of a device and require an emergency patch. Medical device developers will need to closely monitor all upcoming updates for both operating systems, and test accordingly.

Conclusion

The combination of Bluetooth connectivity and smartphone ubiquity has greatly expanded the access, ease of use and capability of medical devices, especially those that patients use in their daily lives. This combination enables the increasing sophistication and power of connected medical device systems that can have a truly positive impact on patients’ health.

Bluetooth is not a perfect technology, and requires workarounds and mitigations to maximize its potential in medical devices. In future installments of this white paper, we’ll delve into the challenges and issues of using Bluetooth in a connected medical device, as well as recommend best practices for taking those issues. Part two will cover cybersecurity.