REGISTRO DOI:10.5281/zenodo.10989653
Maurício Faccin da Silva
Orientador: Prof. Esp. Carlos Hoegen
RESUMO
Praticamente todos os itens consumidos na atualidade passam por uma etapa em seu ciclo de vida que é ligada à área de informática, mesmo que seja apenas em sua fase de projeto. É fato que, independentemente do que seja, é primordial que esta fase seja de qualidade para garantir que o produto final atenda as expectativas do cliente ou usuário. Os itens que demandam um consumo contínuo de softwares requerem uma atenção especial quando se fala de qualidade de software como, por exemplo, máquinas que funcionam e operam controladas por programas de computador. Nesta categoria, dentre outras, encontram-se os equipamentos médicos, que são máquinas utilizadas nos mais diversos tipos de tratamentos de saúde. Como exemplo, podemos citar as máquinas de radiografia (popularmente conhecidas como Raio-X), desfibriladores, eletrocardiógrafos e máquinas de radioterapia. Sobre esta última, existe um caso relevante para o mundo da informática e da medicina, ocorrido na década de 1980. Trata-se de um erro de software da máquina de radioterapia denominada Therac-25. O caso do Therac-25 serve como um marcante exemplo dos perigos associados a falhas de software em sistemas críticos para a saúde humana. O incidente ressalta a importância crucial da Gestão de Qualidade de Software em ambientes onde erros podem resultar em sérios danos. A tragédia do Therac-25 aconteceu por falhas no sistema de controle, que permitiram a administração de doses excessivas de radiação. Uma análise posterior revelou que as falhas eram originadas de erros de programação e validação insuficiente do software. Isso destaca a necessidade premente de uma abordagem abrangente à Qualidade de Software, começando pela análise de requisitos de software. A análise de requisitos é uma fase crítica no ciclo de vida do desenvolvimento de software. No caso do Therac-25, a negligência na compreensão completa dos requisitos resultou em funcionalidades deficientes e na ausência de salvaguardas adequadas. Uma gestão eficaz de requisitos não apenas identifica as necessidades dos usuários, mas também define claramente os limites e as restrições do sistema. Além disso, a importância da verificação e validação de software torna-se evidente. Testes rigorosos, simulações e revisões contínuas do código são essenciais para garantir que o software atenda aos requisitos estabelecidos e que os sistemas de segurança estejam funcionando corretamente. A validação do software em ambientes de produção simulados também desempenha um papel crucial na prevenção de falhas. A gestão de mudanças é outro aspecto vital da Gestão da Qualidade de Software. No caso do Therac-25, a introdução de novas funcionalidades sem uma revisão e teste adequados contribuiu significativamente para os incidentes. Um processo bem definido para gerenciar e implementar mudanças no software é fundamental para evitar surpresas indesejadas. O caso do Therac-25 destaca a importância crítica da Gestão da Qualidade na indústria de desenvolvimento de software, especialmente em aplicações que impactam diretamente a saúde e segurança humanas. A análise cuidadosa de requisitos, testes rigorosos, validação contínua e uma gestão eficaz de mudanças são pilares fundamentais para mitigar riscos e garantir a confiabilidade de sistemas críticos. Essas lições continuam a orientar a abordagem da indústria em direção a práticas mais seguras e robustas no desenvolvimento de software.
Palavras-chave: Therac-25. Qualidade. Software. Gestão da Qualidade. Requisitos.
INTRODUÇÃO
A história do Therac-25 destaca-se como um trágico episódio na interseção entre avanços tecnológicos e a necessidade crítica de gestão da qualidade de software em dispositivos médicos. Desenvolvido na década de 1980 por uma empresa canadense, o Therac-25 era um avançado dispositivo de radioterapia destinado a tratar pacientes com câncer. No entanto, sua implementação inadequada e falhas no software levaram a uma série de incidentes desastrosos, resultando em superdosagens de radiação, graves danos aos pacientes e, em alguns casos, perda de vidas.
A gestão da qualidade de software desempenha um papel crucial na garantia da confiabilidade e segurança de sistemas críticos, especialmente na área da saúde. No caso do Therac-25, a ausência de práticas adequadas de gestão da qualidade de software permitiu a persistência de erros graves, colocando em risco a vida dos pacientes. Este contexto serve como um alerta sobre a importância de uma abordagem sistemática e rigorosa na concepção, implementação e manutenção de software em ambientes onde falhas podem ter consequências devastadoras.
Ao explorar as falhas específicas do Therac-25, desde a análise insuficiente de requisitos até a falta de testes adequados e validação contínua, é possível compreender a urgência de uma gestão de qualidade de software robusta. Este incidente influenciou mudanças significativas na regulamentação e nas práticas da indústria de dispositivos médicos, impulsionando um comprometimento renovado com a segurança e qualidade de software em ambientes críticos para a vida humana. O caso do Therac-25 serve como um lembrete impactante da necessidade contínua de investir na gestão da qualidade de software para proteger a saúde e bem-estar dos pacientes.
Assim, as vidas perdidas derivadas de um erro de software que poderia ter sido corrigido logo no início do desenvolvimento do mesmo aplicando-se práticas que hoje são rotineiras quando se fala de qualidade de software, poderiam ter sido poupadas e, hoje, o Therac-25 seria lembrado como um pioneiro em seu segmento de tratamento de cânceres por radioterapia.
DESENVOLVIMENTO
Therac-25 foi um equipamento médico desenvolvido para o tratamento de cânceres através de radioterapia. Lançado no início da década de 1980, era extremamente moderno para a sua época, pois era inteiramente controlado por um computador (e software), dispensando travas mecânicas de hardware e possibilitando diversos níveis de doses de radiação a serem administrados.
O Therac-25 era uma evolução de seus antecessores: O Therac-6 e o Therac- 20. O Therac-6 era utilizado para o tratamento de tumores mais superficiais e utilizava feixes de elétrons enquanto o Therac-20 tratava de tumores mais profundos utilizando feixes de fótons. Seu sucessor, o Therac-25, oferecia estas duas opções de tratamento em uma única máquina. Os dois modelos anteriores também dependiam de ajustes manuais do operador e tinham menos opções de controle do que o novo modelo. O Therac-25 introduziu uma funcionalidade que permitia o ajuste manual da dose de radiação, porém estava sujeita a falhas graves.
Os softwares de controle utilizados nos primeiros equipamentos da série eram mais simples do que o que foi utilizado no Therac-25, porém, o deste último, foi um ‘aproveitamento’ dos softwares de seus antecessores.
Estes softwares, utilizados nas primeiras duas versões citadas, tinham sistemas de segurança, mas eram menos complexos e, tanto o Therac-6 quanto o Therac-20 nunca haviam apresentado falhas graves detectáveis até então.
A confiança da empresa desenvolvedora deste equipamento no software de controle utilizado nas primeiras duas versões dos equipamentos fez com que eles o “reutilizassem” na nova versão, sem tantos ajustes para a nova condição.
Além disso, a pressa para o lançamento deste novo equipamento no mercado fez com que o código do sistema fosse desenvolvido apenas por uma única pessoa com o objetivo de economia de tempo.
Após o lançamento da máquina no mercado, a mesma foi adquirida por diversos hospitais e centros médicos especializados na América do Norte, principalmente nos Estados Unidos. O Therac-25 funcionou por alguns anos sem apresentar problemas relevantes até que, em junho de 1985, uma paciente recebeu uma superdosagem de radiação, resultando em queimaduras graves e, posteriormente, óbito.
Um dos médicos percebeu que as queimaduras causadas foram por causa de uma dose excessiva de radiação que a paciente havia recebido e contatou a empresa fabricante do equipamento e esta, por sua vez, retornou dizendo que o médico estava fazendo alegações falsas e que era impossível um erro como esse acontecer com o seu equipamento.
Aproximadamente um mês após o primeiro fato, um novo incidente ocorreu, com as mesmas características do primeiro, porém em outra máquina do mesmo modelo localizada em outra cidade. Desta vez, ao ser informada, a empresa afirmou que se tratava apenas de um problema na mesa giratória e, então, adicionou ao software uma atualização que permitia identificar se a mesa estava ou não na posição ideal e alegou que isso aumentaria em milhares de vezes a segurança da máquina.
Em dezembro deste mesmo ano de 1985, outro incidente igual ocorreu, com outro Therac-25 e a empresa voltou a negar, afirmando que o erro seria impossível e que o software da máquina proibiria uma dose tão alta de radiação.
Em março e abril de 1986, em outra máquina, desta vez localizada no estado do Texas, Estados Unidos, outros 2 pacientes receberam uma dose letal de radiação após um erro denominado “Malfunction 54” aparecer na tela de controle do equipamento. Eles faleceram meses depois devido a envenenamento por radiação.
Técnicos que operavam estas máquinas em diversos hospitais relataram que era comum erros com números variados aparecerem na tela dessas máquinas e que as vezes até sumiam sozinhos. Nos manuais de operação da máquina não havia explicação útil para estes erros e os próprios analistas do fabricante também não conseguiram reproduzir estes erros quando foram requisitados, principalmente o Malfunction 54.
A instrução dada pela empresa fabricante e, consequentemente, pelos operadores mais antigos da máquina, era sempre a mesma: desligar e religar a máquina para que os erros “desaparecessem”.
Após todos estes casos o fabricante do Therac-25 resolveu atualizar o código depois que percebeu um erro ligado entre os parâmetros de software e o hardware. Esta atualização consistia em fazer com que o software impedisse o disparo da dose de radiação se a máquina não estivesse na posição correta para esta aplicação.
Ela deveria realizar centenas de verificações logo antes da administração da dose no paciente e, caso o equipamento estivesse em posição incorreta, bloquearia a dose. Em resumo, para esta verificação de software, o fabricante adicionou uma variável de apenas 1 byte, que daria 256 opções possíveis de falha, indo da faixa de 0 a 255. Então, qualquer número diferente de zero faria com que o mecanismo de disparo de radiação não funcionasse. Era improvável que um valor acima desta faixa aparecesse, mas, em janeiro de 1987, aconteceu. Desta forma, o software considerou que o valor fosse zero, pois este valor estava fora do intervalo de inspeção, e permitiu a administração de dose de radiação quando a máquina estava em posição incorreta, o que ocasionou mais um acidente fatal.
Todos os erros relacionados ao Therac-25 e que causaram os acidentes envolvendo pacientes, alguns deles fatais, têm como causa os erros do software e a falta de gestão de qualidade do mesmo.
Posteriormente descobriu-se que o código nunca havia sido testado, mesmo após alegação de milhares de horas de teste terem sido informadas pelo fabricante. Além disso, apenas uma pessoa havia escrito todo o código e não se possuía quase nenhuma documentação do processo ou mesmo do código em si.
A tragédia do Therac-25 revela a importância crucial da Gestão de Qualidade de Software na prevenção de incidentes catastróficos em dispositivos médicos. Se uma abordagem mais abrangente e eficaz de Gestão de Qualidade de Software tivesse sido implementada, muitos dos erros que resultaram nos trágicos eventos poderiam ter sido evitados.
Em primeiro lugar, uma análise de requisitos mais detalhada e rigorosa teria sido fundamental. A falta de clareza nos requisitos, especialmente em relação à transição de modos e representação de dados, foi uma das principais causas dos problemas do Therac-25. Uma análise mais minuciosa teria identificado essas ambiguidades e lacunas, fornecendo uma base sólida para o desenvolvimento do software. Além disso, a execução de testes abrangentes e exaustivos durante todas as fases do desenvolvimento teria revelado as vulnerabilidades críticas presentes no sistema. Testes unitários, de integração e de sistema, explorando cenários extremos, transições de modo e manipulação de dados, teriam permitido a detecção precoce de falhas, impedindo que chegassem aos estágios de produção.
A validação contínua do software, com ênfase em testes de segurança regulares, teria proporcionado uma camada adicional de proteção. Garantir que o Therac-25 operasse dentro de parâmetros seguros, mesmo durante situações críticas, como transições de modo, teria sido vital para prevenir superdosagens de radiação.
A falta de mecanismos robustos de detecção de erros e recuperação foi outra falha crítica. Incorporar sistemas que detectassem precocemente erros e permitissem a recuperação automática teria sido essencial. Esses mecanismos poderiam ter evitado muitos dos incidentes fatais, proporcionando uma resposta imediata diante de comportamentos inesperados.
Por fim, um enfoque na formação adequada dos operadores como parte integrante da Gestão de Qualidade de Software teria sido fundamental. Operadores treinados de forma abrangente teriam compreendido melhor o sistema, possibilitando uma intervenção mais rápida diante de comportamentos inesperados do Therac-25.
A lição essencial extraída da tragédia do Therac-25 é que a Gestão de Qualidade de Software não é apenas uma medida adicional, mas uma necessidade vital em dispositivos médicos críticos. Não apenas aprimora a funcionalidade do sistema, mas serve como uma salvaguarda essencial para a segurança e bem-estar dos pacientes.
Figura 1: A esquerda, computador PDP-11, de 16 bits utilizado para controlar o Therac-25 a direita.
REVISÃO BIBLIOGRÁFICA
Diversas publicações e estudos sobre o caso do Therac-25 têm sido publicados desde os incidentes ocorridos com este equipamento a partir do final da década de 1980. Após o surgimento e crescimento da internet, nos anos 90, cada vez mais material sobre o assunto tem aparecido e sido disponibilizado de maneira online para que todos possam ter acesso.
A Online Ethics Center é uma entidade focada na difusão de informação relevante e recursos para engenheiros, cientistas, professores e estudantes visando a compreensão e abordagem de questões eticamente significativas que surgem da prática científica e de engenharia. Também serve àqueles que promovem a aprendizagem e avançam na compreensão da pesquisa e prática responsável em engenharia, ciências e ciências sociais. Por ser online, a OEC é hospedada pela Universidade de Virgínia, Escola de Engenharia e Ciências Aplicadas.
A OEC traz algumas publicações de profissionais especializados nas áreas de ética, engenharias e computação que analisam o caso Therac-25 de forma detalhada e completa, separando os atores envolvidos no caso e particularizando cada vítima e cada incidente conhecido ocorrido com o equipamento.
O portal Medium.com é uma plataforma online fundada em 2012 por um dos cofundadores do Twitter. Esta plataforma permite que usuários publiquem suas histórias, artigos e textos de forma simplificada e seus autores podem alcançar audiências significativas. Alguns dos conteúdos deste site são gratuitos, mas para acessar a totalidade, é necessário ter, ao menos, uma assinatura.
Como o Medium permite uma gama variada de assuntos, dentre eles está o tema de ciência e tecnologia, que é onde um material sobre o caso do Therac-25 se encontra, publicado por um PhD em Ciência da Computação.
Nancy Leveson é uma renomada professora e pesquisadora na área de engenharia de sistemas e segurança de software. Em 1993 ela publicou um artigo completo sobre o caso Therac-25 pela Universidade de Washington. Atualmente é professora no Departamento de Aeronáutica e Astronáutica e Engenharia de Sistemas no Massachusetts Institute of Technology (MIT), nos Estados Unidos.
O canal Ciência Todo Dia, hospedado pelo Youtube.com, aborda diversos assuntos relacionados exclusivamente a ciência e tecnologia e é administrado pelo físico Pedro Loos. Neste canal existe um material resumido e didático sobre todo o caso envolvendo o Therac-25.
METODOLOGIA
Para este artigo foram necessárias fontes de dados virtuais e dados do material didático disponibilizado pela Unibf durante as aulas de Gestão da Qualidade de Software. Primeiramente, como trata-se de um tema tecnológico cujo assunto principal é um estudo de caso ocorrido na década de 1980, foi-se pesquisado em portais virtuais de entidades idôneas que publicaram relatórios, artigos e pesquisas e sobre o caso. Em seguida, visto que o autor deste artigo possui formação na área de tecnologia da informação, parte do texto foi elaborada segundo o seu próprio conhecimento e, por fim, foi analisada uma publicação completa sobre o caso em que todos os erros ocorridos, que culminaram na tragédia do Therac-25, foram abordados, esmiuçados e explanados por uma autora renomada, pesquisadora e professora de uma universidade estadunidense.
Nos primórdios da programação para máquinas não existiam ferramentas e processos para que se fosse produzido um software de qualidade. A qualidade de software era um mero “acessório” que somente seria utilizado caso houvesse recursos sobrando disponíveis. Porém, após casos importantes como o do Therac- 25, entre outros, começarem a surgir com o avanço da tecnologia, foi-se necessária a criação de processos, procedimentos e políticas de gestão de qualidade na produção de softwares para que tragédias e grandes prejuízos derivados de códigos mal escritos e softwares não testados fossem mitigadas ou extintas.
Foi com o olhar sob a perspectiva das modernas e atuais ferramentas disponibilizadas pelos modelos recentes de qualidade de software que o caso do Therac-25 foi analisado neste artigo, possibilitando que fosse percebido, desde o início da análise do caso, quais erros foram cometidos, em quais etapas do desenvolvimento e como eles poderiam ter sido evitados, mesmo naquela época, se algumas ações simples tivessem sido adotadas.
Em cada incidente, mesmo que quase todos semelhantes entre si, poderia ter sido tomada uma ação diferente, pensando sempre no fato ocorrido e antevendo a possibilidade de uma nova ocorrência, visando a prevenção de erros que teriam como o principal prejuízo a vida humana. Mas, antes mesmo do primeiro erro ocorrido, ainda na fase de produção do código, uma análise de requisitos poderia ter ajudado a evitar ou mitigar a tragédia que viria no futuro.
ANÁLISE DOS RESULTADOS
A publicação da Online Ethics Center apresenta um estudo completo sobre o caso Therac-25, explicando até mesmo como funciona a radioterapia e os princípios básicos de funcionamento das máquinas convencionais para o tratamento de câncer utilizando esta tecnologia. Ainda nesta publicação, são descritos quem são os participantes do caso (Hospitais, FDA, Operadores e fabricante da máquina) e, por fim, cada um dos seis casos conhecidos são detalhados.
No artigo publicado pela professora e pesquisadora Nancy Leveson, pela Universidade de Washington, todos os incidentes ocorridos com o Therac-25, bem como os motivos, são abordados com riqueza de detalhes, trazendo datas, imagens de layout de tela de usuário do software utilizado no computador que controlava a máquina e diagrama com as partes principais.
Ainda no artigo da referida pesquisadora, cada evento é explanado com riqueza de detalhes, trazendo nome de cidades e estados onde as máquinas que apresentaram problemas foram instaladas, nome dos hospitais, datas das ocorrências, qual foi o problema apresentado em cada caso, com detalhes técnicos, inclusive nível de carga de radiação aplicada em cada paciente que foi vítima do Therac-25. Também mostra quais foram as respostas dadas pelo fabricante, quais as ações do governo, dos pacientes e da FDA quanto aos incidentes ocorridos. Por fim, apresenta quais foram as principais causa gerais de tudo que ocorreu com o Therac-25 como, por exemplo, excesso de confiança no software.
O Medium.com traz um resumo muito didático acerca somente do funcionamento e erros acontecidos com o Therac-25. Nesta abordagem não estão detalhes dos pacientes e nem das datas e locais dos incidentes, mas os bugs que aconteceram são explicados com detalhes. Uma imagem de como seria o funcionamento nos dois modos de tratamento oferecidos pela máquina e outra imagem da tela de interface do software utilizado também são apresentadas para que seja mais claro o entendimento de como os erros aconteceram.
O canal do Youtube.com denominado Ciência Todo Dia traz a informação de forma mais didática para que leigos possam compreender qual foi, possivelmente, o maior erro de software da história, com narração, vídeos e imagens sobre o caso.
O caso do Therac-25, sob a lente da Gestão de Qualidade de Software, destaca de maneira contundente a necessidade crítica de práticas robustas e sistemáticas na concepção, desenvolvimento e manutenção de software em dispositivos médicos críticos. A tragédia associada a esse equipamento, marcada por superdosagens de radiação e consequências fatais para os pacientes, ressalta a importância de lições aprendidas para aprimorar a segurança e confiabilidade em ambientes de saúde.
A falta de uma análise de requisitos minuciosa contribuiu significativamente para as falhas do Therac-25. A ausência de clareza nos requisitos, especialmente em relação à transição de modos e à representação de dados, ilustra a necessidade de uma abordagem mais detalhada na fase inicial do desenvolvimento. A Gestão de Qualidade de Software destaca a importância de identificar e corrigir lacunas e ambiguidades desde as etapas iniciais, estabelecendo as bases sólidas essenciais para um sistema seguro.
A execução de testes exaustivos em todas as fases do desenvolvimento é uma prática central na Gestão de Qualidade de Software. No caso do Therac-25, a falta de testes abrangentes, especialmente em cenários extremos, transições de modo e manipulação de dados, evidencia a importância crítica dessas práticas. Testes robustos não apenas detectam falhas, mas também garantem a confiabilidade e a segurança do software.
A validação contínua, incluindo testes de segurança regulares, é uma parte integral da Gestão de Qualidade de Software. Garantir que o sistema opere dentro de parâmetros seguros, mesmo em situações críticas, é vital para prevenir incidentes. Mecanismos de detecção de erros e sistemas de recuperação adequados, como preconizados pela Gestão de Qualidade de Software, poderiam ter evitado muitos dos eventos fatais associados ao Therac-25.
Em suma, o caso do Therac-25 reforça que a Gestão de Qualidade de Software não é uma opção, mas uma necessidade crítica em dispositivos médicos críticos. É uma salvaguarda essencial para a segurança e bem-estar dos pacientes, exigindo uma abordagem abrangente, desde a análise de requisitos até a validação contínua. O legado do Therac-25 ressalta a urgência de priorizar a qualidade de software como um elemento central na concepção de dispositivos médicos, estabelecendo um padrão de excelência para a segurança dos pacientes.
REFERÊNCIAS BIBLIOGRÁFICAS
Disponível em: <https://medium.com/swlh/software-architecture-therac-25-the-killer- radiation-machine-8a05e0705d5b> Acesso em: 30 jan. 2024.
Disponível em: <https://onlineethics.org/cases/therac-25/therac-25-case-narrative> Acesso em: 30 jan. 2024.
Disponível em: <http://sunnyday.mit.edu/papers/therac.pdf> Acesso em: 01 fev. 2024.
Disponível em: <https://youtube.com/watch?v=_4VEtLsGWhY&ab_channel=Ci%C3%AAnciaTodoDia> Acesso em: 23 jan. 2024.
LEVESON, Nancy. Medical Devices: The Therac-25. 1.ed. Washington: University of Washington, 1993.