Seis superdosagens maciças: como o Therac-25 deixou nas mãos do software a segurança que antes vinha do hardware

Em 21 de março de 1986, no East Texas Cancer Center, em Tyler, um paciente estava deitado de bruços na mesa de tratamento para sua nona sessão de radioterapia. Fora da sala blindada, a operadora digitou a prescrição, percebeu que tinha inserido “x” de raio X em vez de “e” de elétrons, subiu o cursor e corrigiu. A tela mostrava “beam ready”. Ela apertou “B”.

A máquina parou e exibiu “Malfunction 54”. O monitor de dose indicava uma subdosagem. Dentro da sala, o paciente sentiu algo parecido com um choque elétrico. Reconstruções posteriores sugeriram que ele pode ter recebido entre 16.500 e 25.000 rads em menos de um segundo. Uma dose típica de uma única sessão ficava em torno de 200 rads.

A máquina era um Therac-25. Entre junho de 1985 e janeiro de 1987, ela esteve envolvida em seis superdosagens maciças conhecidas nos Estados Unidos e no Canadá. Nancy Leveson e Clark Turner, que mais tarde reconstruíram os acidentes, os classificaram como a pior série de acidentes com radiação na história dos aceleradores médicos até então.

Linha do tempo

Junho de 1985, Marietta, Geórgia: um paciente sofre queimaduras graves. O físico do hospital pergunta ao fabricante, a Atomic Energy of Canada Limited (AECL), se a máquina poderia ser a responsável. A AECL diz que não, e o acidente nunca é investigado a fundo.

Julho de 1985, Hamilton, Ontário: uma segunda superdosagem. A AECL culpa um microinterruptor do prato giratório, troca a peça e informa aos clientes que sua análise mostra uma melhora de segurança de pelo menos cinco ordens de grandeza.

Dezembro de 1985, Yakima, Washington: um paciente desenvolve uma queimadura em listras. Em fevereiro de 1986, a AECL responde por escrito que o dano não poderia ter sido causado pela máquina nem por erro do operador.

21 de março de 1986, Tyler, Texas: a superdosagem do “Malfunction 54”. Os engenheiros da AECL não conseguem reproduzi-la e sugerem um problema elétrico. A máquina volta a operar em 7 de abril.

11 de abril de 1986, Tyler: mesma máquina, mesma operadora, mesma mensagem, outra superdosagem.

17 de janeiro de 1987, Yakima: uma sexta superdosagem, causada por um bug de software diferente.

Fevereiro de 1987: os órgãos reguladores dos Estados Unidos e do Canadá orientam os usuários a suspender os tratamentos de rotina até que a máquina seja corrigida.

A decisão de projeto por trás de tudo

O Therac-25 tinha dois irmãos mais velhos, o Therac-6 e o Therac-20. Nessas máquinas, o computador era uma conveniência acrescentada a um hardware que conseguia funcionar com segurança por conta própria. Elas tinham intertravamentos elétricos e mecânicos independentes.

O Therac-25 foi projetado desde o início para ser controlado por computador. Segundo Leveson e Turner, a AECL decidiu não duplicar todos os mecanismos de segurança de hardware existentes e passou a depender do software. Parte desse software foi reaproveitada do Therac-6, e algumas rotinas vieram do Therac-20.

Essa escolha pesa no que aconteceu depois. O software havia sido escrito em grande parte por uma única pessoa, em linguagem assembly do PDP-11, com pouca documentação. Ele executava várias tarefas ao mesmo tempo, que compartilhavam variáveis sem sincronização adequada.

Causa raiz 1: a janela de oito segundos

Depois do segundo acidente em Tyler, o físico do hospital, Fritz Hager, trabalhou com a operadora para recriar exatamente o que ela havia feito. Eles descobriram que o gatilho era a velocidade. Se um operador experiente editasse a prescrição rápido o bastante, o erro aparecia.

O mecanismo, como a AECL o descreveu depois à FDA, funcionava assim. Quando o operador terminava de inserir os dados, uma rotina começava a ajustar os ímãs de deflexão, o que levava cerca de oito segundos. Nesse intervalo, uma sub-rotina deveria verificar se o operador tinha editado algo. Mas uma flag era zerada após a primeira passagem, e as passagens seguintes deixavam de procurar edições.

Se o operador mudasse o modo de raio X para elétrons e levasse o cursor de volta à parte de baixo da tela dentro desses oito segundos, a tela mostrava a nova configuração. A máquina não a aplicava por completo. Ela podia disparar um feixe de alta potência destinado ao modo de raio X sem que o alvo de raio X e o equipamento de conformação do feixe estivessem no lugar.

Uma folha na lateral da máquina dizia que “Malfunction 54” era um erro de “dose input 2”. Nada que estivesse ao alcance dos operadores explicava o que isso significava.

Causa raiz 2: um contador que voltava a zero

O acidente de Yakima em 1987 teve outra causa. Durante a configuração, uma variável de um byte chamada Class3 era incrementada a cada passagem por uma rotina de teste. Um valor diferente de zero significava “verificar a posição do colimador antes de permitir o tratamento”.

Um byte só consegue contar até 255. A cada 256ª passagem, ele voltava a zero, e a verificação era pulada. Se o operador apertasse “set” exatamente nesse momento, a máquina podia ligar o feixe com o prato giratório na posição errada. A correção da AECL foi simples: atribuir à variável um valor fixo diferente de zero em vez de incrementá-la.

Por que ninguém percebeu

Nada disso exigiu más intenções. Bastou que várias suposições aparentemente razoáveis se alinhassem.

A análise de segurança da AECL de 1983 tratava, na prática, o software como confiável e se concentrava em falhas de hardware. As mensagens de erro eram enigmáticas, e a máquina parava com tanta frequência por motivos inofensivos que os operadores aprenderam a apertar “P” para continuar. Um operador declarou em depoimento que não era nada fora do comum algo parar a máquina.

O sinal mais claro veio do modelo mais antigo. Depois dos acidentes de Tyler, um físico da Universidade de Chicago descobriu que o Therac-20 tinha um erro de software semelhante. Naquela máquina, ele só queimava fusíveis, porque os intertravamentos de hardware interrompiam o feixe. Os fusíveis vinham queimando havia anos. O hardware tinha escondido o bug.

O custo

Leveson e Turner registram que pacientes morreram de complicações das superdosagens e que outros sofreram lesões graves, incluindo paralisia e a perda de uma mama. As máquinas foram retiradas do uso de rotina no início de 1987. O plano corretivo final da AECL, emitido em julho de 1987, acrescentou proteção de hardware independente, como um circuito de desligamento por pulso único e o monitoramento do prato giratório, além de mais de vinte alterações no software.

O que teria detectado o problema

• Intertravamentos de hardware independentes que interrompam o feixe, não importa o que o software acredite.
• Tratar código reaproveitado como código novo quando ele passa para um sistema com outras premissas de segurança.
• Sincronização adequada para estado compartilhado entre tarefas concorrentes.
• Mensagens de erro que digam aos operadores quão perigosa é uma falha, e paradas de segurança que não possam ser retomadas com uma única tecla.
• Um processo que investigue cada lesão relatada como uma possível falha do sistema.

Leveson e Turner alertaram contra ler o Therac-25 como a história de um único bug. Concentrar-se em bugs específicos de software, escreveram, não é o caminho para um sistema seguro. A pergunta a fazer sobre os seus próprios sistemas é mais afiada: se o software estiver errado, o que mais continua de pé entre o erro e a pessoa do outro lado?

Fontes

• N. G. Leveson e C. S. Turner, “An Investigation of the Therac-25 Accidents”, IEEE Computer 26(7), julho de 1993
• N. G. Leveson, “The Therac-25: 30 Years Later”, IEEE Computer 50(11), novembro de 2017 (MIT DSpace)
• Ethics Unwrapped, McCombs School of Business, University of Texas at Austin: estudo de caso do Therac-25
• The Boston Globe, 20 de junho de 1986: reportagem sobre as superdosagens do Therac-25 (reprodução)
• Imagem de destaque: terminal DEC VT100, o modelo de terminal usado como console do operador do Therac-25 (ilustrativa, não é um console real do Therac-25). Jason Scott, via Wikimedia Commons, CC BY 2.0