Manual do Carino DICOM

O Carino DICOM é um gateway DICOM e um equipamento de continuidade: recebe estudos, roteia e encaminha, publica o acervo por Query/Retrieve e DICOMweb, e sustenta o setor de imagem quando o PACS ou o RIS param de responder. Este manual cobre a instalação, as tarefas do dia a dia e o que fazer quando elas falham, o modelo de segurança, cada serviço e os limites reais do software.

Todas as capturas deste manual são de uma instância real deste software com estudos inventados para a foto. Nenhum paciente aparece aqui.

1. O que é e qual papel ele cumpre

O Carino DICOM fica entre os equipamentos que geram imagem e os sistemas que guardam ou leem essas imagens. Ele não tenta substituir o seu arquivo: ele quer ser a peça que liga os dois e a que continua de pé quando alguma das outras cai.

São dois papéis, e vale distingui-los porque é isso que define quais serviços você liga:

• Gateway permanente. Recebe por C-STORE, grava em disco por paciente/estudo/série, encaminha para um ou vários destinos conforme regras, anonimiza a cópia que sai quando você pede, e publica o que tem por Query/Retrieve (para equipamento antigo) e por DICOMweb (para visualizadores modernos).
• Rede de segurança. Se o PACS principal para de responder, ele pode ativar a própria Modality Worklist para os técnicos continuarem examinando, segurar o que chega durante a queda e encaminhar automaticamente quando o principal volta. Também recebe pedidos HL7 por MLLP — ou digitados à mão — quando quem caiu foi o RIS.

Tudo é definido em um único config.json e tudo roda sem interface gráfica. O painel web é conveniente, não obrigatório.

Portas padrão

2. Primeiros passos

Escolha a forma de rodar

App de desktop

Baixe o pacote do seu sistema na página de releases e abra. Ele fica na bandeja do sistema; ao clicar, abre o painel. Como ainda não é assinado digitalmente, Windows e macOS avisam na primeira execução: a página inicial traz o passo a passo para abrir mesmo assim.

Na primeira execução ele pergunta, uma vez só, se pode consultar no GitHub se existe uma versão mais nova. Responder que não — ou fechar a pergunta — deixa desligado, que é como ele vem. Se estiver ligado, uma versão nova aparece como uma linha no menu da bandeja e ao lado da versão no painel Resumo; clicar em qualquer uma das duas abre a página do release no seu navegador. Nada é baixado e nada se instala sozinho. A opção Procurar atualizações no menu da bandeja liga e desliga isso quando você quiser, e só a versão de desktop tem essa função: as instalações em contêiner e com systemd não têm.

Docker

git clone https://github.com/MiguelCarino/Carino-DICOM
cd Carino-DICOM
mkdir -p data
echo "PACS_UID=$(id -u)" >> .env
echo "PACS_GID=$(id -g)" >> .env
docker compose up -d --build
docker compose logs -f pacs

A primeira inicialização gera e imprime um token de acesso no log. Abra http://127.0.0.1:8042/ e cole o token quando o painel pedir. Tudo — configuração, estudos, logs, índice — fica em ./data, que é o que você precisa incluir no backup.

Serviço systemd (Linux)

git clone https://github.com/MiguelCarino/Carino-DICOM.git
cd Carino-DICOM
sudo packaging/systemd/install.sh

O instalador cria o usuário de sistema carino-pacs, copia o código para /opt/carino-pacs, prepara /var/lib/carino-pacs e deixa a unit instalada… e não inicia o serviço. Não é esquecimento: iniciar um PACS abre portas que aceitam dados de pacientes, e essa decisão se toma depois de ler a configuração, não antes. Edite /var/lib/carino-pacs/config.json e então:

sudo systemctl enable --now carino-pacs
systemctl status carino-pacs
journalctl -u carino-pacs -f

Rodar o instalador de novo atualiza o código sem tocar no seu config.json.

Onde ficam os dados

O config.json fica junto dos dados, e não em /etc, porque os caminhos relativos do config ("./received", "./logs", "./index.db") são resolvidos em relação ao diretório do próprio arquivo de configuração. Um config em /etc espalharia estudos de pacientes pelo /etc.

Primeira execução, na ordem

1. Escolha os serviços. Tudo vem desligado. O assistente do painel pergunta o que esta máquina deve rodar; ligue só isso.
2. Cadastre os destinos (nome, host, porta, AE title) na aba Destinos de Configuração — é a aba com que ela abre.
3. Teste a conectividade antes de mover uma única imagem: clique em Echo na linha do destino. Numa máquina sem painel, ./run.sh echo --name "PACS do hospital" faz o mesmo. Se o echo não passa, o problema não é o Carino: é rede, firewall ou AE title.
4. Aponte um equipamento para cá usando a linha Aponte o equipamento para do cartão do receptor, e envie um estudo de teste (veja Como faço para…).
5. Olhe a aba Registro de Atividade. Se algo falhar, aparece ali, e também no cartão do serviço como Último problema; este software prefere gritar a falhar em silêncio.

Sem interface gráfica

./run.sh init            # cria config.json e as pastas
./run.sh init --token    # e ainda gera o web.auth_token
./run.sh serve           # painel em http://127.0.0.1:8042
./run.sh receive         # só o receptor
./run.sh send            # só o monitoramento de pasta / encaminhamento
./run.sh qr              # só Query/Retrieve
./run.sh mwl             # só a worklist
./run.sh ris             # só o receptor de pedidos HL7
./run.sh print           # só a impressora virtual
./run.sh echo --host 10.0.0.5 --port 104 --aet PACSREMOTO

Todos os comandos aceitam -c / --config <caminho>. No Windows, run.ps1.

3. Como faço para…

Receitas curtas para as tarefas do dia a dia no setor. Cada uma termina dizendo como você sabe que deu certo; se não deu, o capítulo seguinte é a lista do que conferir.

…apontar uma modalidade para cá para guardar imagens

1. Abra Serviços. Se o cartão Receptor disser que está parado, clique em Iniciar.
2. Leia a linha Aponte o equipamento para do cartão: um AE title, um endereço IP e uma porta (por padrão CARINODICOM e 11112). O botão de copiar ao lado copia os três. Se a máquina tiver mais de um endereço, use o que está na rede da modalidade.
3. Na modalidade, cadastre um destino de armazenamento — cada fabricante chama de um jeito: nó DICOM, arquivo, «Enviar para», destino de «Store» — com esses três valores. O AE title da própria modalidade é o AE chamador; você não precisa digitá-lo aqui.
4. Se Configuração → Configurações → Este PACS tiver AE titles em Aceitar apenas estes AEs, inclua ali o AE title da modalidade, ou o receptor a recusa.
5. Rode o teste de conexão da própria modalidade (costuma se chamar Verify ou Echo) e depois envie um estudo. Ele aparece em Estudos → Histórico.

O botão Testar do cartão verifica o receptor a partir desta própria máquina. Se o Testar passa e a modalidade continua falhando, o problema está entre os dois: endereço, porta, firewall ou a lista de AEs permitidos.

…apontar uma modalidade para cá para imprimir

Para equipamentos cuja única saída é o filme. O Carino finge ser a impressora de filme e captura cada folha para você identificar; nada é impresso em papel.

1. Abra Serviços e clique em Iniciar no cartão Impressão.
2. Leia a linha Aponte o equipamento para do cartão (por padrão CARINOPRINT, o IP desta máquina e a porta 11113).
3. Na modalidade, cadastre uma impressora DICOM — às vezes chamada de impressora a laser ou impressora de filme — com esses três valores. Tons de cinza são sempre oferecidos; se a modalidade só imprime em cores, marque Aceitar também trabalhos de impressão em cores em Configuração → Configurações → Impressão.
4. Clique em Enviar impressão de teste no cartão. Em poucos segundos aparece em Estudos → Pendentes uma folha marcada TEST PRINT — safe to discard (impressão de teste, pode descartar). Isso prova que o receptor funciona; descarte a folha.
5. Imprima um filme a partir da modalidade. O cartão mostra Última impressão com o número de filmes, o AE title da modalidade e o endereço dela, o contador Capturados sobe, e o filme espera em Pendentes para você aprovar (veja abaixo).

Salvar cada filme capturado como (em Impressão) decide em que o filme se transforma quando você aprova. Muitos arquivos e visualizadores guardam um PDF mas não o mostram; escolha Imagem (Secondary Capture) se o filme precisar ser lido do outro lado.

O AE title da impressora digitado na modalidade não é conferido: mesmo com erro de digitação, a impressão sai. Só o AE title da própria modalidade é filtrado, e só se você preencher Aceitar apenas estes AEs. Se uma impressão falhar, o cartão mostra Último problema; a tabela de problemas de impressão lista cada mensagem e a solução.

…apontar uma modalidade para cá para puxar a worklist

1. Garanta que haja pedidos. Ou o RIS envia pedidos HL7 ao serviço RIS de emergência (porta 2575), ou alguém os digita em Pedidos → Novo pedido.
2. Em Configuração → Modalidades, registre a sala com o AE title exato da estação. O destino de um pedido passa a ser escolhido nessa lista em vez de digitado.
3. Abra Serviços, clique em Iniciar no cartão Worklist e leia a linha Aponte o equipamento para (por padrão CARINOMWL e a porta 11114).
4. Na modalidade, configure o provedor de worklist (MWL, «HIS/RIS» ou «servidor de worklist») com esses valores e faça a consulta.

Um pedido sem destino aparece em todas as estações; um pedido com destino aparece só na estação cujo AE title bate exatamente com ele. Quando o estudo volta, é conciliado com o pedido pelo accession number e o pedido se fecha sozinho.

…aprovar um filme pendente

Os filmes capturados, e os PDFs ou imagens encontrados junto de um estudo, esperam em Estudos → Pendentes. O contador 📎 ao lado de Estudos diz quantos são.

1. Abra Pré-visualizar e olhe a folha.
2. Se o paciente tiver um pedido aberto, clique em Associar a um pedido… e escolha-o. Nome, ID do paciente, accession e estudo vêm do pedido, e o pedido é fechado como capturado.
3. Senão, digite a identidade você mesmo. ID do paciente e Nome do paciente são obrigatórios; accession, data e descrição são muito recomendados.
4. Se o item chegou junto de um estudo e você trocou o paciente, escolha a que ele pertence: Anexar ao estudo original só se aquele estudo for mesmo deste paciente; senão, Novo estudo. A escolha errada arquiva a folha de um paciente dentro do estudo de outro.
5. Clique em Aprovar e enviar. O item é convertido em DICOM e encaminhado como qualquer outro estudo.

Não há como desfazer: depois de aprovado, o arquivo original sai de Pendentes e a cópia DICOM já está a caminho. Um erro se corrige no arquivo de destino. Descartar remove um item sem enviá-lo.

…resolver um encaminhamento travado

Abra Estudos → Travados (o contador ⚠ ao lado de Estudos). As linhas são agrupadas por estudo, com paciente, accession e descrição, e separadas em três tipos:

• Tentando automaticamente — um destino recusou ou não respondeu. Leia o erro da linha: ele diz se o destino nos rejeitou (e por quê, por exemplo «add CARINOSCU to the remote's allowed AE titles», ou seja, cadastre CARINOSCU lá), se derrubou a conexão ou se nunca respondeu. Corrija isso, clique em Echo na linha do destino em Configuração → Destinos e depois em Tentar agora.
• Retido — nada está sendo enviado — uma retenção por anonimização. Nenhum temporizador a libera; use os dois botões da linha e veja Anonimização no encaminhamento.
• Sem destino para tentar — os arquivos estão encaminhados a um destino que foi apagado ou desligado. Ligue-o de novo, ou clique em Enviar para… e escolha outro destino, ou em Remover da fila (ele pergunta antes) para aceitar a perda.

…descobrir por que algo falhou

1. Olhe o cartão do serviço. Todo listener mostra Último problema quando algo deu errado; clique nele para abrir o registro já filtrado por aquele serviço.
2. Em Atividade → Registro, use os chips de serviço (store, send, print, worklist, Q/R, RIS…), Só erros e avisos e o filtro de texto — um AE title, um endereço IP ou um accession number estreitam a busca rápido.
3. Para passar o problema adiante, copie as linhas visíveis ou baixe o registro de um dia inteiro.
4. Clique em Testar no cartão. Se o teste passa a partir desta máquina e a modalidade continua falhando, olhe a rede entre as duas.
5. Se uma configuração mudou e ninguém sabe quem mudou, Atividade → Auditoria nomeia a pessoa e as seções que ela alterou.

4. Quando algo dá errado

Primeiro o sintoma, depois onde olhar, depois a solução. Quase toda linha começa nos mesmos dois lugares: o cartão do serviço em Serviços (o Último problema dele) e Atividade → Registro. As linhas de registro aparecem em inglês, como o motor as escreve.

Envio, recepção e worklist

Impressão

Cada recusa e cada falha do receptor de impressão vira uma linha no registro (o chip print), conta nos Erros do cartão e aparece como o seu Último problema. Um trabalho bem-sucedido aparece como Última impressão.

Duas coisas que não são a causa: o AE title da impressora digitado na modalidade (ele não é conferido) e a modalidade deixar para a impressora a numeração da sessão de filme e da caixa de filme (elas são criadas aqui quando faltam). Uma Presentation LUT é aceita e ignorada, e uma modalidade que primeiro pergunta a configuração da impressora recebe resposta.

5. O modelo de segurança e a regra do token

Comecemos pelo que importa: o painel é a chave do acervo. Quem abre o painel pode ler todos os estudos armazenados, baixar os arquivos DICOM, mudar qualquer configuração, iniciar e parar serviços, apagar estudos e desligar o servidor. De fábrica há um único segredo compartilhado e quem o tem pode tudo: os perfis são opcionais e ficam desligados até você ativá-los. Ao ativar, cada pessoa entra como ela mesma, com as próprias permissões, a própria visão dos identificadores do paciente e o próprio nome na auditoria; o token compartilhado continua funcionando como administrador, então nada que já o utilize deixa de funcionar.

As mesmas permissões desenham a navegação. Uma linha da lateral aparece se o perfil tiver alguma das permissões que as abas dela pedem, e depois cada aba é conferida por conta própria: um Radiologista, que tem routing.read e não tem config.read, abre Configuração e enxerga Destinos e Rotas, mas nenhuma aba Configurações, que é onde ficam o token da API e o desligamento do servidor. A Recepção, que não tem nenhuma das três permissões, não vê a linha Configuração.

A regra

O motivo é concreto. Sem autenticação, em 127.0.0.1, o sistema operacional é o controle de acesso: só um processo da própria máquina consegue falar com a API. Isso se defende. Mas web.host é configurável pelo operador, e no dia em que alguém troca para 0.0.0.0 para «acessar do outro PC» — com pressa, numa terça-feira, sem pensar em segurança — essa mesma API entrega a qualquer vizinho de rede a lista de estudos, os caminhos de armazenamento, os bytes DICOM e o /api/shutdown. A regra existe porque essa mudança leva dez segundos e as consequências duram anos.

Todo contêiner está sempre nesse caso: um contêiner publica em 0.0.0.0 por construção. Por isso a imagem gera um token de 256 bits na primeira inicialização se você não fornecer um — e o imprime. O que ela nunca faz é gerar em silêncio: um segredo que ninguém vê é um segredo que ninguém rotaciona.

Como gerar e como enviar o token

./run.sh init --token                                  # grava no config.json
python3 -c "import secrets; print(secrets.token_urlsafe(32))"
openssl rand -base64 32

O servidor aceita a credencial de três formas:

• Authorization: Bearer <token>
• X-Carino-Token: <token>
• um cookie de sessão emitido por POST /api/login

O cookie existe para o painel pedir o token uma vez em vez de guardá-lo em JavaScript, onde qualquer XSS e qualquer extensão do navegador conseguem ler. O cookie não carrega o token: carrega um HMAC calculado com um segredo gerado na inicialização e mantido só em memória. Por isso um restart desloga todo mundo — é a troca certa para um equipamento de operador único: nada guardado em disco para vazar, e no pior caso digita-se o token de novo uma vez por plantão.

O lado DICOM

• allowed_aets — lista branca de AE titles que podem se associar. Vazia significa «aceita qualquer um». É um filtro útil, não autenticação: o DICOM não autentica quem chama.
• DICOM-TLS — disponível dos dois lados e de forma independente, inclusive TLS mútuo com certificado de cliente. Usa a mesma porta: um par em texto claro não conversa com um receptor TLS, nem o contrário. TLS criptografa e autentica o transporte, não a aplicação: combine com allowed_aets ou com certificados de cliente para ter controle de acesso de verdade.
• Firewall — os listeners DICOM escutam em 0.0.0.0 por padrão (embora todo listener venha desligado até você ligar). Isso está certo para algo que as modalidades precisam alcançar, e significa que cabe a você restringir por firewall à sub-rede das modalidades.

O que o modelo não protege

• Os perfis ficam desligados até você ativá-los. Até lá há um único segredo compartilhado para o equipamento inteiro, sem contas, sem perfis de acesso e sem permissões. Esse continua sendo o padrão, porque ativá-los em silêncio durante uma atualização quebraria todos os clientes automáticos do site.
• Não há integração com o seu diretório. As contas vivem no equipamento. Não há LDAP, nem Active Directory, nem logon único, nem como desativar alguém de forma centralizada quando essa pessoa sai.
• A trilha de auditoria pode ser truncada. Ela detecta um registro editado, um removido do meio, registros reordenados e um arquivo cortado no meio da linha — cada caso quebra um resumo, e Verificar integridade diz em qual registro e por quê. Não detecta a exclusão dos últimos registros, porque o que sobra é uma cadeia genuinamente válida, nem impede que alguém com permissão de escrita na pasta a reescreva inteira. Se você precisa de não repúdio, copie o topo da cadeia para um lugar onde esta máquina não possa escrever e compare depois.
• Não há criptografia em repouso. Os estudos são arquivos DICOM comuns, o índice sqlite guarda nomes e identificadores em claro, os pedidos são JSON e o config.json guarda o token em texto puro. Criptografe o volume por baixo (LUKS, BitLocker, FileVault) e restrinja as permissões do diretório de dados.
• O listener HL7/MLLP não tem TLS nem credencial. É um socket TCP com enquadramento MLLP. Seu único controle é o allowed_hosts, que confere o endereço do par e portanto é falsificável. Quem conseguir abrir uma conexão nessa porta consegue injetar pedidos que aparecem na worklist. Amarre a um segmento clínico confiável e proteja com firewall.
• A anonimização não toca nos pixels. Veja o serviço correspondente abaixo: o que está gravado na imagem sobrevive a todos os perfis.

6. Os serviços, um a um

Tudo o que abre uma porta vem desligado. A pergunta certa não é «o que ele consegue fazer?», e sim «o que esta máquina precisa fazer?». Cada serviço ligado é mais uma porta aberta. O índice abaixo é a única exceção: ele sobe sozinho, porque é um cache sqlite local que não abre porta nenhuma.

Cada serviço tem um único interruptor. Iniciar no cartão liga o serviço e o mantém ligado depois de um reinício; Parar pergunta antes, depois para o serviço e o mantém desligado. Em Configuração → Configurações o mesmo interruptor é a caixa Executar este serviço (também ao iniciar), então o cartão e a configuração nunca discordam. Salvar as configurações reinicia só os serviços cujas próprias configurações mudaram, e o painel diz quais.

Receptor — Storage SCP

Porta 11112 · C-STORE, C-ECHO

O que faz

Aceita estudos enviados pelas modalidades e grava em disco, opcionalmente organizados por Paciente / Estudo / Série. Aceita todas as sintaxes de transferência e guarda o que vem comprimido como está: não há transcodificação, então nenhum dado é alterado na entrada.

Quando ligar

Sempre que algo precisar enviar imagens para cá: modalidades, outro PACS, uma estação. É o serviço central.

Quando não

Se esta máquina só encaminha o que outra deixa numa pasta.

Encaminhamento automático — Storage SCU e regras de roteamento

Cliente de saída · C-STORE

O que faz

Monitora uma pasta e encaminha cada arquivo novo para os destinos que couberem. Um arquivo só é enviado quando está estável (o tamanho não mudou entre duas varreduras), então nunca se encaminha arquivo pela metade. O progresso é registrado por destino: só conta como concluído quando todos os destinos habilitados aceitaram, e os que falharam são repetidos na varredura seguinte. Ao concluir, o original pode ser mantido, movido ou excluído.

Regras

Com roteamento ligado, uma regra decide os destinos por modalidade, AE title de origem, estação, ID do paciente ou descrição do estudo (curingas * e ?, sem diferenciar maiúsculas). Exemplo: TC vinda de ER_* para o arquivo de ensino, anonimizada.

A garantia

Um estudo nunca pode ficar sem destino. Se o roteamento estiver desligado, se nenhuma regra casar, se o cabeçalho não puder ser lido ou se uma regra citar um destino que não existe mais, o arquivo vai para todos os destinos habilitados. Enviar demais incomoda o operador; enviar de menos perde uma imagem.

A única exceção

Uma regra que pede anonimização para um destino, quando a limpeza não pode de fato ser feita, deixa aquele destino retido: nada é enviado a ele, em vez de mandar o estudo identificado. Duas coisas impedem a limpeza — o perfil estar em off, ou o perfil estar ligado e nenhum anonimizador poder ser construído com as configurações atuais — e elas se resolvem de maneiras diferentes. Nos dois casos nada se perde; veja Anonimização no encaminhamento abaixo.

Quando ligar

Quando esta máquina tiver que entregar imagens a outro sistema: encaminhar ao PACS central, alimentar uma estação de laudo, mandar cópias para um arquivo de ensino.

A aba tem ainda uma terceira seção, Sem destino para tentar, que esta captura não mostra porque este equipamento não tem nenhum caso: são os arquivos encaminhados a um nome que deixou de ser um destino habilitado — apagado ou desligado na aba Destinos depois de a rota já ter sido decidida. Não sobrou nó para discar, então nada os tenta de novo e nenhum relógio corre a favor deles; o remédio também é outro: restaurar um destino com o mesmo nome, mandá-los a outro destino com Enviar para… ou aceitar a perda com Remover da fila. Cada linha diz o que será dos arquivos, e a distinção importa: uma cópia que a retenção e encaminhamento já prometeu àquele nó espera indefinidamente na pasta de saída, sem ser arquivada nem apagada, enquanto uma que ninguém prometeu é reencaminhada na varredura seguinte sem aquele nome e então arquivada ou apagada conforme o seu Ao enviar, sem nunca ter chegado lá — restaurar o nó só ajuda antes dessa varredura.

Modalidades registradas

Sem porta · Configuração → Modalidades

O que faz

A lista de salas que este equipamento atende: um nome que uma pessoa reconhece, o AE title da estação que a worklist compara exatamente, o código de modalidade e, se você quiser, o nome da estação. Não é uma lista de permissões: um aparelho não precisa estar aqui para enviar imagens, e estar aqui também não o autoriza. O que se ganha é que o destino de um pedido passa a ser escolhido numa lista em vez de digitado, e é dela que a sonda de worklist toma emprestado um AE title.

Preencha quando

Você serve a worklist ou digita pedidos à mão. Enquanto não houver nenhuma estação registrada, o destino de um pedido é digitado e um erro de digitação não tem como ser pego.

Sonda de worklist — perguntar ao outro RIS

Cliente de saída · C-FIND de worklist · Configuração → Modalidades

O que faz

Responde “por que este aparelho não está vendo a lista dele?” sem encostar no aparelho. Dê um endereço ao RIS real do hospital — ou ao broker dele — em Configurações e aperte Testar worklist na linha de uma modalidade: o Carino faz àquele RIS a pergunta que aquela modalidade faria, usando o AE title dela mesma, e arquiva cada resposta em Atividade → Sondas de worklist. Uma execução faz a mesma pergunta cinco vezes, alargando uma chave por vez — estação, data e modalidade; depois sem a modalidade; sem a data; sem a estação — porque o que localiza a falha é a diferença entre as respostas. Se nada volta em nenhuma delas, o outro RIS não tem nada agendado; se só a mais estreita volta vazia, o que está errado é o AE title da estação.

Antes de apertar

Tire a modalidade da rede primeiro. A sonda chama como aquela modalidade, e duas coisas atendendo pelo mesmo AE title num mesmo RIS é uma confusão que alguém depois tem que ir desfazer.

O que não é

Não é serviço, não é agenda e não é fila. O que fica em Sondas de worklist é o registro do que outro respondeu: esses pedidos nunca são servidos na worklist deste equipamento, que não reivindica nenhum deles. Limpar esvazia esse registro e nada mais.

RIS de emergência — pedidos HL7

Porta 2575 · HL7 ORM^O01 sobre MLLP

O que faz

Recebe pedidos HL7 por MLLP e também permite digitá-los à mão no painel quando não sobrou nada vivo do lado de cima. Quando o estudo volta por C-STORE, ele é conciliado com o pedido pelo accession number (com o ID do paciente como reserva) e o pedido é fechado e arquivado para a trilha — nunca apagado.

Quando ligar

Durante uma queda do RIS, ou em testes de integração.

O que ele garante

A entrega das imagens nunca depende de existir um pedido. Um estudo sem pedido correspondente é armazenado e encaminhado do mesmo jeito; o pedido apenas fica em aberto para conciliação manual.

Sem TLS e sem credencial. Veja a seção de segurança: quem conseguir abrir um socket nessa porta consegue injetar pedidos. Só em rede clínica confiável e com firewall.

Impressão virtual

Porta 11113 · DICOM Print, saída em PDF ou Secondary Capture

O que faz

Se apresenta como uma impressora DICOM (AE title CARINOPRINT por padrão) e captura cada folha de filme que mandarem. Para equipamentos cuja única saída é o filme, é a forma de guardar algo arquivável. Um filme não traz identidade de paciente confiável, então cada um espera em Pendentes até uma pessoa identificá-lo; nada impresso é encaminhado sozinho.

Quando ligar

Quando você tiver uma modalidade que só sabe imprimir e quiser resgatar o resultado dela. Os passos estão em Como faço para… imprimir.

Configurações

Em Configuração → Configurações → Impressão: o AE title e a porta, Aceitar apenas estes AEs (as modalidades que podem imprimir; vazio quer dizer qualquer uma), Aceitar também trabalhos de impressão em cores e Salvar cada filme capturado como PDF ou Imagem. Escolha Imagem quando o PACS ou o visualizador de destino não mostrar PDF — muitos não mostram.

Como saber que funciona

Enviar impressão de teste no cartão faz uma impressão completa passar pelo receptor e deixa em Pendentes uma folha marcada «TEST PRINT — safe to discard». Depois de um trabalho real, o cartão mostra Última impressão (quantos filmes, de qual AE e endereço) e o contador Capturados. Uma recusa ou falha aparece como Último problema; veja a tabela de problemas de impressão.

O que ele tolera

Modalidades que deixam para a impressora a numeração da sessão de filme e da caixa de filme, uma Presentation LUT (aceita e ignorada) e um AE title de impressora digitado diferente na modalidade — o AE chamado não é conferido.

Painel web

Porta 8042 · HTTP, 127.0.0.1 por padrão

O que faz

Estado de cada serviço, destinos, pedidos, registro de atividade ao vivo, configurações e um editor DICOM embutido. Tudo o que o painel faz também existe na CLI.

Como se navega

A lateral tem seis linhas: Resumo, Serviços, Estudos, Pedidos, Configuração e Atividade — e uma sétima, Nó de teste, só em um processo iniciado com --dev-peer. As três perguntas que se fazem sobre o mesmo monte de arquivos são as abas de Estudos — Histórico, Pendentes e Travados; o que se ajusta ao comissionar o equipamento são as abas de Configuração — Destinos, Rotas, Configurações, Modalidades e Pessoas, e ela abre em Destinos, não em Configurações; e os registros são as abas de Atividade — Registro, Conexões, Auditoria e Sondas de worklist. Conexões lista as conexões DICOM recentes nos dois sentidos e diz por que uma falhou e o que mudar, e em qual máquina; o botão O que aceita de cada destino pergunta a ele sobre cada tipo de imagem guardado aqui. Sondas de worklist é o que outro RIS respondeu quando este equipamento perguntou a ele como uma das suas modalidades. Pedidos mantém a própria faixa de abertos e fechados. A linha Estudos carrega dois contadores que são botões, 📎 pendentes e ⚠ travados, e cada um abre a sua aba direto, então chegar aos travados é um clique enquanto houver algo travado: um contador em zero fica escondido, porque um contador que marca 0 é um alarme sempre ligado, e sem ele o caminho é o de sempre — a linha, depois a aba, dois cliques. Pedidos tem o seu próprio contador. Cada painel e cada aba tem endereço na URL — #studies/stuck, #configuration/routing, #activity/logs —, então um lugar do painel pode ir para os favoritos e ser ditado por telefone durante uma queda, que é por que esses endereços são palavras e não ids de elemento; o botão «voltar» do navegador funciona e os endereços antigos no estilo #dlgStuck continuam resolvendo. Resumo é a exceção: ele atende por #overview se você digitar, mas nunca é escrito na barra de endereços nem deixa entrada no histórico, porque imprime o nome de um paciente e uma tela sem ninguém na frente não pode voltar sozinha para ele depois de um recarregamento.

Os chips do cabeçalho

Os chips de serviço no alto continuam iguais para quem pode iniciar e parar serviços. Um perfil que não pode continua enxergando-os como indicadores, mas desabilitados: o estado de um serviço não é informação privilegiada, e a recepção precisa ver um receptor morto sem receber um interruptor que o servidor recusaria.

Quando tirar do loopback

Só com um motivo concreto — e então com token obrigatório e HTTPS na frente. Veja a regra do token.

7. Isto não é um dispositivo médico

Dito sem rodeios, porque é mais útil que uma nota de rodapé:

• Se você implanta, a validação é sua. A conformidade regulatória, a análise de risco, a proteção de dados (LGPD) e a responsabilidade clínica são da organização que coloca o software em produção, não do projeto.
• É distribuído sem garantia de espécie alguma, como diz a licença AGPL-3.0.
• Não substitui seu PACS nem seu RIS. É o gateway entre os dois e o que mantém o setor funcionando durante uma queda, até que voltem.
• Trate como infraestrutura clínica assim mesmo. Não ser dispositivo médico não o torna inofensivo: ele movimenta dados de pacientes. Criptografia do volume, firewall, TLS, token e backup não são opcionais.
• Se o cuidado de um paciente depender disto, a responsabilidade é sua, não do software.

Nada disso é pessimismo: o projeto leva a sério que uma imagem que nunca chega em silêncio é pior que uma falha barulhenta, e por isso prefere se recusar a iniciar, contar explicitamente as sub-operações que falharam e encaminhar demais em vez de encaminhar de menos. Ele segura uma entrega em um único caso, de forma barulhenta e reversível: um destino para o qual uma regra pede anonimização quando a limpeza prometida não pode ser feita, seja porque o perfil está desligado, seja porque o perfil está ligado e nenhum anonimizador pôde ser construído. Ele diz qual dos dois é, porque os dois se resolvem de maneiras diferentes. Mas o software só responde pelo que ele faz; pelo resto, quem responde é você.

8. Licença e onde pedir ajuda

O Carino DICOM é publicado sob AGPL-3.0-or-later. Como é um servidor de rede, vale o §13: se você roda uma versão modificada como serviço, precisa oferecer o código dela a quem a usa. Mantenha o arquivo LICENSE e um ponteiro para o código junto de qualquer implantação modificada.

• Código e issues no GitHub
• Política de segurança — o que está protegido, o que não está e como reportar uma vulnerabilidade
• Como contribuir

Se você achar um erro neste manual — ou uma tradução que um radiologista nunca diria — abra uma issue. Os manuais em português, espanhol, japonês e russo são parte do projeto, não um extra.

Carino DICOM · página inicial · parte da oficina carino.systems · AGPL-3.0-or-later.