Sistema de llamado de enfermeras

El problema

Varios servicios de la red hospitalaria llevaban años pidiendo timbres sin que llegaran. Sin timbre, el paciente llama en voz alta o espera a que pase alguien. Y cuando existe un timbre convencional, nadie sabe cuánto se tardó en atenderlo.

La decisión que define el sistema

Un pulsador de emergencia que depende del WiFi del hospital no es un pulsador de emergencia. Por eso el enlace entre el botón y el ESP32 de la habitación no usa WiFi ni router: usa ESP-NOW, el protocolo de radio directo de Espressif. La llamada llega aunque la red esté caída.

El WiFi aparece después, en el salto del ESP32 al servidor por MQTT. Ese tramo ya no es la llamada crítica. Si falla, la luz del pasillo se encendió igual.

Mi rol

Diseñé el sistema completo: electrónica y PCB, firmware, backend, base de datos, panel e integración con el sistema hospitalario. También hice el despliegue en sitio y la capacitación al personal de enfermería.

Stack

Dispositivo	ESP32 · C++ / Arduino · ESP-NOW · MQTT · LittleFS · PCB propia
Servidor	Node.js · Express · MQTT · cron
Datos	PostgreSQL, con la lógica de negocio en funciones almacenadas
Panel	Angular 17 · Material
Despliegue	Docker Compose · firmware actualizado por OTA

Decisiones de diseño

• La lógica vive en PostgreSQL. El hospital ya tiene DBAs y la lógica queda junto a los datos. Es discutible, y conviene saberlo antes de buscar las reglas en el JavaScript.
• Los dispositivos reportan su estado solos. Cada ESP32 manda un heartbeat con número de serie, MAC, IP, estado del relay y señal. El panel detecta un equipo caído sin esperar a que alguien avise.
• El sistema no es dueño de los datos del paciente. Los lee del sistema hospitalario cada 30 minutos. Si esa API no responde, sigue avisando con la última foto conocida de cada cama.
• Actualización por aire. Con dispositivos repartidos por varias habitaciones, ir cama por cama con un cable no es opción.

Lo que enseñaron los datos

El 40 % de los llamados salió del baño (102 de 256). Es el dato que más cambia una decisión: el baño es donde ocurren las caídas y es justo donde el timbre de cabecera no llega.

De día se responde entre 20 y 40 veces más rápido que de noche. Nadie pidió esa función. Es información de gestión que aparece sola cuando cada llamada queda registrada.

Una salvedad: la cifra global está influida por febrero y marzo, los meses de instalación y acompañamiento. El mes más representativo de operación normal es abril, con 47 llamados, mediana de 22.7 s y 64 % atendidos en menos de un minuto. Esa es la cifra que defiendo.

Coste y escala

Materiales por unos S/ 163 por habitación. Se instalaron 32 ESP32 y se gestionaron 67 reemplazos desde el propio sistema.

Limitaciones conocidas

• El panel consulta por intervalos, no recibe notificaciones push. Migrar a WebSocket o SSE es la mejora pendiente más clara.
• La sincronización de pacientes cada 30 minutos es real: un ingreso de hace diez minutos todavía no aparece con su nombre.
• El promedio que muestra el panel no sirve: incluye alertas que nadie canceló. La mediana es la métrica correcta.
• La respuesta se degradó al retirarse el acompañamiento (mediana de 7.4 s en la instalación, 60 s en operación). La causa no está confirmada.

El repositorio público no contiene datos de pacientes. Las fotos se revisaron una a una y se descartaron las que mostraban nombres, documentos o personal identificable.