Managing Edge Cases for Bluetooth Medical Devices

Bernhard Kappe

Published on: November 1st, 2023

This blog contains Part 2 of the Orthogonal White Paper titled “Bluetooth for Medical Devices.” The following are links to each part of the white paper:

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.

– – –

Table of Contents show

Part 2: Edge Cases

Bluetooth connectivity offers many benefits to medical device developers, while also presenting a number of challenges. It allows connected medical devices to take advantage of the power and ubiquity of personal smartphones, but it also adds additional complexities. As device developers and manufacturers, we need to identify and address these variables before our devices get into users’ hands.

What are edge cases?

In computing, an edge case is an issue or scenario that occurs in an extreme situation or exception case. If these “gotchas” or “what if” scenarios are not addressed during development, they can compromise the functionality of a computing system.

For example, consider a CGM app that has been tested on a smartphone with a full battery. But in the real world, battery levels fluctuate. When a smartphone battery gets below a certain threshold, the smartphone OS enters the device into low power mode. To address this edge case, the manufacturers of the CGM app need to know how low power mode will affect their app, and if it does, how to work around it.

How do edge cases impact Bluetooth?

Bluetooth edge cases can impact the usability and safety of a connected medical device. Edge cases may cause the Bluetooth connection between the device hardware and software to drop or prevent the device and app from advertising and pairing successfully. Depending on how reliant a connected medical device system is on Bluetooth, the fallout from unaddressed edge cases can range from frustrating users to compromising essential care.

Speakers from Orthogonal and medical device cybersecurity firm MedSec discussed the impact of edge cases in more detail in our Solving Edge Cases for Bluetooth Low Energy Medical Devices webinar.

Where do Bluetooth edge cases come from?

Edge cases arise when an external factor prevents the user or the device from reaching a goal or performing a particular task. There are hundreds of edge cases that can impact Bluetooth medical devices. The following are selected examples.

Physical parameters

Edge cases can arise when medical device hardware and the companion smartphone running the app are not within optimal range and/or position relative to one another. For example:

The device hardware is physically too far away from the smartphone that controls the device.
An implanted device in the left side of the body can’t reach a smartphone being held on the right side due to weak signal.
The smartphone is inside a bag or suitcase that the Bluetooth signal can’t penetrate through.

Interactions with the smartphone OS

As discussed in Part 1 of this white paper, there are certain actions taken by the underlying smartphone OS that can cause issues for a medical device app. As developers cannot override these lower-level OS behaviors, companion apps must work around them to address potential edge cases. For example:

When the device enters into Low Power Mode, the OS turns off background app refresh, preventing a medical device companion app running in the background from collecting data over Bluetooth.
An update to the OS causes an unexpected error that disconnects the app from the device without notifying the user.
The OS prioritizes processing power on another app, causing a bottleneck on the data transmitted over Bluetooth between the medical device and its app.

Environmental factors

Users are not always in the optimal environment when operating their Bluetooth medical devices. For example:

The user is in an environment that dampens Bluetooth signals.
The user is in a congested environment where multiple Bluetooth devices are active simultaneously, confusing the system as to which physical device is theirs.
The user places their smartphone in Airplane Mode. While Airplane Mode does not turn off Bluetooth, it disconnects the app from the cloud, where the medical device system may perform crucial algorithms.
The user is traveling between geographic regions and/or time zones, which can impact calendar-based device operations.

Operational mistakes

Developers may take for granted that users know how to use their smartphones. But not every user is comfortable with technology. For example:

The user accidentally turns off Bluetooth on their smartphone.
The user moves the device and phone out of Bluetooth range of each other during treatment.
The user turns off app alerts in their smartphone settings.
The user mistakenly pairs their smartphone with the wrong device.

Bluetooth for medical devices white paper CTA

How to address Bluetooth edge cases

As edge cases are inevitable, it’s the responsibility of developers and manufacturers to identify, test and mitigate edge cases in their Bluetooth-enabled medical devices.

Identifying edge cases

To identify edge cases for a Bluetooth-enabled medical device, start by analyzing the medical device’s usage scenarios and system workflows with Bluetooth risks in mind. Pay particular attention to the following usage scenarios:

Bluetooth pairing, bonding and unpairing
User interaction with OS
OS-level configuration parameters
Android and iOS differences (e.g., permissions/control from app)
Interaction or effects of other apps running on OS
Background mode
Updates to the smartphone’s OS and firmware
Connectivity issues (e.g., out of range, intermittent connectivity, connectivity interference)
Reconnection after disconnection

To address these scenarios, developers should examine what smartphone and operating system features are needed to support the medical device’s system workflows. Developers will need to ask what the risk of those interactions would be if they failed, both for device functionality and to the end user. By identifying those, the potential edge cases for a device should become clear.

Testing edge cases

Testing edge cases involves taking a risk-based approach. The kind and quantity of testing done for an edge case should be based on the frequency of occurrence and the potential severity of harm. Many edge case tests can be automated. For example, a testing harness, which imitates the environment a device will be used in, can automatically run through different scenarios on various combinations of devices and hardware.

Some edge cases need specific physical parameters to be tested properly. Testing for these edge cases requires some creativity in setting up test environments. For example, it’s not feasible to surgically implant a device just to test edge cases. To work around this, Orthogonal has created testing setups where implantable devices are placed in a phantom like a saline solution, as seen in the following image:

devices in phantom saline solution bernhard

Testing continues beyond the initial device development phase. The FDA has requirements for medical device software post-market surveillance. General best practices for monitoring software “in production,” or on the market include:

Using Product Analytics tools that can monitor user and device behavior.
Monitoring the production environment for performance issues.
Appropriate logging of system activities from device hardware and firmware to support retroactive analysis of issues.

Medical device software should be set up so that checks on device functions occur at a frequency equal to the risk, and alerts are triggered when errors occur. Expect monitoring and testing to often lead to the discovery of additional edge cases.

Mitigating edge cases

The results of edge case testing may lead to mitigations that are easily implemented in the medical device software and/or hardware. But there will be some edge cases that are outside of developer control and can’t be mitigated. For these scenarios, it is important to communicate errors clearly and specifically to the user.

A best practice to communicate failures is to transparently describe what error occurred, why it happened, and how it impacts the medical device. For example, if a user accidentally connects their app to the wrong device by accident, the app should display an error message alerting the user about the mistake and explaining that the app won’t function properly until the right device is connected.

Building an edge case library

Once an edge case has been identified, tested and solved, you may think to close the book on it. But that knowledge can be extremely valuable for future development projects.

Orthogonal has compiled a detailed edge case library based on our almost 15 years of developing Bluetooth-enabled medical device apps. Our library of edge cases includes issue descriptions, detailed scenarios, actions we took to mitigate them, acceptance criteria and testing methods for future reference. The library expands every time we discover and mitigate a new edge case. The following table includes a few select edge cases from Orthogonal’s library:

Edge case library excerpt image — *Sample of entries in the Orthogonal edge case library*

With each new project, an edge case library becomes a handy checklist to avoid making “known” mistakes in new development. It is an essential practice for any developer who plans to work on multiple Bluetooth-enabled medical devices and/or multiple versions of a single Bluetooth-enabled device.

Conclusion

To solve edge cases that can impact device usability and safety, Bluetooth-enabled medical device developers need to think outside of the box. We must acknowledge that Bluetooth-enabled medical devices are used in the unpredictable real world, and they should be designed and tested accordingly.

– – –

This blog contains Part 2 of the Orthogonal White Paper titled “Bluetooth for Medical Devices.” The following are links to each part of the white paper: