--- title: "El modelo de sepsis de Epic no detectó a 1.709 de 2.552 pacientes en Michigan Medicine" description: "Validación externa en Michigan Medicine: el Epic Sepsis Model no detectó a 1.709 de 2.552 pacientes con sepsis y alertó sobre el 18% de los hospitalizados." slug: "salud-epic-systems-epic-sepsis-model" url: "https://catalizadora.ai/blog/salud-epic-systems-epic-sepsis-model" cluster: "casos-ia" author: "Pablo Estrada" published_at: "2026-08-26T22:39:41.978+00:00" updated_at: "2026-08-26T22:39:42.235894+00:00" read_minutes: "7" lang: "es" --- # El modelo de sepsis de Epic no detectó a 1.709 de 2.552 pacientes en Michigan Medicine > Validación externa en Michigan Medicine: el Epic Sepsis Model no detectó a 1.709 de 2.552 pacientes con sepsis y alertó sobre el 18% de los hospitalizados. ## Qué pasó La sepsis es una emergencia en la que cada hora cuenta: detectarla temprano cambia el desenlace. Por eso un modelo predictivo que avise antes que el ojo humano es, en teoría, una de las mejores ideas que la inteligencia artificial puede aportar a un hospital. Epic Systems, la compañía del expediente clínico electrónico que usan miles de centros, incorporó uno: el Epic Sepsis Model. Investigadores lo validaron con datos propios en Michigan Medicine. El resultado, [publicado en la literatura médica revisada por pares](https://pmc.ncbi.nlm.nih.gov/articles/PMC8218233/), fue este: el modelo no detectó a 1.709 de 2.552 pacientes con sepsis, es decir, el 67%. Al mismo tiempo, generó alertas sobre el 18% de todos los pacientes hospitalizados. Las dos cifras juntas describen el problema completo. El sistema dejaba pasar a dos de cada tres pacientes que sí tenían la condición y, a la vez, señalaba a casi uno de cada cinco ingresados. Fallaba en las dos direcciones a la vez. ## Por qué pasó Un modelo predictivo aprende de una población: sus pacientes, sus criterios de registro, sus prácticas de documentación, sus tiempos. Ese aprendizaje es lo que lo hace útil, y también lo que lo ata al lugar donde se entrenó. Trasladarlo a otro hospital no es instalar un programa: es aplicar a una población distinta un patrón aprendido en otra. El desempeño que reporta un proveedor es una medición legítima en su contexto. No es una promesa transferible. El fallo de proceso está en tratarlo como si lo fuera: activar el modelo en un centro nuevo sin repetir la medición con datos locales, porque la cifra "ya está validada". La segunda parte es la carga de alertas. Un aviso sobre el 18% de los hospitalizados no funciona como una señal, funciona como ruido de fondo. El personal aprende, con toda razón, a descontarlo. Cuando eso ocurre, el modelo puede seguir marcando correctamente algunos casos y ya no cambiar ninguna decisión: la alerta perdió su capacidad de interrumpir a alguien. Ese umbral —cuántas alertas por día tolera un equipo antes de dejar de mirarlas— casi nunca se define antes de encender el sistema. La tercera es la ausencia de un mecanismo de vigilancia continua. Sin una medición periódica de cuántos casos reales se detectaron y cuántos avisos fueron falsos, la única señal disponible es la impresión del equipo. Y la impresión llega tarde. ## Dónde te puede pasar a ti Ninguna de estas dinámicas es exclusiva de un hospital. Se repiten en cualquier organización que enciende un modelo comprado: - Un puntaje de riesgo crediticio entrenado con clientes de otro país aplicado a tu cartera. - Un detector de fraude que marca tantas transacciones legítimas que el equipo lo empieza a ignorar. - Un clasificador de leads que ordena tus prospectos según el comportamiento de los prospectos de otra empresa. - Un modelo de rotación de personal validado en una industria distinta a la tuya. La pregunta que ordena todo es una: ¿alguien midió este sistema con tus datos, tu población y tu operación, antes de dejar que influya en una decisión? ## Cómo se evita 1. **Validación local obligatoria antes de encender.** Se corre el modelo en silencio sobre casos históricos propios y se compara su salida contra lo que efectivamente ocurrió. Si no se puede hacer esa comparación, no se enciende. 2. **Presupuesto de alertas definido de antemano.** Antes de activar el sistema se acuerda cuántos avisos por día es capaz de atender el equipo. El umbral del modelo se ajusta a ese número, no al revés. 3. **Las dos caras del error, siempre juntas.** Ningún reporte muestra solo aciertos: se publican en el mismo tablero los casos que el modelo dejó pasar y los avisos que resultaron falsos. 4. **Revisión periódica con fecha.** El desempeño se vuelve a medir en un calendario fijo, porque la población cambia aunque el modelo no. Un buen modelo mal validado localmente produce el mismo daño que un mal modelo. La diferencia no está en el algoritmo: está en si alguien lo probó donde se iba a usar. ## Cómo lo hacemos en Catalizadora Todo modelo que entra a un sistema que construimos corre primero en modo silencioso contra datos históricos del cliente, y su salida se compara con el resultado real antes de que llegue a un usuario. Fijamos con el cliente cuántas alertas diarias tolera su operación y calibramos el umbral a esa capacidad. Los tableros muestran siempre las dos caras: lo que el sistema marcó y lo que se le pasó. Un modelo que no se puede medir con datos del cliente no se activa. ## Preguntas frecuentes ### ¿Qué mostró la validación externa del Epic Sepsis Model? Que el modelo no detectó a 1.709 de 2.552 pacientes con sepsis, el 67%, y que al mismo tiempo generó alertas sobre el 18% de todos los pacientes hospitalizados. Fallaba en las dos direcciones: dejaba pasar casos reales y señalaba a demasiada gente. ### ¿Por qué un modelo predictivo funciona en un hospital y no en otro? Porque aprende de una población concreta: sus pacientes, sus criterios de registro, sus prácticas de documentación y sus tiempos. Ese aprendizaje lo hace útil donde se entrenó y lo ata a ese contexto. El desempeño que reporta un proveedor es una medición legítima, no una promesa transferible. ### ¿Qué es la fatiga de alertas y por qué importa aquí? Un aviso sobre el 18% de los hospitalizados deja de funcionar como señal y pasa a ser ruido de fondo. El personal aprende a descontarlo, y desde ese momento el modelo puede seguir marcando casos correctos sin cambiar ninguna decisión. El número de alertas tolerable se define antes de encender el sistema, no después. ### ¿Qué hay que hacer antes de activar un modelo predictivo comprado? Correrlo en silencio sobre casos históricos propios y comparar su salida con lo que efectivamente ocurrió; acordar cuántas alertas diarias puede atender el equipo y calibrar el umbral a esa capacidad; publicar en el mismo tablero los casos que dejó pasar y los avisos falsos; y fijar en calendario la próxima medición. --- Source: https://catalizadora.ai/blog/salud-epic-systems-epic-sepsis-model Author: Pablo Estrada — AI Catalysts, LLC (catalizadora.ai)