Bluetooth Low Energy & GATT

In one line

BLE is the short-range, low-power radio in nearly every consumer health device; GATT (Generic Attribute Profile) is the data model that says what the device exposes and how to read it.

Two layers: radio and data model

It helps to separate the two things "Bluetooth" means here:

• BLE (the radio) — a short-range, low-energy link designed so a coin-cell device can run for months. Different from Classic Bluetooth (audio); BLE is built for small, bursty data.
• GATT (the data model) — once connected, GATT defines how the data is organised so any client knows where to look.

The GATT hierarchy

GATT structures a device's data as a small tree:

• Services — a feature group, identified by a UUID (e.g. Heart Rate service 0x180D).
• Characteristics — the actual data points inside a service (Heart Rate Measurement 0x2A37), each with a value and properties.
• Descriptors — metadata about a characteristic (units, the notify-enable switch).

A client can read, write, or — most usefully for monitoring — subscribe via notifications, so each new reading is pushed rather than polled.

Standard health profiles

The Bluetooth SIG standardises health profiles — heart rate, blood pressure, glucose, pulse oximeter, weight scale — so a standards-following device works with any compliant app. This is what makes a generic phone app able to read a cuff it's never seen.

The integration path

In digital health the chain is: GATT characteristic → your data model → FHIR Observation, with proper UCUM units and device identity. The semantics often come from IEEE 11073: BLE carries the bytes, 11073 gives them meaning, FHIR carries them into the record.

Where it shows up in digital health

Almost every RPM kit's first hop is BLE: cuff → phone/gateway app → cloud. Wearables, glucometers, pulse oximeters, and weight scales all rely on it.

Common pitfalls

• Proprietary GATT — vendors that ignore the standard profiles and use custom services are the recurring integration pain; budget for per-device reverse-engineering.
• Dropping units/identity — a number without UCUM units and a device reference isn't a safe Observation.
• Notification vs read — polling a characteristic wastes power; subscribe to notifications.

Key takeaways

• BLE = the low-power radio; GATT = the data model (services → characteristics → descriptors).
• Read, write, or subscribe (notify) — notifications are the efficient path for monitoring.
• Standard SIG health profiles enable cross-vendor interoperability; proprietary GATT breaks it.
• Map GATT → UCUM-coded FHIR Observations, with 11073 supplying the semantics.