Solving Edge Cases for Bluetooth Medical Devices: Webinar Summary

Bluetooth Low Energy (BLE) may be a convenient communication protocol, but dropping it into a connected medical device isn’t easy. Depending on the complexity of the device, you could have dozens of “what if?” scenarios that need to be identified, thoroughly tested and mitigated. How do you solve these “gotchas” or edge cases to create a safe, effective and consistent Bluetooth-enabled medical device?

Orthogonal and MedSec hosted a webinar on Wednesday, August 16th, part of our joint Bluetooth Low Energy for Medical Devices Webinar Series. Bernhard Kappe, Orthogonal’s CEO and Founder, shared highlights from Orthogonal’s library of edge cases, built up over 10+ years of developing connected medical devices with BLE. He was joined by Buddy Smith, MedSec’s Director of Technical Consulting, who offered his perspective working with clients on the cybersecurity side of BLE edge cases. The webinar was moderated by Randy Horton, Chief Solutions Officer at Orthogonal.

Video Recording

Key Takeaway Points

1. To identify potential edge cases for your device, analyze your usage scenarios and system workflows with Bluetooth risks in mind. What device interactions do you need to support these workflows? What failure models or risks might arise, and how will you address them to ensure your device works as intended?
2. Take the identified edge cases and compile them into a library to serve as a baseline for future projects. This approach eliminates the need to start from scratch.
3. Testing edge cases involves taking a risk-based approach. Evaluate the frequency of occurrence for each edge case and the severity of harm it brings. Based on that, you can determine how to mitigate the issue. If the issue can’t be fully mitigated, plan to clearly communicate specific errors to the user if they arise.
4. Automate as much testing as possible. Orchestrate a testing harness to run tests across multiple device and hardware combinations. For tests that can’t be automated, you can get creative with testing environments (e.g. using a cookie tin as a Faraday cage or placing implantable devices in a phantom, like a saline solution (see image below)).
5. Monitor your device in production. Instrument your system to capture Bluetooth-related events and application behaviors while on the market. Product analytics tools like Mixpanel can help diagnose Bluetooth issues specific to the operating system and smartphone model they come from.
6. Bluetooth might not be the optimal choice for every device. Certain scenarios may be better suited for cellular connection or no connection at all. Bluetooth also adds additional considerations. If you have an app that connects over Bluetooth to device hardware, you need to give patients a compelling reason to use the app to get the most out of it.

Speakers

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.

Buddy Smith, Director of Technical Consulting, MedSec

Buddy Smith is a security engineer focused on protecting electronic devices from attack. He has an extensive background in firmware development, bringing his passion for embedded development to the security world. In his 15 years of experience, Buddy has worked in cryptography, hardware design, firmware engineering, and information security. In his role at MedSec, he has supported clients with regulatory filings, performed penetration tests of devices and created threat models for systems, from long-lived implantable devices to bedside infusion pumps.

Buddy holds a Bachelor of Science in Computer Engineering from the Georgia Institute of Technology, and is an Offensive Security Certified Professional. He is also an IEEE Senior member.

Moderator

Randy Horton, Chief Solutions Officer, Orthogonal

Randy Horton is Chief Solutions Officer at Orthogonal, a software consulting firm that improves patient outcomes faster by helping MedTech firms accelerate their development pipelines for Software as a Medical Device (SaMD), digital therapeutics (DTx) and connected medical device systems. Orthogonal makes that acceleration happen by fusing modern software engineering and product management tools and techniques (e.g., Agile, Lean Startup, User-Centered Design and Systems Thinking) with the regulated focus on device safety and effectiveness that is at the heart of MedTech.

Horton serves as Co-Chair for AAMI’s Cloud Computing Working Group, as well as AAMI CR:510(2021) and the in-process Technical Information Report #115, all of which address how to safely move medical device computing functions into the cloud. He is a frequent speaker at conferences and webinars, including events hosted by AdvaMed, AAMI, HLTH, RAPS and the Human Factors and Ergonomics Society (HFES).

Identifying Edge Cases

As a medical device manufacturer, you can’t control where and when patients use your device. Which is why Orthogonal has identified the many surprisingly ordinary edge cases that may impact your device’s BLE functionality. By preparing for these edge cases, you can optimize the usability and reliability of your connected medical device system.

Below, we describe some of the everyday scenarios that are part of our extensive edge case library.

Low Battery & Low Power Mode

Alice has had a busy day. She left the house with her phone’s battery at 75%, but after running errands for hours, the battery has drained to just 20%. Alice is still 45 minutes away from home and needs to make her phone’s battery last, so when her phone suggests it enter Low Power Mode, she readily accepts.

Unbeknownst to Alice, her continuous glucose monitor app, running in the background of her phone, has had its processing power taken away by her phone’s operating system.

An app is considered to be running in the background if it’s turned on but is not the app currently on a user’s screen. Normally, a medical device app running in the background can be programmed to wake up, gather data from a peripheral device over BLE and send that data wirelessly to the cloud. But Low Power Mode turns off background app processing, meaning that the app can no longer perform those functions.

How do you ensure your connected medical device is working correctly when its companion app is effectively turned off? And what happens to the connected device system if the patient doesn’t recharge their phone before the battery depletes entirely?

Airplane Mode

Ben is boarding his flight from LAX to Dallas-Fort Worth. A seasoned traveler, Ben stores his luggage in the overhead compartment, disinfects his seat and straps on his seatbelt. He even puts his personal smartphone into Airplane Mode before a flight attendant has to ask.

Airplane Mode doesn’t prevent Ben’s cardiac monitoring app from retrieving data over BLE from his implanted device. But the app can’t connect through Wi-Fi or cellular internet connection to upload that data to the cloud until his plane lands.

Should the data be stored on the phone so it can later be sent to the cloud? If so, for how long? How will it be encrypted? And what happens if your device relies on AI algorithms in the cloud to analyze the data?

Device out of Range

Carly has just begun a treatment session with her external nerve stimulator, controlled over BLE from a companion smartphone app. But her daughter took a tumble off her bike, all the way down the street. Carly rushes to help her daughter, and in her haste leaves her phone behind. With her phone and device hardware so far apart, the BLE connection is lost and the treatment is interrupted.

What protocols are in place for a loss of Bluetooth connection during treatment? What is the effect of the interrupted treatment session? And how does the smartphone app reestablish BLE communication?

Polluted Environment

Duncan is in the waiting room of his doctor’s office. His doctor wanted to discuss recent readings from his connected implantable cardiovascular device. While waiting, Duncan accidentally turns off Bluetooth on his phone. He switches it back on and tries to find his device again, but the waiting room is full of similar devices from other cardiac patients, all advertising their BLE connectivity.

When too many devices are advertising Bluetooth at once, it can create a polluted environment that can impact device discovery and connection setup.¹ How do you ensure that your patients discover and connect their smartphone to the right device? And what happens if the wrong device is connected?

References

1. Asthana, S. and Kalofonos, D. M. “The Problem of Bluetooth Pollution and Accelerating Connectivity in Bluetooth Ad-Hoc Networks.” Third IEEE International Conference on Pervasive Computing and Communications, Kauai, HI, USA, 1 Apr 2005, pp. 200-207, doi: https://doi.org/10.1109/percom.2005.43