El Valor del Dato, una Infraestructura Crítica en Salud

El VALOR DEL DATO como INFRAESTRUCTURA CRÍTICA en SALUD.

Six4Health

Durante años hemos tratado el dato sanitario como un subproducto: algo que “queda” después de pasar consulta, facturar o presentar un indicador. Pero los sistemas que evolucionan no consideran el dato como residuo, sino como infraestructura. Igual que nadie discute la necesidad de quirófanos o redes eléctricas, un sistema de salud moderno necesita tuberías, estándares y reglas que hagan que la información circule, sea fiable y útil para tomar decisiones. Sin eso, la innovación es marketing.

El valor del dato no está en acumularlo, sino en cambiar decisiones: detectar antes, asignar mejor, aprender más rápido. Por eso, antes de hablar de lagos, nubes o IA, conviene formular la pregunta correcta: ¿qué decisión concreta vamos a mejorar mañana si el dato estuviera bien? Cuando la respuesta es nítida, la arquitectura aparece.

Infraestructura significa cuatro cosas a la vez. Primero, gobernanza: quién define las reglas, qué derechos y deberes tienen clínicos, gestores, pacientes y proveedores; qué se puede usar y para qué, con trazabilidad y seguridad por diseño. Segundo, semántica: hablar el mismo idioma (SNOMED CT, LOINC, ATC, ICD), con catálogos y diccionarios vivos, para que “glucosa” sea glucosa aquí y en cualquier hospital. Tercero, interoperabilidad real (FHIR, APIs abiertas, data contracts) que reduzca el “copiar/pegar” y evite islas tecnológicas. Cuarto, calidad y observabilidad: saber qué falta, qué es incoherente, cuánto tarda en llegar, y poder auditar el linaje desde el origen hasta el panel del gerente o el algoritmo del clínico.

El resto son consecuencias. Cuando esas cuatro capas existen, aparecen ciclos de mejora que se sostienen solos: sentir–decidir–actuar–aprender. Un servicio de Urgencias que mide bien su flujo no “ve” más dashboards; reduce tiempos de triaje porque puede anticipar picos, equilibrar turnos y derivar con criterio. Un servicio de Oncología no “tiene más datos”; evita toxicidades porque identifica perfiles de riesgo y activa seguimiento proactivo. Un hospital no “usa IA”;

disminuye reingresos porque integra modelos en el punto de atención, con alertas que alguien se comprometió a atender.

Para que ocurra, hace falta pasar del proyecto al producto de datos. Un producto de datos es un activo mantenible, con propietario, SLA, descripción semántica y APIs de consumo, orientado a un uso clínico/gestor concreto. Ejemplos: Riesgo de sepsis en hospitalización, Lista de espera quirúrgica priorizada por severidad y tiempo máximo, Panel de adherencia terapéutica en crónicos, Registro de eventos adversos interoperable. Cada producto tiene “clientes” (quién lo usa), decisiones objetivo (qué cambia), métricas de éxito (qué mejora y cuánto) y éxito operacional (latencia, cobertura, calidad).

Para no diluirse, ayuda un modelo de madurez muy simple. Nivel 0: datos dispersos en PDF/Excel. Nivel 1: extracción puntual para informes. Nivel 2: diccionarios comunes y flujos repetibles. Nivel 3: productos de datos con APIs estables y gobierno activo. Nivel 4: decisiones automatizadas o asistidas con evaluación continua de impacto. La trampa está en creer que comprar una plataforma sube de nivel. No: se sube cuando el porcentaje de decisiones que usan esos productos aumenta mes a mes.

Un matiz clave: infraestructura también es ética aplicada. Privacidad diferencial, seudonimización, control de consentimientos, evaluación de sesgos, auditoría de modelos y explicabilidad proporcional al riesgo. La confianza no se pide, se diseña. Y se comunica.

¿Cómo se traduce todo esto en hoja de ruta? Propongo un enfoque de 90 días que evita el “todo o nada”:

• Semana 1–2. Decisiones: tres decisiones prioritarias (una clínica, una operativa, una de salud poblacional. Ej.: “Activar precozmente protocolo de sepsis”, “Reducir cancelaciones quirúrgicas”, “Identificar EPOC no diagnosticada en Atención Primaria”. Definir qué es “mejor” en cada caso (métrica de resultado, proceso y tiempo).

• Semana 3–4. Mapa mínimo de datos: qué tablas, códigos, eventos y tiempos hacen falta; qué parte existe, qué falta estandarizar; acuerdos semánticos rápidos (80/20).

• Semana 5–8. Construcción del MVP del producto de datos con FHIR/APIs, validación de calidad (completitud, consistencia, puntualidad) y panel/alerta en el punto de uso (no otro dashboard en intranet).

• Semana 9–10. Piloto operativo: una unidad, un turno, un servicio. Observabilidad y feedback de usuarios.

• Semana 11–12. Evaluación: ¿qué decisión cambió?, ¿cuánto impactó?, ¿qué fricción?, ¿qué automatizamos?, ¿qué escalamos o descartamos?.

Algunas métricas que importan (y casi nunca medimos): time-to-decision (tiempo desde el evento hasta la señal útil), adopción (porcentaje de decisiones que usaron el producto), calidad observable (missingness, duplicados, coherencia), alineación semántica (porcentaje de campos codificados en estándares), valor clínico (NNT/NNH de la intervención habilitada por los datos), valor operativo (horas administrativas ahorradas). Si no medimos esto, solo medimos actividad.

“Un dato vale lo que vale la decisión que es capaz de cambiar.”

También conviene aceptar que no todo debe centralizarse. En organizaciones complejas funciona mejor un data mesh con equipos clínico-tecnológicos propietarios de cada producto, coordinados por gobierno común. El CDO marca políticas, pero el PO clínico y el data steward están pegados a quirófano, planta o centro de salud. La proximidad a la decisión hace que el dato deje de ser un “proyecto IT” y se convierta en herramienta de trabajo.

¿Y fuera del hospital? Si de verdad creemos en ecosistemas, el dato es el tejido conectivo. Hubs, startups y administración pueden colaborar en data collaboratives con reglas claras: casos de uso acotados, datasets sintéticos cuando proceda, auditoría externa y retorno tangible para quien comparte. Del ego al eco también en datos: abrir cuando suma, proteger cuando toca, siempre con propósito.

Tres ideas para llevarse hoy Primera: “Más datos” no es la respuesta; mejores preguntas sí. Segunda: la IA no arregla un dato roto; arreglar el dato potencia (y hace seguro) cualquier modelo. Tercera: el valor no está en el informe, sino en el cambio de comportamiento que ese informe provoca.

Si mañana tuvieras que elegir un solo frente, elige una decisión crítica y construye el primer producto de datos alrededor de ella. En doce semanas sabrás si la infraestructura está sosteniendo la clínica, y no al revés. A partir de ahí, escala con disciplina. TransFormar la teoría en práctica y los datos en decisiones no es un eslogan: es una forma de trabajar.