08.10.2026 · Signal Titans Editorial

Seis sobredosis masivas: cómo el Therac-25 dejó en manos del software la seguridad que antes daba el hardware

Un terminal DEC VT100 de color beige en una composición editorial con estética de plano técnico sobre los accidentes de radioterapia del Therac-25.

El 21 de marzo de 1986, en el East Texas Cancer Center de Tyler, un paciente yacía boca abajo en la mesa de tratamiento para su novena sesión de radioterapia. Fuera de la sala blindada, la operadora introdujo su prescripción, notó que había escrito “x” de rayos X en lugar de “e” de electrones, subió el cursor y lo corrigió. La pantalla indicaba “beam ready”. Pulsó “B”.

La máquina se detuvo y mostró “Malfunction 54”. El monitor de dosis indicaba una subdosis. Dentro de la sala, el paciente sintió algo parecido a una descarga eléctrica. Reconstrucciones posteriores sugirieron que pudo haber recibido entre 16.500 y 25.000 rads en menos de un segundo. Una dosis típica por sesión rondaba los 200 rads.

La máquina era un Therac-25. Entre junio de 1985 y enero de 1987 estuvo implicada en seis sobredosis masivas conocidas en Estados Unidos y Canadá. Nancy Leveson y Clark Turner, que más tarde reconstruyeron los accidentes, los calificaron como la peor serie de accidentes por radiación en la historia de los aceleradores médicos hasta ese momento.

Cronología

Junio de 1985, Marietta, Georgia: un paciente sufre quemaduras graves. El físico del hospital pregunta al fabricante, Atomic Energy of Canada Limited (AECL), si la máquina podría ser la responsable. AECL responde que no, y el accidente nunca se investiga a fondo.

Julio de 1985, Hamilton, Ontario: una segunda sobredosis. AECL culpa a un microinterruptor de la plataforma giratoria, lo cambia y comunica a sus clientes que, según su análisis, la seguridad ha mejorado al menos cinco órdenes de magnitud.

Diciembre de 1985, Yakima, Washington: un paciente presenta una quemadura en franjas. En febrero de 1986, AECL responde por escrito que el daño no pudo haber sido causado por la máquina ni por un error del operador.

21 de marzo de 1986, Tyler, Texas: la sobredosis del “Malfunction 54”. Los ingenieros de AECL no logran reproducirla y apuntan a un problema eléctrico. La máquina vuelve a estar en servicio el 7 de abril.

11 de abril de 1986, Tyler: la misma máquina, la misma operadora, el mismo mensaje, otra sobredosis.

17 de enero de 1987, Yakima: una sexta sobredosis, causada por un error de software distinto.

Febrero de 1987: los reguladores de Estados Unidos y Canadá piden a los usuarios que suspendan los tratamientos rutinarios hasta que la máquina se corrija.

La decisión de diseño de fondo

El Therac-25 tenía dos hermanos mayores, el Therac-6 y el Therac-20. En esas máquinas, la computadora era una comodidad añadida a un hardware capaz de funcionar de forma segura por sí solo. Contaban con enclavamientos eléctricos y mecánicos independientes.

El Therac-25 se diseñó desde el principio para el control por computadora. Según Leveson y Turner, AECL decidió no duplicar todos los mecanismos de seguridad de hardware existentes y confió en el software. Parte de ese software se reutilizó del Therac-6, y algunas rutinas procedían del Therac-20.

Esa elección es clave para entender lo que ocurrió después. El software lo había escrito en gran parte una sola persona, en lenguaje ensamblador de PDP-11 y con poca documentación. Ejecutaba varias tareas a la vez que compartían variables sin una sincronización adecuada.

Causa raíz 1: la ventana de ocho segundos

Tras el segundo accidente de Tyler, el físico del hospital, Fritz Hager, trabajó con la operadora para recrear exactamente lo que ella había hecho. Descubrieron que el desencadenante era la velocidad. Si un operador experimentado editaba la prescripción con suficiente rapidez, aparecía el error.

El mecanismo, tal como AECL se lo describió después a la FDA, era el siguiente. Cuando el operador terminaba de introducir los datos, una rutina empezaba a ajustar los imanes de deflexión, algo que tardaba unos ocho segundos. Durante ese tiempo, una subrutina debía comprobar si el operador había editado algo. Pero un flag se borraba tras la primera pasada, así que las pasadas siguientes dejaban de buscar cambios.

Si el operador cambiaba el modo de rayos X a electrones y devolvía el cursor a la parte inferior de la pantalla dentro de esos ocho segundos, la pantalla mostraba el nuevo ajuste. La máquina no lo aplicaba por completo. Podía disparar un haz de alta potencia pensado para el modo de rayos X sin que estuvieran en su sitio el blanco de rayos X ni el equipo de conformación del haz.

Una hoja en un costado de la máquina decía que “Malfunction 54” era un error de “dose input 2”. Nada de lo que los operadores tenían a mano explicaba qué significaba eso.

Causa raíz 2: un contador que volvía a cero

El accidente de Yakima de 1987 tuvo otra causa. Durante la preparación, una variable de un byte llamada Class3 se incrementaba en cada pasada por una rutina de prueba. Un valor distinto de cero significaba “comprobar la posición del colimador antes de permitir el tratamiento”.

Un byte solo puede contar hasta 255. En cada pasada número 256 volvía a cero, y la comprobación se omitía. Si el operador pulsaba “set” justo en ese instante, la máquina podía activar el haz con la plataforma giratoria en la posición equivocada. La corrección de AECL fue sencilla: asignar a la variable un valor fijo distinto de cero en lugar de incrementarla.

Por qué no se detectó

Nada de esto requirió malas intenciones. Bastó con que se alinearan varias suposiciones de apariencia razonable.

El análisis de seguridad de AECL de 1983 trataba, en la práctica, el software como fiable y se centraba en los fallos de hardware. Los mensajes de error eran crípticos, y la máquina se detenía tan a menudo por motivos inofensivos que los operadores aprendieron a pulsar “P” para continuar. Uno de los operadores declaró que no era nada fuera de lo común que algo detuviera la máquina.

La señal más clara vino del modelo anterior. Tras los accidentes de Tyler, un físico de la Universidad de Chicago descubrió que el Therac-20 tenía un error de software similar. En esa máquina solo fundía fusibles, porque los enclavamientos de hardware detenían el haz. Los fusibles llevaban años fundiéndose. El hardware había ocultado el bug.

El precio

Leveson y Turner documentan que hubo pacientes que murieron por complicaciones de sus sobredosis y otros que sufrieron lesiones graves, entre ellas parálisis y la pérdida de un pecho. Las máquinas se retiraron del uso rutinario a principios de 1987. El plan correctivo final de AECL, publicado en julio de 1987, añadió protección de hardware independiente, como un circuito de apagado de pulso único y la supervisión de la plataforma giratoria, junto con más de veinte cambios en el software.

Qué lo habría detectado

Enclavamientos de hardware independientes que detengan el haz crea lo que crea el software.
Tratar el código reutilizado como código nuevo cuando pasa a un sistema con supuestos de seguridad distintos.
Una sincronización adecuada del estado compartido entre tareas concurrentes.
Mensajes de error que indiquen a los operadores lo peligroso que es un fallo, y paradas de seguridad que no puedan reanudarse con una sola tecla.
Un proceso que investigue cada lesión notificada como un posible fallo del sistema.

Leveson y Turner advirtieron contra la lectura del Therac-25 como la historia de un solo bug. Centrarse en bugs de software concretos, escribieron, no es la forma de lograr un sistema seguro. La pregunta que conviene hacerse sobre los propios sistemas es más afilada: si el software se equivoca, ¿qué más queda en pie entre el error y la persona que está al otro lado?