Dos formas de ver la seguridad
Imagine que está diseñando el sistema de la farmacia de un hospital. El enfoque tradicional es enumerar todos los puntos donde algo puede salir mal y levantar una defensa para cada uno:
- Se puede entregar el medicamento equivocado → se añade una verificación por código de barras
- Se puede calcular mal la dosis → se añade una verificación automática
- Se puede confundir al paciente → se añade una verificación de identidad
Esto se llama Safety-I: identificar los modos de fallo y levantar barreras. Funciona; durante décadas ha salvado un sinnúmero de vidas.
Pero tiene un punto ciego: solo estudia el 5% de los casos que salen mal e ignora el 95% que sale bien.
En 2014, el científico de seguridad danés Erik Hollnagel propuso un marco distinto: Safety-II[1]. La pregunta que plantea no es «¿por qué salen mal las cosas?», sino:
Con recursos insuficientes, presión desbordante y procesos interrumpidos, ¿cómo logran las personas completar el trabajo con éxito?
La respuesta casi nunca es «porque siguieron el protocolo (SOP)», sino «porque improvisaron sobre la marcha». La idea central de Safety-II es esta: la seguridad no es el grosor de las barreras, sino la capacidad del sistema para adaptarse al cambio.
En el terreno del desastre, Safety-I no basta
Cuando empezamos a diseñar xGrid, nuestro pensamiento también era puramente Safety-I: añadir confirmaciones, añadir verificaciones, añadir barreras. No nos dimos cuenta del problema hasta que corrimos nuestro primer simulacro de escenario completo.
El escenario: tres estaciones médicas evacúan al mismo tiempo. En el momento de la evacuación:
- Hay un paciente recibiendo una transfusión de sangre, y la cadena de custodia del hemoderivado no puede romperse
- Hay una cirugía en curso, que debe interrumpirse, trasladarse y reanudarse en la nueva estación
- Hay medicamentos en tránsito entre estaciones, que necesitan reasignarse a las estaciones que sobreviven
La lógica de Safety-I es «evitar que ocurra la evacuación» o «asegurarse de que la evacuación no coincida con estos momentos». Pero en un desastre real no se puede controlar cuándo hay que evacuar. La artillería no espera a que termine la cirugía.
Lo que necesitábamos no era un muro más grueso, sino la capacidad de ayudar a las personas a seguir completando su tarea incluso cuando el muro ya ha sido perforado.
Eso es Safety-II.
Los cuatro principios de diseño Safety-II de xGrid
Principio uno: la incertidumbre honesta
La mayoría de los sistemas esconden el «no lo sé». ¿El inventario lleva tres días sin sincronizarse? La pantalla sigue mostrando la última cifra conocida, sin ninguna advertencia. El usuario cree que el dato es en tiempo real y toma decisiones basadas en información caducada.
xGrid no funciona así. Etiquetamos cada dato con metadatos de frescura (freshness metadata). Cuando un dato lleva sin sincronizarse más tiempo del umbral permitido, la pantalla lo marca directamente como stale (caducado). Al ver la palabra «caducado», la enfermera sabe que debe hacer una verificación adicional: ir a contar en el lugar, hacer una llamada para preguntar, o escanear un código QR para sincronizar.
Mostrar «no estoy seguro» es más seguro que mostrar un número que podría estar equivocado.
Este es un diseño típico de Safety-II: no se trata de eliminar la incertidumbre (algo que no se puede hacer), sino de hacer visible la incertidumbre para que la persona pueda juzgar a partir de la información correcta.
Principio dos: degradación elegante, con el umbral de seguridad intacto
Se cae la red. Tres estaciones dejan de responder. Se activa el modo de emergencia.
Muchos sistemas, en modo de emergencia, hacen una de dos cosas: o se paralizan por completo («por favor, contacte al departamento de TI»), o se abren del todo (apagan todas las verificaciones para ganar velocidad). Las dos son peligrosas.
El modo de emergencia de xGrid toma el camino intermedio: simplifica la ruta de la operación, pero conserva los pasos de confirmación críticos.
En concreto:
- Los campos no esenciales se pueden omitir (dirección, número de seguro, detalles de alergias)
- Pero la verificación de identidad del paciente → se conserva
- La confirmación del nombre y la dosis del medicamento → se conserva
- La verificación de compatibilidad cruzada del hemoderivado (cross-match) → se conserva
La lógica es esta: bajo presión, las personas van a querer saltarse pasos de forma natural para ganar velocidad. El trabajo del sistema no es impedir que vayan más rápido, sino asegurarse de que, al acelerar, no se salten el paso que podría costar una vida.
Principio tres: registrar para aprender, no para culpar
xGrid registra cada entrega de turno (ISBAR handoff), cada traslado, cada entrega de medicamento, cada movimiento de inventario. El nivel de detalle del registro es tan fino que se puede reconstruir toda la línea de tiempo del evento.
Pero el propósito de estos registros no es «tener con qué investigar si algo sale mal». Dentro del marco de Safety-II, el propósito del registro es aprender de los éxitos cotidianos.
¿Por qué salió tan bien aquella evacuación? Los registros muestran que la enfermera escaneó los datos del hemoderivado en su teléfono tres minutos antes de la evacuación. Eso no estaba en el protocolo, pero su decisión improvisada ahorró 15 minutos. ¿Deberíamos incorporar esto al SOP la próxima vez?
Safety-I solo revisa los registros después de que algo sale mal. Safety-II también los revisa cuando todo va bien, porque las causas del éxito merecen estudiarse tanto como las causas del fracaso.
Principio cuatro: autorización de emergencia (break-glass)
Flujo normal: para entregar un medicamento se necesita receta médica → verificación del farmacéutico → comprobación de la enfermera → entrega. Tres barreras. Muy Safety-I.
Realidad del desastre: el médico está atendiendo a una avalancha de heridos y no puede emitir la receta electrónica. El farmacéutico está en otra estación. La enfermera tiene delante a un paciente que está perdiendo sangre y necesita el medicamento hemostático ahora mismo.
Si el sistema insiste en que «sin receta no hay entrega», el resultado es que la enfermera se salta el sistema por completo (lo anota en papel, lo grita en voz alta, lo saca directamente del gabinete), y luego no queda ningún registro en el sistema.
xGrid ofrece un modo de anulación de emergencia de 24 horas. La enfermera puede activar la autorización de emergencia, y el sistema:
- Permite que la operación continúe
- Registra que «esta operación usó autorización de emergencia»
- La marca como pendiente de revisión
No se trata de eludir la seguridad, sino de reconocer la realidad. En el terreno del desastre, a veces el procedimiento estándar simplemente no funciona. La postura de Safety-II es esta: en lugar de fingir que todo el mundo va a seguir todas las reglas, es mejor diseñar un mecanismo que permita registrar y rastrear con seguridad el momento en que se rompen las reglas.
Patient I: todo aprobado, cero pérdida de datos
Ya vimos la teoría; veamos los datos.
Nuestra suite de pruebas E2E incluye un escenario llamado Patient I — Consolidation Test, diseñado específicamente para poner a prueba los principios de Safety-II en el peor de los casos:
Configuración: 8 estaciones médicas, 3 obligadas a evacuar. Operaciones en curso durante la evacuación:
- Transfusión de sangre en curso (la cadena de custodia no puede romperse)
- Cirugía en curso (debe interrumpirse, documentarse con entrega ISBAR, trasladarse y reanudarse en la nueva estación)
- Medicamentos en tránsito entre estaciones (necesitan reasignarse)
Resultados de la verificación:
| Elemento verificado | Resultado |
|---|---|
| Identidad del paciente preservada entre estaciones | Aprobado |
| Cadena de custodia del hemoderivado intacta + compatibilidad cruzada en la nueva estación | Aprobado |
| Cirugía reanudada en la nueva estación + registro ISBAR completo | Aprobado |
| Inventario conciliado entre estaciones | Aprobado |
| Total: todos los pasos aprobados, 0 pérdida de datos | Aprobado |
Esto es lo que vale Safety-II en un escenario real (simulado): no se trata de «impedir la evacuación», sino de lograr que la evacuación se complete con éxito.
Safety-II no sustituye a Safety-I
Una última aclaración importante: Safety-II no significa «ya no hacen falta las barreras». La verificación por código de barras, la comprobación de dosis, la validación de identidad: estas barreras de Safety-I siguen siendo importantes, y xGrid las tiene todas.
Safety-II se añade encima de Safety-I, como una capa más: ¿cómo ayuda el sistema a que las personas se adapten cuando las barreras ya no bastan?
Safety-I
- Pregunta central
¿Qué sale mal? - Estrategia de diseño
Eliminar los modos de fallo - Supuesto sobre las personas
Las personas son fuente de riesgo - Modo de aprendizaje
A partir de los incidentes - Postura ante la variación
La variación es una amenaza
Safety-II
- Pregunta central
¿Qué sale bien? - Estrategia de diseño
Reforzar la capacidad de adaptación - Supuesto sobre las personas
Las personas son fuente de resiliencia - Modo de aprendizaje
A partir de los éxitos cotidianos - Postura ante la variación
La variación es una adaptación necesaria
xGrid hace las dos cosas. Pero si solo pudiéramos elegir una, en el terreno del desastre elegiríamos Safety-II.
Porque en ese entorno, el muro siempre acaba siendo perforado. La pregunta no es si va a resistir, sino qué pasa después de que lo perforen.
Para seguir leyendo: La prueba del abandono — Si el equipo de desarrollo desapareciera mañana, ¿seguiría viva su sistema? | Continuidad gobernada por el paciente — El reflejo de Safety-II del lado del paciente
Referencias
- Hollnagel E. Safety-I and Safety-II: The Past and Future of Safety Management. Ashgate Publishing; 2014. DOI