Predecir camas hospitalarias con criterio clínico-operativo
Un modelo que no optimiza una métrica de consultoría, sino que reduce la varianza con la que urgencias, planta y dirección toman decisiones cada mañana sobre la capacidad del hospital.
El problema real no está en los datos
En un hospital español medio, la planificación de camas es un ejercicio reactivo. Urgencias decide a quién ingresar sin saber cuántas camas libres quedarán en planta en las próximas seis horas. Planta gestiona las altas sin visibilidad real de la presión que viene desde urgencias. Y la dirección, a primera hora de la mañana, pide una previsión diaria que nadie puede dar con confianza.
He trabajado seis años y medio en hospital. En un turno normal en Méderi, Colombia, llegué a pasar más de cuarenta pacientes. La pregunta operativa no era clínica —los pacientes casi siempre estaban bien estratificados—; la pregunta era logística: ¿dónde ingresamos a este paciente?,¿cuántas camas libera cirugía mañana?, ¿estamos en riesgo de bloquear urgencias por saturación aguas abajo? Ninguna de esas preguntas tiene una respuesta cuantitativa en la mayoría de centros.
La conversación pública sobre sanidad habla mucho de interoperabilidad, historia clínica electrónica y cuadros de mando. Pero entre la capa de datos y la capa de decisión hay un vacío que ningún HIS cubre bien: traducir datos operativos históricos en una previsión útil, a tiempo, y con granularidad por especialidad o por unidad.
El problema no es falta de datos. Es falta de traducción entre datos operativos y decisión clínica en tiempo real.
Por qué los modelos ingenuos fallan
La previsión por defecto que se usa en muchos hospitales es esencialmente un baseline naive: promedio móvil de la ocupación de los últimos días, corregido manualmente por estacionalidad obvia (fines de semana, festivos, invierno). Es un modelo que funciona razonablemente bien en régimen estacionario, y que se rompe precisamente cuando es más necesario.
Falla en tres sentidos concretos. Primero, no captura shocks: una ola gripal en diciembre, un brote en una residencia, una alerta epidemiológica autonómica, un pico de urgencias por un evento meteorológico. Todos ellos son perfectamente visibles en los datos con dos o tres días de antelación, pero un promedio histórico los ignora por construcción. Segundo, asume estacionariedad que no existe: la estancia media por servicio cambia con el casemix, el envejecimiento poblacional mueve la base, los protocolos internos se actualizan cada trimestre. Tercero, e importa más, ignora variables estrictamente clínicas que sí están disponibles en el HIS: distribución por especialidad, gravedad al ingreso, índice de urgencias, porcentaje de ingresos quirúrgicos programados frente a urgentes.
En un hospital de 500 camas con 80% de ocupación media, reducir la varianza de la previsión en un 30% no es un tecnicismo estadístico. Se traduce, en términos operativos, en entre 8 y 15 camas al día de margen de maniobra sin abrir planta nueva, sin derivar, sin cancelar programación. Eso es dinero real y, más importante, es capacidad asistencial real.
La decisión de diseño de este proyecto fue, por tanto, no competir con modelos que optimicen exactitud puntual (RMSE sobre ocupación absoluta), sino competir con el baseline naive en la métrica que de verdad importa: dispersión sobre la planificación operativa.
Variables clínicas más operativas
El modelo se construye sobre dos familias de features. Las variables operativas son las evidentes: ingresos diarios por unidad, altas diarias, estancia media desagregada por servicio, índice de urgencias (ratio de ingresos vía urgencias sobre el total), ocupación histórica con ventanas móviles de 7, 14 y 30 días. Son las variables que cualquier analista de gestión hospitalaria sabe extraer del HIS.
Las variables clínicas son las que, por criterio profesional, sé que marcan la diferencia: especialidad del paciente, gravedad al ingreso (cuando existe triaje estructurado tipo Manchester o ESI), casemix de la planta receptora, porcentaje de ingresos quirúrgicos programados frente a urgentes. Modelamos cada una no como un dato descriptivo más, sino como una señal causal: una planta de medicina interna con casemix envejecido tiene una estancia media estructuralmente distinta a una planta quirúrgica corta-estancia, y la previsión debe saberlo.
Esa combinación —operativa + clínica— es donde se gana frente a los modelos puramente logísticos que venden algunos proveedores de BI sanitario. Un modelo que solo mira ingresos y altas capta la superficie del problema; un modelo que incorpora el contexto clínico captura la física subyacente del flujo asistencial.
En producción, la arquitectura prevista consume estos datos vía HL7 FHIR R4. Los recursos relevantes son Encounter (episodio asistencial con origen, fecha de ingreso y alta, servicio), Patient (demografía y, si está autorizado, comorbilidades agregadas), Location (unidad y cama) y Observation para señales clínicas agregadas. Trabajar desde FHIR no es una preferencia técnica: es una decisión estratégica. Los pliegos de licitación pública en España ya exigen interoperabilidad FHIR en los HIS nuevos, y un modelo que se alimenta de estándar es un modelo portable entre hospitales.
La decisión de diseño más importante fue conceptual: no optimizar una métrica de precisión pura, sino reducir la varianza decisional. Una cama que el modelo predice que llegará y no llega tiene un coste operativo bajo (personal avisado que no se usa). Una cama que no predijo y sí llega tiene un coste alto (paciente en pasillo, derivación a otro centro, cancelación de programación). El modelo está calibrado asimétricamente a favor del segundo tipo de error.
Lo que el modelo entrega
Reducción estimada de varianza en planificación de recursos frente a baseline naive, medida sobre ventana temporal de validación retrospectiva.
En lenguaje de dirección: en un hospital mediano de 500 camas con ocupación media del 80%, esa reducción de varianza equivale a entre 8 y 15 camas al día de margen operativo recuperado sin inversión en infraestructura adicional. Son camas que ya existen y que dejan de perderse por errores de planificación.
Importa ser honesto sobre el alcance. La evaluación se realizó sobre un dataset sintético construido para replicar la dinámica real de un hospital terciario español. No existen datos reales de hospital público español en abierto por restricciones de RGPD, y ese es un límite estructural, no una excusa. La arquitectura del modelo está lista para alimentarse del HIS del hospital receptor vía FHIR, pero los números reales solo se validan en un piloto con datos del centro.
Lo que sí se puede afirmar hoy, con los datos disponibles, es que el criterio de diseño —priorizar la reducción de varianza sobre la métrica puntual— es replicable y auditable, y que la arquitectura cumple desde el primer día con RGPD y con la clasificación Limited Risk del EU AI Act al tratarse de un sistema de apoyo a la decisión operativa y no de diagnóstico clínico.
Qué cambia en un hospital que lo adopta
El impacto más inmediato se ve en la dirección de enfermería. Una previsión fiable de demanda a 24 y 72 horas cambia radicalmente la planificación de turnos, la apertura contingente de plantas y la política de altas tempranas. Hoy esa planificación se hace con criterio humano experto y planillas de Excel; con el modelo, el criterio humano sigue siendo el decisor, pero tiene un soporte cuantitativo auditable.
El segundo efecto es en la coordinación urgencias-planta, históricamente el talón de Aquiles de los hospitales españoles. Cuando urgencias tiene visibilidad sobre la capacidad prevista en las siguientes horas, las decisiones de derivación, observación prolongada e ingreso cambian. Es la misma información que hoy se comunica verbalmente entre supervisores de turno, convertida en dato estructurado y consultable.
El tercer efecto va más allá del hospital. En la compra pública sanitaria, los pliegos de licitación para HIS y módulos de gestión ya están empezando a exigir APIs FHIR abiertas. Un modelo predictivo como este encaja de forma natural como requisito funcional en un pliego de transformación digital: el hospital compra un HIS que expone los datos vía FHIR, y la capa predictiva se despliega encima sin reescribir la pila. Esto es lo que debería exigirse en los proyectos financiados con fondos Next Generation y con recursos del PERTE de salud digital.
Y hay una lectura europea. El Espacio Europeo de Datos Sanitarios (EHDS) establece que no solo los datos clínicos individuales viajan entre estados: también los datos operativos agregados, con fines de investigación y mejora del sistema. Un modelo entrenado sobre datos operativos de un hospital en España es directamente transferible a un hospital portugués o francés, siempre que la arquitectura se diseñe desde el estándar. Esto es relevante para cualquier consultora que esté diseñando hoy ofertas transfronterizas de transformación digital sanitaria.
Stack y marco regulatorio
| Lenguaje | Python 3.11 |
| ML | Scikit-learn, ingeniería de features de series temporales |
| Interoperabilidad | HL7 FHIR R4 · Recursos Encounter, Patient, Location, Observation |
| Despliegue previsto | Contenedor Docker + API FastAPI detrás del HIS del hospital |
| Regulación | RGPD (datos agregados, no identificativos) · EU AI Act, clasificación Limited Risk al tratarse de apoyo a decisión operativa y no de diagnóstico clínico |
Cómo se despliega en un hospital
Revisión de fuentes del HIS
Mapear los recursos FHIR disponibles, validar granularidad temporal y completitud de campos clínicos críticos (servicio, gravedad, origen del ingreso). Entre 2 y 4 semanas.
Extracción retrospectiva de 12-24 meses
Pipeline de anonimización y agregación. Los datos nunca salen del perímetro del centro; el entrenamiento puede realizarse on-premise o en nube soberana europea.
Entrenamiento con validación temporal
Splits respetando causalidad: entrenar en 2024, validar en 2025. Informe de métricas por servicio con intervalos de confianza, no promedios agregados opacos.
Integración en dashboard de dirección
La previsión se publica en el cuadro de mando existente, no en otra herramienta más. La interfaz es para supervisores de turno y dirección, no para científicos de datos.
Evaluación mensual con indicadores mixtos
Reunión mensual con dirección. Se contrasta la previsión con la realidad usando indicadores clínicos (tasa de derivación, tiempo en urgencias) y operativos (ocupación, varianza).
¿Lideras un centro sanitario o una consultora que vende transformación digital?
Hablemos. El modelo, la arquitectura FHIR y el marco regulatorio están listos para sentarse en una mesa de piloto. Lo que falta es el dato real de un hospital dispuesto a validarlo.