← Volver al índice

Incidente médico - 1985-1987

Therac-25

Therac-25 fue un sistema de radioterapia controlado por software. Un conjunto de fallas en concurrencia y validación permitió dosis letales de radiación. El caso es emblemático por su impacto humano y por la necesidad de ingeniería rigurosa en sistemas críticos.

Tipo de sistema Equipo médico de radioterapia
Criticidad Salud - Misión crítica
Impacto Lesiones graves y fallecimientos

Identidad y contexto

Base del caso

Un sistema médico con software complejo requiere tolerancia a fallos y pruebas exhaustivas.

1) Identificación del caso

  • Nombre del sistema: Therac-25 (Control y dosificación).
  • Organismo responsable: AECL (Atomic Energy of Canada Limited).
  • Año del incidente: 1985-1987.
  • Área: Médico, radioterapia, control de equipos.

2) Contexto previo

  • Qué hacía el software: controlaba el modo y la dosis de radiación.
  • Problema real: tratar tumores con precisión y seguridad.
  • Entorno: misión crítica, pacientes finales, entorno clínico.
  • Complejidad: sistema embebido en tiempo real con interfaz operativa.

Naturaleza del bug

Qué falló y cómo se observó

Condiciones de carrera y validaciones incompletas activaron un modo de dosis errónea.

3) Descripción del bug

  • Tipo de error: concurrencia + validación insuficiente.
  • Localización: módulos de control de modo y seguridad.
  • Lenguaje y componente: software embebido y lógica de interfaz.
  • Cómo se introdujo: reutilización de código con supuestos no verificados.

4) Cómo se manifestó

  • Síntoma visible: dosis extremadamente altas sin alarma adecuada.
  • Error intermitente: se activaba en secuencias específicas de entrada.
  • Dependencia: tiempos de operador, ediciones rápidas y estados internos.
  • Reproducción: difícil, dependía de la secuencia exacta.
  • Ejemplo: una edición rápida de parámetros dejaba el modo de alta potencia activo.

Impacto

Consecuencias, costos y personas

El sistema falló en lo esencial: proteger a los pacientes.

5) Consecuencias directas

  • Fallos de servicio en tratamientos seguros.
  • Decisiones automáticas erróneas en la dosis aplicada.
  • Pérdida de control de un sistema físico crítico.

6) Impacto económico

  • Pérdidas estimadas: decenas de millones (litigios y retiradas).
  • Costos de reparación: rediseño del sistema y actualizaciones.
  • Impacto reputacional: daño severo a la marca y al fabricante.

7) Impacto humano

  • Lesiones graves y fallecimientos en pacientes.
  • Impacto social y legal con procesos judiciales posteriores.
  • Pérdida de confianza en tecnologías médicas automatizadas.

Causas y organización

Raíz técnica y fallas de ingeniería

Los mecanismos de seguridad estaban en software y resultaron insuficientes.

8) Causa raíz (Root Cause Analysis)

  • Defecto técnico puntual: condiciones de carrera en el control de modos.
  • Combinación de errores: falta de interlocks hardware + validación incompleta.
  • Mala interacción software-hardware: confianza excesiva en software.
  • Falta de pruebas en condiciones extremas de operador y tiempo.

9) Fallas de ingeniería organizacional

  • Ausencia de revisión por pares profunda en código crítico.
  • Estrés por fechas límite y presión comercial.
  • Falta de QA formal y pruebas de regresión.
  • Documentación insuficiente sobre estados y límites seguros.

Detección y respuesta

Cómo se descubrió y se reaccionó

Los reportes clínicos y las investigaciones revelaron el defecto.

10) Cómo se descubrió

  • Reportes de pacientes y personal médico.
  • Auditorías técnicas y reconstrucción de secuencias.

11) Respuesta de la empresa

  • Actualizaciones de software y comunicados técnicos.
  • Retiro temporal y correcciones de seguridad.
  • Colaboración con reguladores y centros médicos.

12) Cómo se arregló

  • Corrección de lógica de modos y bloqueos.
  • Añadir interlocks hardware y validaciones redundantes.
  • Pruebas de seguridad en escenarios de uso rápido.
  • Automatización de checks críticos antes de irradiar.

Aprendizajes

Lecciones y enfoque moderno

La seguridad no se delega solo al software: requiere redundancia física y formal.

13) Lecciones aprendidas

  • Incluir interlocks hardware en sistemas críticos.
  • Diseño defensivo frente a errores de operador.
  • Validar concurrencia y estados transitorios.
  • Importancia de pruebas en tiempo real.

14) Qué se haría hoy distinto

  • Verificación formal y pruebas de seguridad automatizadas.
  • Observabilidad del estado interno y alertas proactivas.
  • Feature flags y simuladores clínicos antes de desplegar.
  • Estándares regulatorios más estrictos para software médico.
  • IA para detectar patrones de riesgo en eventos clínicos.