El valor del dato como infraestructura crítica en salud

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. 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.

Cuatro capas de infraestructura

• 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.
• 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.
• Interoperabilidad real (FHIR, APIs abiertas, data contracts) que reduzca el 'copiar/pegar' y evite islas tecnológicas.
• 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.

De ciclos de mejora a productos de datos

Cuando esas cuatro capas existen, aparecen ciclos 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 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 o de gestión 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'.

Un modelo de madurez sencillo

• 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.

Ética aplicada

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.

Hoja de ruta de 90 días

• Semana 1–2. Decisiones: tres decisiones prioritarias (una clínica, una operativa, una de salud poblacional). Definir qué es 'mejor' en cada caso.
• Semana 3–4. Mapa mínimo de datos: qué tablas, códigos, eventos y tiempos hacen falta; qué 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.
• 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?

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.

Data mesh y proximidad a la decisión

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.

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

Tres ideas para llevarse hoy

• 'Más datos' no es la respuesta; mejores preguntas sí.
• La IA no arregla un dato roto; arreglar el dato potencia (y hace seguro) cualquier modelo.
• 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.