La respuesta corta

Conectar una app a un dispositivo médico por Bluetooth de baja energía es sencillo en la demo y difícil en producción, y el motivo casi nunca es el protocolo: es la fiabilidad de la conexión, los permisos y una advertencia de seguridad que mucha gente no ha leído.

La advertencia, que está en la documentación de Android y que en un producto sanitario lo cambia todo: cuando el usuario empareja su teléfono con otro dispositivo por BLE, los datos que se comunican entre ambos son accesibles para todas las apps del teléfono. Si tu app captura datos sensibles, la seguridad la tienes que poner tú en la capa de aplicación.

Es decir: el emparejamiento no es tu control de acceso. Si la lectura del glucómetro viaja en claro sobre GATT, cualquier otra app instalada puede leerla.

El modelo: dos parejas de roles que se confunden

Hay dos divisiones de roles y no son la misma:

NivelRolesQué hace cada uno
ConexiónCentral / PeriféricoEl central escanea anuncios; el periférico se anuncia y espera conexiones
DatosCliente GATT / Servidor GATTEl cliente pide datos; el servidor los sirve

El caso típico: el teléfono es central y cliente GATT, y el dispositivo médico es periférico y servidor GATT.

Y una limitación que decide arquitecturas: dos dispositivos que solo soportan el rol de periférico no pueden hablar entre sí, y dos que solo soportan central, tampoco. Si el diseño esperaba que dos aparatos se entendieran directamente, hay que comprobar qué rol soporta cada uno antes de prometerlo.

Servicios, características y descriptores

La jerarquía de datos es corta y conviene tenerla clara al leer la especificación de un fabricante:

  • Servicio: un conjunto de características para una función concreta —por ejemplo, un monitor de frecuencia cardíaca.
  • Característica: un valor único, con cero o más descriptores.
  • Descriptor: atributos que describen la característica —descripción legible, rango aceptable, unidad de medida.

Todo esto viaja sobre el protocolo de atributos (ATT), optimizado para BLE y con un uso mínimo de bytes; cada atributo tiene un UUID de 128 bits.

Y un atajo que ahorra semanas: muchos dispositivos usan perfiles GATT ya adoptados por el Bluetooth SIG en lugar de inventarse los suyos. Antes de escribir un analizador propio, hay que comprobar si el aparato implementa uno estándar.

Notificaciones o indicaciones

Para recibir cambios del dispositivo sin ir preguntando hay dos mecanismos y la diferencia importa en un contexto clínico:

  • Notificaciones: el servidor envía el dato y no espera confirmación. Menos sobrecarga.
  • Indicaciones: el servidor envía y espera confirmación del cliente. Más fiable.

Para una lectura que no puede perderse —una alarma, una medición que se registra en la historia clínica— la elección tiende a indicaciones, con la penalización de rendimiento que conlleva. Es una decisión de producto disfrazada de detalle de protocolo.

Permisos en Android 12 y superior

Desde Android 12 (API 31) hay permisos específicos que se piden en tiempo de ejecución:

<uses-permission android:name="android.permission.BLUETOOTH_SCAN" />
<uses-permission android:name="android.permission.BLUETOOTH_CONNECT" />
  • BLUETOOTH_SCAN para buscar dispositivos. Lleva el atributo neverForLocation, que declara que el escaneo no se usa para deducir la ubicación del usuario — y evita tener que pedir permiso de ubicación, que era la fricción histórica de este flujo.
  • BLUETOOTH_CONNECT para conectarse a dispositivos ya descubiertos.

Ese neverForLocation es de las mejoras que más ayudan en producto: pedir ubicación para «conectar con tu tensiómetro» era una conversación imposible con el usuario.

Lo que rompe en producción

  • El emparejamiento no es seguridad. Ver arriba. Cifrado en la capa de aplicación si el dato es sensible.
  • Reconexión. El dispositivo se aleja, se apaga, cambia de pila. La app tiene que reconectar sola, con reintentos escalonados, sin dejar al usuario mirando una pantalla parada.
  • Segundo plano. Se puede comunicar en segundo plano, pero con las restricciones de cada sistema operativo. Si el producto asume lectura continua mientras el usuario hace otra cosa, hay que validarlo en dispositivos reales, no en el emulador.
  • Fragmentación de fabricantes. El comportamiento de la pila Bluetooth varía entre modelos y capas de fabricante. Sin un banco de pruebas con dispositivos reales de gama media, los fallos aparecen en campo.
  • Batería y pilas. Del teléfono y del aparato. Un producto que agota la pila del dispositivo médico en una semana tiene un problema de negocio.

Lo que hay que pedir al fabricante del dispositivo

Antes de estimar nada, esta lista al proveedor del hardware:

  1. Especificación GATT completa: servicios, características, descriptores y UUIDs.
  2. ¿Usa perfiles adoptados o propietarios?
  3. ¿Notificaciones o indicaciones, y en qué características?
  4. ¿Cómo es el emparejamiento y qué nivel de seguridad implementa el aparato?
  5. ¿Qué pasa con los datos cuando no hay app conectada? ¿Los guarda y los vuelca después, o se pierden?
  6. Dos o tres unidades de prueba, desde el primer día.

La quinta es la que más cambia el producto: si el aparato almacena, hay que diseñar sincronización e histórico; si no, la app tiene que estar conectada en el momento de medir, y eso es otra experiencia completamente distinta.

Y una advertencia de alcance

Si la app interpreta lo que mide el dispositivo en vez de solo mostrarlo, es muy probable que entres en el régimen de producto sanitario. Dónde está exactamente la línea, con la tabla oficial de clasificación, está en cuándo tu app es producto sanitario.

Y si los datos tienen que acabar en la historia clínica del hospital, la integración es otra conversación: la tratamos en HL7 FHIR en una app móvil.

Es el tipo de proyecto que hacemos cuando el software y el hardware van juntos, en apps para el sector salud y en integración con hardware.

Fuente primaria, consultada el 14 de agosto de 2026: Bluetooth Low Energy overview en la documentación de Android.