El Hospital Vall d'Hebron es el mayor de Cataluña. Recoge pacientes de su área directa, pero también muchos pacientes de alta complejidad que se derivan a él desde otras áreas.

Al terminar el tratamiento intensivo, muchos de estos pacientes no están en condiciones de volver a sus casas porque necesitan periodos de estabilización, rehabilitación, observación... Estos pacientes tienen que ser derivados a hospitales llamados "sociosanitarios" o "de atención intermedia" en Cataluña, donde hacen estancias mucho más largas que las de Vall d'Hebron, de semanas a meses. Lo mismo ocurre con pacientes al final de sus vidas, que necesitan estar ingresados durante periodos largos.

Vall d'Hebron trabaja típicamente con 11 de estos sociosanitarios en el área metropolitana de Barcelona. Dado que un día/cama en Vall d'Hebron es muchísimo más caro que un día/cama en un sociosanitario, al sistema le interesa que las derivaciones sean rápidas y frecuentes.

Encontrar una cama en sociosanitario (o "socio") para un paciente a quien el facultativo del hospital da de alta (o fija una fecha próxima para su alta), pero prescribe ingreso en socio.

Este ingreso viene con requisitos, por ejemplo:

- en habitaciones dobles, no puedes poner dos personas de sexos distintos

- el paciente está muy agitado o infeccioso, por lo que necesita habitación con aislamiento y/o un solo ocupante

- no es lo mismo que necesite rehabilitación que observación que cuidados paliativos

- no es lo mismo si se prevé estancia de 4 días que de 1 mes

- ....

Tradicionalmente, el hospital ponía hasta a 3 personas a hacer continuamente llamadas a los socios de la corona: "oye, tendrías cama para un señor que necesita rehabilitación durante 2 semanas, te lo envío mañana por la mañana" "espera que lo miro y te digo algo en 2 horas" "oye, tendrías cama para una señora de paliativos que tiene que salir ya" "uy, déjame ver si puedo reorganizar".

Un sistema ineficiente, lento, y propenso a errores.

El Departamento les propuso utilizar... un grupo de whatsapp! Cada socio publicaba por la mañana las camas que tenía, y el hospital hacía scroll buscando una cama adecuada... que podía todavía existir... o no. Además de los problemas obvios de legalidad y privacidad, la gestión aún era muy ineficiente.

Había otro problema además: la decisión se tenía que tomar lejos del paciente y sus familias, que podían tener preferencias por algunos centros sobre otros, por ejemplo por proximidad.

En un mundo ideal, una aplicación de gestión de derivaciones se integraría con las aplicaciones de gestión de camas de los socios y sabría automáticamente las camas disponibles. También podría saber el estado de los pacientes  del hospital y las previsiones de alta e intentar hacer un match casi sin intervención humana.

Esto sería hoy día terreno abonado para los agentes IA, pero cuando se nos planteó el proyecto en 2019 esto habría sido ciencia ficción.

Por desgracia

- los sistemas de información del hospital eran demasiado cerrados y no permitían a aplicaciones de terceros acceder a estado de camas y pacientes.

- los socios tenían sistemas más precarios aún. Más triste, al no ser públicos puros sino concertados, se resistían a revelar abiertamente las camas que tienen disponibles en todo momento. Esto les permitía "jugar al poker" con las cartas pegadas al pecho para maximizar su rendimiento: hay pacientes que dan mucho trabajo y otros que menos. Los convenios con distintos hospitales no pagan lo mismo....

Por todo esto se optó a la fuerza por una solución sin integración, con entrada manual de datos. Esta fue la propuesta que Amalfi hizo al hospital, y que fue aceptada.

Un marketplace. Como la aplicación "Booking" de hoteles, pero para camas:

- los sociosanitarios publicarían ofertas de camas que tienen disponibles (a mano)

- el hospital podría filtrar ofertas por sus características para buscar una que se ajuste a las necesidades  de un paciente

- el hospital también puede publicar una petición con sus características si no encuentra cama adecuada.

La aplicación permite entonces a ambos lados cuadrar una oferta con una demanda, y compartir información básica del paciente o "chatear" sobre un caso. El hospital cierra por su lado cuando envía el paciente en ambulancia,

y el socio cierra por su lado cuando lo recibe.

Esta aplicación tiene la ventaja de que pasa a registrar datos concretos de un proceso que hasta entonces quedaba totalmente al margen de los sistemas de información: quien ofreció qué cuando, quien pidió qué cuando, qué socios

responden mejor y peor, qué tiempos hay entre petición, aceptación y envío efectivo del paciente... lo que abre las puertas a infinitas mejoras de procesos y de análisis (con consecuencias incluso de finaciación).

Para ello se desarrollaron unos dashboards muy básicos para el hospital y una manera básica (vía ftp) de que pudiera descargarse los datos desde la aplicación. Tras un tiempo el hospital pudo integrar esta información en sus propios dashboards y pasar a analizar efectivamente este "área gris" de su actividad.

Esta aplicación, llamada MINT, ha funcionado en el hospital sin interrupción desde el inicio del COVID (marzo 2020) hasta marzo de 2026.

El impacto que se nos ha reportado ha sido:

- reducción del tiempo dedicado a gestión de derivaciones en más de un 80%

- el mismo facultativo que da o prevé el alta puede encontrar cama...

- ... y además hacerlo junto a la cama del paciente y su familia

- los errores se redujeron a casi cero (había casos como enviar a un paciente  a un socio... para descubrir que la cama prometida ya no estaba)

- reducción de hasta un 50% en el tiempo entre inicio de petición de cama y salida del paciente

- como consecuencia de esto, agilización en los _ingresos_: muchos ingresos  se demoraban por falta de cama disponible. Si envías los pacientes antes, otros pueden entrar antes (no tenemos una cifra).

El marketplace se convirtió en una herramienta insustituible para el hospital, de las de "¡no sabemos como antes podíamos trabajar sin ella!". Darla de baja ha sido uno de los puntos más dolorosos en el fin de la actividad de Amalfi.

El concepto de MINT abría aplicaciones muy distintas a la básica 

a nivel sistémico (que, por resistencias diversas, no se ha llevado a cabo):

- extensión a toda la red de hospitales de Cataluña

- extensión a otros recursos además de cama en socio: UCIs, diálisis, imagen, quimioterapia, boxes...

- creación de una capa de Machine Learning que, en base al histórico, predijera  tanto la necesidad como la disponibilidad de camas en socios, y los desajustes en cada hospital y a nivel de territorio. Habría sido un desarrollo muy fácil con toda la tecnología de Amalfi.

Esto último podría tener una derivada interesante para el SAMUR si en lugar de 

camas de socios hablamos de ocupación de urgencias o camas para ingresos.