A falha no sistema de cobrança do hospital que ninguém percebeu por três semanas

Introdução

Um sistema hospitalar regional no Meio-Oeste implementou uma correção no agendamento por meio de seu processo habitual de mudanças na primavera passada. Nada dramático — uma atualização de rotina na forma como os horários de alta eram sincronizados com o módulo de faturamento. Três semanas depois, alguém do setor de contas a receber percebeu um conjunto de pedidos de reembolso sendo rejeitados por causa de discrepâncias nos carimbos de data e hora. Quando a equipe de TI identificou o problema, a correção já havia afetado os pedidos de reembolso de mais de quatrocentos pacientes. Ninguém havia feito nada de errado, propriamente dito. A atualização passou em todos os testes da lista de verificação. Só que não era a lista de verificação correta.

Essa história ficou na minha memória porque, na verdade, não se trata de hospitais. Trata-se do que acontece quando os sistemas que funcionam silenciosamente nos bastidores de uma organização são tratados como produtos acabados, em vez de uma infraestrutura viva que precisa de análise regular.

A automação que você configurou há dois anos não é a automação que você imagina que seja

A maioria das empresas cria suas primeiras automações de fluxo de trabalho para resolver um problema específico e visível. Uma equipe de RH se cansa de encaminhar manualmente os pedidos de férias. Um profissional de operações de vendas automatiza a atribuição de leads para que os representantes deixem de escolher apenas os melhores. Essas automações são criadas com ferramentas semelhantes ao Power Automate — rápidas de configurar, fáceis de passar para quem estiver disposto a assumir a responsabilidade e praticamente invisíveis depois que começam a funcionar.

O problema é que “assim que começam a funcionar” se tornam permanentes. Ninguém agenda uma revisão. A pessoa que as criou muda de equipe ou sai da empresa. Enquanto isso, o negócio muda em torno da automação — novos campos no CRM, uma hierarquia de aprovação diferente, uma fusão que dobra o volume que passa por um sistema construído para metade da carga. A automação continua funcionando exatamente como foi projetada, e esse é precisamente o problema. Ela foi projetada para uma empresa que não existe mais exatamente dessa forma.

Já vi uma empresa de logística descobrir que um fluxo automatizado de encaminhamento de exceções vinha falhando silenciosamente há onze meses porque um fornecedor alterou o nome de um campo da API. A solução alternativa? Alguém vinha reinserindo manualmente os casos com falha sem avisar ninguém, presumindo que fosse um caso isolado. Isso não é uma falha da ferramenta. É uma falha organizacional em revisar algo que todos presumiam ser estável.

Os hospitais correm o mesmo risco, mas com muito mais em jogo

Pegue esse mesmo padrão e aplique-o à estrutura clínica e administrativa de um hospital, e a margem para erros se reduz drasticamente. O desenvolvimento de software hospitalar tem, tipicamente, priorizado a conformidade e o tempo de atividade em detrimento da adaptabilidade — o que é compreensível, já que uma implantação com falha pode significar que uma enfermeira não consiga acessar o histórico de medicação às 2 da manhã. Mas essa mesma cautela faz com que os sistemas legados frequentemente permaneçam em produção por muito mais tempo do que deveriam, sendo remendados em vez de reconstruídos, porque ninguém quer ser aquele que quebra algo essencial.

O resultado é uma arquitetura que acumula decisões que ninguém se lembra de ter tomado. Um módulo de agendamento se comunica com o de faturamento por meio de uma integração criada em 2016 para um fornecedor que o hospital deixou de utilizar em 2019. Ele ainda funciona, na maior parte das vezes. “Na maior parte das vezes” não é uma expressão que se queira associar aos dados dos pacientes.

O que está mudando, aos poucos, é o reconhecimento de que a resiliência na TI da área da saúde não se trata de evitar mudanças — trata-se de construir sistemas flexíveis o suficiente para absorver mudanças sem precisar de um pequeno milagre toda vez que uma regulamentação muda ou um novo módulo de prontuário eletrônico é acoplado.

Por que “se não está quebrado” é o critério errado

A questão em ambos os cenários é a seguinte: os sistemas não estavam com defeito. Eles estavam funcionando exatamente como configurados. É exatamente por isso que ninguém prestou atenção neles.

Sistemas com defeito chamam atenção por definição — alguém reclama, algo para, um ticket é aberto. Os sistemas perigosos são aqueles que funcionam bem na superfície, enquanto, silenciosamente, ficam fora de sincronia com o que a organização realmente precisa. Uma automação de fluxo de trabalho que ainda é executada, mas encaminha para o departamento errado. Uma interface hospitalar que ainda transmite dados, mas omite um campo do qual um sistema posterior agora depende.

A auditoria não é glamorosa, mas a alternativa também não é

A solução não é complicada em teoria, mesmo que seja tediosa na prática: programe revisões periódicas de tudo o que estiver em execução sem supervisão, independentemente de quão bem tenha funcionado no passado. Pergunte quem é o responsável por isso agora. Pergunte o que mudou a montante e a jusante desde que foi criado. Pergunte se alguém perceberia se, amanhã, ele parasse de funcionar silenciosamente.

A maioria das organizações ignora isso porque parece mais manutenção do que progresso, e a manutenção raramente recebe verba ou aplausos. Mas o custo de ignorar isso não desaparece — ele apenas espera, silenciosamente, pelo momento em que alguém do setor de contas a receber perceba que os números não batem.