Four Challenges in Designing a Consumer Medical Device with Bluetooth
by Sam Koblenski, Device Team Technical Lead, Propeller Health
Designing a consumer Bluetooth medical device is more challenging than it would at first appear. It’s not enough to slap an off-the-shelf Bluetooth module in the device and write some code for it to communicate with the smartphone. Instead, you have to think through several issues: 1) how the user is going to connect the Bluetooth device to their phone the first time, 2) how the connection will behave over time and 3) how Bluetooth communication will affect battery life in a device that should both stay connected and last forever.
At Propeller Health, we use Bluetooth to help the various components of our digital health platform communicate with each other. To use Propeller, a patient attaches a small, battery powered sensor to their existing inhaler for asthma or COPD, which then communicates a timestamp and some metrics of the user’s medication use to the Propeller app on their smartphone. We need the user experience to be simple and obvious, and that means the sensor must be passive, rather than getting in the patient’s way or adding additional burdens. The system should also work flawlessly so the patient doesn’t have to troubleshoot bad connections or deal with unreliable features.
All of these things are difficult to attain on their own. Put them together, and we have some real design challenges to overcome.
1. Getting a New Patient Through First Sync
The first challenge we encounter is getting a patient to connect the sensor to the Propeller smartphone app for the first time, which we call “first sync.” First sync is a critical step in using the Propeller sensor, and we want to give the user the best chance of success.
In an ideal world, first sync happens like this:
- The user receives their new sensor and takes it out of the box. At this point, the sensor is in a deep sleep state called inventory mode, which draws as little power as possible from the battery while still allowing the sensor to wake up with a button press.
- The user opens the Propeller app on their smartphone to go through the first sync workflow with their new sensor.
- The app prompts the user to press the button while displaying a picture of the button’s location on the sensor. While on this screen, the app scans for the sensor using the sensor ID.
- The sensor, now awake, advertises over Bluetooth that it has events to offload.
- When the app sees the correct sensor ID, it connects and offloads the manual event from the button press, along with a couple reset events from when the sensor went into and came out of inventory mode.
- These events are sent up to the server before coming back to the app, finalizing the sensor’s association with the user’s account.
Of course, things don’t always go as intended. If the user focuses on attaching the sensor to their inhaler but never looks at the app, they may never get through first sync. To address this problem, the backend system will track the sensor shipment and send the user automatic emails and notifications once they’ve received the sensor, directing the user to go into the app and run through the first sync flow.
Another problem occurs if the user has Bluetooth turned off on their phone. In this case, the user gets stuck in the first sync flow and never connects the sensor and the app because communication between the sensor and phone is impossible. To fix this problem, the app can sense when Bluetooth is off and tell the user to turn on Bluetooth in the phone’s settings.
Even if the user is doing everything right, the sensor and app can still fail to connect. If that happens, the app will timeout, then prompt the user to press the button on the sensor again to restart the connection attempt. If the user is still having trouble after a few attempts, they can call the Propeller customer support line. Most often something has gone awry in the Bluetooth stack on the phone, and rebooting the phone will fix it. Rarely, the sensor has a problem and needs to be replaced.
All of these design decisions have gone into getting the user through first sync, and they run the gamut from sensor UI design to app UI design to the company design with customer support.
2. Choosing Bonding or Association
Bluetooth connections can be managed in two different ways: by bonding the device to the phone or by a simple direct connection where the app is responsible for connecting to the device. Bonding establishes a more permanent link between the phone and another Bluetooth device by remembering that a particular device has connected to the phone in the past and connecting the next time the device is in range. This type of connection works well for things like Bluetooth headphones, car stereos or keyboards.
For a device like the Propeller sensor, this option is less appealing. The sensor is normally not connected to the user’s phone, and a connection is only necessary if the sensor has an event to offload to the phone, or if the user has lost their sensor and wants the app to find it.
For this type of use case, bonding is overkill. Setting up the bond requires a more complicated handshake between the sensor and the phone, and we found that users are generally not motivated to get through a bonding workflow for this type of device. They’ll do it for headphones and keyboards, but an inhaler sensor should just work with minimal setup fuss. We also found that Bluetooth bonding wasn’t terribly reliable, and users periodically had to re-bond their sensors to their phones, causing users to fall off the system at an alarming rate.
Instead, we settled on associating specific sensors with users’ accounts. When the app is scanning and sees a sensor advertising that is associated with its user, it automatically connects to that sensor to offload events. This way of connecting creates a permanent association between the user and the sensor; the phone is simply a conduit. In fact, the sensor effectively follows the user around if they switch phones or use multiple phones and tablets. As long as the user is logged into the Propeller app on a given phone, that phone knows about their sensors and will connect to them without any additional setup.
3. Extending Battery Life
Bluetooth Low Energy (BTLE) claims to be energy efficient. It’s right there in the name. And while it certainly uses less energy than Wi-Fi or cellular, we still need to design a solution that can run off a small coin cell battery for more than a year. This means squeezing an extra year of in-use life out of that battery, in addition to the sensor’s shelf life, while sending data over Bluetooth.
The first step in using Bluetooth efficiently is to reduce the connection time as much as possible, and one way to do that is to send as little data as possible. The less data there is to send, the less time the connection needs to be open. For a Propeller sensor, all of the necessary data for an inhalation event fits into 24 bytes, so offloading each event happens quickly. This data consists of the MAC address of the sensor, timestamp of the event, battery level, and other inhalation characteristics. Once any pending events are offloaded, the phone only needs to update a couple parameters through similarly short commands, and the connection can be closed.
Another way to reduce connection time is to connect only when the sensor has an event to send to the phone. The rest of the time, the connection is closed and the sensor is in a sleep state, saving power. When the sensor has pending events, it has an advertising policy to signal the phone to open a connection. When a new event is generated, the sensor starts advertising at a fast rate for 80 seconds in case the phone is nearby and can connect to the sensor quickly. Because this fast advertising rate eats up battery power, if the phone doesn’t connect within that window, the sensor will slow its advertising rate until the phone eventually connects or another event occurs, causing the sensor to jump to the fast advertising rate again.
This advertising policy creates a balance that reflects the user’s life. When the user takes their medication and their phone is likely nearby, the advertising policy is highly responsive. The rest of the time, the sensor conserves its battery life while maintaining the ability to connect to the phone if it comes within range.
4. (Un)reliable Syncing
These design decisions work well for most users most of the time, but for some users Bluetooth barely works at all. Sometimes the reason for the syncing problem is obvious: the Propeller app isn’t running, or Bluetooth isn’t turned on. In this case, we can send emails and notifications to users who regularly turn off the app or Bluetooth to explain how Bluetooth enables the best syncing experience. In some cases, the user doesn’t want to leave the app or Bluetooth on because they want to extend the battery life of their phone. For these users, the Propeller system might not be a good fit for their needs.
Some users seem to experience chronic syncing issues with their phones that have nothing to do with the Propeller platform. These cases aren’t explained by the user turning off Bluetooth or fixed with a reboot of the phone, which is usually a quick fix for Bluetooth stack issues. We believe that part of the problem lies with the slow advertising rate if the phone misses the sensor during its fast advertising period. During the slow advertising rate, the phone must attempt to connect immediately after it sees the advertising packet, or it will miss the chance to connect until the next advertising packet five seconds later and time out instead. Some phones seem to miss this connection window every time. We’re still investigating this issue and exploring ways to improve it for those users suffering from chronic syncing problems.
—
Designing a Bluetooth-enabled consumer medical device can be challenging. All of these design aspects involve hard trade-offs, so picking the right mix of features and behaviors is essential to providing the best possible user experience. Dealing with the edge cases and finding new and better ways to sync the device with the phone is a constant exercise. We keep searching for those improvements so our users don’t have to struggle with the technology, and we can concentrate on helping them enjoy a better life with asthma or COPD.