Passei quase cinco anos construindo e evoluindo um sistema de prontuário eletrônico numa healthtech. É um dos trabalhos mais desafiadores que já fiz — e também o mais revelador sobre o que significa escrever software de qualidade.
Quando o sistema que você escreve é usado por um médico no momento de atender um paciente, o conceito de "bug aceitável" deixa de existir.
O que torna um sistema de saúde diferente
A maioria dos sistemas tem consequências reversíveis. Você errou o preço num e-commerce? Estorna e reembolsa. Mandou uma notificação errada? Pede desculpa.
Num prontuário eletrônico, os dados clínicos têm rastreabilidade jurídica. Uma informação exibida errada, um dado gravado no registro errado, uma integração que falha silenciosamente com o laboratório — essas falhas têm consequências que vão muito além da experiência do usuário.
Isso muda tudo: como você escreve testes, como você modela o banco, como você faz deploy, como você prioriza débito técnico.
Modelagem de dados que resiste ao tempo
Um dos primeiros desafios foi lidar com um schema que precisava ser imutável em partes e flexível em outras.
O histórico de consultas de um paciente não pode ser alterado retroativamente — isso é auditoria. Mas os templates de anamnese mudam conforme a especialidade do médico e evoluem ao longo do tempo.
A solução que adotamos separava dados estruturados (campos fixos com colunas próprias) de dados semiestruturados (campos dinâmicos em JSONB no PostgreSQL). Com índices GIN e queries cuidadosas, conseguíamos performance aceitável mesmo em clínicas com dezenas de milhares de registros.
A lição: não existe modelagem universal. Você modela para os padrões de acesso reais, não para os hipotéticos.
Integrações com laboratórios e o caos dos padrões
A integração com laboratórios foi onde aprendi mais sobre resiliência de sistemas.
O padrão HL7 existe para garantir interoperabilidade entre sistemas de saúde. Na prática, cada laboratório implementa o padrão de um jeito diferente, com campos opcionais que eles tratam como obrigatórios, encodings inesperados e timeouts arbitrários.
Construímos uma camada de adaptadores — um por laboratório — com filas para retry, dead-letter queues para falhas permanentes e logs estruturados suficientes para conseguir debugar uma integração que falhou três horas atrás.
Sem essa rastreabilidade, seria impossível responder ao suporte: "o resultado do exame do paciente X não apareceu, por quê?"
Testes em sistemas com efeitos colaterais reais
Testar um sistema que envia pedidos de exame para laboratórios externos, gera PDFs assinados digitalmente e aciona cobranças automáticas requer isolamento cuidadoso.
Criamos ambientes de sandbox com mocks dos parceiros externos, mas mantivemos testes de integração reais rodando periodicamente contra ambientes de homologação. Mock que nunca é confrontado com a realidade vira documentação mentirosa.
O que levo para qualquer projeto
- Logs são parte da feature, não um afterthought. Se você não consegue reconstruir o que aconteceu, o bug nunca vai ser corrigido corretamente.
- Dados críticos precisam de audit trail. Saber o que mudou não basta — você precisa saber quando, por quem e a partir de qual estado anterior.
- Deploys em sistemas críticos são eventos, não rotina. Feature flags, rollout gradual e rollback documentado são obrigatórios.
Trabalhar com saúde me fez um desenvolvedor mais cuidadoso. Recomendo a experiência para qualquer engenheiro que queira elevar seu padrão de qualidade.