Radiologia não depende apenas de ter imagem armazenada.

Depende de ter imagem disponível no momento em que ela precisa ser usada.

Essa diferença parece pequena quando se olha o PACS como repositório. Ela fica grande quando se olha a fila de trabalho como operação viva. Um exame pode existir no PACS, estar tecnicamente recuperável e, ainda assim, chegar tarde demais para o ritmo de leitura, revisão ou distribuição clínica.

O Skadi Hot Cache nasce desse problema.

Não como substituto do PACS.

Como uma camada de disponibilidade para dados quentes.

O nome é deliberado.

Na mitologia nórdica, Skaði, grafada aqui como Skadi, é associada ao inverno, às montanhas, à caça e ao deslocamento por terreno difícil.

A escolha não é decorativa: o sistema opera justamente nesse território intermediário, onde o dado precisa atravessar distância, rede, PACS, nuvem e cliente antes de se tornar útil.

O contraste com Hot Cache é intencional. Skadi pertence ao frio; o sistema existe para manter quente, próximo e disponível o dado que a radiologia precisa usar no momento do clique.

O PACS é a fonte de verdade da imagem.

Mas fonte de verdade não é, necessariamente, o melhor ponto de entrega.

Em muitos ambientes, o caminho entre o exame e o usuário final passa por servidores com disponibilidade variável, WADO lento, múltiplos hops de rede, grande quantidade de arquivos pequenos, regras de fila, viewers diferentes e dependência de infraestrutura local.

Quando o usuário clica, todo esse caminho aparece como uma coisa só:

espera.

O problema não é apenas o tempo absoluto de download. É a imprevisibilidade. Um exame abre rápido, outro demora. Uma tomografia pequena chega bem, uma ressonância volumétrica trava o fluxo. Um exame anterior existe, mas buscá-lo no momento do uso custa tempo demais.

Em radiologia, essa espera não é neutra. Ela interrompe continuidade cognitiva, adia comparação, reduz a chance de usar exames anteriores e transforma disponibilidade técnica em atrito operacional.

O recorte do projeto é simples:

O ganho não vem de inventar outro viewer.

Vem de mudar o ponto de entrega.

Em vez de o cliente depender da recuperação síncrona no PACS no momento do clique, o sistema antecipa o trabalho pesado e deixa os pacotes prontos em uma infraestrutura com melhor disponibilidade, melhor throughput e comportamento mais previsível.

O Skadi não é apenas uma pasta de arquivos em nuvem.

Na prática, ele combina duas responsabilidades diferentes.

A primeira é a publicação da fila. O Skadi materializa listas operacionais como plantao, medicina-interna, neurorradiologia, msk e cardiovascular, já com ordem de trabalho, metadados, SLA e indicação de quais artefatos em nuvem estão disponíveis para cada accession number.

A segunda é a preparação do dado pesado. Essa parte fica com o broker DICOM.

No Orchestrum, a fronteira canônica dessa preparação é o stack imaging_hot_cache. O nome antigo opportunistic_metrics ainda aparece como detalhe interno de compatibilidade, mas o papel operacional é outro: manter imagem e artefatos quentes para o fluxo de leitura.

O broker observa candidatos TC/RM, consulta o inventário do exame, aguarda janelas de estabilidade e rechecagem, baixa o estudo por WADO, empacota o exame pai por séries e publica manifestos e artefatos em /artifacts/{AN}.

Essa separação é importante.

O cliente não precisa descobrir sozinho se existe exame pai, anterior, laudo anterior DICOMizado ou artefato de pipeline. As listas do Skadi recebem, em lote, um resumo cloud_artifacts para parent_dicom, prior_exams e heimdallr.

Isso evita que cada linha da fila vire uma investigação própria. O cliente recebe esse estado na lista e, quando o dado está disponível, consome o pacote preparado pela camada de artefatos.

O cache quente não precisa copiar todo o PACS.

Esse é um ponto importante.

O projeto trabalha com dados operacionais de curto prazo:

O objetivo não é retenção longa.

É disponibilidade rápida para aquilo que está em uso ou prestes a entrar em uso.

Essa diferença muda a arquitetura. Um arquivo frio, arquivado por anos, precisa de política de preservação. Um dado quente precisa de política de descoberta, atualização, expiração e entrega.

Para exames anteriores, um ZIP único é suficiente.

O usuário não precisa navegar série a série de cada anterior antes de decidir se baixa. O pacote existe para comparação e contexto.

Para o exame pai, a lógica muda.

O estudo principal é o primeiro objeto de trabalho. Se ele for empacotado em um único ZIP grande, o cliente só começa a usar o exame depois que tudo terminou. Isso transforma uma camada rápida em uma entrega ainda sequencial.

Por isso, o exame pai pode ser quebrado por séries:

Antes do bloco de ZIPs, o manifest também pode listar anexos clínicos DICOMizados e amostras centrais das séries principais. A ideia é permitir que o cliente comece a abrir contexto DICOM enquanto os pacotes completos ainda estão descendo.

O cliente pode iniciar pelos itens mais importantes e seguir a ordem declarada. A nuvem entrega rápido, mas o formato também importa. Não basta aproximar o dado; é preciso empacotar de modo compatível com uso progressivo.

Nos testes que motivaram o desenho, o problema não era abstrato.

Em dois PACS avaliados, o acesso nativo pela Internet ficava, de modo observado, na faixa de 20 a 60 Mb/s.

Isso não é necessariamente ruim para qualquer uso.

Mas, para TC e RM, com muitos objetos DICOM e necessidade de comparação rápida, essa faixa ainda deixa o usuário exposto à latência do PACS original no momento mais sensível: depois que ele já decidiu abrir o exame.

Quando o mesmo tipo de entrega passou pela camada em nuvem na AWS, a velocidade observada chegou a aproximadamente 550 Mb/s.

Esse número não deve ser lido como garantia universal. Ele depende de região, rota, cliente, empacotamento, concorrência, infraestrutura local e tamanho dos pacotes.

Mas ele muda a ordem de grandeza do problema.

Se a entrega sai de dezenas para centenas de megabits por segundo, o cache deixa de ser apenas otimização técnica. Ele passa a ser uma forma de deslocar espera para antes do clique e transformar variabilidade de PACS em disponibilidade mais previsível para o cliente.

O manifest é o contrato entre a camada de cache e o cliente.

Ele informa quais partes do exame estão disponíveis, em que ordem devem ser baixadas, qual URL usar, qual SHA-256 esperar e quais séries existem em cada pacote.

Esse detalhe evita que o cliente precise adivinhar estrutura de storage.

Também permite que a interface mostre disponibilidade real:

No caso do exame pai, a disponibilidade não é tratada como um booleano superficial. O estado complete só deve aparecer quando o manifest e os artefatos referenciados por ele estão prontos, com tamanho e hash coerentes.

O manifest não é um detalhe administrativo. Ele transforma um conjunto de arquivos em um estado operacional legível.

Exames radiológicos não são sempre estáticos no primeiro momento em que aparecem.

Um estudo pode ser descoberto, baixado, publicado e depois receber novas imagens em uma rechecagem posterior.

Por isso, o cache precisa tratar atualização como parte normal do fluxo. Quando o fingerprint do inventário muda, o pacote publicado deixa de ser a melhor representação do exame. A versão antiga deve ser removida e uma nova deve ser publicada.

Esse comportamento é mais importante do que parece.

Sem ele, o cache rápido vira uma fonte de divergência silenciosa.

Com ele, o cache continua sendo uma camada de entrega, não uma fonte concorrente de verdade.

O Skadi Hot Cache lida com dado clínico.

Isso exige que a simplicidade operacional não vire descuido.

O desenho assume:

A decisão relevante aqui é não transformar cada AN em uma permissão individual. Em uma fila operacional dinâmica, esse modelo ficaria caro, frágil e pouco aderente ao uso real. O controle mais natural é por usuário, instalação, escopo e auditoria.

O cache quente não resolve tudo.

Ele não substitui o PACS, não corrige metadados ruins, não elimina falhas de origem e não dispensa política de segurança.

Também não deve virar arquivo permanente por acidente. Se tudo fica retido indefinidamente, o projeto muda de natureza e passa a disputar o papel de repositório.

O limite saudável é outro:

Grupos órfãos expiram por janela separada. Isso preserva o caráter de cache, não de arquivo.

O Skadi Hot Cache é uma camada de distribuição para radiologia em tempo operacional.

Ele parte de uma constatação pragmática: o dado existir no PACS não garante que ele esteja disponível com a velocidade, previsibilidade e ergonomia que o trabalho exige.

Ao transferir dados quentes para uma camada em nuvem, empacotar o exame de forma progressiva e expor manifestos legíveis ao cliente, o sistema reduz a distância entre fila, imagem, anterior e artefato.

O resultado esperado não é apenas download mais rápido.

É uma experiência de leitura em que a infraestrutura aparece menos.