# Cache PACS/WADO para reduzir tempo morto em radiologia
3
4
> Cache PACS/WADO não é sobre guardar imagem; é sobre reduzir o tempo morto entre clicar no exame e começar a laudar.
5
6
Publicado em 17 de maio de 2026
7
8
Cache PACS/WADO não é sobre guardar imagem.
9
10
É sobre reduzir o tempo morto entre clicar no exame e começar a laudar.
11
12
O ponto do cache não é criar outro repositório de imagem. É aproximar o estudo do momento em que ele será usado.
16
17
## Problema
18
19
Em radiologia, a espera pela abertura do estudo costuma ser tratada como detalhe técnico.
20
21
Não é.
22
23
Quando o radiologista clica em um exame, a expectativa operacional é simples: as imagens necessárias para laudar deveriam estar disponíveis sem atrito.
24
25
Quando isso não acontece, o problema não fica restrito à infraestrutura. Ele entra no ritmo cognitivo da leitura, interrompe o fluxo e transforma abertura de exame em tempo morto.
26
27
Em um ambiente real, a causa exata da lentidão no caminho original nem sempre é simples de isolar. Pode envolver servidor, banco, storage, filesystem, quantidade de arquivos, rede ou a forma como o próprio PACS entrega os objetos.
28
29
Sem diagnóstico causal fechado, ainda assim havia um efeito observável:
30
31
o médico clicava e esperava.
32
33
## Recorte
34
35
O projeto partiu de uma hipótese pragmática.
36
37
Nem todo gargalo de radiologia precisa ser resolvido modificando o sistema principal ou esperando uma mudança no roadmap do fornecedor.
38
39
Às vezes, há valor em criar uma camada bem delimitada entre o PACS e o uso real.
40
41
Nesse caso, o recorte foi um cache WADO/PACS transparente:
42
43
- observar a fila de exames;
44
- identificar estudos prováveis de serem abertos;
45
- antecipar o download dos objetos DICOM;
46
- manter o cache próximo do ponto de leitura;
47
- entregar localmente o que já estivesse disponível.
48
49
O ganho observado foi da ordem de 6 a 8 vezes no tempo de abertura/entrega dos exames cacheados.
50
51
Esse número é útil como ordem de grandeza, não como promessa universal. O ganho depende do ambiente, da rede, do comportamento do PACS original, do tamanho dos estudos e da política de antecipação.
52
53
## Transparência
54
55
O ponto mais importante não foi apenas velocidade.
56
57
Foi transparência.
58
59
Para o usuário, nada muda.
60
61
Ele continua clicando no exame do mesmo jeito, no mesmo sistema, sem configurar viewer, endpoint, rota ou servidor.
62
63
A diferença acontece abaixo da interface.
64
65
A chamada WADO continua parecendo a mesma para o fluxo de trabalho, mas pode ser resolvida por uma camada local quando o estudo já foi antecipado.
66
67
Essa é uma diferença relevante em operação.
68
69
Se uma solução exige que o radiologista aprenda outro caminho, configure outro destino ou lembre de mais uma etapa, ela pode trocar um gargalo técnico por um gargalo de uso.
70
71
O desenho aqui tenta fazer o contrário: retirar espera sem acrescentar tarefa.
72
73
## Arquitetura
74
75
O cache não precisa estar dentro do PACS.
76
77
Ele pode ficar em um ponto controlado da rede, desde que consiga enxergar as chamadas dos clientes, alcançar os servidores WADO originais e ser anunciado ou controlado pela camada de rede.
78
79
No meu caso, o proxy/cache rodou em um mini-PC Linux simples, com Celeron N5095 e 8 GB de RAM.
80
81
O ponto não era força bruta.
82
83
Era posicionamento no fluxo.
84
85
Em termos conceituais, a arquitetura separa duas responsabilidades.
86
87
A primeira é de domínio: transformar a lista operacional de exames em candidatos de prefetch, resolver metadados, baixar objetos DICOM e manter política de cache.
88
89
A segunda é de host e rede: manter serviço, proxy, diretórios locais, regras de encaminhamento, watchdog, observabilidade básica e rollback.
90
91
Essa separação importa porque evita confundir duas coisas diferentes:
92
93
- a regra operacional de quais exames devem ser antecipados;
94
- a implantação local que faz o cache existir na rede.
95
96
## Limites
97
98
Um cache desse tipo não substitui o PACS.
99
100
Ele também não resolve todos os problemas de desempenho de imagem, nem elimina a necessidade de investigar infraestrutura quando há gargalo persistente.
101
102
Os limites são claros:
103
104
- o cache armazena DICOM e precisa ser tratado como dado clínico;
105
- a política de retenção deve ser explícita;
106
- a camada de rede precisa ter rollback simples;
107
- falhas de proxy ou redirect não podem deixar o fluxo sem caminho de retorno;
108
- o ganho depende de antecipar o exame certo antes do clique.
109
110
Por isso, a parte operacional é tão importante quanto o código.
111
112
Não basta baixar objetos DICOM.
113
114
É preciso saber quando baixar, onde manter, quando remover, como observar e como voltar ao caminho original se algo falhar.
115
116
## Síntese
117
118
Esse tipo de projeto raramente parece sofisticado em uma demonstração.
119
120
Mas ele toca um ponto concreto do trabalho radiológico.
121
122
O radiologista não quer pensar em WADO, proxy, endpoint, rota ou cache.
123
124
Ele quer clicar no exame e começar a laudar.
125
126
Se uma camada técnica consegue aproximar o estudo desse momento sem mudar o hábito do usuário, ela não está apenas acelerando download.
127
128
Ela está removendo atrito do workflow.
Rodrigo Américo Cunha de Souza
Escreve sobre operações, dados e engenharia de processos em radiologia.
