Race+: cómo digitalizamos el protocolo de código ictus en urgencias hospitalarias
La realidad brutal de un protocolo sensible al tiempo
Cada minuto que transcurre desde el inicio de un ictus isquémico sin tratamiento destruye aproximadamente 1,9 millones de neuronas. No es una metáfora ni una estimación cómoda: es biología medida. Treinta minutos de retraso en administrar el fibrinolítico pueden marcar la diferencia entre un paciente que sale del hospital caminando y un paciente que pasa el resto de su vida con hemiparesia, afasia o dependencia funcional severa. La ventana terapéutica es estrechísima —cuatro horas y media para trombólisis intravenosa en la mayoría de los protocolos— y dentro de esa ventana cada bloque de quince minutos penaliza el desenlace neurológico de forma medible.
El indicador que condensa toda esa urgencia es el tiempo puerta-aguja: los minutos que pasan desde que el paciente cruza la puerta de urgencias hasta que recibe el tratamiento. Las guías internacionales lo colocan por debajo de 60 minutos, las mejores unidades del mundo lo empujan por debajo de 30. Cuando empezamos a trabajar con equipos de neurología y urgencias en España, la media en muchos centros estaba por encima de los 50 minutos, con una varianza enorme entre turnos.
Esa varianza era la pista. Un hospital no tiene un tiempo puerta-aguja: tiene una distribución. Y en la cola de esa distribución, en los peores casos del turno de noche o del fin de semana con equipos incompletos, estaba la mayor parte del daño evitable.
Qué había antes de Race+
Antes de construir nada, pasamos semanas observando cómo funcionaba el protocolo existente. Lo que vimos era predecible, pero no por eso menos frustrante. Cuando un paciente con sospecha de ictus llegaba a urgencias, el médico responsable iniciaba una cascada de llamadas telefónicas: primero a neurología de guardia, después a radiología para reservar TAC, después a UCI si se anticipaba necesidad de cama crítica, y finalmente a farmacia para preparar el fibrinolítico. Cada llamada tenía su propio ciclo: marcar, esperar tono, identificarse, explicar el caso, confirmar disponibilidad.
A la par, alguien tenía que ir rellenando un checklist en papel con los tiempos relevantes. Ese papel se quedaba en la sala de triaje y se transcribía al sistema de historia clínica horas después, a veces con los tiempos reconstruidos de memoria.
El sistema funcionaba gracias a la experiencia individual de los profesionales, no gracias al proceso en sí. En un turno con un adjunto veterano que conocía a toda la guardia, el protocolo fluía. En un turno con un residente de primer año enfrentándose por primera vez a un código ictus, la cadena se rompía en algún eslabón: el número del neurólogo de guardia no estaba actualizado, nadie sabía si radiología estaba disponible, el farmacéutico tardaba en responder.
Los cambios de turno eran especialmente vulnerables. La información sobre qué pacientes estaban en curso, qué pruebas se habían pedido y qué decisiones quedaban pendientes se transmitía verbalmente, y cualquier pérdida en esa transmisión se pagaba en minutos.
Las decisiones de producto que más importaron
La primera decisión, y la más contraintuitiva para parte del equipo clínico, fue que Race+ tenía que ser móvil primero. El instinto inicial de varios jefes de servicio era pedir una aplicación de escritorio integrada en el PC del box de urgencias. Pero ese PC no siempre está disponible, los clínicos se mueven entre boxes, y el teléfono móvil es el único dispositivo que siempre está con el profesional. Cualquier fricción de acceso —tener que volver al puesto, tener que autenticarse de nuevo— era tiempo perdido.
La segunda decisión crítica fue la activación con un único gesto. Race+ tiene una pantalla de inicio sencilla: un botón de activación de código ictus que ocupa el 60% de la interfaz. Un toque, y el sistema notifica simultáneamente a neurología, radiología, UCI y farmacia basándose en la planificación actualizada del hospital para ese turno. No hay formularios previos, no hay selección de destinatarios, no hay cadena de llamadas. La información clínica detallada se introduce después, mientras el equipo ya está movilizándose.
El diseño del resto del flujo siguió el mismo principio. Cada profesional recibe una notificación con un contexto mínimo y acciona una única confirmación para señalar que está en camino. Los tiempos relevantes —llegada, activación, TAC, decisión terapéutica, administración del fibrinolítico— se capturan automáticamente como consecuencia de las acciones que el equipo ya realiza dentro de la aplicación. No hay que rellenar un registro adicional: los datos clínicos auditables se generan como subproducto del trabajo.
Los problemas técnicos que nadie menciona en las demos
Construir una aplicación de salud para urgencias hospitalarias plantea exigencias técnicas que no aparecen en ninguna presentación comercial. Tres se llevaron la mayor parte del esfuerzo de ingeniería.
La primera fue la fiabilidad en redes hospitalarias. Las WiFi en entornos hospitalarios son, en muchos centros, fragmentadas, con zonas de cobertura irregular y congestionadas especialmente en urgencias. Diseñamos Race+ para funcionar en modo degradado cuando la conexión es intermitente: las notificaciones críticas se reintentan automáticamente con backoff, el estado local se persiste en el dispositivo y se sincroniza cuando se recupera la conexión, y el sistema nunca bloquea una acción clínica esperando confirmación de red. La arquitectura offline-first no era un nice-to-have: era la única manera de garantizar que un código se pudiera activar en el box más lejano del hospital, donde la cobertura puede caer a una barra intermitente.
La segunda fue la integración con sistemas legados. Los hospitales públicos en España tienen infraestructura de HIS (Hospital Information System) que en muchos casos lleva décadas en producción. Implementamos integración HL7 v2 para recibir datos de admisión del paciente y escribir los registros de tiempo en el expediente clínico, algo que requirió más tiempo de ingeniería que toda la interfaz de usuario combinada. Los estándares de interoperabilidad en salud están bien definidos en papel; en producción, cada instalación tiene sus propias variaciones de campos, segmentos opcionales que son obligatorios para este hospital, codificaciones de eventos que difieren entre versiones. FHIR es el estándar moderno, pero la realidad de los hospitales españoles sigue siendo mayoritariamente HL7 v2 durante muchos años más.
La tercera fue el requisito de uptime. Una aplicación de urgencias con disponibilidad del 98% no es aceptable: eso significa más de siete días de caída al año, y cualquier caída durante un código ictus puede tener consecuencias reales. Diseñamos la arquitectura con redundancia activa en GCP, health checks agresivos, failover automático entre regiones europeas, y un procedimiento de degradación que notifica al equipo técnico antes de que los clínicos perciban cualquier problema. Cuando el sistema detecta cualquier señal de inestabilidad, un SMS de respaldo se dispara automáticamente al neurólogo de guardia con la información crítica, para que el teléfono siga siendo un fallback viable. El objetivo no era el 99,9% teórico; era el 99,9% demostrable en auditoría, con registros de incidencias y tiempos de recuperación documentados.
Lo que significa 99,9% cuando hay vidas en juego
El 99,9% de uptime suena bien en una slide. En la práctica, significa presupuestar 8 horas y 45 minutos de caída al año como máximo, y diseñar cada deploy, cada migración de base de datos y cada actualización de dependencias para que no consuma ese presupuesto. Significa que una ventana de mantenimiento programada no es "los martes por la noche": es una operación coordinada con los servicios de neurología de todos los hospitales, con procedimientos de contingencia en papel activos durante la ventana.
Significa también que la cultura de ingeniería cambia. No hay deploy los viernes. No hay cambios en producción sin revisión por pares y sin test automatizados que cubran los flujos críticos. Y los postmortems de cualquier incidente —por pequeño que sea— se hacen con rigor, porque lo que hoy es un glitch mañana puede ser una caída en el peor momento.
La parte humana: el cambio de flujo en el equipo médico
Lo más importante que aprendimos construyendo Race+ es que la mejor aplicación del mundo no mejora tiempos si el equipo no la incorpora en su rutina. La adopción en entornos hospitalarios no es un problema de producto: es un problema de cambio organizativo.
Las primeras semanas tras el despliegue en un hospital son siempre las más críticas. Hay un porcentaje del equipo que adopta la herramienta inmediatamente, otro que la tolera, y otro que se resiste por costumbre o por desconfianza. Identificar campeones internos —normalmente adjuntos con credibilidad y residentes con apetito digital— y trabajar con ellos durante el despliegue resultó más efectivo que cualquier mejora de funcionalidad. Sesiones de formación presencial, simulacros de código ictus con Race+ activo, y presencia física de nuestro equipo durante las primeras guardias fueron inversiones que valieron cada hora.
Resultados y lo que viene
Después de desplegar Race+ en más de 20 hospitales, la reducción media en tiempo puerta-aguja ha sido del 30%. Es un número significativo, pero la métrica que nos importa más es la varianza. Con el protocolo en papel, la diferencia entre el caso óptimo y el peor caso dentro de un mismo hospital era enorme. Con Race+, esa varianza se comprime: los turnos de noche y los fines de semana dejan de ser los outliers que arrastraban la media.
Las líneas abiertas ahora son tres: extender la plataforma a otros códigos tiempo-dependientes (código infarto, sepsis, politrauma), profundizar la integración con sistemas de imagen para que el neurólogo pueda ver el TAC desde Race+ sin cambiar de aplicación, y avanzar en componentes predictivos —con la cautela que el dominio exige— que identifiquen pacientes de alto riesgo antes de que el código se active.
Race+ no es un producto terminado. Es infraestructura digital para un protocolo que seguirá evolucionando con los hospitales que lo usan, y esa mentalidad —que el producto no se cierra, se sostiene— es lo que define la diferencia entre software médico y software que se despliega en hospitales.
¿Quieres llevar esto a tu empresa?
Cuéntanos tu proyecto y te ayudamos a encontrar la solución tecnológica adecuada.
Hablar con nuestro equipo