El 95% Que Ignoramos
En 2014, Erik Hollnagel publico un libro que cambio silenciosamente la forma en que los cientificos de seguridad piensan[1]. Su argumento era simple e inquietante: el campo de la seguridad habia dedicado decadas a estudiar el pequeno porcentaje de casos donde las cosas salen mal, mientras ignoraba casi por completo la gran mayoria de casos donde las cosas salen bien.
Llamo al enfoque tradicional Safety-I: identificar modos de falla, construir defensas, prevenir resultados adversos. Es la base de cada lista de verificacion, cada mecanismo de seguridad, cada cuadro de dialogo de confirmacion. Y funciona. Excepto cuando no.
La alternativa, Safety-II, parte de una pregunta diferente: en lugar de preguntar por que las cosas ocasionalmente fallan, preguntar por que generalmente tienen exito. La respuesta no es "porque construimos buenas barreras". La respuesta es "porque las personas se adaptan". Las enfermeras improvisan. Los medicos se desvian del protocolo cuando el protocolo no aplica. El personal de logistica encuentra soluciones que nadie planeo.
Safety-I trata esta variacion como un problema. Safety-II la trata como la fuente principal de resiliencia.
El Escenario Que Rompio Nuestro Pensamiento Safety-I
Estabamos construyendo xGrid, una plataforma de logistica medica para desastres que funciona sin conexion en dispositivos Raspberry Pi. Al inicio del desarrollo, nuestro diseno era completamente Safety-I: escaneo de codigos de barras, verificacion de identidad, dialogos de confirmacion de multiples pasos, controles de acceso basados en roles.
Entonces realizamos un ejercicio de simulacion. El escenario:
Tres de ocho estaciones medicas se ven forzadas a evacuar simultaneamente. En el momento de la evacuacion, las siguientes operaciones estan en curso:
- Una transfusion sanguinea con requisitos estrictos de cadena de custodia
- Una cirugia activa que debe interrumpirse y reanudarse en otro lugar
- Medicamentos en transito entre estaciones que necesitan reasignacion
Nuestro sistema Safety-I manejaba bien las verificaciones individuales. Lo que no podia manejar era la situacion completa. El sistema asumia condiciones operativas estables. La realidad proporciono lo contrario.
Necesitabamos algo que no solo previniera errores en condiciones normales, sino que ayudara activamente a las personas a tener exito en condiciones anormales.
Cuatro Principios Aprendidos
1. Hacer Visible la Incertidumbre
El instinto en diseno de software es presentar informacion limpia y confiable. Numeros sin calificadores. Indicadores de estado que son verdes o rojos, nunca amarillos.
En un escenario de desastre, esta confianza es peligrosa. Si los datos de inventario no se han sincronizado en tres dias, mostrar el ultimo conteo conocido como si fuera actual conduce a malas decisiones. Una enfermera podria omitir un conteo fisico porque el sistema dice que hay 12 unidades. Podria haber 4.
xGrid etiqueta cada punto de datos con metadatos de frescura. Cuando la sincronizacion excede un umbral, la interfaz muestra un marcador stale (obsoleto). Esto no es un indicador de error, es una senal de honestidad. Le dice al operador: "Este numero podria estar equivocado. Verifique antes de actuar."
Un sistema que admite incertidumbre es mas confiable que uno que la oculta. Los usuarios aprenden a confiar en el sistema precisamente porque les dice cuando no deben confiar en los datos.
2. Degradar con Gracia, No con Permisividad
Cuando los sistemas entran en modo de emergencia, los disenadores enfrentan un dilema. Bloquear todo y arriesgar la detencion de operaciones criticas, o abrir todo y arriesgar errores.
La mayoria de los sistemas eligen un extremo. xGrid no elige ninguno.
En modo de emergencia, eliminamos las entradas no esenciales. Campos de direccion, numeros de seguro, documentacion detallada de alergias: todo es omitible. Pero tres pasos de confirmacion permanecen obligatorios independientemente del estado del sistema:
- Verificacion de identidad del paciente
- Confirmacion de nombre y dosis del medicamento
- Verificacion de compatibilidad cruzada de hemoderivados (cross-match)
La filosofia de diseno: las personas bajo presion naturalmente omitiran pasos. Eso no es un defecto del comportamiento humano, es una adaptacion. El trabajo del sistema es permitirles omitir los pasos que pueden esperar mientras hace imposible omitir los que no pueden esperar.
3. Disenar Registros para el Aprendizaje, No para la Culpa
Cada transferencia en xGrid genera un registro. Cada dispensacion de medicamento, cada traslado, cada movimiento de inventario. Los datos son lo suficientemente granulares para reconstruir una linea de tiempo completa del evento.
Pero disenamos el sistema de registro con un proposito especifico que la mayoria de los sistemas de auditoria omiten: aprender del exito, no solo del fracaso.
Considere: despues de una evacuacion particularmente fluida, los registros mostraron que una enfermera habia escaneado proactivamente los datos de hemoderivados a su telefono tres minutos antes de que llegara la orden de evacuacion. Esto no estaba en ningun protocolo. Fue improvisacion. Y ahorro quince minutos de re-escaneo en la estacion receptora.
Safety-I nunca descubriria esto, porque Safety-I solo investiga cuando algo sale mal. Safety-II investiga rutinariamente, porque las causas del exito son tan valiosas de comprender como las causas del fracaso. La improvisacion de esa enfermera ahora es parte del flujo de trabajo recomendado.
4. Proporcionar una Via Legal para Romper las Reglas
Dispensacion normal de medicamentos: el medico prescribe, el farmaceutico verifica, la enfermera confirma, se dispensa. Tres puertas de control. Safety-I solido.
Realidad del desastre: el medico esta clasificando veinte pacientes. El farmaceutico esta en otra estacion. Un paciente esta hemorragico. La enfermera necesita medicamento hemostatico ahora.
Si el sistema dice "sin prescripcion, sin dispensacion", la enfermera encontrara una forma de evitarlo: notas en papel, ordenes verbales, acceso directo al gabinete. El medicamento se administra. El sistema no registra nada.
xGrid ofrece una anulacion de emergencia de 24 horas (break-glass). Una enfermera puede activar la autorizacion de emergencia. El sistema registra la accion, la etiqueta como autorizada por emergencia y la marca para revision. La operacion continua con un rastro de auditoria completo.
Esto no es eludir la seguridad. Es una funcion de seguridad. Lo mas peligroso que un sistema puede hacer es forzar a las personas a trabajar fuera de el, porque entonces se pierde toda visibilidad. Una ruptura de reglas legitima y registrada es infinitamente mas segura que una solucion alternativa invisible.
La Evidencia: Patient I
Nuestra suite de pruebas E2E incluye Patient I — la Prueba de Consolidacion. Esta disenada para ser exigente.
Configuracion: 8 estaciones, 3 forzadas a evacuar simultaneamente. Durante la evacuacion:
- Transfusion sanguinea activa (la cadena de custodia debe mantenerse)
- Cirugia en progreso (debe interrumpir, documentar via transferencia ISBAR, transportar, reanudar)
- Medicamentos en transito entre estaciones (deben reasignarse a estaciones sobrevivientes)
Resultados:
| Verificacion | Resultado |
|---|---|
| Identidad del paciente preservada en la transferencia | Aprobado |
| Cadena de custodia de sangre mantenida, compatibilidad cruzada en nueva estacion | Aprobado |
| Cirugia reanudada con registro completo de transferencia ISBAR | Aprobado |
| Inventario conciliado en todas las estaciones fusionadas | Aprobado |
| 34 pasos ejecutados, 34 aprobados, cero perdida de datos | Aprobado |
Esto es Safety-II en la practica. El escenario no es "prevenir la evacuacion" — eso es imposible. El escenario es "hacer que la evacuacion tenga exito". Cada dato sobrevivio. Cada transferencia fue registrada. Cada puerta de seguridad se mantuvo donde importaba y cedio donde era necesario.
Un Complemento, No un Reemplazo
Safety-II no argumenta en contra de las barreras. xGrid todavia tiene escaneo de codigos de barras, verificacion de identidad, controles de dosis, acceso basado en roles. Estos mecanismos Safety-I previenen los errores que son prevenibles.
Safety-II maneja todo lo demas: los casos donde las condiciones estan demasiado degradadas para procedimientos normales, donde el protocolo asume recursos que usted no tiene, donde la respuesta del libro de texto no se ajusta a la situacion frente a usted.
Safety-I
- Pregunta central
Que sale mal? - Estrategia de diseno
Eliminar modos de falla - Vision de las personas
Fuente de riesgo a controlar - Detonante de aprendizaje
Despues de incidentes - Vision de la variacion
Amenaza a controlar
Safety-II
- Pregunta central
Que sale bien? - Estrategia de diseno
Mejorar la capacidad adaptativa - Vision de las personas
Fuente de resiliencia a apoyar - Detonante de aprendizaje
Durante operaciones normales - Vision de la variacion
Adaptacion necesaria
En entornos estables, Safety-I generalmente es suficiente. En entornos de desastre, es necesario pero no suficiente.
El muro sera vulnerado. La pregunta que importa es que sucede despues.
Relacionado: La Prueba de Abandono — Diseno de Software Que Sobrevive a Sus Creadores
Referencias
- Hollnagel E. Safety-I and Safety-II: The Past and Future of Safety Management. Ashgate Publishing; 2014. DOI