El error en la facturación del hospital que nadie detectó durante tres semanas

Introducción

El pasado primavera, un sistema hospitalario regional del Medio Oeste aplicó un parche de programación siguiendo su proceso habitual de cambios. Nada del otro mundo: una actualización rutinaria de la sincronización de las horas de alta con el módulo de facturación. Tres semanas más tarde, alguien del departamento de cuentas por cobrar se percató de que se estaba produciendo una acumulación de reclamaciones rechazadas por discrepancias en las marcas de tiempo. Para cuando el departamento de TI localizó el problema, la corrección ya había afectado a las solicitudes de reembolso de más de cuatrocientos pacientes. En realidad, nadie había hecho nada mal. La actualización superó todas las pruebas de la lista de comprobación. Simplemente no era la lista de comprobación adecuada.

Esa historia se me quedó grabada porque, en realidad, no trata sobre los hospitales. Trata de lo que ocurre cuando los sistemas que funcionan silenciosamente en segundo plano en una organización se tratan como productos acabados en lugar de como una infraestructura viva que necesita un escrutinio regular.

La automatización que configuraste hace dos años no es la que crees que es

La mayoría de las empresas crean sus primeras automatizaciones de flujos de trabajo para resolver un problema específico y evidente. Un equipo de RR. HH. se cansa de tramitar manualmente las solicitudes de vacaciones. Un responsable de operaciones de ventas automatiza la asignación de clientes potenciales para que los comerciales dejen de «escoger lo mejor». Estas automatizaciones se crean con herramientas similares a Power Automate: rápidas de configurar, fáciles de traspasar a quien esté dispuesto a hacerse cargo de ellas y, en gran medida, invisibles una vez que funcionan.

El problema es que «una vez que funcionan» se convierten en algo permanente. Nadie programa una revisión. La persona que lo creó cambia de equipo o se marcha. Mientras tanto, el negocio cambia a su alrededor: nuevos campos en el CRM, una jerarquía de aprobación diferente, una fusión que duplica el volumen que fluye a través de un sistema diseñado para la mitad de la carga. La automatización sigue funcionando exactamente como se diseñó, y ese es precisamente el problema. Se diseñó para una empresa que ya no existe tal y como era entonces.

He visto cómo una empresa de logística descubría que un flujo automatizado de enrutamiento de excepciones llevaba once meses fallando silenciosamente porque un proveedor había cambiado el nombre de un campo de la API. ¿La solución provisional? Alguien había estado volviendo a introducir manualmente los casos fallidos sin decírselo a nadie, dando por hecho que se trataba de un caso aislado. Eso no es un fallo de las herramientas. Es un fallo organizativo por no revisar algo que todo el mundo daba por estable.

Los hospitales corren el mismo riesgo, pero con mucho más en juego

Si tomamos ese mismo patrón y lo trasladamos al entorno clínico y administrativo de un hospital, el margen de error se reduce drásticamente. El desarrollo de software hospitalario suele haber priorizado el cumplimiento normativo y el tiempo de actividad frente a la adaptabilidad —algo comprensible, dado que una implementación fallida puede significar que una enfermera no pueda consultar el historial de medicación a las 2 de la madrugada—. Pero esa misma cautela implica que los sistemas heredados suelen permanecer en producción mucho más tiempo del que deberían, parcheados en lugar de reconstruidos, porque nadie quiere ser quien rompa algo que soporta una carga importante.

El resultado es una arquitectura que acumula decisiones que nadie recuerda haber tomado. Un módulo de programación se comunica con el de facturación a través de una integración creada en 2016 para un proveedor que el hospital dejó de utilizar en 2019. Sigue funcionando, más o menos. «Más o menos» no es una expresión que se quiera tener cerca de los datos de los pacientes.

Lo que está cambiando, poco a poco, es el reconocimiento de que la resiliencia en las tecnologías de la información sanitarias no consiste en evitar el cambio, sino en crear sistemas lo suficientemente flexibles como para absorberlo sin necesidad de un pequeño milagro cada vez que cambia una normativa o se añade un nuevo módulo al historial clínico electrónico.

Por qué «si no está roto» es un criterio erróneo

Lo que ocurre con ambos escenarios es lo siguiente: los sistemas no estaban estropeados. Funcionaban exactamente tal y como estaban configurados. Y precisamente por eso nadie les prestó atención.

Los sistemas que fallan llaman la atención por definición: alguien se queja, algo se detiene, se abre un ticket. Los sistemas peligrosos son aquellos que, en apariencia, funcionan bien, pero que, silenciosamente, se van desincronizando de lo que la organización realmente necesita. Una automatización de flujos de trabajo que sigue ejecutándose, pero que deriva la información al departamento equivocado. Una interfaz hospitalaria que sigue transmitiendo datos, pero que omite un campo del que ahora depende un sistema posterior.

La auditoría no es glamurosa, pero tampoco lo es la alternativa

La solución no es complicada en teoría, aunque resulte tediosa en la práctica: programar revisiones periódicas de todo lo que funcione de forma autónoma, independientemente de lo bien que haya funcionado históricamente. Preguntar quién es el responsable actual. Preguntar qué ha cambiado en las fases anteriores y posteriores desde que se creó. Preguntar si alguien se daría cuenta si mañana dejara de funcionar sin que nadie se diera cuenta.

La mayoría de las organizaciones se saltan este paso porque lo ven como mantenimiento en lugar de como progreso, y el mantenimiento rara vez recibe presupuesto ni aplausos. Pero el coste de omitirlo no desaparece: simplemente espera, en silencio, hasta el momento en que alguien del departamento de cuentas por cobrar se dé cuenta de que las cifras no cuadran.