Del wearable al EMR: el viaje de una lectura

Una lectura en un dispositivo portátil es inútil hasta que llega al expediente que el clínico realmente está viendo. La distancia entre "el sensor midió algo" y "está en Epic, en el paciente correcto, disparando la alerta correcta" es donde vive la mayoría del software de dispositivos médicos — y donde más se rompe. Aquí está el viaje que toma una sola lectura, a partir de la plataforma que construimos detrás de un monitor hemodinámico portátil.

Las cuatro capas que cruza una lectura

Llevar un valor de la piel al expediente significa cruzar cuatro capas distintas, cada una con sus propios modos de falla:

1. Dispositivo y Bluetooth — el sensor mide y transmite.
2. Gateway / edge — algo cercano lo recibe y lo lleva a la nube.
3. Middleware — un almacén canónico, orquestación y traducción.
4. EMR — el valor aterriza en el registro que usa el equipo de atención.

Omite o subestima cualquiera de estas y los datos se pierden en silencio.

Saliendo del dispositivo: Bluetooth que sobrevive al mundo real

Nuestro wearable mide parámetros hemodinámicos y anuncia lecturas por BLE 5.0 cada pocos minutos. Un pequeño gateway (escribimos el nuestro en Python) busca el dispositivo, se suscribe a su característica, parsea el payload y lo reenvía.

La parte difícil no es el camino feliz — es la realidad junto a la cama. El Bluetooth se cae. El Wi-Fi parpadea. Por eso el gateway reenvía sobre HTTPS con autenticación por llave y reintentos con backoff exponencial, y trata las desconexiones como normales: simplemente vuelve a descubrir el dispositivo en el siguiente escaneo. La regla rectora para la ingesta de dispositivos es que una conexión perdida nunca debe significar una lectura perdida.

Un almacén canónico, luego traducir hacia afuera

Cada lectura se escribe primero en un almacén canónico FHIR R4 (usamos HAPI FHIR) como un Observation — incluyendo un sistema de códigos a medida para los biomarcadores propietarios del dispositivo, ya que aún no todos tienen un código LOINC estándar. Este enfoque canónico-primero es la decisión de arquitectura más importante de todo el pipeline: al guardar una vez como FHIR y traducir hacia afuera, podemos agregar un nuevo EMR destino más adelante sin tocar el código del dispositivo ni del gateway.

Desde ahí, una Suscripción FHIR dispara un webhook en cada lectura nueva. Una capa de orquestación (n8n) la toma, y Mirth Connect traduce el recurso FHIR a un mensaje de resultado HL7v2 ORU^R01 — el formato que esperan los motores de interfaces hospitalarios.

Aterrizando en el EMR — de tres maneras a la vez

Distintos EMRs quieren cosas distintas, así que la plataforma le habla a cada uno en sus propios términos:

• Epic — una escritura directa en FHIR R4 (vía SMART on FHIR / OAuth 2.0) actualiza filas de flowsheet, dispara Best Practice Alerts al InBasket del equipo y soporta facturación de monitoreo remoto (CPT 99453–99458).
• Oracle Health (Cerner) — HL7v2 mediante Bridges y CareAware.
• Todo lo demás — el camino universal HL7v2 ORU^R01 cubre los EMRs que solo hablan v2, que siguen siendo la mayoría.

Una lectura, escrita una vez, puede llegar a las tres.

Las lecciones que de verdad importan

• Mapea la terminología antes de escribir código. Una lectura en la fila de flowsheet equivocada es peor que ninguna lectura. Define tus códigos LOINC/SNOMED/a medida y dónde aterriza cada uno en cada EMR desde el inicio.
• Haz la ingesta idempotente y observable. Los reintentos reenviarán; el sistema no debe crear observaciones duplicadas, y debes poder ver en qué punto del pipeline está una lectura en cualquier momento.
• Separa "medido" de "entregado". Un almacén canónico desacopla el dispositivo del EMR. Es la diferencia entre agregar un nuevo hospital en días o reconstruir la integración.
• Planea el camino de la alerta, no solo el de los datos. El valor clínico es la alerta que llega a la persona correcta — flowsheets, BPAs y notificaciones son funciones de primera clase, no ocurrencias tardías.

Esta es la forma de Vysio: del dispositivo al gateway, a FHIR, a HL7v2, a Epic, Cerner y más. El sensor es la parte fácil. La ingeniería es todo lo que pasa después de que la lectura existe — y eso determina si alguna vez ayuda a un paciente.

¿Construyes un dispositivo conectado o un producto de RPM? Cuéntanos.