Como Funciona a Comunicação na Rede DICOM?
Se você trabalha com sistemas de imagem médica, já deve ter se perguntado por que dois equipamentos DICOM simplesmente “não conversam” entre si, mesmo estando na mesma rede. A resposta quase sempre está na configuração dos protocolos de comunicação DICOM — um tema que muitos profissionais de saúde e TI subestimam até enfrentar problemas reais de integração.
A comunicação DICOM vai muito além de um simples formato de arquivo de imagem. Na verdade, o padrão define uma linguagem completa de serviços de rede que orquestra todo o fluxo de trabalho clínico digital. Para uma visão abrangente do ecossistema DICOM, confira nosso guia completo sobre DICOM na prática clínica.
Neste Artigo
Application Entities: Identificando Dispositivos na Rede DICOM
Cada dispositivo em uma rede TCP/IP possui um endereço IP — isso você já sabe. Mas no universo DICOM, existe uma camada adicional de identificação: a Application Entity (AE). Uma AE corresponde a qualquer aplicação DICOM rodando em um dispositivo de rede, seja um servidor de arquivo (PACS), uma estação de trabalho de visualização, uma impressora DICOM ou uma modalidade de aquisição como um tomógrafo.
Além do endereço IP padrão, cada AE recebe um nome exclusivo chamado Application Entity Title (AET). O AET pode ter até 16 caracteres e, na prática, recomenda-se usar nomes intuitivos como PACSSERVER, CTWORKSTATION1 ou ARCHIVE — preferencialmente em letras maiúsculas, sem espaços ou caracteres especiais.
AE = Aplicação, Não Computador
Um detalhe fundamental que muitos ignoram: AE titles identificam aplicações, não máquinas. Nada impede que um único computador rode várias aplicações DICOM simultaneamente — servidor, estação de trabalho, servidor de impressão. Na prática, isso é bastante comum. Cada aplicação recebe um AET diferente, e os outros dispositivos da rede podem se comunicar com uma aplicação específica, e não com a máquina toda.
Para configurar seu dispositivo na rede DICOM, três parâmetros são essenciais:
- AET (AE Title) — alfanumérico, até 16 caracteres. Pense em nomes como
CTWORKSTATION1ouPACS_SERVER. - Endereço IP da AE — deve ser reservado e fixo para aquela aplicação.
- Número de porta — a porta padrão DICOM é a 104, mas qualquer porta disponível pode ser usada, desde que consistente em toda a rede.
A porta desempenha papel crucial quando existem várias aplicações DICOM no mesmo computador. Enquanto os AETs diferentes identificam cada aplicação, as portas diferentes as separam na camada de rede. Uma mesma AE pode até ter duas portas: uma para envio e outra para recepção — recurso que a maioria dos softwares DICOM modernos suporta.
Serviços e Dados: O Modelo SCU/SCP
O modelo de comunicação adotado pelo DICOM é elegante na sua simplicidade conceitual: Application Entities prestam serviços umas às outras. Uma AE pode solicitar um serviço a outra, e essa outra fornece o serviço solicitado.
Na terminologia DICOM, a AE que solicita um serviço é o Service Class User (SCU), e a que fornece é o Service Class Provider (SCP). Por exemplo, quando um tomógrafo envia imagens para um arquivo digital, o tomógrafo atua como SCU e o arquivo atua como SCP do serviço de armazenamento.
Os DICOM Service Classes associam um ou mais Information Objects (IODs) com um ou mais comandos. Se isso soa abstrato, pense em impressão de imagens: o Print Management Service Class combina o comando de impressão com os IODs de imagem (CT, RM etc.). Qualquer impressora DICOM pode atuar como SCP desse serviço, e qualquer dispositivo que envie imagens para impressão atua como SCU.
Esse modelo é a base de toda a comunicação DICOM e, se você já leu sobre a estrutura de objetos e dados DICOM, verá como serviços e dados se complementam naturalmente.
DIMSE: A Linguagem de Serviços da Rede DICOM
Como AEs pedem serviços umas às outras? Da mesma forma que nós humanos: enviando mensagens. No DICOM, essas mensagens de serviço são chamadas de DICOM Message Service Elements (DIMSE). O protocolo DIMSE estabelece as regras para troca de serviços — a espinha dorsal da comunicação DICOM em rede.
Cada serviço DIMSE geralmente possui dois componentes: uma mensagem de request (solicitação) e uma de response (resposta). Requests são enviados pelas AEs SCU — por exemplo, um tomógrafo tentando armazenar uma imagem no arquivo — e responses são fornecidos pelas AEs SCP.
Command Objects vs. Data Objects
O DICOM precisa distinguir atributos de serviço de atributos de dados. Para isso, reserva o grupo 0000 para todas as tags de serviço, chamando esses objetos de DICOM Command Objects. Os dados propriamente ditos (imagens, informações de paciente) seguem nos grupos 0008 em diante, como Data Objects.
Quando um serviço precisa transferir dados junto com o comando, o atributo Data Set Type (0000, 0800) indica isso. Se seu valor é 0101 (NULL no DICOM), não há dados anexados. Qualquer outro valor significa que um Data Object segue imediatamente após o Command Object. Os serviços DICOM funcionam como “lançadeiras” que transportam dados entre Application Entities.
Os serviços DIMSE que lidam com dados compostos são chamados de DIMSE-C (como C-Store para armazenar imagens), e os que lidam com dados normalizados são DIMSE-N. O prefixo “C” ou “N” identifica o tipo de dados que o serviço manipula.
C-Echo: O “Ping DICOM” que Salva seu Dia
O C-Echo é, de longe, o serviço DIMSE mais simples — e provavelmente o que você mais vai usar na prática. Ele verifica se duas AEs DICOM estão corretamente conectadas. É o famoso “DICOM ping”.
Atenção: não basta que dois dispositivos estejam fisicamente conectados pelo cabo de rede. Também não basta conseguir executar um ping TCP/IP entre eles. Um ping bem-sucedido prova apenas que os dispositivos estão na mesma rede TCP/IP — não garante absolutamente nada sobre a conectividade DICOM. A única forma de confirmar que duas AEs estão configuradas corretamente é fazer um C-Echo de uma para outra.
Como Funciona o C-Echo
O fluxo é direto: a AE solicitante envia um C-Echo-Rq (request). Se a AE receptora responde com um C-Echo-Rsp (response) válido, as duas estão corretamente conectadas no nível DICOM. O C-Echo é puramente um Command Object — não carrega nenhum dado (o Data Set Type é 0101, ou NULL).
Alguns campos importantes na mensagem C-Echo:
- Affected Service Class UID:
1.2.840.10008.1.1— identificador único do serviço C-Echo - Command Field:
0030para Rq,8030para Rsp (o dígito 8 diferencia respostas de solicitações) - Message ID: número único de 2 bytes que identifica cada mensagem durante sua breve vida
- Status:
0000no C-Echo-Rsp indica sucesso
O C-Echo é considerado falho apenas se nenhuma resposta retornar dentro do intervalo de timeout (geralmente poucos segundos). Para outros serviços DIMSE mais complexos, valores não-zero no campo Status indicam warnings ou erros — como uma imagem indisponível para impressão.
Erros Comuns na Configuração DICOM de Rede
Na minha experiência trabalhando com integrações DICOM, estes são os erros que mais vejo em campo:
- Configuração assimétrica de AE: Adicionar as configurações do scanner no arquivo, mas esquecer de adicionar as configurações do arquivo no scanner. Resultado: nada funciona, e leva mais um dia para agendar suporte.
- Conflito de portas: Usar a mesma porta para duas aplicações DICOM diferentes no mesmo computador, ou insistir na porta 104 quando ela já está ocupada. Uma boa prática é usar portas altas (10000+) quando não quiser a padrão.
- AET com caracteres especiais: Usar espaços, acentos ou pontuação nos AE Titles. Embora tecnicamente possível com alguns softwares, é receita para problemas de interoperabilidade.
Limitações e Quando Não Usar DIMSE Tradicional
Embora o DIMSE seja a base da comunicação DICOM há décadas, ele não é solução para tudo:
- Performance em alta escala: O protocolo DIMSE tradicional pode ser lento para transferência massiva de dados. Protocolos como DICOMweb (WADO-RS, STOW-RS) são alternativas mais modernas baseadas em HTTP/REST.
- Redes não-locais: DIMSE foi desenhado para LANs. Para comunicação via internet ou entre sites distantes, considere DICOMweb ou soluções com VPN.
- Integração com sistemas não-DICOM: Quando a interoperabilidade envolve HL7 FHIR ou outros padrões, o DIMSE sozinho não resolve. Você precisa de camadas de integração adicionais.
Se você quer entender como esses protocolos se integram a comandos e objetos DICOM mais complexos, confira o deep dive sobre comandos e objetos DICOM.
Próximos Passos
Dominar a comunicação DICOM é essencial para qualquer profissional que trabalhe com sistemas de imagem médica. Com os conceitos de AE, SCU/SCP e DIMSE que exploramos aqui, você tem a base necessária para diagnosticar problemas de conectividade, configurar novos dispositivos e entender o que realmente acontece quando seus equipamentos “conversam” na rede.
Se está planejando uma nova integração ou enfrentando problemas de comunicação entre dispositivos, comece sempre pelo C-Echo — é o diagnóstico mais rápido e confiável que existe no mundo DICOM.
