Managing Edge Cases for Bluetooth Medical Devices

 

This blog will be part of a future Orthogonal white paper on Bluetooth for connected medical devices.

• Part 1: Introduction to Bluetooth for Medical Devices
• Part 2: Managing Edge Cases for Bluetooth 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 2: Edge Cases

Bluetooth connectivity offers many benefits to medical device developers, while 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 variables and complexities. As developers and manufacturers, we need to identify these variables and address them before our devices get into users’ hands.

What are edge cases?

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

For example, a continuous glucose monitor (CGM) app 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 operating system 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 they can 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 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 outside factor stops the user or the device from reaching a goal or performing a particular function. There are hundreds of edge cases that can impact Bluetooth medical devices. The following are selected examples.

Physical parameters

Edge cases can arise when device hardware and app software 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 app that controls the device.
• An implanted device has been placed in the left side of the body, and its signal isn’t strong enough to reach a smartphone being held on the right side.
• The smartphone is packed away in 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 operating system (OS) that can cause issues for a medical device app. As developers cannot override these actions, they must work around the function of the smartphone’s OS to address potential edge cases. For example:

• The device enters Low Power Mode and 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 device and 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 advertising at once, confusing the user as to which 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 store crucial algorithms.
• The user is traveling between geographic regions and/or time zones, which can impact 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 turns Bluetooth off on their smartphone by accident.
• The user moves out of Bluetooth range while treatment is underway.
• The user turns off alerts from the app in the settings of their smartphone.
• The user pairs their smartphone with the wrong device.

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 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 OS and firmware
• Connectivity issues (e.g., out of range, intermittent connectivity, connectivity interference)
• Reconnection after disconnection

Examine what smartphone and OS interactions are needed to support a medical device’s system workflows. Ask what would be the risk of those interactions failing, both to 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 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 can automatically run scenarios on multiple device and hardware combinations.

There are edge cases that require certain physical parameters to be met. Testing for these requires some creativity with testing 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 rigs where implantable devices are placed in a phantom like a saline solution, as seen in the following image:

Testing is not limited to while the device is in development. The FDA has requirements for medical device software post-market surveillance. General best practices for monitoring software “in production,” or on the market include:

• Product analytics.
• Monitoring production environment for performance.
• Appropriate logging from device hardware and firmware.

Medical device software should be instrumented appropriately so that checks on device functions are performed at a frequency equal to the risk, and signals are sent when errors occur. Both monitoring and testing may lead to the discovery of additional edge cases.

Mitigating edge cases

The results of edge case testing may lead to mitigations that can be 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 clearly and specifically communicate errors to the user.

A best practice to communicate “transparent failures” is to describe what error occurred, why it happened, and how it impacts the medical device. For example, if a user connects their app to the wrong device by accident, the app needs to show the user an error message alerting them to this mistake and letting them know the app won’t work 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 to future development endeavors.

Orthogonal has built a detailed edge case library out of our work from over 10+ years of Bluetooth-enabled medical device development. Our library contains edge cases we’ve identified and addressed, and includes issue descriptions, detailed scenarios, actions we took to mitigate them, acceptance criteria and testing methods for future reference. The library grows with every new edge case we discover and mitigate.

An edge case library eliminates the need to start from scratch with every new project, creating an accessible checklist that we can run new projects through. It is an essential practice for any developer who plans to work on multiple Bluetooth-enabled medical devices.

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.

In the next installment, we will discuss another important challenge of working with Bluetooth: Cybersecurity.

– – –

This blog will be part of a future Orthogonal white paper on Bluetooth for connected medical devices.

• Part 1: Introduction to Bluetooth for Medical Devices
• Part 2: Managing Edge Cases for Bluetooth Medical Devices