AECL Therac-25: responsabilidad en seguridad de dispositivos

Resumen

Seis accidentes conocidos del Therac-25 con sobredosis masivas de radiación ocurrieron entre junio de 1985 y enero de 1987. El registro existente documenta lesiones graves y muertes, pero no respalda tratar cada muerte posterior como causada únicamente por la sobredosis ni asignar una dosis exacta a cada paciente.
Dos rutas de software distintas están bien establecidas. La edición rápida del modo y energía de tratamiento podía dejar los datos de prescripción mostrados inconsistentes con la configuración de la máquina en los accidentes de Tyler. En el segundo accidente de Yakima, un contador de 8 bits podía desbordarse a cero y omitir una verificación de posición del colimador. La ruta de software exacta para los primeros tres accidentes sigue siendo desconocida.
El fallo de control más profundo fue arquitectónico. Las máquinas Therac anteriores mantenían circuitos protectores independientes y enclavamientos mecánicos. El Therac-25 dio al software una mayor responsabilidad de seguridad y no duplicó todas esas protecciones, permitiendo que un error de software y el estado del sistema asociado se convirtieran en un camino hacia una exposición catastrófica.
La detección falló en varias capas. Mensajes crípticos clasificaban condiciones peligrosas como pausas de tratamiento, los monitores de dosis podían saturarse y mostrar una aparente subdosis, las interrupciones frecuentes no peligrosas entrenaban a los operadores a reanudar, los registros de auditoría de tratamiento eran incompletos, y los informes de diferentes hospitales no constituyeron una imagen compartida oportuna del incidente.
AECL controló el diseño, la reutilización del código, la documentación del software, el análisis de peligros, las advertencias al cliente y el plan de acción correctiva. Los hospitales controlaron la operación local, la observación del paciente, la retirada del equipo y la escalada. Los reguladores controlaron los hallazgos de defectos, la clasificación de retirada y la aprobación de la acción correctiva, pero el régimen de notificación de EE. UU. dependía entonces en gran medida de los fabricantes y no imponía los deberes posteriores de las instalaciones de usuario.
La evidencia de reparación es sustancial pero limitada. El plan de acción correctiva final añadió apagado independiente del ordenador y enclavamientos de plato giratorio, cambió pausas por suspensiones, mejoró los mensajes, restringió la edición, corrigió defectos conocidos y requirió más pruebas y análisis de seguridad. El registro público no contiene un paquete de validación moderno completo, historial de código fuente, todos los resultados de pruebas o un conjunto de datos de rendimiento de campo a largo plazo.
La lección duradera no es que los dispositivos médicos deban evitar el software. Es que el software no debe permitir que una condición catastrófica sea alcanzable a través de una sola ruta no controlada. Barreras independientes, requisitos basados en peligros, pruebas de interacción realistas, alarmas accionables, pistas de auditoría, informes rápidos entre sitios y evidencia de acción correctiva revisable de forma independiente son parte del caso de seguridad.

Los famosos errores son evidencia, no la explicación completa

El Therac-25 es recordado porque el código y el daño al paciente pueden conectarse de manera inusualmente clara. Esa claridad es útil, pero puede distorsionar la responsabilidad si la investigación comienza y termina con una condición de carrera o una variable desbordada. Un defecto explica cómo se comportó una ruta de ejecución particular.

No explica por sí solo por qué una ruta podía colocar un haz de alta energía en una configuración insegura, por qué el sistema físico carecía de una parada independiente, por qué una consola podía informar poca o ninguna dosis después de una exposición masiva, por qué se invitaba a un operador entrenado a continuar, o por qué las advertencias de varias instalaciones no convergieron rápidamente.

Lainvestigación originalde Nancy Leveson y Clark Turner, publicada en IEEE Computer en 1993 y basada en material de la FDA, registros regulatorios canadienses, cartas y declaraciones judiciales, es inusualmente explícita sobre sus límites probatorios. Los autores pudieron documentar seis accidentes conocidos, dos mecanismos de software y una larga secuencia de acción correctiva. No pudieron obtener información completa sobre la gestión de desarrollo de AECL, los controles de calidad o cada evento. Por lo tanto, su relato respalda una conclusión a nivel de sistema sin respaldar todas las alegaciones que se han acumulado en torno al caso.

El registro oficial de retirada proporciona un ancla independiente importante. Elexamen de retiradas selectivas de dispositivosde la Oficina General de Contabilidad de EE. UU. lista el Therac-25 como una retirada de Clase I que involucra cinco aceleradores en EE. UU., con fecha del 3 de junio de 1987, e identifica dos defectos de software capaces de causar sobredosis masivas de radiación. Ese registro es más estrecho que la historia completa de accidentes. Leveson y Turner reportaron once máquinas instaladas, cinco en EE. UU. y seis en Canadá. La cantidad de la GAO debe entenderse, por lo tanto, como la población de retirada en EE. UU. en su conjunto de datos, no como el número de unidades Therac-25 en todo el mundo.

Esta distinción apunta a la cuestión central de responsabilidad. Un fabricante no puede prometer que el software crítico para la seguridad no contenga defectos. Puede decidir si un defecto es suficiente para producir energía catastrófica, si un mecanismo físico separado verifica el estado de la máquina, si la interfaz transmite peligro, si la evidencia de campo se conserva y combina, y si una acción correctiva aborda la clase de peligro en lugar de solo la secuencia de entrada más recientemente reproducida. Esas fueron decisiones de diseño y gobernanza controlables.

La arquitectura transfirió una función de seguridad física al software

El Therac-25 era un acelerador lineal médico de doble modo. Podía usar electrones acelerados para tratamientos superficiales o producir rayos X para tratamientos más profundos. En modo fotón, la máquina necesitaba un blanco y equipo de aplanamiento del haz en la trayectoria del haz. En modo electrón, necesitaba equipo de escaneo y otro para esparcir y controlar el haz. Un plato giratorio rotatorio movía el equipo relevante a su posición.

El peligro físico era directo incluso si la implementación era compleja: alta potencia del haz combinada con un estado incorrecto del plato giratorio o colimador podía concentrar energía que debería haber sido moldeada, medida o bloqueada.

Ladescripción del plato giratorio preservada por el MITmuestra por qué un enclavamiento era una barrera de seguridad y no una característica de conveniencia. Tres microinterruptores reportaban la posición al ordenador. El ordenador posicionaba y verificaba el plato giratorio. En la posición de luz de campo, un espejo usado para alinear al paciente se encontraba en la trayectoria del haz y no se esperaba ninguna cámara de ionización porque ningún haz de tratamiento debería estar presente. Los enclavamientos electromecánicos tradicionales se habían utilizado para evitar la operación en un estado incompatible. En el Therac-25, las comprobaciones de software sustituyeron a muchos de ellos.

Esa sustitución representó un cambio material con respecto al linaje en el que AECL confiaba. Therac-6 y Therac-20 añadieron control por ordenador a máquinas que podían operar de forma independiente y conservaban protecciones de hardware estándar de la industria. El Therac-25 fue diseñado en torno al control por ordenador. Su software tenía una mayor responsabilidad en la supervisión de la operación segura, mientras que no todos los circuitos protectores anteriores se duplicaron.

El Therac-20 más antiguo proporcionó más tarde una comparación accidental: un defecto de edición relacionado podía disparar fusibles o disyuntores, pero circuitos protectores independientes impedían la activación del haz y no se produjo ninguna exposición comparable del paciente.

La reutilización del código no fue inherentemente el error. AECL reutilizó la estructura y las rutinas de máquinas anteriores, y la reutilización puede preservar el comportamiento probado. El problema era que las suposiciones de un sistema con protección de hardware independiente cruzaron a un sistema donde el software se había convertido en parte del límite de seguridad primario. Elrelato de desarrollo de softwareexistente dice que el programa evolucionó a partir del código Therac-6, fue escrito en lenguaje ensamblador PDP-11, y utilizaba un ejecutivo en tiempo real personalizado con tareas concurrentes y manejadores de interrupciones. También registra documentación escasa y la preocupación de un revisor de la FDA de que faltaban especificaciones y un plan de pruebas de software.

En una aplicación benigna, las suposiciones heredadas pueden producir inconvenientes. En un acelerador médico, se vuelven peligrosas cuando el nuevo sistema elimina el componente independiente que antes las contenía. La pregunta relevante del ciclo de vida no es simplemente si el código reutilizado había funcionado durante años. Es si cada suposición de seguridad fue reestablecida contra el nuevo hardware, la nueva autoridad de control, el nuevo flujo de trabajo del operador y la nueva consecuencia de falla. El registro público no muestra que ocurriera dicha revisión integrada de suposiciones antes del uso clínico.

El análisis de seguridad previo al accidente no probó la nueva fuente de control

AECL realizó un análisis de seguridad de árbol de fallas en marzo de 1983. Según la investigación, asumió que los errores de programación se habían reducido mediante pruebas extensas y excluyó los defectos de software residuales. Trató los errores de ejecución del ordenador principalmente como consecuencias de fallas de hardware o perturbaciones aleatorias. Sin embargo, el software ahora llevaba funciones de seguridad que el hardware había llevado en máquinas anteriores. Por lo tanto, el análisis prestó poca atención útil al componente cuya autoridad había aumentado más.

Esto no fue meramente un problema cuantitativo. Asignar una probabilidad extremadamente baja a un evento de ordenador vagamente descrito no puede demostrar que se hayan identificado los estados inseguros. Los defectos de software deterministas no aparecen aleatoriamente como un componente desgastado; se repiten siempre que el estado y la sincronización requeridos se alinean. Si el análisis no modela edición rápida, interacciones de variables compartidas, desbordamiento de contadores, configuración de máquina obsoleta, monitores saturados o pantallas contradictorias, un resultado numérico pequeño dice poco sobre esos caminos.

Elresumen del análisis de seguridad del Therac-25posterior es evidencia de una revisión más seria después de los accidentes. Utilizó análisis de modos de falla y efectos, análisis de árbol de fallas y examen de software. Identificó funciones críticas para la seguridad, incluyendo escaneo, selección de energía, apagado del haz y calibración, y condujo a recomendaciones para enclavamientos independientes del ordenador. Incluso ese análisis posterior fue sincero sobre los límites: la inspección del código no podía proporcionar alta confianza en funciones complejas de escaneo y selección de energía. Esa incertidumbre apoyó añadir barreras en lugar de afirmar que la inspección había demostrado que el código estaba completo.

La inferencia respaldada es que el caso de seguridad original estaba estructuralmente desajustado con el diseño. La evidencia pública no establece quién aprobó cada suposición, qué objeciones internas se plantearon, o si el costo fue la razón decisiva para no duplicar la protección de hardware. Sí establece que el análisis excluyó errores de software residuales mientras se confiaba en el software para prevenir configuraciones físicas inseguras. Eso es suficiente para ubicar el problema de responsabilidad a nivel de diseño del sistema sin inventar un motivo privado.

Seis accidentes se convirtieron en un solo incidente solo después de daños repetidos

La cronología importa porque cada evento cambió lo que razonablemente se podía saber. Lalínea de tiempo consolidada de eventoscomienza el 3 de junio de 1985 en el Kennestone Regional Oncology Center en Marietta, Georgia. Un paciente que recibía tratamiento de electrones reportó calor intenso y luego desarrolló lesión por radiación severa. El registro de tratamiento estaba desactivado, sin dejar registro impreso. El físico del hospital preguntó a AECL si la máquina podía operar en modo electrón sin escaneo; AECL respondió que no. Las cuentas difirieron sobre cuándo AECL recibió notificación formal, pero la empresa tenía notificación oficial del litigio para noviembre de 1985. Ninguna investigación oportuna estableció la ruta de la máquina.

El 26 de julio de 1985, un paciente en la clínica Ontario Cancer Foundation en Hamilton experimentó pausas repetidas de tratamiento y un mensaje H-tilt. La pantalla indicaba dosis cero, y el operador usó el comando de continuar permitido varias veces. El paciente sufrió una sobredosis local importante. AECL no pudo reproducir el evento y sospechó una falla del microinterruptor. Rediseñó la lógica del interruptor e hizo una afirmación de mejora de seguridad muy grande a pesar de que su propio relato no podía ser firme sobre la causa.

Funcionarios canadienses y un consultor independiente pidieron cambios más fuertes, incluyendo una verificación independiente de la posición del plato giratorio y la suspensión del tratamiento para fallos relevantes. AECL no instaló el enclavamiento independiente solicitado en esa etapa.

En diciembre de 1985, un paciente en el Yakima Valley Memorial Hospital desarrolló una reacción cutánea estriada después del tratamiento. El personal investigó otras explicaciones y escribió a AECL el 31 de enero de 1986. AECL respondió el 24 de febrero que ni un mal funcionamiento de la máquina ni un error del operador podían haber producido la lesión y se refirió a la ausencia de incidentes similares. Elprimer relato de Yakimamuestra por qué el control de la información importaba: la instalación no conocía la historia completa entre sitios y confiaba en la confianza técnica del fabricante. Solo después del segundo accidente de Yakima la primera lesión fue reconocida como una probable sobredosis.

El 21 de marzo de 1986, el primer paciente de Tyler recibió tratamiento de electrones después de que un operador experimentado corrigiera rápidamente una entrada inicial de rayos X. La máquina mostró Mal funcionamiento 54, clasificó la condición como una pausa de tratamiento y mostró una aparente subdosis. El operador siguió el flujo de trabajo normal y continuó. Los enlaces de audio y video a la sala de tratamiento blindada no funcionaban ese día, retrasando el reconocimiento de la angustia del paciente. Los ingenieros de AECL inicialmente no pudieron reproducir el mal funcionamiento y nuevamente consideraron una explicación eléctrica.

Después de que las pruebas no encontraron problemas de conexión a tierra, la clínica devolvió la máquina al servicio el 7 de abril.

El 11 de abril, un segundo paciente de Tyler experimentó el mismo Mal funcionamiento 54 después de que el mismo operador editara rápidamente el modo. Esta vez el intercomunicador funcionó y el operador se detuvo. El físico de la clínica, Fritz Hager, retiró la máquina del servicio y trabajó con el operador hasta que pudo reproducir la secuencia. La velocidad era la condición faltante. Una vez que se le dijo a AECL que la edición debía realizarse rápidamente, reprodujo el mal funcionamiento y midió una salida masiva. AECL presentó un informe de accidente a la FDA el 15 de abril.

La FDA declaró el dispositivo defectuoso el 2 de mayo y requirió un plan de acción correctiva.

El 17 de enero de 1987, un segundo paciente de Yakima fue expuesto mientras el plato giratorio estaba asociado con la configuración de luz de campo. La consola no mostró dosis de tratamiento más allá de exposiciones de película anteriores, la máquina se detuvo y el operador pudo continuar. Esta era una ruta de software diferente. La reconstrucción preliminar de AECL estimó miles de rads por intento, pero la dosis exacta administrada sigue siendo incierta. El evento mostró que una corrección específica de Tyler no era un caso de seguridad completo.

La FDA y las autoridades canadienses se movieron en febrero para recomendar descontinuar el uso rutinario hasta que se completaran modificaciones permanentes.

La cronología no respalda la afirmación de que una persona ignoró seis alarmas idénticas. Los accidentes ocurrieron en diferentes instalaciones, produjeron diferentes mensajes y no todos fueron técnicamente comprendidos en ese momento. Sí respalda la conclusión de que la información del incidente permaneció fragmentada, las conclusiones tempranas de imposibilidad fueron demasiado fuertes y la acción correctiva inicialmente siguió a los componentes sospechosos en lugar de a la clase de peligro.

Cada evento adicional debería haber reducido la confianza en la premisa de que el software y las comprobaciones existentes hacían imposible la sobredosis.

Tyler expuso una inconsistencia sensible al tiempo entre la pantalla y la máquina

El desencadenante de Tyler no fue simplemente que el operador escribiera demasiado rápido. El operador ingresó un modo de tratamiento, se movió a la línea de comandos, regresó al modo de edición y cambió la entrada de rayos X a electrón dentro del período en que la máquina estaba configurando los imanes de curvatura. La pantalla reflejaba la corrección. Las tareas de software concurrentes no propagaban de manera confiable el estado editado a todos los parámetros de la máquina.

Lareconstrucción detallada del software de Tylerdescribe variables compartidas utilizadas por el manejador de teclado, la rutina de entrada de datos y las tareas de control de tratamiento. Un indicador de finalización señalaba que el cursor había alcanzado la línea de comandos, no que la edición hubiera terminado realmente. Otro indicador asociado con la configuración del imán se borraba demasiado pronto, por lo que las ediciones posteriores podían escapar al reconocimiento. Los bytes bajos y altos de una variable de modo y energía podían influir en diferentes tareas. Bajo la sincronización requerida, el posicionamiento del plato giratorio o colimador podía seguir el valor editado mientras que otros parámetros operativos permanecían derivados de la selección anterior de rayos X.

Por lo tanto, el desencadenante directo puede establecerse de manera estrecha: una edición rápida dentro de una ventana específica permitió que un estado inconsistente pasara al tratamiento. El defecto solo era reproducible cuando el flujo de trabajo se realizaba a la velocidad real de un experto. Un ingeniero lento siguiendo una secuencia escrita podía pasarlo por alto. Es por eso que la reconstrucción del físico de la clínica importó. Trató la experiencia del operador como una condición de prueba, no como evidencia de mal uso.

El resultado inseguro requirió más que la condición de carrera. El software no realizó una verificación de consistencia independiente final entre el tratamiento mostrado, la configuración de la máquina y los parámetros del haz. El hardware no bloqueó de forma independiente la configuración incompatible. Las cámaras de ionización se saturaron bajo el pulso intenso y pudieron reportar un valor bajo. La máquina etiquetó el evento como una pausa y puso a disposición un reinicio de una tecla. El operador había sido condicionado por muchas pausas inofensivas a usar ese comando.

En el primer evento de Tyler, los monitores de sala rotos eliminaron un último canal de detección humana.

Llamar causa a la acción del operador invertiría la relación de control. La interfaz apoyaba intencionalmente la entrada y edición rápidas porque los operadores habían solicitado eficiencia. La tecla de continuar era la respuesta especificada a una pausa. La velocidad y familiaridad del operador eran características previsibles del entorno de uso previsto. Desencadenaron un defecto, pero AECL controlaba si esa interacción podía crear un estado peligroso de la máquina y si el estado sería detenido de forma independiente.

Yakima expuso una ruta diferente a través del desbordamiento del contador

El segundo mecanismo de Yakima ocurrió más tarde en la lógica de control. Una variable de un byte utilizada en comprobaciones repetidas de configuración se incrementaba en cada pasada. Debido a que solo podía representar 256 estados, se desbordaba a cero en cada pasada 256. Cero también se usaba para significar que no se requería verificar ninguna inconsistencia del colimador superior. Si el operador emitía el comando de ajuste en el momento del desbordamiento, la verificación de posición podía omitirse y el tratamiento podía continuar con el plato giratorio aún en un estado inseguro relacionado con la luz de campo.

Lareconstrucción original de la falla de Yakimadistingue esto de Tyler. La tarea concurrente Housekeeper realizaba la verificación del colimador solo cuando la variable compartida Class3 era distinta de cero. Set-Up Test incrementaba esa variable cientos de veces mientras esperaba la configuración de la máquina. En el desbordamiento, el software omitía la verificación. La corrección inmediata del código de AECL fue establecer la variable en un valor fijo distinto de cero en lugar de incrementarla.

Nuevamente, el cambio de código corrigió el desencadenante identificado pero no estableció la seguridad por sí mismo. Un valor de estado crítico para la seguridad compartido entre tareas concurrentes no debería combinar silenciosamente un contador y un estado de autorización. Más importante aún, ninguna barrera física independiente impedía la activación del haz mientras la configuración del plato giratorio era incorrecta. Por lo tanto, la acción correctiva final necesitaba tanto una corrección de código como un enclavamiento del plato giratorio que no dependiera de la misma ruta de software.

El registro existente no identifica la ruta de código exacta para Kennestone, Hamilton o el primer evento de Yakima. Hubo especulación contemporánea de que Hamilton pudo haberse parecido al segundo mecanismo de Yakima, pero Leveson y Turner lo marcaron como especulación. Sigue siendo posible que estuvieran involucradas condiciones de carrera desconocidas u otros defectos. Un relato disciplinado no debería retroadaptar los dos mecanismos posteriores a cada lesión anterior simplemente porque el resultado físico parecía similar.

Esa incógnita no es exculpatoria y no debería llenarse con certeza. Muestra por qué la arquitectura importaba. Cuando varias rutas de software desconocidas pueden alcanzar el mismo estado catastrófico, probar y parchear un defecto a la vez es una estrategia de control inadecuada. Una barrera independiente puede contener tanto rutas conocidas como desconocidas. Este es el valor práctico de la defensa en profundidad: reduce la dependencia del caso de seguridad del conocimiento completo del comportamiento del software.

La interfaz convirtió señales de peligro contradictorias en trabajo rutinario

Lainterfaz de operadordel Therac-25 distinguía entre una suspensión de tratamiento, que requería un reinicio, y una pausa de tratamiento, que permitía un comando de continuar de una tecla. También generaba mal funcionamientos frecuentes que normalmente se asociaban con inconvenientes o subdosis. Los operadores aprendieron de la experiencia repetida que pausar y continuar era normal. La capacitación reforzaba la confianza en que múltiples mecanismos de seguridad hacían la sobredosis virtualmente imposible.

En los accidentes, ese modelo operativo falló de varias maneras. Los números de mal funcionamiento eran crípticos y no estaban adecuadamente explicados en los manuales disponibles. Una condición severa relacionada con la dosis podía presentarse con baja prioridad. El hardware de monitoreo saturado podía reportar una aparente subdosis precisamente cuando la salida era peligrosamente alta. La consola podía mostrar "verificado" o "haz listo" aunque la configuración física y los parámetros internos fueran inconsistentes. La máquina permitía la exposición repetida sin forzar una nueva prescripción o una verificación independiente.

Estos no son defectos cosméticos separados. Una alarma es un control solo si ayuda al operador a distinguir un estado peligroso y tomar la acción correcta. Una pausa de baja prioridad que permite la continuación inmediata es una autorización. Una pantalla que subestima la dosis administrada cambia la decisión del operador. Un mensaje "verificado" es una afirmación de seguridad. Cuando esas señales entran en conflicto con el informe de un paciente de ardor o con un monitor físico, el sistema debe dirigir a los usuarios hacia la interpretación más conservadora.

Eldocumento posterior del OIEA sobre lecciones de exposiciones radioterapéuticas accidentalesformaliza este principio sin hacer una conclusión legal retrospectiva sobre AECL. Pide investigar señales inconsistentes, asumir la indicación más grave hasta que se refute, diseñar y probar para el entorno clínico hombre-máquina, capacitar al personal para interpretar pantallas anormales y usar múltiples capas protectoras. Therac-25 demuestra por qué esos elementos pertenecen al sistema de ingeniería en lugar de dejarse como vigilancia personal.

El control práctico estaba distribuido, pero no era igual

AECL tenía el control preventivo más amplio. Seleccionó la arquitectura de hardware y software, eligió qué enclavamientos conservar, controló el código fuente y la documentación, estableció el significado y prioridad de las alarmas, diseñó el comportamiento de reinicio, realizó el análisis de peligros inicial, recibió informes de campo, emitió avisos a los clientes y propuso acciones correctivas. También controló si los usuarios y reguladores recibían una imagen completa entre sitios. Esos poderes hicieron del fabricante el principal responsable del riesgo sistémico de diseño y aprendizaje de incidentes.

Eso no hace pasivos a los hospitales. Las instalaciones controlaban si el audio y video de la sala funcionaban, si los registros de tratamiento y las funciones de auditoría estaban habilitados, cómo se registraban las fallas recurrentes, cuándo se retiraba el equipo, con qué rapidez investigaba un físico médico y qué se reportaba a las autoridades estatales o federales. El primer evento de Tyler muestra una falla de detección local: el enlace audiovisual no estaba disponible y el tratamiento continuó después.

El segundo evento de Tyler muestra un control local efectivo: el operador escaló, el físico detuvo el uso y la instalación reconstruyó el desencadenante. La primera investigación de Yakima muestra el límite de la experiencia local cuando el fabricante negó que el dispositivo pudiera producir el daño observado y la evidencia de otros sitios no estaba disponible.

Los operadores controlaban la entrada de datos, la configuración del paciente y la decisión inmediata de continuar después de una pausa, pero no controlaban el modelo de concurrencia oculto, la clasificación de alarmas, el comportamiento saturado del monitor de dosis o los enclavamientos independientes faltantes. Sus acciones deben evaluarse contra el flujo de trabajo previsto y la información disponible. Un usuario entrenado que corrige rápidamente un error de entrada común no es una entrada adversaria imprevisible.

Presionar la tecla que la interfaz ofrece para una pausa de tratamiento no es prueba de que el usuario aceptó un riesgo de sobredosis no revelado.

Los físicos médicos tenían un poder diagnóstico importante. El trabajo de Hager en Tyler proporcionó la secuencia reproducible que ni las pruebas de servicio rutinarias ni una reconstrucción de ingeniería inicialmente más lenta habían encontrado. Los usuarios también formaron un grupo, intercambiaron información y presionaron por cambios de hardware, mejores mensajes, revisión de software independiente y una pista de auditoría. Sin embargo, carecían de acceso al código fuente y no recibieron un registro completo lo suficientemente temprano para actuar como una red de seguridad coordinada.

Los reguladores controlaban los hallazgos legales y la puerta de acción correctiva. La FDA podía declarar defectuoso el producto emisor de radiación, requerir notificación al comprador y revisar el plan de acción correctiva de AECL. Las autoridades de radiación canadienses podían exigir cumplimiento y recomendar descontinuar el uso. No operaban las salas de tratamiento ni escribían el software, y el sistema de notificación de EE. UU. aún no requería que las instalaciones de usuario informaran como lo haría una ley posterior.

Su responsabilidad se refiere a si las advertencias se recopilaron, la autoridad se usó con prontitud, las soluciones propuestas se desafiaron y el cierre dependió de la evidencia en lugar de la afirmación.

Los pacientes tenían la evidencia más directa del daño y el menor control del sistema. Varios reportaron inmediatamente calor, ardor o sensaciones similares a descargas que contradecían las pantallas de la máquina. No podían inspeccionar el estado de la máquina, obtener un historial de incidentes entre sitios o desactivar una característica de diseño. Un sistema de seguridad que trata el testimonio del paciente como menos creíble que una pantalla que se sabe capaz de saturación coloca el poder probatorio con la señal menos confiable.

La detección falló antes de que fallara la respuesta

Es útil separar la detección de la respuesta. La falla de detección ocurrió cuando el sistema no preservó o interpretó la evidencia de que había ocurrido un evento inseguro. La falta de datos de tratamiento impresos en Kennestone, las cámaras de ionización saturadas, la dosis baja o nula mostrada, los códigos de mal funcionamiento crípticos, los manuales incompletos, la monitorización de sala desactivada y la incapacidad de reproducir secuencias sensibles al tiempo redujeron la observabilidad. La fragmentación entre sitios significaba que cada clínica podía parecer que experimentaba una anomalía aislada.

La falla de respuesta comenzó cuando la evidencia disponible no desencadenó una precaución suficientemente amplia. Después de Hamilton, AECL abordó la lógica sospechosa del microinterruptor y redujo el número de reintentos permitidos, pero no instaló el enclavamiento de posición independiente solicitado ni convirtió todas las pausas relevantes en suspensiones. Después del primer informe de Yakima, la empresa declaró que el mal funcionamiento de la máquina y el error del operador no podían haber causado la lesión.

Después del primer accidente de Tyler, la incapacidad de reproducir el Mal funcionamiento 54 apoyó una hipótesis eléctrica y la máquina volvió a uso. Esas acciones eran comprensibles solo si se confiaba más en el modelo de seguridad existente que en la evidencia adversa.

La secuencia revela un error epistémico recurrente: la incapacidad de reproducir se trató demasiado como prueba de imposibilidad. El software concurrente sensible al tiempo puede ser determinista y aún así eludir una prueba que no recrea la sincronización, la carga de trabajo y la interacción experta. Un resultado negativo debería reducir o redirigir una hipótesis, no cerrar el peligro cuando las consecuencias son graves y la lesión física es consistente con la exposición excesiva.

La comunicación era en sí misma un control. Un usuario que supiera sobre Kennestone, Hamilton y Yakima evaluaría el Mal funcionamiento 54 de manera diferente a un usuario al que se le dijo que no había eventos de sobredosis. Un regulador que recibiera informes oportunos del fabricante y las instalaciones podría identificar un patrón antes. Un ingeniero de servicio con registros de auditoría exactos podría distinguir un desajuste de configuración de un transitorio eléctrico. La ausencia de esa evidencia compartida aumentó el tiempo durante el cual la operación insegura seguía siendo plausible.

La inferencia respaldada es que la agregación temprana y la escalada conservadora podrían haber acortado la exposición al peligro. El registro público no puede determinar si algún accidente posterior específico se habría prevenido ciertamente, porque los mecanismos tempranos exactos siguen siendo desconocidos y las necesidades de tratamiento diferían. Puede mostrar que las instituciones con información y control tuvieron oportunidades de detener el uso rutinario, añadir barreras independientes o emitir advertencias más contundentes antes de enero de 1987.

El régimen de notificación fue una condición contribuyente, no una excusa completa

En el momento de los primeros accidentes, la notificación de dispositivos médicos en EE. UU. dependía en gran medida de los fabricantes e importadores. Los hospitales y profesionales de la salud aún no estaban sujetos al deber federal posterior de notificación de instalaciones de usuario. Los informes de Tyler llegaron a la FDA a través del departamento de salud de Texas antes del informe detallado de dispositivo médico de AECL. Esa estructura hacía que el sistema federal de alerta temprana fuera vulnerable a la incertidumbre local y al flujo de información del fabricante.

La debilidad no era meramente teórica. Larevisión de 1986 de la GAO sobre la subnotificación de dispositivos médicosencontró serias brechas en cómo los hospitales, fabricantes y la FDA comunicaban los problemas de los dispositivos y recomendó relaciones de notificación más sólidas. Surevisión posterior de la implementación de la notificación de dispositivos médicos de la FDAencontró deficiencias en la evaluación del cumplimiento, el procesamiento de datos y la documentación de cómo los informes conducían a acciones correctivas. Untestimonio del Congreso de la GAO de 1989concluyó que el sistema de notificación no proporcionaba la alerta temprana prevista y que la autoridad legal de la FDA sobre retiradas era limitada.

El Congreso cambió el marco después de los accidentes. LaLey de Dispositivos Médicos Seguros de 1990requirió que las instalaciones de usuario de dispositivos informaran información que sugiriera razonablemente que un dispositivo causó o contribuyó a la muerte o lesión grave de un paciente, estableció plazos de notificación y amplió las autoridades de corrección, retirada y recall. Esa ley es evidencia de una respuesta política posterior a las debilidades generales de vigilancia. No debe describirse como una conclusión judicial de que los accidentes del Therac-25 causaron cada disposición, ni sus deberes posteriores deben aplicarse retroactivamente a los hospitales en 1985.

La autoridad canadiense operaba a través de una estructura diferente. LaLey de Dispositivos Emisores de Radiaciónprohibía la venta, arrendamiento o importación de dispositivos que no cumplieran con las normas aplicables o crearan riesgos de radiación específicos y proporcionaba poderes de inspección, notificación y regulatorios. La Oficina Canadiense de Protección contra la Radiación solicitó cambios de hardware y software después de Hamilton y luego coordinó con la FDA para descontinuar el uso rutinario. El registro aún muestra demora entre la primera solicitud de enclavamiento independiente y su instalación a través de la acción correctiva final.

La fragmentación regulatoria también importa en EE. UU. Ladescripción actual de la jurisdicción de radiación de la NRCexplica que los estados regulan las máquinas productoras de radiación como rayos X y aceleradores de partículas, mientras que las agencias federales tienen roles distintos. Por lo tanto, el Therac-25 involucró a hospitales, autoridades estatales de radiación, la FDA y organismos canadienses. La jurisdicción distribuida no es necesariamente defectuosa, pero requiere una ruta explícita para que una anomalía de tratamiento local se convierta en una señal de producto nacional y transfronteriza.

La causa raíz, las condiciones contribuyentes y los desencadenantes deben permanecer separados

El desencadenante directo de Tyler fue la edición rápida dentro de una ventana de sincronización. El desencadenante directo del segundo Yakima fue una acción de ajuste en el momento en que una variable de 8 bits se desbordaba a cero. Esos eventos seleccionaron rutas inseguras en el software. No son la causa raíz porque ninguno explica por qué la ruta tenía autoridad para activar energía peligrosa sin una parada independiente.

La proposición central de causa raíz respaldada por el registro es arquitectónica y organizativa: la responsabilidad de seguridad se trasladó de los enclavamientos de hardware independientes al software sin un análisis de peligros, ciclo de vida del software, validación integrada, diseño de interfaz y sistema de aprendizaje de incidentes acordes con el daño posible. El diseño permitió que una sola cadena controlada por software configurara, juzgara consistencia, presentara estado y autorizara el tratamiento. La dependencia común derrotó la apariencia de múltiples comprobaciones.

Las condiciones de ingeniería contribuyentes incluyeron rutinas reutilizadas cuyas suposiciones no se demostró que hubieran sido revalidadas en la nueva arquitectura; variables compartidas y tareas concurrentes con semántica de estado insegura; falta de una verificación de consistencia final; monitores que podían saturarse; manejo de mal funcionamiento que permitía reinicio; mensajes crípticos; documentación de software escasa; y prácticas de prueba que inicialmente no incluían edición a velocidad experta realista.

El tratamiento del software en el árbol de fallas original redujo la posibilidad de que esos caminos fueran examinados antes del despliegue.

Las condiciones operativas contribuyentes incluyeron pausas benignas frecuentes, capacitación del operador que enfatizaba la abundancia de mecanismos de seguridad, canales de auditoría y monitoreo de sala faltantes o desactivados, y la capacidad limitada de las instalaciones para comparar incidentes. Una decisión local de reanudar la operación importó, pero ocurrió dentro de un entorno de información diseñado e influenciado por el fabricante.

Las condiciones de gobernanza contribuyentes incluyeron un seguimiento débil de incidentes, afirmaciones contundentes de imposibilidad o mejora enorme de seguridad sin una causa raíz reproducida, propagación incompleta de información adversa, presentaciones de acción correctiva que carecían del detalle de software y planes de prueba solicitados, y demora en convertir las recomendaciones de protección de hardware independiente en barreras instaladas. El registro de la FDA citado en la investigación muestra solicitudes repetidas de documentación, análisis de interacción, mensajes significativos y pruebas de instalación.

La falla de respuesta también debe separarse de la falla de recuperación. La respuesta fue lenta cuando las máquinas continuaron en uso clínico rutinario mientras el peligro seguía siendo incierto. La recuperación se convirtió en un desafío separado cuando se requirieron múltiples revisiones del CAP y las modificaciones identificaron nuevos subsistemas no cubiertos. Una reparación que no puede instalarse, probarse y verificarse de manera consistente en cada unidad no es aún una flota recuperada.

El impacto no puede reducirse a una dosis o un recuento de muertes

El impacto confirmado es severo. Seis accidentes conocidos involucraron sobredosis masivas. Los pacientes experimentaron lesiones por radiación, discapacidad, dolor prolongado y muertes en asociación temporal y, en algunos casos, médicamente documentada con las exposiciones. Dos pacientes de Tyler murieron por lesiones relacionadas con la sobredosis según la investigación. El segundo paciente de Yakima tenía cáncer terminal antes del accidente y murió después de sufrir complicaciones de la sobredosis; los sobrevivientes alegaron que la exposición acortó la vida y aumentó el sufrimiento, y la demanda se resolvió.

El paciente de Hamilton murió de un cáncer agresivo, mientras que el registro de autopsia identificó daño grave por radiación que de otro modo habría requerido un tratamiento importante.

Las afirmaciones de dosis exactas deben permanecer calificadas. Las cámaras de ionización de la máquina se saturaron, diferentes instalaciones reprodujeron diferentes salidas, las tasas de pulso variaron y algunas sesiones carecían de datos impresos. Las simulaciones posteriores al evento produjeron rangos en lugar de mediciones directas. Por lo tanto, el artículo no convierte cada estimación en una dosis medida del paciente ni compara la exposición local con la letalidad de todo el cuerpo como si los efectos biológicos fueran equivalentes.

El impacto operativo se extendió más allá de los seis pacientes. Once instalaciones dependían de un dispositivo cuyo estado seguro no podía establecerse a partir de su propia pantalla. Las clínicas tuvieron que suspender o restringir el tratamiento, inspeccionar máquinas, cambiar flujos de trabajo, unirse a reuniones de usuarios y gestionar pacientes que necesitaban terapia continua. Los operadores y físicos llevaron la carga de reconstruir el comportamiento sin acceso al código fuente ni información completa del incidente.

Los reguladores y usuarios pasaron más de dos años desde el descubrimiento de Tyler hasta el análisis de seguridad final.

El impacto legal y financiero es menos medible. La investigación fuente registra varias demandas y acuerdos extrajudiciales, pero el registro público primario revisado aquí no proporciona una sentencia de méritos que asigne responsabilidad, términos completos de acuerdo, pagos de aseguradoras o daños agregados. Un acuerdo confirma la resolución de la disputa, no la negligencia adjudicada ni una admisión. Sería engañoso convertir los resultados privados en un costo corporativo preciso o una conclusión legal.

El impacto sistémico más amplio fue un cambio en qué evidencia requería la seguridad de los dispositivos médicos. La ley posterior fortaleció la notificación de eventos adversos y la autoridad de retirada. La regulación posterior añadió controles de diseño. La orientación moderna exige documentación de software basada en riesgos, validación y trabajo de factores humanos. Therac-25 es relevante para esos controles, pero la relevancia no es prueba de que una sola serie de accidentes produjera todo el régimen moderno.

La acción correctiva pasó de una solución alternativa de tecla a barreras independientes

La primera instrucción posterior a Tyler de AECL se centró en deshabilitar la tecla de cursor arriba, incluyendo prevenir físicamente su uso, para que los operadores reingresaran toda la prescripción. La FDA rechazó ese aviso como inadecuado porque no explicaba el defecto o peligro y su tono no comunicaba urgencia. Esta es una distinción de responsabilidad entre una solución alternativa operativa y una reparación de seguridad. Una solución alternativa puede reducir un desencadenante mientras deja a los usuarios incapaces de juzgar el riesgo residual.

El primer plan formal de acción correctiva en junio de 1986 fue más allá. Propuso corregir el comportamiento de Tyler, cambiar el monitoreo de pulso, convertir muchos mal funcionamientos de pausas a suspensiones, añadir un circuito para inhibir el modulador después de un pulso excesivo, limitar las teclas de edición y revisar los manuales. La FDA estuvo de acuerdo con la dirección pero solicitó repetidamente más documentación de software, análisis de interacción y un plan de pruebas detallado.

AECL inicialmente respondió que no existía un plan y un informe de pruebas de software único porque el hardware y el software se habían ejercitado durante años.

Elregistro regulatorio y de respuesta del usuariomuestra por qué el CAP requirió cinco revisiones. La FDA se opuso a mantener el comportamiento de pausa para fallas de tasa de dosis e inclinación del haz, requirió mensajes significativos y quería pruebas rigurosas de cada modificación de software futura. Después del segundo accidente de Yakima, la agencia concluyó que el software solo no podía garantizar una operación segura. Las autoridades canadienses alcanzaron una posición paralela. Se desaconsejó el uso rutinario mientras se desarrollaban cambios permanentes.

La participación del usuario mejoró materialmente el plan. En una reunión de marzo de 1987, usuarios, AECL, la FDA, reguladores canadienses y representantes técnicos revisaron los seis accidentes. Los usuarios solicitaron evaluación de software independiente, acceso al código fuente, una pista de auditoría impresa y modificaciones de hardware adicionales. El registro dice que no se proporcionó el código fuente y se citaron restricciones de memoria en contra de una opción de auditoría.

Esas decisiones dejaron algunas brechas de transparencia, pero la reunión creó un mecanismo directo para probar la propuesta de AECL contra la experiencia clínica.

El CAP final en julio de 1987 cambió la arquitectura y operación. Las interrupciones de dosimetría se convirtieron en suspensiones en lugar de pausas reanudables. Los operadores tenían que reingresar parámetros. Se añadió protección de apagado de pulso único, incluyendo protección de hardware descrita anteriormente en el proceso. Se añadieron enclavamientos de posición del plato giratorio e imán de curvatura. La activación del haz se bloqueaba cuando el plato giratorio estaba en luz de campo o en una posición intermedia.

Los códigos de mal funcionamiento crípticos se reemplazaron con mensajes significativos, se restringió el comportamiento de edición, se corrigieron los defectos conocidos de Tyler y Yakima, se revisaron los manuales y numerosos otros cambios de software abordaron fallas encontradas durante la revisión.

La aprobación de la FDA estaba condicionada a los resultados finales de las pruebas, un análisis de seguridad independiente, documentación revisada y finalización de la instalación. El análisis de seguridad posterior identificó subsistemas críticos adicionales no cubiertos completamente por una revisión anterior del CAP, demostrando el valor de revisar el peligro más allá de los errores reproducidos. Sus recomendaciones añadieron protección independiente del ordenador para escaneo y selección de energía y continuaron el mantenimiento del software en versiones posteriores.

El registro de retirada de la GAO clasifica la acción de EE. UU. como Clase I, la categoría reservada para una probabilidad razonable de consecuencias adversas graves para la salud o muerte. Fecha la retirada el 3 de junio de 1987, mientras que la narrativa muestra un proceso que se extiende antes y después de esa fecha administrativa. Una fecha de retirada, aprobación del CAP, instalación e informe final de análisis de seguridad son hitos diferentes. Tratar cualquiera como el instante de la reparación oscurecería cuánto tiempo tomó ensamblar la garantía.

La evidencia de reparación es real, pero un lector moderno no puede reproducir el caso de seguridad completo

La evidencia de reparación más sólida es el cambio de dependencia común del software a protección física independiente. Un apagado de hardware después de un pulso excesivo y comprobaciones independientes del estado del plato giratorio, escaneo y selección de energía pueden contener defectos de software que no han sido descubiertos. Las suspensiones evitan que un operador autorice repetidamente una condición de dosimetría no resuelta. Mejores mensajes mejoran la detección. Las pruebas de instalación y los protocolos de modificación futura reducen la probabilidad de que un diseño correcto se copie o configure incorrectamente.

El desafío regulatorio es otra forma de evidencia. La FDA no aceptó el primer aviso al usuario ni el primer CAP como suficientes. Solicitó especificaciones, planes de prueba, análisis de interacción, diagramas más claros, pruebas de modificación futura y verificación de instalación. Identificó datos de prueba contradictorios y requirió un análisis de seguridad independiente. Las autoridades canadienses y los usuarios presionaron por barreras de hardware. Este registro es más fuerte que un anuncio del fabricante por sí solo.

El registro público, sin embargo, se queda corto de un paquete de garantía reproducible completo. No expone el árbol fuente completo y el historial de versiones, todos los requisitos previos y posteriores a la modificación, cada entrada de prueba y resultado esperado, cobertura de estados de sincronización y desbordamiento, análisis de independencia para cada enclavamiento, registros de instalación para cada unidad, registro de defectos no resueltos, o datos de campo a largo plazo por versión de software y hardware.

El resumen final del análisis en sí mismo dice que la inspección no podía proporcionar alta confianza para algunas funciones complejas.

La ausencia de otra catástrofe del Therac-25 documentada públicamente después de la modernización es consistente con una reparación efectiva, pero no es una prueba controlada. La flota era pequeña, el uso cambió, las máquinas envejecieron y la notificación pública era imperfecta. La conclusión defendible es que el CAP fortaleció materialmente el sistema y bloqueó específicamente las rutas catastróficas conocidas. La afirmación más fuerte de que cada ruta de software peligrosa fue encontrada y eliminada no es necesaria ni está respaldada.

Las leyes y estándares posteriores muestran qué evidencia faltaba, no qué era legalmente requerido en 1985

Estados Unidos no tenía el marco de control de diseño posterior cuando el Therac-25 entró en uso. La ley de 1990 expandió los mecanismos de notificación y retirada. Laregla final del Sistema de Calidad de la FDA de 1996, efectiva en 1997, añadió controles de diseño de preproducción después de que estudios encontraran deficiencias de diseño detrás de una parte sustancial de retiradas y fallos relacionados con software. Esas reglas posteriores no deben presentarse como requisitos que AECL violó antes de que existieran. Son un punto de referencia para identificar las categorías de control que faltaban en el registro histórico.

LosPrincipios Generales de Validación de Softwarede la FDA describieron más tarde la validación como evidencia del ciclo de vida en lugar de un evento de prueba final. Laguía actual de la agencia para presentaciones previas a la comercialización de funciones de software de dispositivospide documentación proporcional al riesgo, incluyendo arquitectura, requisitos, análisis de peligros, verificación y validación, historial de revisiones y anomalías no resueltas. El propósito de citar estos documentos es comparativo: hacen visibles los artefactos que un revisor actual esperaría pero que no puede encontrar en el registro sobreviviente del Therac-25.

Las expectativas modernas de factores humanos también abordan la ruta de la interfaz. Laguía de factores humanos y usabilidadde la FDA trata a los usuarios previstos, entornos de uso, tareas críticas y peligros relacionados con el uso como entradas de diseño. Bajo ese enfoque, la corrección rápida por un operador experimentado, las pausas frecuentes, los mensajes ambiguos y un comando de continuar de una tecla se probarían como parte del problema de seguridad, no se descartarían como comportamiento fuera del control de ingeniería.

La FDA reconoceIEC 62304como un estándar de ciclo de vida de software de dispositivos médicos. Su marco de proceso no garantiza software seguro y no valida un dispositivo final por sí mismo. Sí requiere un proceso de desarrollo y mantenimiento mantenido que haga los requisitos, controles de riesgo, configuración, resolución de problemas e impacto de cambios más auditables. Eso es directamente relevante para el código heredado a través de generaciones Therac y posteriormente parcheado a través de varias revisiones del CAP.

A partir de la fecha de publicación del artículo, elReglamento del Sistema de Gestión de Calidadde la FDA ha sido efectivo desde el 2 de febrero de 2026 e incorpora ISO 13485:2016 por referencia. Da a los reguladores actuales un marco más amplio de gestión de calidad e inspección, incluyendo diseño y desarrollo, investigación de quejas y registros. Es evidencia de la línea base de responsabilidad actual, no prueba de lo que una inspección habría encontrado en AECL cuatro décadas antes.

El marco de notificación también es ahora más explícito. Elhistorial de la regulación MDRde la FDA traza la expansión posterior a 1990 a las instalaciones de usuario, y suvisión general de notificaciónactual distingue los deberes del fabricante, importador e instalación. Mejores reglas aumentan la probabilidad de que la anomalía de un hospital se convierta en una señal de producto. Aún dependen de que el personal reconozca que un evento puede estar relacionado con el dispositivo y preserve suficiente evidencia para investigarlo.

La responsabilidad no puede inferirse solo del control técnico

El control práctico es una forma disciplinada de investigar la responsabilidad, pero no es un sustituto de la aplicación de la ley por parte de un tribunal. La autoridad de diseño de AECL, el conocimiento y el papel de acción correctiva respaldan una fuerte responsabilidad de ingeniería. Los poderes de operación y notificación de los hospitales respaldan el examen de las decisiones locales. La autoridad de los reguladores respalda el escrutinio de la oportunidad y suficiencia. Ninguna de esas observaciones establece los elementos de negligencia, causalidad, defecto del producto, violación legal o daños en una jurisdicción y caso particular.

La investigación original se basó en declaraciones y reportó que varias demandas se resolvieron extrajudicialmente. Un acuerdo puede reflejar costos de litigio, incertidumbre, seguros, confidencialidad, compasión o asignación de riesgos. Sin términos públicos y conclusiones adjudicadas, no puede establecer una admisión o pérdida agregada. No aparece ningún fallo de méritos accesible públicamente que resuelva las principales reclamaciones por lesiones del Therac-25 en el registro primario utilizado aquí.

La identidad corporativa también requiere cuidado. AECL era una corporación de la Corona canadiense, y su negocio médico cambió más tarde de nombre y propiedad. El sujeto manifiesto es Atomic Energy of Canada Limited porque AECL controló el producto durante el período de accidentes y CAP. Las entidades posteriores no deberían heredar automáticamente el conocimiento fáctico o la responsabilidad legal sin transacciones y registros corporativos que establezcan esa conexión.

La responsabilidad sigue siendo posible sin reclamar en exceso la responsabilidad legal. El artículo puede identificar quién podía prevenir, detectar, limitar y reparar un peligro; comparar esos poderes con las acciones reales; y preservar la incertidumbre sobre los resultados legales. Eso produce un resultado más útil que declarar culpabilidad a partir de un defecto de software o tratar los acuerdos confidenciales como exoneración.

Los contrafactuales anteriores son más útiles que una fantasía de código perfecto

El contrafactual más débil es que mejores programadores habrían escrito código impecable. Es no comprobable y establece el estándar equivocado. El software concurrente en tiempo real puede contener defectos a pesar de un trabajo competente. Un caso de seguridad debe asumir que algunos defectos sobreviven y evitar que uno solo alcance energía catastrófica.

El contrafactual más fuerte comienza en la arquitectura. Si el Therac-25 hubiera conservado enclavamientos independientes de escaneo y plato giratorio comparables a las protecciones del Therac-20, el defecto de edición compartido podría haber causado un apagado en lugar de una exposición. Esto está respaldado por el descubrimiento posterior de la misma clase de defecto en el Therac-20 sin lesión al paciente y por las barreras independientes seleccionadas en el CAP final. No prueba que cada uno de los seis accidentes se habría prevenido, porque las rutas exactas de los primeros tres son desconocidas.

Un segundo contrafactual comienza después de Kennestone. Si la pregunta del físico, la lesión del paciente y el aviso de demanda hubieran entrado en un registro de peligros formal compartido con todos los usuarios y reguladores, las instalaciones posteriores habrían tenido una razón para desconfiar de una aparente subdosis y afirmaciones de imposibilidad. La máquina podría haberse restringido mientras se probaban el escaneo y el comportamiento del enclavamiento bajo estados de caso peor.

El registro no puede probar que la evidencia disponible en junio de 1985 fuera suficiente para una retirada definitiva, pero era suficiente para una investigación conservadora y documentada.

Un tercero comienza después de Hamilton. Funcionarios canadienses y un consultor independiente recomendaron un enclavamiento de posición independiente y un manejo no reanudable de fallos de tasa de dosis. Instalar esos cambios en toda la flota antes de reanudar el uso rutinario habría abordado la clase de configuración insegura más ampliamente que modificar la lógica del microinterruptor. El CAP posterior adoptó controles estrechamente relacionados.

Por lo tanto, es razonable inferir que una implementación anterior podría haber reducido el riesgo, evitando al mismo tiempo la afirmación de que ciertamente habría bloqueado un mecanismo desconocido de Kennestone o del primer Yakima.

Un cuarto comienza en la primera detección de Tyler. Una regla de que cualquier contradicción grave de dosis requiere suspensión del tratamiento, evaluación del paciente, estado de la máquina preservado y escalada al fabricante-regulador habría prevenido la continuación inmediata de una tecla. El audio y video funcionales habrían mejorado la detección humana. Ninguno de los dos controles arregla el software, pero ambos limitan la exposición repetida y mejoran la evidencia.

Después del primer evento, mantener la máquina fuera de servicio clínico hasta que se reprodujera el Mal funcionamiento 54 probablemente habría prevenido la segunda exposición de Tyler en esa unidad.

Un quinto concierne a las pruebas. Replicar la edición a velocidad experta, aleatorizar la sincronización de tareas, forzar el desbordamiento de bytes, inyectar estado compartido obsoleto y contradictorio, saturar las entradas de medición y verificar la configuración física final contra la prescripción habría tenido una mejor oportunidad de exponer las rutas conocidas que el uso repetido ordinario. La inferencia está respaldada por cómo el físico de Tyler reprodujo el defecto y cómo se explicó finalmente Yakima. La evidencia pública no puede mostrar qué técnica habría encontrado qué defecto antes del lanzamiento.

Hechos confirmados, inferencia respaldada e incógnitas públicas

Los hechos confirmados incluyen los seis accidentes conocidos; el mayor papel de seguridad asignado al software del Therac-25; la ausencia de algunas protecciones independientes conservadas en máquinas anteriores; la exclusión de errores de software residuales en el análisis de 1983; la ruta de edición dependiente de sincronización de Tyler; la ruta de desbordamiento de contador de Yakima; el comportamiento de interfaz engañoso o críptico; la comunicación fragmentada de incidentes; el hallazgo de defecto de la FDA y las objeciones repetidas al CAP; las demandas canadienses de cambio; la retirada de Clase I en EE.

UU.; y la acción correctiva final que añadió protección de hardware independiente, cambios de software, comportamiento de suspensión más fuerte y documentación revisada.

También está confirmado que el registro de la FDA no aceptó varias garantías de AECL al pie de la letra. La agencia rechazó un aviso inicial al usuario inadecuado, solicitó más detalle y pruebas, cuestionó datos que no respaldaban la corrección reclamada, requirió cambios más allá del defecto de Tyler y condicionó la aprobación del CAP a resultados finales y análisis independiente. Los usuarios y funcionarios canadienses contribuyeron al conjunto de control final. Por lo tanto, la reparación fue negociada y probada a través de varias instituciones, no entregada como un parche incontestado.

La inferencia respaldada comienza donde esos hechos interactúan. Las barreras independientes anteriores probablemente habrían prevenido al menos algunas exposiciones catastróficas porque el mismo tipo de inconsistencia de software fue contenida por hardware en el Therac-20 y porque el CAP final seleccionó esas barreras. Un registro de peligros compartido y una advertencia rápida entre sitios probablemente habrían acelerado el reconocimiento porque la creencia de cada instalación en la imposibilidad dependía en parte de la falta de información del incidente.

Pruebas integradas más realistas podrían haber expuesto las condiciones de sincronización y desbordamiento. Estas conclusiones son efectos de control probables, no historia alternativa reconstruida.

Varios hechos son disputados o inciertos. La oportunidad e integridad del conocimiento temprano de AECL difirieron entre cuentas de la empresa, el hospital y el litigio. El mecanismo de Hamilton nunca fue firmemente reproducido. Los primeros tres accidentes no pueden asignarse a un defecto de software particular a partir de la evidencia pública. Las dosis exactas de los pacientes varían según la reconstrucción y las condiciones de la máquina. Para algunos pacientes, el cáncer y la lesión por radiación afectaron ambos los resultados, por lo que un simple recuento de muertes no puede expresar la causalidad médica.

El razonamiento privado detrás de las decisiones de diseño y la asignación de autoridad corporativa entre individuos nombrados no son públicos.

Las incógnitas legales y financieras son sustanciales. Los montos y términos de los acuerdos no están disponibles en el registro primario central. No hay una decisión de méritos pública que asigne responsabilidad entre AECL, hospitales, médicos u organizaciones de servicio. La cobertura de seguro, indemnizaciones, gastos legales y totales de compensación no están disponibles. La ausencia de esos registros no significa que no hubo costo o responsabilidad; impide afirmaciones precisas.

También permanecen incógnitas de reparación. Las fuentes públicas no proporcionan cada resultado de prueba del CAP, todo el documento de trabajo de revisión independiente, todos los registros de instalación de unidades, historial de control de código fuente o tasa de incidentes longitudinal. No prueban cómo se comportó cada máquina modificada hasta su retiro. El marco regulatorio y de estándares posterior demuestra lo que contendría un paquete de evidencia actual, pero no puede fabricar retroactivamente artefactos faltantes.

La evidencia que podría alterar la conclusión incluye un registro de peligros completo de AECL, historial de código y cambios, requisitos originales y análisis de seguridad, registros de revisión interna, todos los registros de servicio de instalaciones, correspondencia regulatoria no reproducida en la investigación, datos completos de prueba del CAP, resultados de aceptación de instalación y registros de acuerdos desclasificados o judiciales. Dicho material podría refinar quién sabía qué y cuándo.

No cambiaría el hecho físico básico de que las barreras independientes estaban ausentes antes de los accidentes y se añadieron durante la reparación, pero podría cambiar materialmente la asignación y oportunidad de la responsabilidad organizativa.

Una prueba de responsabilidad duradera para la seguridad médica dependiente de software

La primera prueba es la propiedad del peligro. Para cada estado de energía peligrosa, ¿hay un propietario organizativo nombrado con autoridad sobre requisitos, arquitectura, validación, monitoreo de campo y acción correctiva? ¿Mantiene ese propietario el peligro a través de generaciones de productos y componentes reutilizados? Un peligro que se divide entre equipos de hardware, software y clínicos sin un punto de integración responsable probablemente caerá entre ellos.

La segunda prueba es la independencia de la barrera. ¿Puede un solo defecto de software, variable compartida obsoleta, configuración corrupta o comando erróneo derrotar tanto la acción de control como su verificación? Una segunda rutina de software en el mismo procesador, leyendo el mismo estado y usando las mismas suposiciones, puede ser redundante en código pero no independiente en seguridad. La energía catastrófica requiere una barrera cuya falla no sea causada por la misma ruta: detección de posición física, corte cableado, monitoreo independiente u otro mecanismo demostrablemente separado.

La tercera prueba es el control de suposiciones a través de la reutilización. ¿Cada rutina reutilizada lleva suposiciones documentadas sobre enclavamientos de hardware, sincronización, rango numérico, comportamiento del planificador, validez del sensor y flujo de trabajo del operador? ¿Se revalidan esas suposiciones cuando el software se mueve a un nuevo producto? Un largo historial operativo en un predecesor protegido no es evidencia de campo para un sucesor que elimina la protección.

La cuarta prueba es la evidencia de software basada en peligros. ¿Comienzan los requisitos con estados físicos inseguros y restricciones requeridas, o con características y comportamiento esperado? ¿Pueden los revisores rastrear cada peligro hasta los requisitos, arquitectura, código, pruebas, riesgo residual y monitoreo de campo? ¿Se evalúan las anomalías no resueltas por la peor consecuencia creíble en lugar de solo la frecuencia? Pasar tratamientos ordinarios no ejercita combinaciones de estado raras.

La quinta prueba es la prueba de interacción realista. ¿Se observa a usuarios expertos realizando correcciones comunes a máxima velocidad? ¿Se inyectan deliberadamente sincronización de interrupción, ediciones rápidas, pausas repetidas, límites de desbordamiento, prioridad de tareas y valores de sensores contradictorios? ¿Incluye la prueba al operador más rápido y experimentado, no solo una secuencia lenta guionizada? La eficiencia prevista debe tratarse como parte del entorno operativo.

La sexta prueba es la autoridad conservadora hombre-máquina. ¿Comunica la pantalla el peligro en un lenguaje que el operador pueda usar? ¿Una contradicción grave por defecto suspende? ¿Se bloquea el reinicio hasta que el estado se restablece y verifica de forma independiente? ¿Se miden y reducen las alarmas molestas frecuentes antes de que normalicen la continuación insegura? Un sistema de alarma que enseña a los usuarios a ignorarlo ha consumido su propio margen de seguridad.

La séptima prueba es la medición veraz. ¿Pueden los monitores representar la peor salida creíble sin saturación o respaldo engañoso? Cuando las indicaciones independientes entran en conflicto, ¿el sistema preserva ambas y asume el estado más peligroso? ¿Se retienen las lecturas brutas, los límites de rango y la validez del sensor? Un cero mostrado es peligroso cuando significa que el instrumento excedió su capacidad en lugar de que no ocurrió nada.

La octava prueba es un registro de incidentes auditable. ¿Cada tratamiento retiene prescripción, ediciones, versiones de software y configuración, estados de enclavamiento físico, comandos de haz, lecturas de monitor, alarmas, reinicios y sincronización de reloj? ¿Puede un físico reconstruir la secuencia sin depender de la memoria? ¿Está el registro protegido contra desactivación rutinaria y dimensionado para la vida del producto? La investigación se convierte en especulación cuando el sistema descarta el estado que importa.

La novena prueba es la escalada entre sitios. ¿Puede cualquier instalación reportar un evento grave sospechoso sin primero probar que el dispositivo lo causó? ¿Se agregan los informes por producto y peligro a través de países, organizaciones de servicio y departamentos corporativos? ¿Reciben los usuarios advertencias fácticas rápidas que distingan mecanismos confirmados de riesgo no resuelto? Un fabricante no debería esperar lesiones idénticas cuando el resultado común es catastrófico.

La décima prueba es la amplitud de la acción correctiva. ¿La respuesta arregla solo el desencadenante reproducido, o identifica todos los caminos hacia el estado peligroso? ¿Se etiquetan las soluciones alternativas provisionales como tales, con riesgo residual y vencimiento? ¿La reparación final incluye análisis de impacto de cambios, pruebas de regresión, revisión independiente, verificación de instalación y monitoreo posterior a la comercialización? Una restricción de tecla puede ganar tiempo; no puede cerrar un caso de seguridad.

La undécima prueba es la evidencia lista para el regulador. ¿Puede el fabricante proporcionar requisitos, especificaciones, planes de prueba, resultados, registros de anomalías y datos de instalación cuando se soliciten, o debe reconstruirlos después de una lesión? ¿Tienen los reguladores autoridad y una red de notificación que les permita actuar antes de que el fabricante tenga certeza perfecta? ¿La aprobación especifica condiciones y prueba de finalización? La garantía de seguridad se debilita cuando la documentación sigue a la reparación en lugar de gobernarla.

La duodécima prueba es la verificación duradera. ¿Se desafían periódicamente las barreras independientes bajo condiciones de falla realistas? ¿Se evalúan los cambios de software contra los peligros originales, incluso después de cambios de personal y propiedad? ¿Se realiza un seguimiento de las alarmas molestas, anomalías de campo y cuasi accidentes? ¿Publica la organización suficiente evidencia agregada para que hospitales y reguladores sepan que el control sigue integrado? La ausencia de catástrofe reportada no equivale a prueba de rendimiento.

Por lo tanto, el Therac-25 no debe reducirse a una moraleja sobre codificación descuidada u operadores desatentos. Fue un sistema de control en el que la autoridad del software se expandió mientras que la protección independiente, la observabilidad y el aprendizaje institucional no se expandieron con ella. Los defectos conocidos hicieron visible ese desequilibrio. Los mecanismos anteriores no probados y los registros incompletos muestran por qué la responsabilidad no puede depender de encontrar cada error después del daño.

La reparación se movió en la dirección correcta porque cambió quién y qué podía detener el haz. Enclavamientos independientes, apagado de un pulso, fallas de seguridad no reanudables, mensajes más claros, análisis más amplio y acción correctiva probada por el regulador hicieron que el sistema dependiera menos del código perfecto y la interpretación perfecta. La lección restante es probatoria: un fabricante crítico para la seguridad debe poder mostrar, antes del despliegue y después de cada señal grave, que ningún camino oculto único puede convertir el trabajo clínico ordinario en exposición catastrófica.