El caso Vanderbilt: La tecnología cediendo bajo estrés

Cuando la presión asistencial desborda los salvaguardas de seguridad

La premisa es cruda: los sistemas de salud no fallan en el vacío. Fallan bajo la "presión de producción" del día a día clínico. En condiciones ideales, la tecnología es una promesa; pero bajo estrés, sus deficiencias dictan sentencia. A continuación analizamos cómo la presión asistencial expone fallos tecnológicos, desde errores de medicación por interfaces mal diseñadas hasta la sobreconfianza en sistemas informáticos, y cómo algunos entornos resilientes logran resistir mejor dichas tensiones.

El colapso del "Filtro Humano": El caso Vanderbilt (2017)

Un ejemplo trágico de la tecnología cediendo bajo estrés es el caso de RaDonda Vaught en el Hospital Vanderbilt (2017). Una enfermera, trabajando bajo presión en un entorno inusual (una sala de radiología), buscó un sedante (Versed) en un gabinete automático de medicamentos (ADC). Debido a fricciones técnicas, tuvo que usar la función de override (anulación) del dispensador – una práctica cotidiana en muchos hospitales. Al escribir solo las letras "VE" en la búsqueda, la interfaz del ADC mostró Vecuronio, un bloqueador neuromuscular letal, en lugar de Versed (Midazolam). La enfermera seleccionó el primer resultado creyendo que era el sedante, preparó y administró el fármaco equivocado al paciente, quien dejó de respirar y posteriormente falleció. Investigaciones posteriores revelaron múltiples fallos de diseño y procesos: el sistema permitía búsquedas por nombre comercial (Versed) a pesar de que ese nombre ya no era estándar, aceptaba solo dos letras para autocompletar, y la ausencia de escáner de código de barras en radiología impidió detectar el error antes de la administración.

¿Error humano o fallo del sistema? El Institute for Safe Medication Practices (ISMP) señaló que este evento no fue simplemente culpa de una persona "distraída", sino el resultado de vulnerabilidades sistémicas. La combinación de una interfaz mal diseñada y la urgencia situacional indujo un peligroso sesgo de confirmación: la profesional vio "VEcuronium" en la pantalla y, bajo prisa, su cerebro lo tomó por "VErsed", confirmando falsamente que era el fármaco correcto. En otras palabras, el sistema tecnológico no filtró el error humano, sino que lo potenció. Según análisis de ISMP, la misma configuración defectuosa (búsqueda por dos letras y fácil anulación de alertas) podría existir en muchos hospitales, preparando el terreno para errores similares. El caso Vanderbilt ejemplifica cómo, bajo estrés real, el "filtro humano" puede colapsar si el soporte tecnológico ofrece opciones peligrosas sin salvaguardas robustas.

La trampa de la "Obediencia Tecnológica"

Bajo la presión asistencial, el cerebro humano busca atajos cognitivos (heurísticos) para aligerar la carga. Uno de estos atajos es confiar ciegamente en la tecnología: si el sistema dice "OK", el clínico tiende a saltarse verificaciones críticas. Esta obediencia tecnológica o sesgo de automatización se ha vuelto un riesgo sutil en la era digital.

Un estudio seminal de Classen et al. publicado en JAMA Network Open (2020) expuso los límites de esa confianza: durante 10 años evaluaron los principales sistemas de prescripción asistida por computadora (CPOE) en hospitales de EE. UU., encontrando que, a pesar de la madurez y amplia adopción de estos sistemas, no detectaron errores de medicación potencialmente mortales en el 33% de los casos de prueba. En otras palabras, un tercio de los errores graves "sembrados" intencionalmente en pacientes ficticios pasaron sin generar alertas, a pesar de que los profesionales seguían las indicaciones del software. Esto sugiere que confiar en que "si no saltó una alerta, todo está bien" es una falsa seguridad. De hecho, se ha documentado una falsa sensación de seguridad tanto en profesionales como en pacientes cuando se implementan historias clínicas y prescripción electrónicas: existe un exceso de confianza en que el sistema informático lo controla todo y siempre alertará de cualquier problema.

La lección es clara: el software de salud no es un guardián infalible; muchas veces se convierte en generador de una peligrosa confianza excesiva. Cuando los clínicos depositan toda su fe en el sistema, pueden omitir su propio juicio crítico. La tecnología, diseñada para prevenir errores, puede paradójicamente adormecer la alerta humana si sus limitaciones no son reconocidas. El resultado es que errores graves pasan desapercibidos hasta que es demasiado tarde. En suma, la tecnología médica debe complementar, no reemplazar, la atención y el criterio del profesional. Si la vigilancia activa del clínico se rinde ante la obediencia ciega al algoritmo, el sistema entero queda expuesto a fallos catastróficos.

Resiliencia: Por qué Utah e Intermountain son distintos

Aunque muchos sistemas ceden bajo estrés, existen organizaciones sanitarias que resisten mejor la prueba de fuego gracias a un enfoque de resiliencia. En la ciencia de la seguridad se habla de dos paradigmas: Safety-I y Safety-II (Erik Hollnagel, 2013). Safety-I se enfoca en prevenir que algo salga mal (evitar errores y accidentes), mientras que Safety-II busca asegurar que todo salga bien incluso ante variabilidad y condiciones adversas. En palabras de Hollnagel, "la seguridad es la presencia de capacidades, no la ausencia de errores" – es decir, tener sistemas robustos y flexibles que puedan adaptarse y seguir funcionando correctamente bajo presiones inesperadas.

Centros como Intermountain Healthcare (Utah) y algunos sistemas escandinavos han adoptado prácticas alineadas con Safety-II. No se conforman con instalar software y suponer que resolverá los problemas; rediseñan proactivamente el flujo de trabajo clínico para adaptarlo a la realidad del terreno. Utilizan enfoques de "Etnografía Clínica": observan cómo trabajan realmente los médicos y enfermeras en entornos reales, en vez de basarse únicamente en cómo deberían trabajar según manuales o diseñadores de software. Por ejemplo, antes de implementar una nueva alerta o protocolo, analizan la carga de trabajo real, las interrupciones habituales, y cómo los profesionales compensan variaciones día a día. Estos Clinical Development Programs (CDPs) integran tecnología con procesos humanos de forma iterativa, ajustando las herramientas a la forma en que el trabajo se realiza de verdad.

En la práctica, Intermountain y similares han logrado que sus sistemas clínicos sean más robustos y tolerantes al error humano. Se enfocan en potenciar capacidades: entrenan al personal para detectar y corregir desvíos, fomentan culturas de reporte abierto de eventos (en lugar de castigo), y continuamente afinan el software tras recoger feedback de la "trinchera" clínica. Un sistema resiliente asume que la variabilidad es la norma (picos de demanda, distracciones, pacientes complejos) y se diseña para absorberla. Por eso, en lugares así, cuando ocurren situaciones de estrés o casos atípicos, la tecnología se adapta (o los humanos tienen margen para adaptarla) en vez de romperse. La seguridad, visto desde Safety-II, es un proceso activo: no se trata de vigilar para que nada falle, sino de asegurar que todo funcione bien mediante adaptabilidad y aprendizaje continuo.

Cabe destacar una cita clave de la ingeniería de resiliencia: "La seguridad es la presencia de capacidades, no la ausencia de errores." En estos sistemas, el énfasis está en desarrollar capacidades adaptativas – por ejemplo, protocolos flexibles, doble verificación colegiada, comunicación eficaz – de modo que incluso si algo se desvía (y siempre algo se desviará), existan barreras y respuestas rápidas para evitar el daño. Utah e Intermountain demuestran que invertir en resiliencia paga: sus resultados en calidad y seguridad destacan porque han aprendido a trabajar con la tecnología, las personas y los procesos como un todo, preparándose para lo inesperado en lugar de solo reaccionar a lo malo después que ocurre.

El fenómeno de la "Fatiga de Alertas"

En un entorno clínico informatizado típico, un profesional puede enfrentarse a cientos de alertas y notificaciones por turno: interacciones medicamentosas, recordatorios, alarmas de monitores, avisos del sistema, etc. La intención de cada alerta es buena, pero en conjunto crean un "ruido" abrumador. Bajo estrés, ese ruido se vuelve contraproducente: ante la sobrecarga, el cerebro comienza a ignorar los avisos repetitivos o percibidos como irrelevantes. Es el fenómeno conocido como fatiga de alertas (alert fatigue).

Estudios en hospitales académicos de EE. UU. han mostrado que los clínicos ignoran o descartan entre el 70% y el 90% de las alertas de interacción farmacológica que reciben. En particular, los avisos de interacción fármaco-fármaco son tan frecuentes (muchas veces por combinaciones de riesgo teórico mínimo) que los médicos habitualmente los override (anulan) casi sistemáticamente. Un análisis reveló que en sistemas CPOE comerciales, más del 90% de las alertas de interacción mayores son obviadas por los prescriptores. Esto significa que potencialmente se pasan por alto alertas verdaderamente importantes mezcladas entre decenas de falsas alarmas. La fatiga de alertas no solo implica que "se cierren" ventanas emergentes; puede llevar a desactivar notificaciones sonoras, desarrollar hábito de pulsar "Aceptar" sin leer, e incluso una actitud de cinismo hacia cualquier recomendación del sistema.

¿Cómo combaten este problema los sistemas más resilientes? La clave está en la inteligencia contextual y la jerarquización de alertas. En lugar de lanzar alertas intrusivas por cada interacción teórica o desviación menor, se configuran alertas diferenciadas por nivel de criticidad. Por ejemplo, un enfoque implementado en algunos hospitales (como los de la Universidad de Utah) es el tiering de alertas: las interacciones o errores de alto riesgo generan alertas de alta prioridad (a menudo con interrupción obligatoria hasta que el clínico las atienda), mientras que las de riesgo bajo o dudoso se presentan de forma pasiva o no intrusiva. Estudios han demostrado que tierizar las alertas por severidad aumenta la adherencia de los profesionales a las recomendaciones importantes, a la vez que reduce el override masivo de alertas en general. En un hospital donde se implementó este sistema escalonado, el cumplimiento de las alertas críticas llegó al 100%, comparado con solo ~34% en hospitales donde todas las alertas "gritan" por igual. En resumen, al reducir el ruido de fondo, los clínicos confían más en las alarmas que realmente aparecen, pues saben que si el sistema interrumpe es por algo verdaderamente crucial.

Otra estrategia relacionada es hacer las alertas más contextuales. Esto implica tener en cuenta, por ejemplo, si ya se tomó alguna acción mitigadora, si el paciente ya tiene una determinada condición controlada, o si la combinación de fármacos está intencionada y documentada, para no alertar innecesariamente. Asimismo, se pueden usar distintos canales (visuales, sonoros) según urgencia, o incluso escalar alertas: primero un aviso sutil, y solo si no se corrige, un aviso mayor. En cualquier caso, la meta es evitar la saturación del profesional con advertencias triviales. Los sistemas resilientes reservan la interrupción del flujo de trabajo solo para riesgos críticos y accionables, aquellos donde la intervención humana inmediata marca la diferencia. Al restaurar la señal en medio de tanto ruido, se protege tanto al paciente (porque las alertas importantes sí reciben atención) como al profesional (que puede concentrarse en la tarea clínica sin tanta distracción).

Conclusión

La clínica no perdona abstracciones ni idealizaciones tecnológicas, porque el cuerpo humano no tiene un botón de "deshacer". Cada vez que un sistema informático entra en la dinámica asistencial, es puesto a prueba por la realidad: pacientes complejos, tiempos limitados, interrupciones constantes, estrés y fatiga humana. Hemos visto cómo lo que funciona en papel puede fallar estrepitosamente en la práctica bajo presión. Por eso, un sistema de salud resiliente no es el que presume tener el mejor algoritmo o la interfaz más avanzada, sino aquel que protege el espacio para la duda y el juicio clínico incluso cuando el reloj corre en contra. Es el sistema que anticipa errores humanos y los contiene antes de que hieran al paciente; el que apoya al profesional en lugar de sobrecargarlo; el que se adapta y aprende de cada evento adverso para salir fortalecido.

En última instancia, la tecnología debe ser un copiloto, nunca el piloto automático, especialmente cuando entramos en zona de turbulencia. Los profesionales de la salud –médicos, enfermeras, farmacéuticos– necesitan ese copiloto tecnológico para volar más alto y seguro, pero manteniendo siempre las manos en los controles. Bajo estrés, la tentación es delegar en la máquina; el deber es usarla como apoyo sin abdicar la responsabilidad. La seguridad del paciente florece cuando la suma de capacidades humanas y técnicas es mayor que sus partes, cuando la alerta electrónica va de la mano con la vigilancia consciente. En la "prueba de estrés" diaria de la clínica real, ganan aquellos sistemas que entienden que la última línea de defensa es, y seguirá siendo, el juicio humano respaldado por una tecnología bien diseñada. La tecnología sanitaria, por sofisticada que sea, debe recordarnos siempre que su rol es asistir la toma de decisiones y nunca reemplazar la prudencia clínica, porque en medicina no existen atajos seguros frente a la incertidumbre ni errores sin consecuencias. Por ello, invertir en resiliencia –en personas, procesos y herramientas que sepan absorber el estrés– no es opcional, es imperativo. La verdadera innovación tecnológica se medirá no solo por lo que hace en condiciones ideales, sino por cómo previene tragedias y salva vidas cuando todo lo demás empieza a fallar.