O que a medicina pode aprender com a programação?

10 min readMay 2, 2022

Esse texto são apenas reflexões que foram geradas durante diálogos entre um engenheiro de software e uma médica.

No mundo da programação, os profissionais estão em constante aperfeiçoamento nos processos, nas ferramentas, nas pessoas e na cultura, com a tentativa de reduzir riscos, erros e melhorar a produtividade.

Toda essa filosofia é uma construção de anos com o compartilhamento de ideias de várias pessoas da industria, e onde foram aprimoradas por diversas metodologias como a Cascata, Agile, Kaizen, Lean, Scrum e assim por diante. Atualmente, são usadas como convenções sociais entre os times de desenvolvimento, pois se você é júnior ou sênior, você entrará em contato com essas ideias independente do tamanho da empresa em que esteja ou de sua localização.

Em resumo, estamos constantemente nos auto analisando e aplicando melhoria contínua. Já fazemos isso tanto, de tantas maneiras que às vezes, não percebemos o quanto evoluímos e que isto pode ser compartilhado com outras áreas profissionais.

Vou descrever algumas delas para exemplificar para você, que não é da área de tecnologia.

O mito do programador gênio

Essa é uma apresentação de 2009 feita por dois engenheiros do Google: Brian Fitzpatrick e Ben Collins-Sussman.

A pervasive elitism hovers in the background of collaborative software development: everyone secretly wants to be seen as a genius. In this talk, we discuss how to avoid this trap and gracefully exchange personal ego for personal growth and super-charged collaboration. We’ll also examine how software tools affect social behaviors, and how to successfully manage the growth of new ideas.

Em miúdos, a palestra fala sobre termos a humildade de compreender que não sabemos de tudo, independente dos anos de experiência, que precisamos de colaboração na melhoria de nosso trabalho. A crítica é importante ao trabalho. Permitir-se falhar, e tantos outros princípios muito valiosos para o trabalho em time. Sugiro assistir a apresentação por completo.

Ok, e como isso se aplica no dia-a-dia do programador?

Revisão de código

Uma das práticas mais valiosas que considero é a revisão de código, mas antes vou explicar um pouco da nossa rotina de forma simples.

Primeiro recebemos a demanda do nosso líder de produto;
Entendemos a demanda, geralmente está bem descrita e mesmo que não esteja (ou que não saibamos previamente sobre aquilo) temos tempo de pesquisar, planejar para em seguida iniciar a programar;
Envio o meu código para revisão, onde 51% do time tem que avaliar tudo que eu fiz, linha por linha, arquivo por arquivo e se houver alguma inconsistência ou melhoria, isso será comentado no meu código de forma didática e respeitosa. Em seguida vou melhorar o que já fiz.

3.1 Esse ciclo de melhorias é iterativo, pode se repetir diversas vezes e por dias dependendo do nível de complexidade da demanda.

4. Os passou por todas as revisões? os membros do time estão satisfeitos? Enfim, agora a minha contribuição é aprovada e a demanda é submetida.

É importante entender esse fluxo, pois raramente temos poder de tomar uma decisão unilateral sobre algo em que fazemos, independente se você começou na carreira ou tem 30 anos de experiência, sempre você passará pelo crivo e interpretações de outros membros sob seu trabalho.

Isto é sensacional, pois você se sente mais seguro e preparado para finalizar esta demanda. Você sempre aprende algo novo a partir da perspectiva de outra pessoa, além de ser um ótimo benefício para reduzir viés ou bias de programação. Isto faz parte da nossa rotina em qualquer tarefa.

Abaixo como isso ocorre na prática. Isto é um print screen de um projeto gratuito do Google, onde você pode acompanhar todo o progresso do desenvolvimento. Você pode ver, em seta vermelha, duas pessoas aprovando o trabalho de alguém. Após aprovações, na seta roxa, o trabalho sendo submetido.

Linha do tempo de comentários, aprovações e submissão

Se tiver interesse, você pode acompanhar com mais detalhes aqui: https://github.com/angular/angular/pull/45756

Você percebe a linha do tempo dos comentários e o que cada pessoa registrou nessa contribuição. Isso também serve como documentação, onde qualquer membro pode retornar no passado e entender as decisões tomadas.

Então, podemos entender que revisão de código, atualmente, é uma metodologia difundida socialmente sendo considerado uma boa prática. Isto é possível atualmente, pois foram anos de conscientização e adoção nas empresas.

Se você quiser mergulhar neste assunto, abaixo alguns artigos acadêmicos para você avaliar os benefícios:

Análise estática de código

Todo mundo sabe que erros são ruins. Alguns erros causam falhas que frustram os usuários. Outros comprometem a segurança de um sistema crítico. Não importa que tipo de programa você esteja desenvolvendo, é importante evitar esses erros. É por isso que muitas equipes de desenvolvimento confiam no linting.

Linting é a verificação automatizada do que escrevemos quanto a erros programáticos e estilísticos. Isso é feito usando uma ferramenta de lint.

Como isso funciona?

Vou apresentar um exemplo bem prático.

Trecho de código apresentando o tipo de uma variável

Vamos supor que vou fazer um programa para calcular o preço total de uma quantidade de bananas. Com isso eu declaro que existe um variável que irá receber a quantidade de bananas. Essa variável se chama quantidadeBananas. Como se trata de quantidade eu só posso permitir valores numéricos na quantidade de bananas.

Entretanto, na linha 3, eu adiciono um novo valor "estrela", sendo este valor um texto. Automaticamente a ferramenta já adiciona um sublinhado vermelho abaixo da variável indicando que tem algo de errado.

Passando o cursor do mouse a ferramenta indica qual o erro:

Trecho de código apresentando o erro gerado pela análise estática

O erro é que quantidadeBananas não aceita um valor textual, aceita apenas do tipo numérico.

É assim que o analisador estático funciona, este é um exemplo simples. Nele contém outras regras mais complexas e validações que nos ajudam a reduzir os erros em tempo real e termos mais qualidade no nosso resultado final.

Para maiores detalhes sobre os benefícios dessas ferramentas em desenvolvimento de software, segue alguns links abaixo:

Contextualizando

Foi apresentado duas formas extensamente utilizadas no nosso dia-a-dia de trabalho:

O ciclo de trabalho entre o processo manual e automatizado

Importante ressaltar, que independente dos anos de experiência e o quão excelente tecnicamente você seja, as pessoas e ferramentas tem papeis importantes na qualidade do nosso trabalho. Nenhuma substitui a outra, ambas são complementares.

Preocupações …

Um dos pontos que me chamou atenção em nossas conversas é a quantidade de falhas passíveis de ocorrerem durante os fluxos de atendimentos médicos, como por exemplo:

Investigação diagnóstica incompleta resultando em encaminhamento incorreto para outro setor/especialidade.
Escassas revisões entre os pares em relação às definições diagnósticas e terapêuticas.
Limitado feedback entre profissionais após identificação de erros médicos.
Erros de prescrição médica.

Pesquisando mais a fundo encontrei alguns dados alarmantes:

Estudo realizado nos Estados Unidos da América revela que cada paciente internado em hospital norte-americano está sujeito a um erro de medicação por dia, sendo registrados anualmente, nessas instituições, no mínimo 400.000 eventos adversos evitáveis relacionados a medicamentos. [Fonte]
Estima-se que os erros de medicação em hospitais provoquem mais de 7.000 mortes por ano nos Estados Unidos da América, acarretando importantes custos tangíveis e intangíveis. [Fonte]
De acordo com o boletim de Farmacovigilância, um estudo realizado em cinco hospitais públicos de ensino das regiões Norte, Nordeste, Sudeste e Centro-Oeste identificou 1.500 erros de medicação relacionados à administração de medicamentos, demonstrando que 30% das doses administradas continham alguma falha. [Fonte]
Dados de outros estudos realizados em hospitais públicos brasileiros mostraram que os erros de medicação ocorrem principalmente durante a prescrição, a administração e a preparação de medicamentos. [Fonte]

Isso me trouxe algumas reflexões?

Quantas vezes meus receituários foram revisados por outro médico?
Por que eu confio plenamente na decisão de apenas um médico?
Se na engenharia de software onde trabalhamos com situações concretas, em ambiente controlado e de certa forma previsíveis, mesmo assim passamos por tantas etapas de revisão e validação antes de qualquer decisão a ser tomada:
Por que no tratamento do paciente, onde o ser humano é mais abstrato, imprevisível e há muitos mais fatores a serem considerados, como biológicos e psicológicos, não há maior rigor antes de passar uma receita?
Por que não há mais etapas de validação antes de passar um paciente para um outro setor clinico?
Por que o processo de atendimento médico não é transparente e colaborativo?

Há vários outros questionamentos, mas eles podem ser abordados em próximos artigos. Vamos se ater apenas a estes, para não tornar o artigo muito longo.

Então, como posso aplicar aquelas ideias anteriores a medicina?

Revisão médica

Lembra da primeira figura explicando sobre a revisão de código? Agora, vamos atualizar alguns itens para o contexto da medicina.

Você pode estar se questionando, “Você substituiu a demanda de código por um de paciente, isso é inadequado, o paciente não é código!”. Exatamente!

Paciente não é um trecho de código e por isso requer um processo mais rigoroso no atendimento. Pois no código se há algum erro, podemos retornar ao código anterior que funcionava antes, já um erro de receita ou diagnóstico pode comprometer a seguridade do paciente ou até mesmo uma vida.

Partindo desse pressuposto, acredito que poderia ter um processo de revisão em todas as tomadas de decisão do atendimento médico, onde as revisões são feitas de forma respeitosa e com intuito de aprimorar o profissional.

Permitindo que a falha seja capturada antes da tomada de decisão. Onde a falha seja comentada e melhorada trazendo referências que tornam esse conhecimento mais fundamentado e em seguida documentado para servir de referência para outros médicos. Permitindo que o médico iniciante ou experiente não tenha tanto medo de cometer um erro e assumir essa responsabilidade. Onde o trabalho do atendimento médico se transforme para um fluxo mais colaborativo e menos individual.

Em ambientes onde não há feedbacks constantes (semanais ou mensais), possivelmente você já conheceu algum profissional que se considera que “sabe de tudo”, que a forma como trabalha “não está perfeito, mas funciona”, provavelmente este profissional não está evoluindo na carreira, sempre estagnado no mesmo lugar, fazendo do mesmo jeito errado se justificando por vários anos.

Além disso, tem um assunto delicado que é o viés ou bias do médico durante o atendimento, um exemplo seria, como um médico que advém de cultura machista e patriarcal vai atender um paciente LGBTQI2SA+ ou uma paciente que sofreu um estupro? Quais critérios subjetivos ele irá usar nesse atendimento? Entendo que todo profissional deve ser imparcial ou isento, este é o ideal, mas somos humanos e isso precisa ser considerado e avaliado em contexto.

Se você deseja se aprofundar mais nesse assunto há um artigo interessante sobre gaslighting médico: [New York Times][Veja]

Você pode me questionar: “Gostei da proposta, mas isso vai atrasar ainda mais o atendimento do paciente.”, e te pergunto de volta:

O problema está no tempo de atendimento do paciente ou na cultura dos hospitais em atender o maior número de pacientes possível?
Você prefere atender um paciente a cada 30 minutos e assumir a margem de erro e possivelmente comprometer a vida de alguém ou prefere ter um processo mais estruturado que te assegure maior qualidade em seu serviço?

Isso são questões culturais que podem ser melhoradas com o passar do tempo, mas antes precisamos questionar, trazer a consciência e propor novas formas de operar, e assim os métodos e ferramentas serão atualizados para atender essa nova demanda.

Análise de receita médica

A segunda ideia é semelhante ao análise estática de código só que ao invés de código seria voltado para medicamentos aprovados pela ANVISA, com suas formas farmacêuticas, forma de administração e concentração.

Por exemplo, a Amoxicilina possui as variações abaixo de acordo com a ANVISA:

Variações da Amoxicilina baseado nos dados da ANVISA

No momento da escrita da receita médica, se o médico digitasse Amoxicilina 700mg/5ml pó automaticamente a ferramenta acusaria um erro pois não é permitido essa variação, assim evitaria um erro durante a escrita. Funcionaria semelhante ao lint para o código.

Conclusão

Ressalto que essas ideias não garantem que ficaremos imunes à falhas. Esses fluxos nos ajudam a identificar erros mais rapidamente, corrigi-los e, assim, aprimorarmos o processo. Sem isso, seria muito pior.

Há muitas outras ideias que podem ser implementadas na medicina, como alguns rituais de Scrum como os 1:1 e Retrospectivas, que seriam ótimos momentos para debater os casos clínicos mais complexos ou para médicos se ajudarem entre si.

Eu não tenho certeza se algum dia essas ideias serão implementadas ou que haverá algum resultado, mas acredito que qualquer processo onde envolve colaboração todos se beneficiam.

Desejo que essas reflexões possam trazer novas ideias para melhorar o atendimento médico para todos os envolvidos.

Inclusive, estou desenvolvendo um projeto para ajudar médicos do SUS a fazerem suas receitas de forma mais legível e reduzir erros:

Receituário Médico SUS - Online

Prescrição médica digital, simples e gratuito.

www.receituariomedico.app

Obrigado por dedicado seu tempo a esta leitura. Fique à vontade para oferecer qualquer feedback sobre o artigo. 😊

Ferramenta usada para os diagramas: https://excalidraw.com/

Fontes: