---
title: "O conflito prático entre retenção médica e minimização de dados no PostgreSQL"
author: "Pedro Dalben"
date: "2026-10-24T11:03:12Z"
category: "Arquitetura & CTO"
reading_time: "7 min"
canonical: "https://pedrodalben.com.br/blog/o-conflito-pratico-entre-retencao-medica-e-minimizacao-de-dados-no-postgresql"
---

# O conflito prático entre retenção médica e minimização de dados no PostgreSQL

> A colisão entre a guarda de vinte anos do prontuário e a LGPD revela o perigo de auditar sistemas clínicos duplicando dados sensíveis no banco.

**Autor:** Pedro Dalben (CTO no Integrar Plus)  
**Publicado em:** 24 de October de 2026  
**URL Canônica Oficial:** [https://pedrodalben.com.br/blog/o-conflito-pratico-entre-retencao-medica-e-minimizacao-de-dados-no-postgresql](https://pedrodalben.com.br/blog/o-conflito-pratico-entre-retencao-medica-e-minimizacao-de-dados-no-postgresql)  

---


O primeiro choque que qualquer arquiteto de software enfrenta ao projetar um prontuário eletrônico no Brasil é a colisão frontal entre duas obrigações legais. De um lado, a Lei 13.787 e as resoluções do Conselho Federal de Medicina impõem a guarda dos dados clínicos por no mínimo vinte anos. Do outro lado, a LGPD exige minimização rigorosa e finalidade clara para o tratamento de dados pessoais sensíveis.

Essa tensão destrava uma discussão polarizada nos times de engenharia. A primeira posição, bastante comum entre desenvolvedores que vieram de produtos tradicionais de internet, defende aplicar mecanismos agressivos de expurgo e anonimização quase imediata de qualquer campo acessório, tratando o sistema de saúde como se fosse um comércio eletrônico. A segunda posição, típica de quem teme processos nos conselhos de classe, assume uma postura de terra arrasada jurídica: argumenta que a base legal de cumprimento de obrigação legal anula o princípio da minimização, permitindo guardar qualquer dado periférico, rascunho de tela ou log de requisição indefinidamente.

Eu considero as duas posturas equivocadas, mas a segunda me preocupa muito mais no dia a dia de produção. Dizer que a obrigação legal autoriza acumular lixo digital sensível é uma desculpa preguiçosa de arquitetura. O que a lei exige reter por duas décadas é o ato médico: a anamnese, a evolução clínica, as prescrições, os exames anexados e a identificação inequívoca de quem atendeu e quem foi atendido. A lei não exige guardar o cabeçalho HTTP de uma requisição de 2021, nem o rascunho descartado a cada toque de tecla num campo de texto rico, muito menos duplicar todo o histórico de alterações clínicas dentro de tabelas genéricas de auditoria em texto puro.

O erro mais frequente que vejo em sistemas Rails nessa área é a dependência cega de gems de versionamento de modelos que simplesmente serializam o registro inteiro em colunas JSONB a cada gravação. Quando você faz isso numa tabela de evolução médica, cada correção ortográfica feita pelo profissional cria uma cópia completa de diagnósticos, hipóteses e dados biométricos em uma tabela paralela. Em pouco tempo, a sua trilha de auditoria acumula cinco vezes mais dados sensíveis desestruturados do que a própria tabela de prontuários. Se amanhã houver um incidente de segurança, o atacante não precisa explorar as regras complexas de autorização da aplicação: basta ler a tabela de versões, onde todo o passado clínico do paciente repousa sem filtros.

Minimização em prontuário eletrônico não significa apagar o diagnóstico que o médico registrou. Significa disciplinar estritamente o que entra no banco de dados e isolar o ciclo de vida de dados que possuem prazos de validade distintos.

No modelo que adoto, separo claramente três tipos de estruturas no PostgreSQL:

1. Os dados de saúde permanentes, que constituem o prontuário de fato e possuem a regra estrita de imutabilidade clínica.
2. Os metadados administrativos e operacionais, como agendamentos, preferências de contato e dados de cobrança, sujeitos a políticas normais de retenção e exclusão mediante solicitação válida.
3. Os registros de auditoria de acesso e modificação.

A trilha de auditoria é onde o consenso técnico costuma quebrar. Quase todo mundo concorda que precisa registrar alterações. Poucos lembram que a LGPD e o sigilo médico exigem saber quem visualizou o prontuário, não apenas quem alterou. Isso muda completamente a volumetria da infraestrutura. Em uma clínica com dezenas de profissionais, o volume de leituras de telas clínicas supera em milhares de vezes o volume de edições.

Se você tentar registrar visualizações disparando uma escrita síncrona no banco a cada requisição de página via Hotwire ou Turbo Frame, você destrói a latência da interface e sobrecarrega o pool de conexões do PostgreSQL. Se deixar de registrar, você opera em desconformidade ética e regulatória.

A saída técnica que sustenta essa carga sem comprometer a estabilidade envolve transformar o evento de auditoria em algo estritamente enxuto. O registro de acesso não deve conter o conteúdo exibido na tela. Ele precisa conter apenas o identificador do operador, o identificador do paciente, o tipo de recurso acessado, a estampa de tempo em microssegundos e o endereço de rede de origem.

```ruby
class AuditReadEvent
  def self.log(user:, patient:, section:, ip:)
    AuditLog.create!(
      actor_id: user.id,
      patient_id: patient.id,
      section_accessed: section,
      ip_address: ip,
      created_at: Time.current
    )
  end
end
```

Parece uma estrutura quase simplória, mas é essa disciplina de dados mínimos que permite reter o histórico de auditoria por anos sem exaurir o armazenamento de uma VPS própria nem violar a segurança dos dados. O conteúdo lido já está gravado na tabela principal; registrar o que foi visto duplicando os textos no log é desperdício de espaço e ampliação desnecessária de risco.

Além disso, a integridade da trilha de auditoria exige defesas nativas do banco de dados. No PostgreSQL, a tabela de auditoria não pode permitir que a aplicação execute comandos de exclusão ou atualização. O usuário de conexão que o Rails utiliza para rodar a aplicação web diária precisa ter permissão exclusiva de inserção e consulta nessa tabela:

```sql
REVOKE UPDATE, DELETE ON audit_logs FROM app_user;
GRANT INSERT, SELECT ON audit_logs FROM app_user;
```

Essa barreira impede que um bug na camada de aplicação ou uma brecha de injeção acidental permita a um invasor limpar seus próprios rastros após bisbilhotar fichas de pacientes. Se um registro for gravado errado, a retificação precisa entrar como um novo registro compensatório, preservando a verdade histórica.

Existe uma incerteza técnica real quando pensamos em auditoria de visualizações em lote, como telas de listagem de pacientes na recepção ou filas de espera do dia. Se a tela exibe vinte nomes com status de atendimento, devo gerar vinte eventos de auditoria individuais ou um único evento contendo a lista de identificadores? Eu tendo a agrupar a visualização em uma única entrada com uma matriz de identificadores quando se trata de listagem administrativa, reservando o evento individual e estrito para quando a ficha clínica completa é aberta. Não encontrei jurisprudência técnica fechada sobre isso, mas operacionalmente essa distinção evita que o banco gaste metade dos seus recursos de disco apenas escrevendo logs de visualização de recepção.

Tratar a LGPD na área da saúde como um bicho de sete cabeças é consequência de tentar aplicar soluções mágicas prontas para sistemas genéricos. Minimização não é apagar o que a medicina exige guardar. Minimização é ter a coragem de não coletar campos inúteis no formulário de atendimento, não usar a trilha de auditoria como depósito de lixo JSON e garantir que os dados de tráfego temporários morram rapidamente, enquanto o prontuário legítimo permanece seguro, isolado e acessível apenas a quem tem motivo clínico para consultá-lo.