Article
Roundup: Bluetooth Medical Devices Cleared by FDA in 2024
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.
– – –
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.
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.
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.
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.
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:
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:
Users are not always in the optimal environment when operating their Bluetooth medical devices. For example:
Developers may take for granted that users know how to use their smartphones. But not every user is comfortable with technology. For example:
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.
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:
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 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:
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:
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.
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.
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:
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.
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:
Related Posts
Article
Roundup: Bluetooth Medical Devices Cleared by FDA in 2024
Article
Roundup: Bluetooth Medical Devices Cleared by FDA in 2023
Article
Testing Strategies for Bluetooth Medical Devices
Article
Patient Engagement & UX for Bluetooth Medical Devices