Bluetooth Low Energy for Medical Devices Crash Course

Bernhard Kappe

Published on: July 12th, 2023

Introduction

Bernhard Kappe, Orthogonal’s CEO and Founder, kicked off our first Bluetooth Low Energy (BLE) for Medical Devices Webinar with a crash-course on the essential trends, advantages and challenges of using BLE for connected medical devices. He addressed key questions such as: What is Bluetooth Low Energy? How do smartphones and connected medical devices communicate? And how do medical device manufacturers overcome the challenges of working on hardware and with a protocol that they don’t fully control?

This blog is a detailed summary of his talk with the accompanying slide deck. You can watch the video recording of Bernhard giving this presentation below.

__________

In 2007, Steve Jobs announced the first iPhone. In 2011, Marc Andreessen, creator of the Netscape browser and co-founder of the Andreessen Horowitz venture capital firm, wrote an op-ed in the Wall Street Journal called “Software is Eating the World.” It was inspired by the rapid adoption of smartphones in just four years since the first iPhone was introduced. Andreessen’s thesis was that every company would eventually become a software company. This prediction has largely come true, and iPhones and Android smartphones were big contributors to that transformation.

It’s been almost 16 years since the first iPhone was introduced, and the technology has been constantly evolving: the processing power has gone up 500 fold; the cellular network data throughput is around 2000 times faster; it has 32 times the storage; where the original had a two megapixel camera, the latest model has three backward-facing 12 megapixel cameras as well as a forward-facing 12 megapixel camera.

In its first year on the market, the iPhone sold 1.4 million units. Today, there are 7.3 billion plus smartphones out in the world, with consumers upgrading to the latest model every few years.

What about the App Store? When the iPhone launched, it had a small number of apps. Today’s App Store has over two million apps that cover any function you can imagine. There are more medical apps and medical device companion apps every year. The first medical device app Orthogonal worked on was the Accu-Chek Connect App in 2012. It was a Bluetooth-enabled app for Roche Diagnostics that connected to a glucometer and included an insulin bolus calculator.

How has the medical device space evolved since then? As an example, let’s take a look at Point of Care Diagnostics. On the left side of the above slide is the Quidel Sofia 2. It is used in many doctor’s offices, clinics and hospitals to diagnose COVID or strep throat from a swab test. The swab is inserted into the machine, which then processes it using a lateral flow assay. Within 10 minutes, you have the results.

On the right is the latest device from Quidel, the Sofia Q. It’s much smaller than the Sofia 2. In fact, it’s a lot less smart too, with a much lower bill of materials. What makes this device powerful is the companion smartphone app that controls the device over Bluetooth. The app scans a barcode on the assay and instructs the device on what test to run. Once the test is completed, the app analyzes the data through an AI algorithm, displays the results and sends those results to the cloud and even to the CDC. It’s an example of the trend of moving smarts and functionality from the device to the app, reducing production costs and facilitating scalability.

Another example is the category of implantable spinal cord nerve stimulators. Early versions of this device came with remotes with very simple interfaces – just a few buttons and indicator lights – but they satisfied users’ needs. Later, St. Jude Medical (now owned by Abbott) added Bluetooth to the device and provided patients with an iPod Touch to control the nerve stimulator. The iPod Touch enabled the device to have a much richer interface with finer controls, making it easier to adjust treatment.

The latest evolution in this category, released late last year, is this device on the right, from Nevro. It’s a spinal cord nerve stimulator that’s BYOD – Bring Your Own Device – meaning it uses a patient’s smartphone rather than a smartphone provided by the manufacturer. It includes the same initial functionality for changing the stimulator settings, but it also collects data from the patient and feeds it into an AI algorithm capable of providing personalized therapy setting recommendations. The app also includes a useful feature that allows the device to enter MRI safe mode, enabling safe MRI scans with the implanted device inside the patient.

Again, we see the trend of increasing functionality to enhance patient benefits, providing them with better treatment and greater convenience in their lives. We also see companies strive to outperform one another to create better devices. St. Jude is likely developing their own device in response to what Nevro has done.

Smartphone technology is used more frequently and in more sophisticated ways in combination with medical devices. There’s obvious reasons for this trend – smartphones are useful, convenient and familiar to patients. However, they are significantly different from the medical devices themselves. As a medical device manufacturer, you have control over every aspect of your device: hardware, software and firmware. You manage the size and costs of the processor and memory, and you design the user interface.

This isn’t the case with smartphones. Apple, Samsung and other manufacturers dictate the devices’ specifications, and their primary goal is to ensure that smart devices are convenient for consumers. Your medical device app is just one among many apps on a user’s phone.

When developing a smartphone companion app, you have to consider the variety of smartphone models available, as well as the different operating system versions installed on those models. The number of combinations of device model and OS versions in the U.S. alone is over 18,000^[1]. You also aren’t in control of when the smartphone software updates are released – that decision lies with the manufacturer or the user.

Now that we have established the context, let’s delve into Bluetooth. Bluetooth is a communication protocol controlled by the Bluetooth Special Interest Group (SIG). The current version of Bluetooth is 5.3, although there are multiple different types of Bluetooth available. Bluetooth Classic is used in devices such as Bluetooth speakers, headphones and other data or audio streaming devices. Bluetooth Low Energy (BLE) is what we use for our medical devices. As the name implies, BLE has lower battery consumption but also has lower bandwidth compared to Bluetooth Classic. The only commonality they share is the Bluetooth name.

Bluetooth Low Energy is easily conceptualized as the relationship between a peripheral and a central device. The peripheral advertises its availability, and the central is listening for those advertisements. The central sends a connection request and connects to the peripheral. Once they’re connected, the central becomes the parent device and the peripheral becomes the child device. Either of those devices can act as a client or server.

In the majority of use cases we see, the smartphone assumes the role of the central while the medical device functions as the peripheral. For example, when connecting my smartphone to a glucometer to receive data, the glucometer is the one advertising its availability and my smartphone is the one connecting. There are some exceptions, but most FDA cleared devices follow this pattern.

When it comes to the relationship between peripheral and central devices, one common misconception we see is clients thinking, “The peripheral can remain dormant and awaken the phone when it needs to do something.” That’s not how it works with BLE. In order to connect to the smartphone, the peripheral device has to be advertising itself at regular intervals. This has consequences for background processing.

A smartphone is a consumer device, and battery life is at a premium. Operating systems prioritize the app that users are engaging with at that moment – the app running in the foreground. That foreground app gets most of the processing power. Apps that are open but not currently on the user’s screen are in background mode, and receive a minimal amount of processing.

To do anything with an app in background mode, you have to schedule tasks that prompt the operating system to launch the app. Once the task is completed, the app returns to a dormant state. For example, a continuous glucose monitor (CGM) app that gets data from the CGM peripheral every two minutes.

There are several caveats to consider when dealing with background mode. You have a limited time frame of around 10 seconds to run tasks. You can ask for additional time for data processing, but it’s up to the operating system, and it depends on what else is going on in the device. You’ve got less throughput in background mode than in foreground mode.

Background mode is also influenced by the device’s battery status. When the battery runs low, the device enters a lower power mode, which disables background app refresh. Consequently, you won’t be able to get any data in that case.

What happens when a user closes an app, by swiping up on it as depicted in the picture? When the user closes the app, background app refresh is disabled, and the peripheral – the medical device – can’t communicate over BLE to re-open the app.

Next, let’s discuss pairing. Pairing is how devices connect securely to each other over BLE, and is necessary for enabling any kind of encryption. As described earlier, it occurs when the central device’s connection request is accepted by the advertising peripheral device. Bonding is storing that pairing information on the devices, eliminating the need to repeat the pairing process every time. Bonding offers greater convenience, although there are cases where the pairing process needs to be repeated, such as when the user deletes the registration, or gets a new device or phone.

The most common and default way to pair devices over BLE is called Just Works. It uses a temporary key set to zero. However, this pairing method is not very secure and is not ideal for medical devices, although it may be suitable for certain devices.

Numeric comparison is more secure than Just Works, as it adds an additional calculated number on both devices that the user confirms. Another method is out-of-band pairing, which uses another wireless technology, like Near Field Communication, to exchange keys. You might’ve seen a barcode or QR code on one device that the other device scans to establish the connection. The Apple Watch uses this method, along with a pass key.

What are the common use cases we see for BLE? One is a single data fetch. The devices connect in the foreground mode, the app gets a reading, displays it to the users and then uses it to adjust the treatment. This can be seen with devices such as pulse oximeters or glucometers. Another use case is changing the settings on the device, like the aforementioned spinal nerve cord stimulator app enabling the device’s MRI safe mode.

In the background, you can use BLE for over-the-air (OTA) device firmware updates. Chip makers like Nordic have software development kits for doing OTA updates securely. You can also perform periodic data collection and alerts in the background. Again, we have the example of a CGM that collects data every couple of minutes and sends alerts to the patient in case of hypoglycemic or hyperglycemic events. Another thing you can do in the background is streaming data. For example, a cardiac monitoring device that pulls waveform data continuously and uses that data in an algorithm to monitor for potential risk.

Pairing also comes with various use cases. Typically, you’re doing a one-to-one pairing between the peripheral device and the smartphone. But you might have situations that need one-to-many or even many-to-many pairing.

An example of one-to-many pairing would be a parent who is monitoring the CGMs of multiple children on a single smartphone. How do you know you have the right connection for the right child’s insulin pump?

An example of many-to-many pairing would be multiple nurses checking multiple medical devices around a hospital bed. Nurses work in shifts, so the medical devices need to be able to pair with multiple nurses’ personal smart devices.

In certain scenarios, there may be multiple devices and smartphones together in a room. For example, if you are implanting a Bluetooth-enabled device in an operating room, there may be multiple smartphones present, and you need to pair the implanted device to the correct one.

For this last slide, I’ll briefly touch on topics that we’ll explore in-depth in their own dedicated webinars. First, security. BLE introduces increased security concerns for your device. There’s a variety of attack vectors and surfaces you need to mitigate: man-in-the-middle attacks, identity tracing, passive eavesdropping, phone hacks or cloud hacks, etc.

BLE also comes with a bevy of edge cases. Due to smartphones being consumer devices, unforeseen events can happen. We’ve compiled a library of dozens of edge cases that we consider when developing connected medical devices. It includes situations like dropped connections, intermittent connections, data loss, data priority, crash recovery, dealing with low power mode and more.

Some of our edge cases have nicknames. For instance, we refer to smartphone clock time synchronization as “Siberia” because smartphones don’t automatically sync to a universal clock in Russia. Moving between cellular service bands is nicknamed “Niagara Falls” as it’s very easy to cross the U.S.-Canada border there. These are a few examples of the issues you may encounter when verifying your device.

Another important consideration is platform compatibility testing. Just because a smartphone is compatible with Bluetooth doesn’t mean that it has all the features of the latest version of the protocol. You need to be very careful with what features you are leveraging. The same applies for BYOD testing. It’s impossible to test for all possible permutations, but if you want your software to run on the maximum number of devices, you need to account for hardware and software variability.

Of course, Bluetooth is liable to change, and how we use it will continue to evolve as well. We’ll have a webinar where we discuss our insights on the future direction of Bluetooth.

Last but not least, regulatory considerations are crucial. The FDA has relaxed certain requirements for BYOD testing in certain devices. However, devices with more sophisticated features introduce additional client-side risks. We can share various strategies for testing and mitigating those risks to satisfy regulatory requirements. We invite you to join us for our future discussions on these topics.

__________

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

About the Author

Bernhard Kappe, CEO and Founder, Orthogonal

Bernhard Kappe is the Founder and CEO of Orthogonal. For over a decade, Bernhard has provided thought leadership and innovation in the fields of Software as a Medical Device (SaMD), Digital Therapeutics (DTx) and connected medical device systems. As a leader in the MedTech industry, Bernhard has a passion for launching successful medical device software that makes a difference for providers and patients, as well as helping companies deliver more from their innovation pipelines. He’s the author of the eBook Agile in an FDA Regulated Environment and a co-author of the AAMI Consensus Report on cloud computing for medical devices. Bernhard was the founder of the Chicago Product Management Association (ChiPMA) and the Chicago Lean Startup Challenge. He earned a Bachelor’s and Masters in Mathematics from the University of Pennsylvania, and a Bachelor’s of Science and Economics from the Wharton School of Business.

References

1. Source: ScientiaMobile

Back to Insights