Análise Multidimensional do Caso Therac-25: Engenharia de Software, Ética Profissional e Segurança de Sistemas Críticos em Ambientes de Saúde
Análise Multidimensional do Caso Therac-25: Engenharia de Software, Ética Profissional e Segurança de Sistemas Críticos em Ambientes de Saúde
A introdução de sistemas computacionais complexos em dispositivos médicos durante as décadas de 1970 e 1980 representou um avanço sem precedentes na precisão e eficiência de tratamentos oncológicos. Entretanto, esse período também testemunhou um dos capítulos mais sombrios da história da tecnologia: os acidentes com o acelerador linear Therac-25.1 Entre 1985 e 1987, esta máquina foi responsável por pelo menos seis incidentes graves de overdose de radiação, resultando em mortes e ferimentos devastadores.1 A análise deste caso transcende a simples identificação de erros de programação; ela revela uma falha sistêmica na gestão da qualidade, na compreensão da segurança de sistemas e na responsabilidade ética das organizações e indivíduos envolvidos.3 Este relatório examina exaustivamente a arquitetura técnica, as falhas de design, a cronologia dos acidentes e o legado regulatório deixado pelo Therac-25, fundamentado em repositórios acadêmicos internacionais e nacionais.
Evolução Tecnológica e a Transição para o Controle por Software
O desenvolvimento do Therac-25 pela Atomic Energy of Canada Limited (AECL) e pela empresa francesa CGR não ocorreu em um vácuo tecnológico, mas foi o resultado de uma trajetória de automação iniciada com os modelos Therac-6 e Therac-20.3 Para compreender a magnitude das falhas, é imperativo analisar a transição estrutural entre essas gerações de equipamentos.
O Legado dos Modelos Therac-6 e Therac-20
As máquinas predecessoras, Therac-6 e Therac-20, baseavam-se em designs de aceleradores mecânicos pré-existentes, como o Neptune e o Sagittaire.7 Nesses modelos, o computador servia inicialmente como uma camada de conveniência, automatizando tarefas de configuração que poderiam ser realizadas manualmente.1 A segurança não dependia exclusivamente do software, pois o hardware mantinha intertravamentos eletromecânicos independentes.7 Esses circuitos físicos garantiam que o feixe de radiação não fosse ativado a menos que todos os componentes, como o alvo de tungstênio e os ímãs de varredura, estivessem em suas posições corretas.1
A Arquitetura Stand-Alone do Therac-25
Diferente de seus antecessores, o Therac-25 foi projetado para tirar proveito total do controle computacional desde o início.1 A AECL adotou um design inovador de "passagem dupla" (double-pass), que permitia acelerar elétrons em um espaço mais compacto, reduzindo custos de fabricação e dimensões físicas do aparelho.7 A decisão crítica, no entanto, foi a remoção dos intertravamentos de hardware físicos, substituindo-os por verificações lógicas implementadas em software.2 Essa mudança partiu da premissa perigosa de que o software era inerentemente confiável e que a redundância de hardware era uma despesa desnecessária.1
A reutilização de módulos de código do Therac-20 no Therac-25 é frequentemente citada em teses nacionais como um erro clássico de engenharia de software.12 O código que funcionava com segurança no Therac-20 continha bugs latentes, mas estes nunca haviam causado acidentes porque o hardware físico impedia estados inseguros.3 Ao remover a proteção física no Therac-25, esses bugs tornaram-se críticos e fatais.13
Engenharia de Software e Concorrência no PDP-11
O coração computacional do Therac-25 era um minicomputador DEC PDP-11, programado quase inteiramente em linguagem Assembly.2 A escolha da linguagem Assembly, embora comum na época para sistemas de tempo real devido à restrição de recursos de hardware, introduzia uma camada de complexidade e dificuldade na verificação formal de segurança.2
O Sistema Operacional Real-Time e o Agendador de Tarefas
O software operava sob um executivo de tempo real proprietário que gerenciava várias tarefas simultâneas através de um agendador por interrupção.1 As tarefas principais incluíam:
Tarefa de Interface (Data Entry): Responsável por processar a entrada do operador no terminal e atualizar os parâmetros de tratamento na memória compartilhada.10
Tarefa de Controle de Hardware (Bending Magnet): Responsável por ler os parâmetros da memória e posicionar os ímãs e a mesa giratória.10
Tarefa de Monitoramento: Realizava verificações de consistência e ativava intertravamentos de software se detectasse anomalias.1
A falha fundamental residia na ausência de mecanismos de sincronização robustos, como semáforos ou seções críticas, para gerenciar o acesso às variáveis compartilhadas entre essas tarefas.11 Em ambientes acadêmicos brasileiros, esse cenário é frequentemente utilizado para ilustrar a importância da atomicidade em sistemas concorrentes.16
A Física do Feixe e a Mesa Giratória
Para entender as falhas, é necessário detalhar os dois modos principais de tratamento do Therac-25: o modo de elétrons (E-mode) e o modo de fótons ou raios-X (X-ray mode).10 No modo de elétrons, o acelerador gera um feixe de baixa energia que é espalhado por ímãs de varredura para atingir tumores superficiais.7 No modo de raios-X, o acelerador dispara elétrons com uma energia massiva de 25 contra um alvo de tungstênio, produzindo fótons para tumores profundos.1 Este feixe de alta energia é tão potente que requer um "achatador de feixe" (beam flattener) para tornar a dose uniforme e segura para o paciente.7
A mesa giratória (turntable) posicionava os componentes necessários no caminho do feixe. Havia três posições principais:
Varredura: Para o modo de elétrons.7
Alvo/Achatador: Para o modo de raios-X.7
Luz de Campo: Para o posicionamento inicial do paciente, sem emissão de radiação.7
O erro fatal ocorria quando o software permitia que o feixe de alta energia (25 , destinado a raios-X) fosse ativado enquanto a mesa giratória ainda estava na posição de varredura ou de luz de campo, sem o alvo de tungstênio para atenuar a radiação.10
Anatomia Crítica das Falhas: Condição de Corrida e Overflow
As investigações lideradas por Nancy Leveson, amplamente estudadas em cursos de graduação e pós-graduação no Brasil e no exterior, identificaram dois bugs de software principais que desencadearam os acidentes.1
A Condição de Corrida de Oito Segundos (Malfunction 54)
A "Malfunction 54" é o exemplo de condição de corrida mais citado na literatura de engenharia de software médico.2 Ela ocorria devido a uma falha na lógica de processamento da entrada do operador.11 Quando um operador entrava no console para definir um tratamento, o software iniciava uma rotina de 8 segundos para configurar os ímãs de curvatura.2
Se um operador experiente e rápido cometesse um erro inicial (como digitar "X" para raios-X) e usasse a tecla de correção ("Seta para Cima") para mudar para "E" (elétrons) dentro dessa janela de 8 segundos, o software de interface registrava a mudança, mas a tarefa de controle de hardware, que já havia passado pela fase de verificação de modo, não atualizava os parâmetros físicos.10 O resultado era a ativação do feixe de raios-X (alta intensidade) com a mesa giratória na posição de elétrons. O paciente recebia uma dose direta de elétrons de alta energia concentrada em uma área ínfima, causando queimaduras profundas e síndrome aguda de radiação.19
A Falha de Overflow e o Ciclo da Variável Class3
O segundo erro, responsável pelos acidentes em Yakima, envolvia o gerenciamento de uma variável de 8 bits (um byte) chamada Class3.4 Esta variável era incrementada a cada ciclo de uma rotina de verificação de consistência do hardware.11 A lógica do programa determinava que, se o valor de Class3 fosse diferente de zero, o sistema deveria impedir o disparo do feixe por razões de segurança.4
Entretanto, como a variável era limitada a um byte, ela podia armazenar valores de 0 a 255. Após atingir 255, o próximo incremento causava um "rollover" aritmético, retornando o valor para zero.10 Se o operador tentasse iniciar o tratamento precisamente no instante em que o overflow ocorria, o software interpretava o valor zero como "ausência de erro" e permitia o disparo do feixe, mesmo com o hardware em estado inconsistente.4
Cronologia Detalhada dos Incidentes e Respostas Institucionais
A série de acidentes demonstra uma falha não apenas tecnológica, mas de comunicação e reconhecimento de risco por parte da fabricante e dos órgãos reguladores.
Marietta e Hamilton: Os Primeiros Sinais Ignorados
Em 3 de junho de 1985, no Kennestone Regional Oncology Center em Marietta, Geórgia, uma paciente recebeu uma overdose massiva durante um tratamento para câncer de mama.21 Ela relatou sentir um "calor tremendo" e um choque elétrico. A AECL, ao ser consultada, negou que a máquina pudesse causar queimaduras, sugerindo que o problema era de origem elétrica externa.10 O caso resultou em danos graves, incluindo a necessidade de remoção da mama e perda de função do braço.21
O segundo acidente ocorreu em 26 de julho de 1985, em Hamilton, Ontário. A máquina emitiu uma mensagem de erro "H-tilt", mas indicou dose zero no console.21 Seguindo os procedimentos, a operadora tentou reiniciar o tratamento cinco vezes. A paciente sofreu queimaduras severas e necrose tecidual, vindo a falecer em novembro daquele ano.21
Tyler, Texas: O Ponto de Inflexão
Os acidentes em Tyler, no East Texas Cancer Center, em março e abril de 1986, foram fundamentais para a descoberta da falha de software.23 No primeiro incidente, Ray Cox sentiu um choque elétrico insuportável.23 No segundo, três semanas depois, outro paciente sofreu danos cerebrais fatais.24 O físico médico Fritz Hager e os técnicos de Tyler recusaram-se a aceitar as negativas da AECL e conseguiram, através de uma investigação exaustiva, reproduzir a "Malfunction 54" digitando comandos no console com extrema rapidez.15 Esta evidência empírica forçou a AECL e a FDA a reconhecerem a falha de design.9
Fatores Humanos e a Interface Homem-Computador
A interface do Therac-25 é um estudo de caso clássico sobre como o design de software pode induzir ao erro humano.5 O terminal VT100 utilizado não possuía uma organização visual moderna; era inteiramente baseado em texto e comandos rápidos.7
Fadiga de Alarme e Mensagens Crípticas
Os operadores conviviam com uma média de 5 a 10 mensagens de erro por dia, a maioria de baixa prioridade.10 Isso gerou um fenômeno de dessensibilização ou "fadiga de alarmes", onde códigos como "Malfunction 54" eram vistos apenas como interrupções irritantes.10 Além disso, o manual da máquina não fornecia explicações sobre o significado desses números, referindo-se a eles genericamente como "erros de dose".10
A Psicologia do "Segundo Vítima"
Interviews recentes com os físicos e operadores envolvidos destacam o impacto psicológico devastador desses acidentes nos profissionais de saúde.15 O conceito de "segundo vítima" descreve o trauma sofrido por profissionais que, inadvertidamente, causam dano a pacientes devido a sistemas falhos.15 Em Tyler, a descoberta de que o software estava silenciosamente permitindo overdoses gerou um clima de desconfiança absoluta na tecnologia médica da época.15
Consequências Éticas e a Responsabilidade Profissional
O caso Therac-25 é frequentemente utilizado em discussões sobre ética em computação para ilustrar o conceito de "O Problema das Muitas Mãos" (The Problem of Many Hands), formulado por Helen Nissenbaum.3
Barreiras à Responsabilidade
Segundo Nissenbaum, existem quatro barreiras principais que diluem a responsabilidade em falhas computacionais, todas visíveis no caso do Therac-25 3:
Muitas Mãos: Tantos engenheiros, gestores e reguladores estavam envolvidos que ninguém sentia a responsabilidade direta pelos resultados fatais.3
O Bug como Desculpa: Erros de software eram tratados como inevitáveis ou "misteriosos", o que servia como escudo para a negligência no teste e design.3
Computador como Bode Expiatório: A culpa era frequentemente atribuída à "falha da máquina" ou "erro elétrico", removendo a agência humana da equação.3
Propriedade sem Responsabilidade: A AECL detinha a propriedade intelectual do sistema, mas resistia em assumir a responsabilidade pelos danos causados por sua falha.3
Cursos de ética na USP e Unicamp enfatizam que a competência técnica é inseparável da responsabilidade social.12 O programador do Therac-25, embora tecnicamente capaz de escrever em Assembly complexo, falhou em seguir princípios básicos de documentação, revisão por pares e análise de segurança.2
Impacto Regulatório e a Modernização de Padrões
Os acidentes forçaram uma reavaliação completa da forma como os dispositivos médicos são aprovados pela Food and Drug Administration (FDA) e outros órgãos internacionais.1
O Fim da Equivalência Substancial para Software
Antes do Therac-25, a AECL obteve aprovação alegando "equivalência pré-mercado", afirmando que o dispositivo era tecnicamente similar aos modelos anteriores.9 Isso permitiu que o sistema ignorasse testes rigorosos de software.9 Após os incidentes, a FDA passou a exigir validação de software específica para qualquer dispositivo que controle funções críticas de vida.13
A Lei de Dispositivos Médicos Seguros de 1990 (SMDA)
A promulgação do Safe Medical Devices Act (SMDA) em 1990 foi uma resposta direta às falhas de comunicação entre hospitais e fabricantes.13 A lei passou a exigir que os usuários (hospitais e clínicas) reportassem acidentes diretamente à FDA, impedindo que fabricantes como a AECL pudessem ocultar padrões de falha sob a alegação de "incidentes isolados".1
A Norma IEC 62304 e a Garantia de Qualidade
Hoje, o desenvolvimento de software médico é regido por padrões como a IEC 62304, que estabelece um ciclo de vida rigoroso baseado em risco.29 A norma exige:
Gestão de Configuração: Para rastrear mudanças no código e evitar a reintrodução de bugs antigos.29
Verificação e Validação (V&V): Testes exaustivos em nível de unidade, integração e sistema.4
Análise de Risco de Software: Identificação proativa de perigos lógicos antes da implementação.29
Lições Aprendidas para a Prática de Engenharia de Sistemas
A análise retrospectiva do Therac-25 fornece lições imperecíveis para a engenharia de sistemas de segurança crítica, aplicáveis não apenas à medicina, mas à aviação, energia nuclear e infraestrutura crítica.1
Confiabilidade versus Segurança
Uma das distinções mais importantes reforçadas por Leveson é que um sistema confiável não é necessariamente um sistema seguro.1 O software do Therac-25 era confiável no sentido de que executava exatamente o que o programador escreveu; a falha foi que o que foi escrito não previa estados inseguros do sistema.1 A segurança deve ser vista como uma propriedade emergente do sistema total, abrangendo hardware, software, operadores e procedimentos organizacionais.15
A Importância da Redundância e Fail-Safe
A remoção de intertravamentos de hardware em favor do software foi um erro de projeto fundamental.1 Princípios modernos de design ditam que sistemas críticos devem possuir modos de falha segura (fail-safe). No caso de um acelerador linear, qualquer inconsistência detectada deveria resultar na suspensão imediata do tratamento, exigindo um reset físico, em vez de permitir uma continuação facilitada.1
O Papel dos Testes e da Formalização
A dependência exclusiva de testes de sistema (system testing) no final do processo de desenvolvimento foi insuficiente para capturar erros de concorrência que ocorrem em condições muito específicas.4 Métodos formais, como lógica temporal e verificação de modelos (model checking), são hoje recomendados para provar a ausência de condições de corrida em sistemas de tempo real.15
Conclusões e Perspectivas Futuras
O legado do Therac-25 permanece como um aviso contínuo sobre os perigos do excesso de confiança na automação e da negligência na engenharia de software.3 O caso demonstrou que falhas invisíveis no código podem ter consequências físicas tão letais quanto falhas mecânicas catastróficas.19 À medida que avançamos para uma era de medicina personalizada e tratamentos controlados por Inteligência Artificial, os princípios de transparência, redundância e responsabilidade ética estabelecidos após o desastre do Therac-25 tornam-se mais relevantes do que nunca.15 A segurança não é um recurso a ser adicionado, mas uma disciplina fundamental que deve permear todo o ciclo de vida do desenvolvimento tecnológico, garantindo que o progresso nunca ocorra à custa da integridade e da vida humana.4
Trabalhos citados
An Investigation of the Therac-25 Accidents - Columbia University Computer Science, acesso a maio 19, 2026, https://www.cs.columbia.edu/~junfeng/08fa-e6998/sched/readings/therac25.pdf
Therac-25 - Wikipedia, acesso a maio 19, 2026, (Fonte desconsiderada)Therac-25 - Ethics Unwrapped, acesso a maio 19, 2026, https://ethicsunwrapped.utexas.edu/case-study/therac-25
GESTÃO DA QUALIDADE DE SOFTWARE: ESTUDO DE CASO DA ..., acesso a maio 19, 2026, https://revistaft.com.br/gestao-da-qualidade-de-software-estudo-de-caso-da-maquina-therac-25-e-a-importancia-da-qualidade-de-software/
Therac-25: Ethics in Engineering Failure | PDF - Scribd, acesso a maio 19, 2026, https://www.scribd.com/document/886783269/Therac25-Ethics-Report
An Investigation of the Therac-25 Accident - Stanford University, acesso a maio 19, 2026, https://web.stanford.edu/class/cs240/old/sp2014/readings/therac-25.pdf
Medical Devices: The Therac-25 Story, acesso a maio 19, 2026, https://homes.luddy.indiana.edu/samth/full-211/leveson-safeware-therac-25.pdf
Therac-25 | Ethics Unwrapped, acesso a maio 19, 2026, https://ethicsunwrapped.utexas.edu/wp-content/uploads/2022/07/Therac25_Case-Study_Spanish.pdf
1, acesso a maio 19, 2026, https://www.usna.edu/Users/cs/wcbrown/courses/x221x/classes/L26/Ethics.doc
The Worst Computer Bugs in History: Race conditions in Therac-25, acesso a maio 19, 2026, https://web.stanford.edu/class/cs208e/lectures/17-Computers-and-Ethics/Therac25.pdf
Medical Devices: The The ac- ! Nancy Leveson University of ..., acesso a maio 19, 2026, http://sunnyday.mit.edu/papers/therac.pdf
um roteiro para o ensino de qualidade de arquitetura de software guiado por requisitos não funcionais - Biblioteca Digital de Teses e Dissertações da USP, acesso a maio 19, 2026, https://teses.usp.br/teses/disponiveis/3/3141/tde-19072016-121434/publico/RenatoManzandeAndrade2015.pdf
17 Therac-25: Software that Killed - Cambridge University Press & Assessment, acesso a maio 19, 2026, https://www.cambridge.org/core/services/aop-cambridge-core/content/view/F525A54C5FF13497A61472A0AFF8EB27
6.033 Assignment: Due in Recitation 3, 02/13/2007 - MIT, acesso a maio 19, 2026, https://web.mit.edu/6.033/2007/wwwdocs/assignments/therac25.html
Therac-25 Accidents: We Keep on Learning From Them - Vrije ..., acesso a maio 19, 2026, https://research.vu.nl/ws/portalfiles/portal/399472131/Therac-25_Accidents_We_Keep_on_Learning_From_Them.pdf
Verificaç˜ao Automática de Sistemas Descritos Usando a Linguagem Ladder - repositorio ufmg, acesso a maio 19, 2026, https://repositorio.ufmg.br/server/api/core/bitstreams/e23d5258-ab0a-40ce-96a4-4e9623103c50/content
JORGE RADY DE ALMEIDA JUNIOR SEGURANÇA EM SISTEMAS CRÍTICOS E EM SISTEMAS DE INFORMAÇÃO - UM ESTUDO COMPARATIVO - Biblioteca Digital de Teses e Dissertações da USP, acesso a maio 19, 2026, https://teses.usp.br/teses/disponiveis/livredocencia/3/tde-29102025-121313/publico/JorgeRadydeAlmeidaJuniorLD.pdf
6.033 | Spring 2017 | Therac-25 Recitation - MIT, acesso a maio 19, 2026, https://web.mit.edu/6.033/2017/wwwdocs/assignments/rec-therac25.html
Therac-25: Erro de Software Deixou Vítimas Há 40 Anos - PSTQB, acesso a maio 19, 2026, https://pstqb.pt/therac-25-erro-de-software-deixou-vitimas-ha-40-anos/
Case Study on Accidental Overdoses in Therac-25 Radiation Therapy Systems - Studocu, acesso a maio 19, 2026, https://www.studocu.vn/vn/document/international-university-vnu-hcm/engineering-ethics-and-professional-skills/case-study-accidental-overdoses-in-medical-radiation-therapy-systems/45579314
Death and Denial: The Failure of the THERAC-25, A Medical Linear Accelerator, acesso a maio 19, 2026, https://users.csc.calpoly.edu/~jdalbey/SWE/Papers/THERAC25.html
An Investigation of Therac-25 Accidents - I, acesso a maio 19, 2026, https://cse.msu.edu/~cse470/Public/Handouts/Therac/Therac_1.html
Safety-Critical Computing: Hazards, Practices, Standards, and Regulation - University of Washington, acesso a maio 19, 2026, https://staff.washington.edu/jon/pubs/safety-critical.html
Therac-25 - II - MIT, acesso a maio 19, 2026, https://cse.msu.edu/~cse470/Public/Handouts/Therac/Therac_2.html
Therac-25 - III - Computer Science and Engineering, acesso a maio 19, 2026, https://cse.msu.edu/~cse470/Public/Handouts/Therac/Therac_3.html
An Investigation of the Therac-25 Accidents -- Part V - Computer Science and Engineering, acesso a maio 19, 2026, https://cse.msu.edu/~cse470/Public/Handouts/Therac/Therac_5.html
Algorithmic Discrimination – The Challenge of Unveiling Inequality in Brazil - Teses USP, acesso a maio 19, 2026, https://teses.usp.br/teses/disponiveis/2/2134/tde-16072020-174508/publico/6855593_Dissertacao_Original.pdf
Read "Infusing Ethics into the Development of Engineers: Exemplary Education Activities and Programs" at NAP.edu, acesso a maio 19, 2026, https://www.nationalacademies.org/read/21889/chapter/3
IEC 62304 Guide: Medical Device Software Safety Standard - IntuitionLabs, acesso a maio 19, 2026, https://intuitionlabs.ai/pdfs/iec-62304-guide-medical-device-software-safety-standard.pdf
Comentários
Postar um comentário