How Medical Devices Use BLE to Stream Patient Data Without Wi-Fi or Cellular
Most connected medical devices ship with a wireless radio that costs under $2, draws microamps in sleep, and pairs with every smartphone on the planet. Yet engineering teams routinely leave 80% of that radio’s throughput on the floor because they never tune past the default BLE settings. A CGM running stock connection parameters might push 40 kbps when it could hit 500+. An ECG patch might drop waveform data during a bathroom break because nobody configured store-and-forward. The BLE stack in your medical device is probably the most under-optimized subsystem in your entire product.
This article walks through the protocol-level architecture that makes BLE the dominant connectivity layer for patient-facing hardware: GATT structure for health data, Bluetooth SIG medical profiles, real-time streaming vs. batch transfer strategies, throughput optimization, and the security baseline your device needs.
GATT Architecture: How Medical BLE Data Is Actually Structured
BLE uses a client-server model called GATT (Generic Attribute Profile). The sensor is the GATT server; the phone, tablet, or gateway is the GATT client. Data lives on the server side, organized into Services (logical groupings) and Characteristics (individual data points).
A CGM, for instance, exposes a Continuous Glucose Monitoring Service containing characteristics like CGM Measurement, CGM Feature, and Session Start Time. The phone reads or subscribes to those characteristics to get patient data.
┌──────────────────┐ BLE ┌──────────────────┐
│ Medical Sensor │◄────────────────────►│ Phone / Gateway │
│ (GATT Server) │ │ (GATT Client) │
│ │ │ │
│ ┌──────────────┐ │ Notify/Indicate │ ┌──────────────┐ │
│ │ Health Service│ │ ──────────────────► │ │ Mobile App │ │
│ │ │ │ │ │ │ │
│ │ Characteristic│ │ Read/Write │ │ Dashboard │ │
│ │ (Measurement)│ │ ◄──────────────────► │ │ │ │
│ └──────────────┘ │ │ └──────────────┘ │
└──────────────────┘ └──────────────────┘Three data transfer mechanisms matter:
Read: The client polls the server. Simple, but wasteful for continuous data. Use this for static config values (device model, firmware version) or infrequent measurements.
Notify: The server pushes data whenever it’s ready, with no acknowledgment from the client. Fast, low overhead, ideal for continuous data flow (heart rate, SpO2, glucose readings).
Indicate: Same push model, but the client must acknowledge each message before the server sends the next. Roughly half the throughput of Notify, but guarantees delivery. Use this for critical alerts or batch transfer where you can’t afford silent data loss.
For most BLE patient monitoring scenarios, Notify is the workhorse. Indicate is the safety net.
Bluetooth SIG Medical Profiles: Standards That Save You Months
The Bluetooth SIG maintains standardized GATT profiles for common medical device types: pre-defined service and characteristic structures that any compliant device can use and any compliant app can consume.
The ones you’ll encounter most:
- Glucose Service (GLS): Glucometers and CGMs. Includes glucose measurement, measurement context, and Record Access Control Point (RACP) for batch retrieval.
- Continuous Glucose Monitoring Service (CGMS): Purpose-built for CGM devices like the Dexcom G7. Adds session management and calibration data on top of GLS.
- Heart Rate Service (HRS): Heart rate measurement and sensor location. Well-supported across every mobile OS.
- Blood Pressure Service (BLP): Systolic, diastolic, MAP, plus pulse rate. Designed for cuff-based monitors.
- Health Thermometer Service (HTS): Temperature measurement with type (oral, axillary, etc.).
- Pulse Oximeter Service (PLX): SpO2 and pulse rate, with spot-check and continuous measurement modes.
Using SIG profiles isn’t mandatory; you can define custom GATT services for proprietary data. But SIG profiles buy you interoperability with third-party apps, simpler mobile development (iOS and Android have built-in parsing for some), and alignment with what regulatory bodies expect as a recognized baseline.
If your health sensor fits an existing profile, lean on it. You’ll shave months off development.
Real-Time Streaming vs. Batch Transfer: Picking the Right Strategy
Medical devices broadly need one of two data movement patterns, sometimes both.
Real-time streaming means continuous notifications at a fixed cadence. An ECG patch sampling at 250 Hz needs to push waveform data every few milliseconds. A pulse oximeter updating SpO2 every second needs low, consistent latency. You tune the connection interval tight (7.5 to 30 ms), pipeline multiple notifications per connection event, and use Notify for speed.
Batch transfer means the device stores data locally and uploads when a phone connects. Think overnight glucose readings on a CGM, or a 24-hour Holter monitor dump. The Bluetooth SIG defines RACP (Record Access Control Point) specifically for this. Here’s how it works: the client writes a request (e.g., “give me all records from the last 8 hours”) to the RACP characteristic. The server then sends stored measurements via notifications or indications. Finally, the client acknowledges completion. This is how most CGM implementations work for historical data.
Choose your BLE data transfer strategy:
┌─────────────────────────────────────────────────┐
│ Is the data latency-sensitive (< 1 sec)? │
│ │
│ YES ──► Real-time Notifications │
│ • Tune connection interval (7.5-30ms) │
│ • Pipeline multiple notifs per event │
│ • Use Notify (not Indicate) for speed │
│ │
│ NO ──► Batch Transfer via RACP │
│ • Store-and-forward on device │
│ • Transfer on next connection │
│ • Use Indicate for reliability │
│ • Relaxed conn interval saves power │
└─────────────────────────────────────────────────┘Many products need both. A CGM streams the current reading in real time but also stores 8 hours of history for batch sync. Design your GATT services to support both patterns from the start.
Where BLE Throughput Is Won or Lost in Medical Devices
Default BLE settings are conservative to a fault. Every medical device connectivity project I’ve seen needed to touch at least 3 of these 5 levers.
Connection Interval controls how often the radio wakes up to exchange data (range: 7.5 ms to 4 seconds). For real-time medical streaming, 7.5 to 15 ms is typical. For low-priority batch transfers, 100 to 500 ms works. The tradeoff is direct: shorter intervals burn more power but give more transmit opportunities.
MTU Negotiation is probably the single biggest throughput win. The default ATT_MTU is 23 bytes, just 20 bytes of usable payload per notification. Negotiate up to 247 bytes (or higher if your stack supports it) and you move 244 bytes per notification: a 12x improvement in payload efficiency per packet. Both sides must support the negotiated size.
Data Length Extension (DLE) extends the link-layer PDU from 27 to 251 bytes. Without it, even a large MTU gets fragmented at the link layer, eating air time with packet headers. Most modern BLE 4.2+ stacks support DLE, but it’s often off by default.
PHY Selection (BLE 5.0+) gives you 3 options. 1M PHY is the baseline. 2M PHY doubles the raw bitrate with minimal range penalty indoors. Coded PHY extends range dramatically (useful for devices that need to reach a gateway through walls) but cuts throughput significantly. For body-worn devices talking to a phone in the same room, 2M PHY is almost always the right call.
Notification Pipelining stacks multiple notifications into a single connection event (4, 6, or more) instead of one per interval. This is what pushes you into the 400–700 kbps range.
Estimated BLE Throughput by Configuration:
Config | Practical Throughput
─────────────────────────────── | ───────────────────
Default (23B MTU, 1M PHY) | ~35-50 kbps
DLE + 247B MTU + 1M PHY | ~200-300 kbps
DLE + 247B MTU + 2M PHY | ~400-700 kbps
+ Notification Pipelining | Upper end of range
Typical medical data rates needed:
Pulse Oximeter SpO2: ~0.1 kbps
Heart Rate: ~0.5 kbps
Blood Pressure: ~1 kbps (batch)
CGM Glucose: ~1-5 kbps
Single-lead ECG (250 Hz): ~20-50 kbps
Multi-lead ECG: ~100-300 kbpsMulti-lead ECG is the edge case that pushes you toward max configuration. Everything else has headroom to spare. Even a single-lead ECG fits comfortably within a mid-tier BLE setup.
If you’re working with the Hubble Network for satellite or terrestrial connectivity and building custom BLE firmware, the Hubble Device SDK provides the BLE stack foundations; the same MTU, DLE, and PHY principles apply when configuring your advertising packets and data payloads. For packet structure specifics, the advertising packet documentation shows how payload bytes are allocated.
Power and Reliability for Devices Worn Days or Weeks
Sleep current in the low µA range, transmit bursts measured in milliseconds: that’s what keeps BLE viable for body-worn medical devices. A CGM patch running for 14 days on a coin cell isn’t magic; it’s a well-tuned BLE connection with long sleep intervals between transmissions.
Connection supervision timeout determines how long the device waits before declaring a lost connection. Too short (a few hundred ms) and the link drops every time the patient walks to the kitchen. Too long (30+ seconds) and you waste power scanning for a peer that’s gone. For patient monitoring, 6 to 20 seconds is a practical range. Pair this with on-device storage so no data is lost during disconnections. Store-and-forward isn’t optional for medical devices; it’s a safety net that should always be running.
Indicate vs. Notify reliability: Notify is faster but the server has no way to know if the client received the data. For streaming waveforms, use Notify with application-layer sequence numbers so your app detects gaps and requests retransmission. For critical alerts (hypoglycemia alarm, arrhythmia detection), use Indicate. The throughput hit is worth the delivery guarantee.
Connection subrating (BLE 5.1+) is worth adopting if your chipset supports it. It lets devices dynamically switch between a fast connection interval during active streaming and a slow interval during idle periods, all without tearing down and re-establishing the connection.
Security Baseline for Medical Bluetooth Data
BLE security for medical devices comes down to a few non-negotiable requirements.
LE Secure Connections (LESC) with ECDH key exchange is the minimum. Legacy pairing (the pre-4.2 “Just Works” model) is broken against passive eavesdropping. Don’t ship it.
AES-128-CCM encryption is mandatory for any GATT characteristic carrying health data. The Bluetooth SIG’s standardized health services require encryption and authentication on their characteristics. If you’re building custom services, enforce the same GATT security levels.
Bonding stores encryption keys so the device and phone don’t have to re-pair every connection. For medical devices, bonding is essential for both user experience (no re-pairing after a phone restart) and security (keys are stored securely, not exchanged in the open repeatedly).
Bluetooth SIG Qualification (QDID): every product using Bluetooth must complete qualification through the SIG, declaring your design, listing components, and paying a fee. Regulatory bodies (FDA, MDR) increasingly reference Bluetooth SIG security standards when evaluating medical device connectivity, so alignment matters beyond just compliance.
Implementation Checklist
Before you tape out or freeze firmware:
- Select a SIG health profile if one exists for your sensor type. Design a custom GATT service only when necessary.
- Choose streaming, batch, or hybrid based on your clinical data latency requirements.
- Negotiate max MTU, enable DLE, select 2M PHY unless range forces you to Coded PHY.
- Implement store-and-forward on-device. Assume disconnections will happen.
- Enforce LE Secure Connections and encrypted GATT access on every health characteristic.
- Complete Bluetooth SIG qualification early; don’t let it become a launch blocker.
The difference between a BLE medical device that barely works and one that works brilliantly is almost entirely in how you configure the connection. Tune it deliberately, and both your patients and your battery budget benefit.
Hubble Network extends BLE connectivity from bedside to anywhere — enabling medical devices to transmit patient data over satellite without Wi-Fi, cellular, or additional radios. See how it works →