Bluetooth connections drop every day. Readings should not. Here is how to design the device protocol and the phone app so that every reading reaches the clinician once, in order.
A patient wears a heart monitor overnight. In the morning the care team's dashboard shows a gap from 2am to 6am. The sensor worked all night. The readings never made it off the device, or they made it to the phone and stopped there.
Gaps like this are rarely a hardware fault. They are usually a design choice in the app and the device protocol, made early and without much thought. This post covers the choices that matter, in plain terms, for product owners and engineering leads building a wearable or remote monitoring product.
Treat a dropped connection as a normal state, not an error. These things happen to every patient, every week:
You cannot stop these. You can make sure none of them costs a reading.
The most common mistake is a "live stream only" design. The device sends each reading once, as it happens. If the phone is not listening at that moment, the reading is gone.
The fix is simple to describe. The device stores every reading in its own memory and gives each one a number that only goes up. The phone remembers the last number it saved. After any reconnect, the phone asks for everything after that number.
This is not a new idea. The Bluetooth SIG's Glucose Service works this way. Each record carries a sequence number, stored records are fetched through a "Record Access Control Point", and the collector is expected to ask for records from the last one it received plus one. The spec also advises filtering by sequence number rather than time, because a device clock can be wrong (Bluetooth SIG, Glucose Service 1.0.1). If your device uses its own protocol, as many wearables do, copy this pattern.
A reading passes through three places: the device, the phone, and your server. Each place should keep its copy until the next place says "got it".
This means some readings will arrive twice. That is fine if the server is ready for it. Use the device ID plus the sequence number as the key, and have the server ignore a reading it already holds. Duplicates you can detect are harmless. Readings you deleted too early are gone for good.
Plan for the device filling up, too. If the phone is off for a week, what does the device drop first? Decide this with the clinical team, write it down, and show it in the app.
Getting the connection back is only the first step. On Bluetooth Low Energy, notification subscriptions do not carry over to a new connection, so the app has to set them up again. A solid reconnect runs the same steps every time:
Write this as an explicit state machine in the code, with a named state for each step. It makes bugs easier to find, and it lets the app show the patient something honest, such as "Catching up on 4 hours of readings", instead of a spinner.
iOS. The app must declare the bluetooth-central background mode and use Core Bluetooth state restoration, so the system can relaunch it for Bluetooth events after ending it to free memory (Apple). It has limits. Developers report that restoration does not relaunch an app the user has swiped away (example report). So the device must hold data until the patient opens the app again, which is one more reason for Rule 1.
Android. Since Android 12 the app needs the BLUETOOTH_SCAN and BLUETOOTH_CONNECT runtime permissions (Android Developers). For a connection that must stay open, a foreground service with a visible notification is the usual approach. Then test on the phone brands your patients actually own, because battery savers differ by maker.
A demo shows the app connecting once on a desk. Real testing breaks the connection on purpose, in the middle of a transfer, and checks that every reading still arrives exactly once. A short list to start with:
Log every step of the connection with timestamps, on the phone and on the server. Bluetooth bugs are hard to reproduce, and a good log is often the only way to tell whether a gap came from the radio, the app or the upload.
Many monitoring products learn a personal baseline for each patient and flag changes against it. Missing data weakens that. A gap can hide the start of a decline, and a burst of late readings can look like a sudden change if timestamps are wrong. Reliable transfer is not separate from the analytics. It is what the analytics stand on. Our wearable and remote patient monitoring software page shows how the pieces fit, from device to care team.
Innometrique was founded in 2025. Before that, the founder's earlier company, Hashtaag Technologies (later acquired by Biofourmis), built the AWAK dialysis companion app, including the protocol work for building data packets and handling the device's replies, and the Relief recovery app, which used Bluetooth connected devices. That is founder background, not Innometrique client work. The details are on the founder track record page.
If you are planning a wearable product and want a rough budget first, the AI project cost estimator gives an indicative range with every assumption shown. For the production side of any build, see AI Proof of Concept vs Production: Why Most POCs Never Ship.
Tell us about your device and your app. We will look at the protocol, the sync design and the test plan, and tell you plainly where the risks are.
Talk to Us →