Uma forma simples de perder tempo em radiologia é fazer o médico esperar o exame chegar depois que ele já decidiu laudar.

Isso parece pequeno.

Mas, em escala, vira fricção diária.

O fluxo cotidiano pode parecer simples: olhar a fila, escolher um exame, abrir o viewer e laudar.

Só que, em muitos ambientes, existe uma etapa intermediária mal resolvida.

O exame ainda precisa ser baixado.

As imagens ainda precisam chegar.

O viewer ainda precisa importar o estudo.

E, em alguns fluxos, anexos clínicos ainda precisam ser encontrados em outro lugar.

E, quando isso acontece depois da decisão de laudar, o tempo perdido já entrou no fluxo do radiologista.

O Nox nasceu para atuar exatamente nessa fricção.

Não como PACS.

Não como viewer.

Não como sistema de laudo.

Mas como uma ferramenta local de aquisição DICOM orientada por fila.

A versão macOS é uma aplicação nativa em Swift/AppKit.

Esse recorte importa.

O objetivo não era carregar um runtime pesado para uma tarefa estreita, nem transformar a estação de leitura em bancada de engenharia.

Era criar uma interface pequena, rápida e aderente ao uso real.

Na build observada, o executável nativo tinha 828 KB, o bundle .app cerca de 1,1 MB e o pacote .dmg cerca de 465 KB.

O tamanho não é o valor principal do projeto.

Mas ele ajuda a mostrar a tese: software operacional útil em saúde digital nem sempre precisa ser grande.

Às vezes, precisa ser pequeno, específico e bem posicionado.

Um ponto importante é que a fila não é montada manualmente por cada usuário.

Ela vem de uma fonte central.

Na prática, o app consome listas prontas, como Plantão, Medicina Interna, Cardiovascular, Neurorradiologia e Músculo-Esquelético.

Essas listas são servidas a partir de queries estruturadas em banco, já com metadados úteis para operação: data, hora, SLA, unidade, accession number, paciente, modalidade, quantidade de imagens, especialidade e tipo.

Isso muda o papel da interface.

Ela deixa de ser uma tela onde o usuário tenta descobrir o que deve fazer.

Passa a ser um consumidor local de uma decisão operacional centralizada.

No desenho do Nox, a estação local não é a fonte de verdade da operação.

O cliente macOS não tenta carregar regra de negócio local que deveria ser compartilhada com outros clientes ou com a operação.

Ele consome contratos publicados pelo backend.

A fila, a ordem, a disponibilidade de pacotes em nuvem, os anexos DICOMizados, artefatos de IA publicados como egress, as referências para exames anteriores, a informação clínica resumida e algumas ações operacionais vêm de serviços externos.

O app nativo fica com uma função mais estreita: apresentar a lista, executar ações autorizadas, baixar arquivos, manter estado local, abrir no viewer e reduzir atrito na estação de leitura.

Essa separação evita transformar uma GUI local em sistema de verdade da operação.

O Nox coordena dois caminhos possíveis para aproximar o exame do viewer.

O primeiro é o caminho direto pelo PACS. Na implementação atual, esse caminho usa WADO, mas a ideia não depende de um protocolo específico.

O segundo é o caminho pelo Skadi Hot Cache, quando já existem pacotes e artefatos prontos em nuvem.

Essa diferença é central para entender o projeto.

O Skadi não substitui o PACS.

Ele é uma camada intermediária.

A fonte de verdade clínica permanece sendo o PACS.

O que o Skadi faz é publicar sinais operacionais que ajudam o cliente local a escolher melhor como baixar e entregar o material.

Na interface do Nox, isso aparece em colunas como Zip, Ant e Art.

Zip indica que o exame atual pode ter pacote DICOM pronto em nuvem.

Ant sinaliza exames anteriores disponíveis, ou a ausência confirmada deles.

Art aponta artefatos derivados, incluindo material produzido fora do PACS.

Quando o manifesto do exame está disponível, o Nox pode não precisar buscar o exame diretamente no PACS, série por série. Ele pode consumir os pacotes publicados pelo Skadi.

O cliente lê a ordem de download, baixa os ZIPs em sequência, valida o tamanho quando essa informação foi publicada e só entrega o arquivo completo ao destino do viewer.

Isso evita que o OsiriX ou o Horos enxerguem um ZIP parcial como se fosse um artefato pronto.

O caminho direto ao PACS existe como opção explícita ou de retaguarda.

A ação Baixar do PACS, por exemplo, força o fluxo direto pelo PACS e não consulta os artefatos do Skadi.

Essa distinção importa porque ela preserva duas ideias ao mesmo tempo:

Também muda a economia do download.

Nos testes, o PACS nativo acessado pela Internet ficava na casa de 20-60 Mb/s.

Com os pacotes servidos pela AWS, a velocidade chegou a 550 Mb/s.

Quando essa diferença aparece na prática, o problema deixa de ser apenas "como baixar mais cedo".

Passa a ser "como escolher o melhor caminho e entregar rápido quando o radiologista precisa".

O monitoramento continua fazendo sentido em um cenário específico: quando o caminho disponível é buscar imagens diretamente no PACS.

Nesse fluxo, a aplicação pode consultar o PACS em ciclos, perceber que um exame apareceu cedo na fila, identificar novas imagens chegando depois e baixar o que falta antes da decisão de leitura.

É uma forma de compensar uma origem lenta e variável.

Com o Skadi, a lógica muda.

Se o exame já está aquecido em nuvem e pode ser entregue muito mais rápido, monitorar para baixar preventivamente deixa de ser a estratégia principal.

O ganho passa a estar menos em sondar o PACS o tempo todo e mais em priorizar corretamente a fila local, escolher entre Img PACS e Img Skadi e abrir o viewer no momento certo.

Por isso a fila persistente de Downloads é uma peça central do cliente.

Essa fila pode ser alimentada por ações manuais, por Baixar agora, pela intenção de abrir um exame, por exames anteriores selecionados e por outros comandos autorizados.

O app abre na tela de downloads, mantém a fila entre sessões e permite pausar, retomar, reordenar, limpar e abrir itens já entregues.

Esse detalhe parece operacional, mas muda a ergonomia.

O usuário deixa de depender de uma ação frágil e repetida no momento da leitura.

Ele pode organizar a fila antes, ou deixar que a própria intenção de abertura promova um item para prioridade.

Na tela, o progresso também ficou mais honesto: há separação entre Img PACS e Img Skadi.

Img PACS representa o caminho direto ao PACS.

Img Skadi representa pacotes do exame atual, anteriores e artefatos derivados vindos do cache quente.

Além de baixar o exame atual, o cliente aproveita outros sinais publicados junto da fila.

Quando a lista informa que há exames anteriores disponíveis, o Nox pode abrir um diálogo de seleção, baixar o manifesto leve, validar a referência publicada e, só então, carregar o snapshot completo para permitir que o usuário escolha quais anteriores baixar.

Os exames anteriores selecionados entram em uma fila própria, sem misturar essa ação com o download do exame atual.

Outro contrato útil é a informação clínica.

Quando há contrato de backend para informação clínica, o app pode copiar uma síntese para a área de transferência. Se não houver informação clínica publicada, isso aparece como ausência de dado, não como falha técnica do fluxo de imagem.

Esse detalhe é importante porque o projeto não está tentando fazer o viewer ou o PACS virarem interface universal de contexto. Ele aproxima o contexto que já foi estruturado no backend do ponto em que a leitura acontece.

Outra dor prática são os anexos do paciente.

Na ponta, nem sempre se controla bem a qualidade ou o tamanho do que foi digitalizado. O resultado pode ser um PDF grande, pesado, fora do fluxo natural de leitura.

No Nox, quando configurado, o cliente também consome anexos já DICOMizados.

Aqui a fronteira é importante: a aplicação macOS não é quem busca o PDF original nem faz a DICOMização.

Esse trabalho fica em outra aplicação, que consulta o endpoint adequado, transforma o conteúdo em DICOM e expõe os arquivos pela API de artefatos.

O Nox consome essa API, baixa os arquivos publicados e entrega os anexos no mesmo destino operacional dos DICOMs do exame.

Na prática, o anexo deixa de ser uma peça externa que o usuário precisa procurar manualmente e passa a chegar junto do fluxo de imagem, quando disponível.

O mesmo desenho também ajuda em outra dificuldade prática: incorporar artefatos de uma pipeline de IA em um fluxo que continua girando em torno do PACS e do viewer.

Nem todo resultado útil de IA precisa, ou consegue, nascer dentro do PACS.

Às vezes o artefato é produzido por uma pipeline externa, com autenticação, contrato próprio e controle de acesso adequado.

Nesse cenário, o Nox pode consumir esse egress como artefato do Skadi e aproximar o material do exame na estação de leitura, sem exigir que o PACS passe a conhecer nativamente aquela pipeline.

Essa diferença é relevante.

O app não transforma um resultado de IA em decisão clínica automática.

Ele apenas entrega, no ponto de uso, um artefato que já foi produzido e autorizado por outro componente do sistema.

No macOS, o destino natural é usar OsiriX ou Horos.

O Nox pode gravar os DICOMs diretamente na pasta incoming do viewer, permitindo importação progressiva quando o caminho é a entrega direta a partir do PACS.

Quando o caminho é o Skadi, ele usa área de staging fora do incoming e só move o pacote completo para o destino operacional depois da validação.

Isso reduz a necessidade de o usuário ficar gerenciando arquivos, pastas ou etapas manuais.

O objetivo é simples:

quando o radiologista for abrir o estudo, o exame já deve estar mais perto de estar pronto.

O Nox não substitui o PACS.

Não interpreta imagem.

Não decide prioridade clínica sozinho.

Não assina laudo.

E não tenta resolver todos os problemas de distribuição DICOM de uma instituição.

O projeto tem uma fronteira mais estreita:

Essa fronteira é justamente o que torna o projeto útil.

Ele não controla a qualidade da digitalização na ponta, não substitui o serviço que DICOMiza os anexos e não transforma cache em fonte de verdade. Apenas aproxima esse material do ponto de leitura quando ele já foi publicado em formato consumível.

Em radiologia, tempo perdido nem sempre aparece como grande falha.

Às vezes, aparece como pequenos intervalos repetidos: esperar a lista carregar, esperar o exame baixar, esperar o viewer importar, verificar se chegaram mais imagens, procurar anexos que deveriam estar no mesmo fluxo.

O Nox tenta reduzir essa camada de atrito.

Não por força bruta.

Mas por uma ideia simples:

fazer a fila trabalhar antes do clique.