El problema, en tres capas
El papel dificulta la interoperabilidad y la trazabilidad. La información recogida durante la asistencia prehospitalaria debe poder consultarse, compartirse con el hospital y relacionarse con las decisiones tomadas durante el servicio. Los formularios en papel limitan ese recorrido y dificultan la explotación posterior de los datos.
El texto libre no permite aprovechar toda la información clínica. Datos como la forma de aparición de los síntomas, su evolución o los factores desencadenantes suelen registrarse dentro de campos narrativos. Convertirlos en información estructurada facilita la interoperabilidad, el análisis y la creación de alertas de seguridad.
La interfaz no puede asumir un entorno de escritorio. La herramienta se utiliza dentro de una ambulancia, durante una asistencia y bajo condiciones que pueden incluir movimiento, poca conectividad y uso de guantes. Los patrones habituales de una aplicación de escritorio no siempre funcionan en ese contexto.
El reto de diseño consistía en trasladar un proceso clínico complejo a una interfaz que redujera la carga cognitiva, permitiera registrar la información con rapidez y mantuviera la continuidad del dato durante todo el episodio asistencial.
Investigación: auditoría, no entrevistas
En esta fase no realicé entrevistas ni pruebas moderadas con usuarios. La investigación se centró en analizar la documentación clínica, los estándares aplicables y el funcionamiento real del producto.
Auditoría comparada con el estándar documental. Revisé cada sección y cada campo del producto contrastándolos con modelos públicos de documentación asistencial, requisitos de interoperabilidad y marcos clínicos como OPQRST, SOCRATES, AMPLE y SOAP/SBAR.
Auditoría del recorrido completo del servicio. Analicé el flujo desde la recepción del aviso hasta el cierre y la firma, identificando interrupciones, duplicidades, riesgos de atribución y puntos donde la interfaz podía aumentar innecesariamente la carga cognitiva.
Clasificación por impacto y riesgo. Los problemas no se priorizaron únicamente según su capacidad para bloquear una tarea. También se valoró su posible efecto sobre la seguridad del dato clínico, especialmente cuando una información podía quedar asociada al paciente, episodio o profesional equivocados.
La interfaz debía permitir registrar la asistencia sin obligar al profesional a apartar más atención de la necesaria del paciente.
Cómo se construyó
Nexo Clinical se desarrolló mediante un proceso de diseño y construcción asistido por agentes de código. Mi responsabilidad fue definir el problema, modelar el dominio, tomar las decisiones de producto, establecer los criterios de aceptación y validar cada resultado sobre el producto real.
Descubrimiento antes de construcción
Cada encargo comenzaba con una fase de análisis en modo de solo lectura sobre el código existente. Las referencias a archivos, componentes o comportamientos se verificaban contra el estado real del repositorio antes de realizar cualquier cambio.
Premisas sometidas a revisión
Cada tarea debía identificar tanto lo que no se había podido determinar como las premisas que no se sostenían al contrastarlas con el producto. Esto permitió corregir decisiones antes de convertirlas en código.
Un único frente activo
El trabajo se dividió en alcances pequeños y verificables. Cada sesión se concentraba en un único problema de producto, con validaciones funcionales y técnicas antes de avanzar al siguiente.
Trabajar de forma individual también introducía un riesgo: ser al mismo tiempo quien define la solución y quien la valida aumenta el sesgo de confirmación. Por eso incorporé comprobaciones adversariales, criterios de aceptación explícitos y validación directa del comportamiento antes de dar cada cambio por terminado.
Tres decisiones de diseño
La prioridad se mantiene a la izquierda y el estado de actualización del dato se comunica mediante una señal independiente.
Una misma señal visual no puede comunicar dos estados distintos
La sección de anamnesis ya utilizaba un indicador naranja para mostrar su prioridad. Añadir otro punto del mismo color para avisar de que el resumen estaba desactualizado generaba dos señales visualmente iguales con significados diferentes.
La solución fue mantener la prioridad en una posición y utilizar el indicador de completitud existente para comunicar el estado del dato: ausente, actualizado o pendiente de revisión.
El modal proporciona controles táctiles amplios, un acceso directo a la hora actual y una confirmación explícita.
La hora de una medicación se corrige en un modal
El control de hora estaba integrado directamente en la tabla de medicación. Aunque podía funcionar con ratón, el área de interacción era demasiado pequeña para utilizarla de forma fiable en una tablet.
La edición se trasladó a un modal con botones de incremento y reducción, un acceso directo a «Ahora» y una confirmación explícita antes de guardar la corrección.
La interfaz solo cambia definitivamente cuando el episodio queda formalmente cerrado.
El desenlace no equivale al cierre del episodio
El sistema ocultaba varias fases del informe en cuanto se seleccionaba un desenlace. Sin embargo, esa elección podía cambiar durante la asistencia y no debía modificar prematuramente la interfaz.
La visibilidad pasó a depender del cierre formal del episodio. De este modo, el profesional puede modificar el desenlace mientras la asistencia continúa sin perder acceso a información necesaria.
Resultados
El producto todavía no dispone de métricas obtenidas en un entorno asistencial real. Los resultados disponibles proceden de auditorías internas del producto, del análisis de cobertura y del trabajo de consolidación técnica realizado durante su desarrollo.
Madurez global del producto
Auditoría de ocho capas. Núcleo clínico: 84 %; seguridad a nivel de fila: 90 %.
Cobertura del estándar documental
Nodos cubiertos en «Motivo de consulta», con los tres huecos restantes clasificados por su impacto legal, clínico o de interoperabilidad.
Suite de tests automáticos
Junio a agosto de 2026.
Integración continua
Comprobación de tipos, pruebas automatizadas y compilación ejecutadas en cada cambio incorporado al repositorio.
Migración al sistema de radios
Sustituciones realizadas para trasladar la interfaz a una escala visual coherente y reutilizable.
Errores de TypeScript en HEAD
Qué aprendí
Las pruebas automáticas no detectan todos los fallos entre capas
Una suite de pruebas podía completarse correctamente mientras algunos datos se almacenaban en un lugar equivocado. Cada capa cumplía su contrato de forma aislada, pero el problema aparecía en la relación entre ellas. La validación debía comprobar el recorrido completo del dato y no solamente la respuesta visible de la interfaz.
El modelo de datos puede adelantarse a la interfaz
Algunos campos existían en el dominio y eran utilizados por otros procesos, pero ninguna pantalla permitía introducirlos. El sistema no mostraba errores: la información simplemente permanecía vacía. Esto convirtió la auditoría de extremo a extremo en una parte necesaria del proceso de diseño.
Una corrección basada en eventos no repara automáticamente el histórico
Los episodios creados antes de una corrección conservaban una secuencia de eventos generada con el comportamiento anterior. Para validar un cambio era necesario distinguir entre registros históricos afectados y episodios nuevos creados después de la solución.
El sistema de diseño debía haberse definido antes
Migrar posteriormente la interfaz a una escala coherente de radios implicó 1.379 sustituciones en 116 archivos. Definir antes los fundamentos visuales y las validaciones automáticas habría reducido el coste de las modificaciones posteriores.
¿Tienes un sistema donde el error cuesta caro?
Cuéntame en dos líneas y te respondo en 24 h.