Consulta de Ultrassom Funciona, mas a Recuperação Falha: Rastreie a Conexão C-MOVE Separada

Por que a consulta pode ser bem-sucedida enquanto todas as recuperações falham?

Poucos sintomas de rede confundem mais as equipes de manutenção do que um sistema de ultrassom que consegue pesquisar o sistema de arquivamento e comunicação de imagens (PACS, Picture Archiving and Communication System) hospitalar sem erros, mas falha sempre que um ultrassonografista tenta recuperar um exame anterior. O console lista os exames do paciente, o operador seleciona um deles e pressiona Recuperar e, após uma pausa, o sistema relata uma falha genérica de transferência ou recuperação. A redação exata varia conforme o fabricante e a versão do software.

A suposição intuitiva é que a conectividade de rede é simétrica: se o scanner consegue pesquisar o arquivo, o pipeline funciona, portanto uma falha de recuperação deve significar uma falha interna do scanner, uma opção de software corrompida ou uma placa de rede de entrada/saída (I/O) com defeito. Para a recuperação por C-MOVE no DICOM (Digital Imaging and Communications in Medicine), essa suposição está incorreta. A consulta e a recuperação utilizam operações diferentes e, no caso do C-MOVE, diferentes associações de rede abertas em direções opostas. ^{1 5}

Quando um sistema de ultrassom executa uma consulta, ele atua como um Service Class User (SCU) da classe de serviço Query/Retrieve e utiliza a operação C-FIND. ⁹ O scanner abre uma conexão TCP para o endereço IP e a porta de escuta configurados do arquivo. A porta 104 é a porta DICOM bem conhecida, mas as portas são configuradas por local; na família Philips citada abaixo, a porta de escuta tem como padrão a 104 e muda para 2762 quando o Secure DICOM está habilitado. ³ O scanner solicita uma associação usando seu próprio AE Title (calling) e o AE Title (called) do arquivo, envia a solicitação C-FIND com chaves de busca como ID do paciente, nome ou data do exame, e recebe as correspondências por essa mesma associação.

Quando o ultrassonografista pressiona Recuperar, o scanner não faz o download dos arquivos por essa associação. Ele envia uma solicitação C-MOVE solicitando que o arquivo entregue as instâncias selecionadas a um Move Destination AE Title designado. O DICOM PS3.4, Seção C.4.2, estabelece que as suboperações C-STORE “devem sempre ser realizadas por meio de uma Associação diferente da Associação que realiza a operação C-MOVE”, com o Query/Retrieve SCP atuando como o Storage SCU. ¹

O motivo está na mesma seção: a entidade de aplicação que recebe as instâncias armazenadas “pode ou não ser a originadora da operação C-MOVE”. O C-MOVE foi projetado para que um solicitante possa enviar um exame para um terceiro sistema, como uma estação de trabalho de visualização. É por isso que o arquivo, e não o solicitante, abre a conexão de entrega, mesmo quando o scanner solicita que as imagens retornem para si mesmo. ¹

Portanto, uma consulta bem-sucedida comprova apenas que o scanner consegue alcançar a porta de escuta do arquivo. Não comprova que o caminho reverso, do arquivo de volta para a porta de escuta do destino, esteja configurado, liberado por firewalls ou aceito pelo receptor DICOM do scanner. Antes de suspeitar do hardware, separe as falhas de armazenamento do lado do scanner das falhas na direção de recuperação rastreando cada associação separadamente.

Quais são os três endpoints e as duas associações em uma recuperação de ultrassom?

Para diagnosticar uma falha de C-MOVE com precisão, o engenheiro deve reconhecer que uma recuperação DICOM envolve três endpoints lógicos distintos e duas associações de rede independentes, mesmo quando o sistema de ultrassom solicita que as imagens sejam entregues a ele mesmo. O DICOM PS3.4, Seção C.4.2, define esses papéis com precisão técnica: ¹

• SCU solicitante (console de ultrassom): O sistema que inicia a associação 1 com o arquivo, emite solicitações de consulta C-FIND e emite o comando de recuperação C-MOVE. Ele identifica quais exames, séries ou instâncias transferir e designa o Move Destination AE Title.
• Query/Retrieve SCP (arquivo PACS ou VNA): aceita a associação 1, faz a correspondência da consulta, recebe o C-MOVE, consulta o Move Destination AE Title em sua própria configuração e atua como Storage SCU para enviar as instâncias.
• Move Destination (Storage SCP): o nó designado na solicitação C-MOVE para receber as imagens. Frequentemente é o mesmo scanner que solicitou, mas o padrão permite qualquer nó de armazenamento, como uma estação de trabalho de revisão. Na família Philips citada aqui, o scanner indica seu próprio AE Title como o destino. ^{1 3 5}

Como o Move Destination pode ser um nó de terceiros, o protocolo C-MOVE foi deliberadamente projetado para que o arquivo inicie a conexão de entrega. Isso cria duas associações de rede distintas com direções de conexão opostas:

Associação 1 (associação de solicitação direta): Iniciada pelo SCU do ultrassom para o PACS Q/R SCP. Essa associação lida com o handshake A-ASSOCIATE, a troca de consultas C-FIND, a solicitação C-MOVE, as respostas periódicas de status pendente do C-MOVE e a resposta final de conclusão do C-MOVE. Se essa associação falhar, o ultrassom não conseguirá buscar pacientes nem enviar o comando inicial de recuperação.

Associação 2 (associação reversa de armazenamento): aberta pelo arquivo, atuando como Storage SCU, para o Move Destination, atuando como Storage SCP, após o arquivo receber a solicitação C-MOVE. Ela transporta uma solicitação C-STORE por instância, seja imagem, cine ou relatório estruturado. Se essa associação não puder ser aberta, for bloqueada por um firewall ou for rejeitada pelo receptor, as suboperações falham enquanto a associação 1 ainda funciona. ^{1 2 6}

O Anexo F da PS3.2 ilustra essa mesma divisão em um exemplo informativo de declaração de conformidade para um servidor fictício de query-retrieve. Nele, a entidade de aplicação QUERY-RETRIEVE-SCP “nunca iniciará associações”; em um C-MOVE, ela comanda uma entidade de aplicação STORAGE-SCU separada “a iniciar uma associação com o AE DICOM de destino”. Sua Tabela F.4.2-8 mostra que um timeout, abort ou perda de socket nessa associação de entrega é reportado de volta e um status apropriado é enviado na resposta do C-MOVE. Produtos reais implementam isso de forma diferente, mas a direção da segunda conexão é a mesma. ²

O que a resposta C-MOVE final realmente informa?

A maioria dos consoles exibe apenas um pop-up breve quando uma recuperação falha. Evidências mais úteis estão na resposta C-MOVE retornada pela associação 1, geralmente visíveis no log DICOM do archive e, às vezes, no log de serviço do scanner. A Tabela C.4-2 da PS3.4 lista os status de C-MOVE sob Failure (recusado, erro ou incapaz de processar), Cancel, Warning, Success e Pending. ¹

A PS3.4 também define atributos de contagem de suboperações. Respostas Pending devem contê-los. Respostas finais podem conter alguns deles, portanto uma contagem ausente não é, por si só, um erro:

• Number of Remaining Sub-operations (0000,1020): instâncias que ainda precisam ser enviadas. Obrigatório em respostas Pending, opcional em Cancel e não incluído em respostas Warning, Failure ou Success.
• Number of Completed Sub-operations (0000,1021): suboperações C-STORE concluídas com êxito. Obrigatório em respostas Pending, opcional em respostas finais.
• Number of Failed Sub-operations (0000,1022): suboperações C-STORE que falharam. Obrigatório em respostas Pending, opcional em respostas finais.
• Number of Warning Sub-operations (0000,1023): suboperações que terminaram com status Warning.
• Failed SOP Instance UID List (0008,0058): em respostas Cancel, Failure ou Warning, os identificadores das instâncias cujo C-STORE falhou. Fica ausente quando nenhuma suboperação tiver falhado. ¹

Leia o status e as contagens em conjunto. Uma falha com zero concluídas e todas as instâncias com falha significa que nada foi entregue. Isso geralmente aponta para a própria associação, mas um archive pode produzir o mesmo padrão quando o destino recusa todos os tipos de objeto. Concluídas e com falha ambos acima de zero significa que o caminho reverso funciona para ao menos algumas instâncias, e o problema está em objetos específicos, codificações ou recursos do destino. As contagens restringem a busca; o log do archive mostra o motivo. ^{1 5}

A Failed SOP Instance UID List (0008,0058) costuma ser o atributo mais útil depois do status. Em uma transferência parcial, compare os UIDs com falha com o registro de cada objeto no archive. Se todos os itens com falha forem clipes cine multiframe enquanto imagens single-frame chegaram, uma incompatibilidade de sintaxe de transferência ou de contexto de apresentação é uma forte candidata. Confirme isso no log de associação do archive antes de alterar qualquer coisa.

O que o status Refused: Move Destination unknown (A801) identifica?

O status A801 (Refused: Move Destination unknown) é um dos códigos mais específicos que você pode receber, e uma lição neutra de treinamento em PACS descreve o destino desconhecido como a causa mais comum de falhas de movimentação. Isso significa que o arquivo não conseguiu resolver o AE Title designado como destino. ^{1 4 5}

A solicitação C-MOVE transmite o destino apenas como um AE Title em Move Destination (0000,0600), sem endereço IP ou porta. ¹ O arquivo deve converter esse AE Title em um endereço e porta a partir de sua própria configuração. A Medical Connections, fornecedora de ferramentas DICOM, observa que, por mais oneroso que isso pareça, “nenhuma alternativa é permitida pelo DICOM”. ⁶

Se o arquivo não encontrar nenhuma entrada correspondente, ele não terá endereço para se conectar e recusará a solicitação com A801. Nenhuma suboperação é tentada. O PS3.4 lista apenas um comentário de erro como campo relacionado para este status, portanto não espere contagens significativas de suboperações. ^{1 4}

As causas clínicas comuns do status A801 incluem:

• Scanner novo ou reinstalado: o scanner foi configurado para enviar exames ao PACS, mas ninguém adicionou seu AE Title, endereço IP e porta como destino de recuperação no arquivo.
• Divergência na string exata: um AE Title tem no máximo 16 caracteres, e o PS3.5 trata espaços iniciais e finais como não significativos. ¹² Caracteres internos ainda importam. Compare as strings caractere por caractere, incluindo maiúsculas e minúsculas, underscores versus hífens e a letra O versus o número zero, em vez de presumir que qualquer um dos sistemas irá normalizá-las.
• AE Titles diferentes para envio e recebimento: alguns sistemas permitem que o console use um AE Title ao armazenar e defina outro como seu destino de recuperação. Se apenas o título de envio estiver registrado no arquivo, o título de destino será desconhecido.
• Destino incorreto inserido no scanner: o console especifica um destino que diverge do registro criado pelo administrador do PACS. Nesse caso, a correção deve ser feita no lado do scanner, sob controle de alterações.

Um A801 não é motivo para substituir o hardware de rede nem alterar portas de switch. A solução consiste em fazer com que o AE Title de destino enviado pelo scanner corresponda a um registro de nó no arquivo com o endereço IP e a porta de escuta atuais do scanner. O registro no arquivo pertence ao administrador do PACS; a configuração de destino do próprio scanner pertence a quem realiza a manutenção do scanner.

O que significa quando o destino rejeita a associação do arquivo?

Se o arquivo resolver o destino, ele tenta abrir a associação 2 para esse endereço IP e porta. A forma como ele relata uma falha aqui depende da implementação. O sistema de gerenciamento de dados Canon HCBA-01, por exemplo, documenta A702 quando “as suboperações C-STORE não podem ser executadas devido à falha de uma Solicitação de Associação ou de uma Solicitação C-STORE.” Outros arquivos podem usar um status diferente, portanto consulte o código de acordo com a declaração de conformidade do próprio arquivo. ⁴

Uma falha neste estágio se divide em dois cenários distintos de engenharia: bloqueio de transporte de rede e rejeição de associação em nível de aplicação.

1. Bloqueio de transporte de rede (recusa de conexão TCP): O servidor PACS tenta enviar um pacote TCP SYN para o endereço IP do ultrassom na sua porta de escuta configurada, mas recebe um TCP RST (conexão recusada) ou nenhuma resposta (timeout de SYN). Isso ocorre quando:

• O serviço de escuta DICOM do scanner de ultrassom está parado ou desativado no software.
• Um firewall de host no console, onde a plataforma possui um, bloqueia as conexões de entrada na porta de escuta.
• Firewalls de rede departamentais ou listas de controle de acesso (ACLs) de rede local virtual (VLAN) permitem o tráfego de saída das modalidades médicas para o PACS, mas bloqueiam o tráfego de entrada iniciado na sala de servidores de volta para os carrinhos de ultrassom clínicos. ⁵

2. Rejeição de associação em nível de aplicação (A-ASSOCIATE-RJ): a conexão TCP é bem-sucedida, mas o destino recusa a associação DICOM. A Philips documenta isso como o mecanismo em que a consulta funciona, mas a recuperação falha para a família EPIQ Elite, Elite Advanced, E7, E5, CVx, CVxi e Affiniti 70/50/30 Release 6.0.x (000737000000163 Rev A, Seção 4.1.2.1): ³

“Um segundo dispositivo ‘DICOM Storage Server’ no sistema de ultrassom deve ser usado para adicionar o AE Title de envio do servidor para a associação C-Store iniciada pela solicitação C-Move enviada ao servidor Query Retrieve. Sem esse segundo dispositivo, a consulta será bem-sucedida, mas a recuperação falhará porque o sistema de ultrassom rejeitará qualquer solicitação de associação de um AE Title ‘desconhecido’.”— Philips EPIQ/Affiniti Release 6.0.x DICOM Conformance Statement, 000737000000163 Rev A, Seção 4.1.2.1 (grafia conforme o original)

A seção de configuração do mesmo documento acrescenta dois detalhes importantes durante a manutenção. Primeiro, o arquivo “geralmente usará um AE Title diferente” para o C-STORE em relação àquele consultado pelo scanner, de modo que o scanner precisa de uma entrada adicional de Storage Device com esse AE Title de envio e o endereço IP ou hostname do arquivo. Segundo, como o arquivo não envia a partir de uma porta fixa, a Philips afirma que uma porta fictícia, como a 9999, pode ser inserida, e espera-se que a verificação automática após salvar essa entrada falhe; “Isso não é um erro.” Para envios não solicitados, o documento exige igualmente que o AE Title e o endereço IP do remetente sejam configurados com antecedência. ³

Nessa família, o scanner aceita até cinco associações de armazenamento simultâneas (Tabela 4.4), um valor que a tabela de configuração lista como não configurável. Se um archive abrir mais associações de entrega paralelas para um destino do que o destino aceita, as associações excedentes podem ser recusadas; portanto, compare a configuração de simultaneidade por destino do archive com o limite documentado do destino. Não presuma que esse limite se aplique a outros modelos ou versões. ³

Na mesma família, o Query/Retrieve é uma opção: a nota de rodapé da visão geral afirma que ele “Requer a opção ‘Ultrasound Query Retrieve’ ou ‘Multi-Modality Query Retrieve’”. Confirme se a opção está presente no sistema exato antes de solucionar problemas de rede, principalmente após uma recarga de software ou em um sistema usado cujas opções possam diferir do seu pedido original. ³

Decodificando a rejeição de associação: telemetria de PDU e códigos de diagnóstico

Quando a associação 2 é rejeitada, uma captura ou o log do archive mostra como. A Seção 9.3.4 da DICOM PS3.8 define a PDU A-ASSOCIATE-RJ, que transporta campos de um byte para Result, Source e Reason/Diag. ¹¹

Compreender esses códigos de diagnóstico evita substituições desnecessárias de hardware ao distinguir rejeições por política de segurança de falhas no transporte de rede:

• Result: 1 é rejected-permanent; 2 é rejected-transient. ¹¹
• Source: 1 é o DICOM UL service-user (o aplicativo receptor); 2 é o UL service-provider (função relacionada à ACSE); 3 é o UL service-provider (função relacionada à apresentação).
• Reason/Diag.: com Source 1, 1 no-reason-given, 2 application-context-name-not-supported, 3 calling-AE-title-not-recognized e 7 called-AE-title-not-recognized. Com Source 3, 1 temporary-congestion e 2 local-limit-exceeded. ¹¹

Uma rejeição com Source 1 e Reason 3 (calling-AE-title-not-recognized) é uma forte evidência de que o caminho TCP funciona e que o aplicativo de destino recusou o calling AE Title do archive. Se um determinado scanner envia esse código de motivo exato ou um menos específico depende de sua implementação, portanto leia o código na captura ou no log. De qualquer forma, substituir placas de rede ou cabos não resolverá o problema.

Outras plataformas de ultrassom: leia a declaração de conformidade dessa versão

Os detalhes da Philips acima são específicos de uma família de versões documentada. Outros fabricantes e versões configuram query/retrieve, chamadores aceitos e portas de escuta à sua própria maneira, e este guia não generaliza os menus ou mensagens de erro de um sistema para outro. Para qualquer outro scanner, obtenha a declaração de conformidade DICOM do modelo e da versão de software exatos e procure por estes pontos:

• Status da opção: se o Query/Retrieve é padrão ou uma opção licenciada.
• Identidade do destino: qual AE Title o scanner designa como Move Destination e se ele pode diferir do AE Title que utiliza ao armazenar.
• Chamadores aceitos: se os remetentes de armazenamento devem ser pré-registrados por AE Title, endereço IP ou ambos.
• Porta de escuta e segurança: a porta padrão e configurável, e se um modo TLS (DICOM seguro) a altera.
• Limites de associação: quantas associações de armazenamento simultâneas o scanner aceita.
• Objetos aceitos: as SOP Classes e sintaxes de transferência que o scanner aceita como Storage SCP.

Se a declaração de conformidade não responder a algum ponto, registre-o como desconhecido e consulte o canal de assistência técnica do fabricante. Não preencha a lacuna com suposições de outra marca.

Quando a própria solicitação está incorreta (erros A900 e de nível)?

Nem todas as falhas de C-MOVE são causadas por problemas de conectividade ou de roteamento. Quando o arquivo retorna o status A900, a falha reside na estrutura da própria solicitação C-MOVE. O DICOM PS3.4, Seção C.4.2, Tabela C.4-2 define o status A900 como “Error: Data Set does not match SOP Class”. A declaração de conformidade do Canon HCBA-01 (Tabela 4.2-30) o rotula como “Identifier does not match SOP Class”. ^{1 4}

Uma solicitação C-MOVE transporta um conjunto de dados Identifier que especifica o modelo de informação de consulta e as instâncias de destino. O status A900 ocorre quando esse identificador viola as regras normativas da Query/Retrieve Service Class:

• Ausência de QueryRetrieveLevel (0008,0052): O identificador da solicitação deve indicar o nível hierárquico de recuperação: PATIENT, STUDY, SERIES ou IMAGE. Se esse atributo for omitido ou contiver uma string não suportada, o arquivo rejeita o comando. ¹
• Ausência de chaves únicas obrigatórias: no modelo Study Root, uma recuperação no nível STUDY necessita do Study Instance UID (0020,000D); uma recuperação no nível SERIES também necessita do Series Instance UID (0020,000E), e uma recuperação no nível IMAGE também necessita do SOP Instance UID (0008,0018). ¹
• Incompatibilidade no modelo de informação: o identificador não se enquadra no modelo de informação negociado para o C-MOVE, como chaves criadas para Study Root enviadas sob um contexto de Patient Root.
• Ambiguidade do Patient ID: O PS3.4 observa que o emissor do Patient ID é implícito em uma solicitação C-MOVE, com “nenhuma previsão para enviar o Issuer of Patient ID”, e que “uma recuperação no nível STUDY deve ser usada em vez de uma recuperação no nível PATIENT” quando o Patient ID puder ser ambíguo. Para problemas de identificação em múltiplos locais, consulte quando o mesmo Patient ID existe sob dois emissores. ¹

Não confunda Modality Worklist com Query/Retrieve. O Worklist utiliza C-FIND em uma fonte de agendamento para buscar os pedidos do dia; o Query/Retrieve pesquisa em um arquivo de imagens por estudos concluídos. Um scanner pode receber sua worklist corretamente e, ainda assim, falhar em todas as recuperações, porque os dois serviços frequentemente são executados em hosts diferentes com AE Titles distintos. Mantenha o estado da worklist separado do query/retrieve do arquivo durante a investigação.

Por que algumas imagens chegaram e outras falharam (aviso B000 e contagens)?

Um status de aviso B000 (Sub-operations Complete – One or more Failures) significa que algumas suboperações foram bem-sucedidas e outras falharam. Na prática, o ultrassonografista abre o estudo recuperado e constata que as imagens de quadro único estão presentes, mas faltam alguns cine loops, volumes ou relatórios. ¹

O status B000 é uma boa evidência de que ambas as associações podem ser estabelecidas: o arquivo alcançou o destino e pelo menos algumas solicitações C-STORE foram bem-sucedidas. A falha está relacionada a instâncias ou SOP Classes específicas, ou a recursos no destino.

As principais causas de falhas parciais de recuperação incluem:

• Incompatibilidade de sintaxe de transferência: o arquivo armazena um clipe em uma codificação que o destino não aceita (por exemplo, MPEG-4 AVC/H.264 ou JPEG-LS) e não pode ou não consegue convertê-lo. Os arquivos diferem entre si: a declaração do Canon HCBA-01, por exemplo, descreve uma lista configurável de sintaxes de transferência por AE Title de destino e tentativas de transcodificação quando o destino não oferece suporte à sintaxe armazenada. ⁴
• Objetos que não são de imagem recusados: estudos podem incluir Structured Reports, Encapsulated PDF ou presentation states. Um receptor que aceita apenas SOP Classes de imagem de ultrassom recusa o restante. A aceitação não é o mesmo que a exibição: a declaração da Philips Release 6.0.x afirma que o sistema aceita e pode importar objetos SR com um estudo, mas não exibe SR importado. ³ Para verificar objetos de relatório, reconcilie as instâncias que efetivamente chegaram com a aquisição original.
• Espaço de armazenamento de destino: se o console ficar com pouco espaço local durante uma recuperação grande, seu receptor poderá recusar instâncias posteriores. Antes de liberar espaço, verifique as instâncias retidas antes de confiar nelas ou excluir cópias locais.

Para B000, comece com a Failed SOP Instance UID List (0008,0058). A correspondência desses UIDs com os registros do archive mostra quais SOP Classes e transfer syntaxes falharam, de modo que a correção possa ser direcionada.

Fluxo de trabalho de diagnóstico passo a passo para engenheiros clínicos

Para evitar alterações descoordenadas entre a engenharia clínica, o PACS e a TI, siga a mesma sequência sempre que uma recuperação falhar. Cada etapa indica quem normalmente a executa:

1. Etapa 1 — Capture o status e as contagens: obtenha o status final do C-MOVE (por exemplo, A801, A702, A900 ou B000) e quaisquer contagens informadas no log DICOM do archive (administrador do PACS) ou no log de serviço do scanner, onde ele as exibir. Compare o padrão com a Tabela 2.
2. Etapa 2 — Registre a identidade DICOM do scanner: seu AE Title de envio, o AE Title que ele indica como Move Destination, sua porta de escuta e seu endereço IP atual (serviço do scanner).
3. Etapa 3 — Verifique o registro de destino do archive: com o administrador do PACS, confirme se existe uma entrada de nó para esse AE Title de destino com o endereço IP e a porta atuais do scanner, comparando as strings exatamente.
4. Etapa 4 — Teste a acessibilidade a partir do lado do archive: a equipe de rede ou do PACS testa se o archive consegue alcançar a porta de escuta do scanner, usando suas ferramentas aprovadas. Observe que o ping ICMP pode ser bloqueado por política mesmo quando a porta DICOM estiver aberta; portanto, um ping com falha por si só prova pouco.
5. Etapa 5 — Verifique os chamadores aceitos no scanner: em sistemas que pré-registram remetentes de armazenamento, como a família Philips documentada, confirme se o AE Title de envio e o endereço IP do archive estão inseridos (serviço do scanner).
6. Etapa 6 — Confirme a opção: verifique se a opção de Query/Retrieve exigida pelo fabricante, se houver, está presente no sistema (serviço do scanner).
7. Etapa 7 — Reconcilie objetos e codificações: para transferências parciais, verifique se os objetos com falha compartilham uma SOP Class ou transfer syntax que o destino não aceita (administrador do PACS e serviço do scanner).

Topologias de rede complexas: NAT, VLANs e carrinhos sem fio com DHCP

Em redes corporativas hospitalares modernas, os sistemas de ultrassom operam cada vez mais em infraestruturas dinâmicas ou segmentadas, introduzindo complexidades de roteamento que não afetam modalidades de imagem estacionárias, como TC ou RM:

1. Tradução de endereços de rede (NAT): se o scanner estiver atrás de NAT, por exemplo em uma rede sem fio segmentada, o archive vê o endereço do gateway, enquanto seu registro de nó para o AE Title de destino pode apontar para um endereço que ele não consegue alcançar diretamente. Conexões de entrada não solicitadas para esse endereço são descartadas, a menos que a rede seja projetada para elas. A base de conhecimento da Medical Connections descreve roteadores, NAT e firewalls de software como bloqueadores comuns da conexão C-MOVE reversa; suas soluções alternativas voltadas para desktop de desativar firewalls ou abrir portas no roteador não são apropriadas em uma rede hospitalar. ⁶

2. Alteração de endereços IP: scanners portáteis que se deslocam entre departamentos podem receber novos endereços via DHCP. Se o registro de nó do archive mantiver um endereço fixo para o AE Title do scanner, qualquer alteração enviará a associação 2 para o endereço antigo e ela expirará por tempo limite. Scanners que necessitam de recuperação geralmente exigem um endereço estável, como uma atribuição estática ou reserva de DHCP, definida pela equipe de rede.

3. Inspeção de estado e roteamento assimétrico: Firewalls corporativos frequentemente implementam inspeção de estado que permite automaticamente pacotes de retorno de entrada para conexões iniciadas a partir de uma zona protegida. Embora a Associação 1 (ultrassom para o PACS) seja reconhecida como um fluxo ativo com estado, a Associação 2 é uma conexão TCP inteiramente nova iniciada pelo servidor PACS na direção oposta. A menos que o administrador do firewall crie uma política bidirecional explícita ou uma regra de entrada que permita o tráfego do servidor PACS para a porta de escuta do ultrassom, o firewall descartará a Associação 2 como uma sondagem de entrada não autorizada.

Negociação de contexto de apresentação e incompatibilidades de sintaxe

Quando a Associação 2 estabelece um soquete TCP, o archive do PACS (atuando como Storage SCU) propõe uma lista de Contextos de Apresentação ao carrinho de ultrassom (atuando como Storage SCP). Cada contexto proposto emparelha uma Sintaxe Abstrata (o UID da SOP Class) com uma ou mais Sintaxes de Transferência (o formato de codificação e codec de compressão). O ultrassom avalia cada proposta e retorna um código de aceitação ou rejeição em sua resposta A-ASSOCIATE-AC.

Os sistemas de ultrassom lidam com uma combinação única de cine loops de alta taxa de quadros, mapeamentos de fluxo em cores multizona e medições estruturadas complexas. A tabela abaixo detalha as colisões de Contexto de Apresentação mais comuns encontradas durante as suboperações C-STORE:

Diagnósticos em nível de pacote e captura não intrusiva de tráfego

Não instale ferramentas de captura de pacotes, scanners de portas ou outros softwares no console de ultrassom. Ele é um dispositivo médico sob o controle de software do fabricante e o controle de alterações da instituição, e softwares não aprovados podem afetar sua configuração validada e sua segurança.

Quando uma captura for justificada, a equipe de rede pode realizá-la a partir da infraestrutura, por exemplo com espelhamento de porta de switch (SPAN) ou um TAP de rede passivo, e analisá-la em uma estação de trabalho autorizada separada. Capturas de tráfego DICOM não criptografado contêm dados de pacientes, portanto devem ser autorizadas, minimizadas, armazenadas e excluídas de acordo com a política de privacidade e segurança da instituição. Se o DICOM seguro (TLS) estiver em uso, a captura mostrará a conexão TCP, mas não as mensagens DICOM em seu interior; em vez disso, use os logs do arquivo e do scanner.

No Wireshark, um filtro de exibição como dicom || tcp.port == <listening port>, utilizando as portas configuradas do local, isola o tráfego relevante. Em seguida, verifique ambas as associações em ordem:

• Verificação da Associação 1: Localize o handshake TCP de três vias (SYN, SYN-ACK, ACK) com origem na porta efêmera do console de ultrassom para a porta de escuta do PACS. Imediatamente após o handshake, verifique a PDU A-ASSOCIATE-RQ (Tipo 01H) contendo os Contextos de Apresentação Propostos para Study Root Query/Retrieve Information Model - FIND e MOVE. Confirme se o servidor PACS retorna uma PDU A-ASSOCIATE-AC (Tipo 02H) aceitando ambos os contextos.
• Envio da Requisição C-MOVE: Rastreie a PDU P-DATA-TF contendo o comando C-MOVE-RQ. Verifique o Message ID, o QueryRetrieveLevel (por exemplo, STUDY), a chave de correspondência StudyInstanceUID e o atributo Move Destination AE Title (0000,0600). Confirme se a string de destino corresponde exatamente ao AE Title de escuta esperado do ultrassom.
• Início e Handshake da Associação 2: Observe a chegada de um novo pacote TCP SYN independente vindo do endereço IP do servidor PACS direcionado ao IP estático e à porta de escuta do carrinho de ultrassom. Este é o ponto crucial do diagnóstico. O comportamento desse pacote identifica a causa raiz imediatamente.

Concorrência, gerenciamento de filas e tempos limite de socket

Em setores de diagnóstico por imagem de alta rotatividade, as falhas de recuperação frequentemente se manifestam de forma intermitente sob condições de carga de trabalho pesada. Um carrinho de ultrassom que recupera um estudo de tireoide de cinco imagens sem dificuldade pode falhar consistentemente ao tentar importar um exame complexo de ecocardiografia de 600 quadros ou um estudo vascular periférico abrangente. Essas falhas dependentes de volume são causadas por limites de fila de rede e configurações de tempo limite de socket.

1. Limitação de taxa do archive e tempos limite do cliente: os archives frequentemente limitam transferências de saída simultâneas. Se vários usuários solicitarem estudos grandes ao mesmo tempo, as suboperações podem entrar em fila. Se o scanner solicitante aplicar seu próprio tempo limite à recuperação geral, ele poderá desistir e relatar uma falha enquanto o archive ainda estiver enviando. Compare a linha do tempo do log do archive com o momento em que o scanner relatou o erro.

2. Gravações lentas no destino: um destino que não consegue gravar os dados tão rápido quanto eles chegam torna a transferência mais lenta. Se uma paralisação exceder o tempo limite de mensagem ou de rede do archive, o archive aborta a associação 2. O exemplo informativo da PS3.2 descreve exatamente isso: um A-ABORT em um tempo limite de nível de mensagem ou de baixo nível, com um status de falha apropriado retornado na resposta C-MOVE. ²

3. Tentativas repetidas: cada acionamento de Retrieve envia uma nova solicitação C-MOVE, o que pode enfileirar transferências duplicadas e ocultar a primeira falha nos logs. Capture o status da primeira falha e, em seguida, repita a operação uma vez de maneira controlada após a causa ter sido solucionada.

Validação pós-recuperação: indexação do banco de dados local e prevenção de divisão de estudos

Um status final de 0000 (Success) significa que cada suboperação C-STORE foi entregue e confirmada. Isso não garante que o estudo esteja onde o ultrassonografista espera encontrá-lo no scanner.

Os sistemas de ultrassom diferem na forma como arquivam e listam os estudos recebidos, e a declaração de conformidade ou o manual do operador da versão exata é a referência definitiva. Os objetos recebidos são geralmente agrupados por seus atributos de identificação, como Patient ID (0010,0020), Study Instance UID (0020,000D) e Accession Number (0008,0050), portanto diferenças nesses valores alteram onde um estudo aparece.

Se as imagens recuperadas não aparecerem na tela do console apesar da confirmação com status 0000, os engenheiros devem investigar três anomalias comuns de ingestão no banco de dados:

• Exame aberto: alguns sistemas podem não atualizar a lista de estudos enquanto um exame estiver em andamento. Verifique a tela de revisão ou de estudos recebidos descrita no manual do operador.
• Arquivado sob um registro de paciente diferente: se o estudo arquivado contiver um Patient ID ou accession diferente do pedido de hoje, o scanner poderá listá-lo sob uma entrada de paciente separada. Pesquise por Study Instance UID ou data antes de concluir que a recuperação falhou.
• Falha de armazenamento local ou de indexação: se o armazenamento local estiver quase cheio ou o processo de importação tiver falhado, o log de serviço do scanner geralmente indicará isso. Libere espaço apenas por meio do procedimento aprovado pelo fabricante e da política de retenção da instituição.

Quem é responsável por cada correção: manutenção do scanner, administrador do PACS ou equipe de rede?

As equipes de serviço de engenharia clínica desempenham um papel crucial de triagem no ciclo de vida do gerenciamento de tecnologias em saúde. Quando ultrassonografistas clínicos relatam falhas de recuperação (retrieve), os técnicos biomédicos costumam ser os primeiros a prestar atendimento no ambiente hospitalar. Em vez de encaminhar o problema imediatamente a help desks externos de TI ou abrir uma autorização de devolução por avaria no equipamento, os engenheiros clínicos devem estabelecer uma linha de base formal de conectividade DICOM durante o comissionamento inicial da máquina. Essa linha de base deve documentar o endereço IP estático verificado, a máscara de sub-rede, o gateway padrão, o endereço MAC físico, o AE Title local de Storage SCP, a porta de escuta e a compilação de software do carrinho de ultrassom, juntamente com a data e o número do chamado de alteração de quaisquer modificações de rede. Manter esse registro de linha de base de conectividade no Sistema Informatizado de Gestão de Manutenção (CMMS, Computerized Maintenance Management System) do hospital garante que futuras reavaliações de IP, reconfigurações de portas de switch ou atualizações de software possam ser instantaneamente reconciliadas com um estado funcional conhecido, reduzindo drasticamente o tempo de diagnóstico e evitando chamados de assistência técnica desnecessários.

Como uma recuperação DICOM cruza fronteiras institucionais — abrangendo firmware de dispositivos médicos, switches de rede hospitalar, firewalls e bancos de dados de PACS corporativos —, a solução de problemas frequentemente se degrada em troca de acusações entre departamentos. Os engenheiros clínicos culpam a TI hospitalar pelo bloqueio de portas, a TI culpa o fornecedor do PACS por falhas de software, e os administradores do PACS culpam o carrinho de ultrassom por hardware defeituoso.

Para eliminar o tempo de inatividade desperdiçado, as equipes técnicas hospitalares devem estabelecer limites claros de responsabilidade com base em evidências objetivas de protocolo. Cada camada da cadeia de recuperação pertence a uma disciplina profissional específica:

O que deve ser registrado antes de alguém alterar uma configuração?

Registre todas as alterações: o que foi alterado, por quem, em qual ordem de serviço e o resultado dos testes de antes e depois. Se uma recuperação posterior falhar, esse registro indicará se a causa é uma alteração recente na infraestrutura ou uma nova falha no equipamento. Quando o fabricante disponibilizar uma exportação de configuração suportada, faça uma antes de alterar as configurações do scanner e armazene-a de acordo com a política da instituição para que a alteração possa ser revertida.

Quando um equipamento de ultrassom falha ao recuperar estudos, a equipe técnica deve resistir ao impulso de alterar aleatoriamente parâmetros de configuração, alternar definições de firewall ou solicitar placas de E/S de rede para substituição. A resolução de problemas por tentativa e erro não coordenada cria graves riscos de segurança e frequentemente introduz falhas secundárias que dificultam a recuperação.

Erros de roteamento também representam um risco à privacidade. Se alguém tentar corrigir um A801 adivinhando AE Titles de destino ou apontando o Move Destination para outro nó conhecido sem confirmar do que se trata, o arquivo enviará os estudos dos pacientes para esse dispositivo. Em muitas jurisdições, isso pode ser um incidente de privacidade de notificação obrigatória; o encarregado de privacidade da instituição decide como ele deve ser tratado.

Antes de modificar qualquer arquivo de configuração, abrir um chamado de suporte ou solicitar componentes de reposição, os engenheiros clínicos devem coletar um pacote de evidências estruturado e higienizado para a entrada de serviço:

Ferramentas de simulação controlada: verificação sintética sem arriscar dados de pacientes

Quando a recuperação de exames de ultrassom falha intermitentemente ou quando as equipes de rede contestam se uma porta de firewall está realmente aberta, os engenheiros clínicos precisam de um método objetivo e reprodutível para isolar o endpoint com falha sem enviar repetidamente exames reais de pacientes pelas sub-redes clínicas. Em ambientes hospitalares regulamentados, disparar repetidamente transferências com falha de estudos clínicos reais gera ruído de auditoria e aumenta o risco de divulgação acidental de informações de saúde protegidas.

Para estabelecer a realidade dos fatos, as equipes de engenharia clínica podem implantar suítes padronizadas de verificação DICOM (como utilitários do toolkit DCMTK ou ferramentas de teste DVTk) em execução em uma estação de trabalho de teste dedicada e autorizada pela TI dentro da mesma sub-rede clínica:

• Teste do caminho reverso com um listener de teste: execute um listener de armazenamento DICOM temporário na estação de trabalho de teste autorizada, em uma porta acordada com a equipe de rede, e solicite ao administrador do PACS que registre o seu AE Title como um destino. Se um C-MOVE de um estudo de teste designado alcançar o listener, o arquivo conseguirá alcançar esse segmento de rede, e a atenção se voltará para a configuração do próprio scanner.
• Verificação do listener de armazenamento do ultrassom a partir da rede: Por outro lado, um engenheiro pode enviar um estudo de teste de ultrassom sintético e desidentificado do notebook de teste diretamente para o IP e porta de escuta do carrinho de ultrassom usando C-STORE. Se o ultrassom aceitar a associação e ingerir a imagem de teste, o serviço Storage SCP local do carrinho, o firewall do SO local e o banco de dados interno comprovam-se totalmente operacionais. Se o carrinho rejeitar a associação com A-ASSOCIATE-RJ, a configuração de Calling AE Title aceito no scanner é imediatamente confirmada como a causa raiz.
• Limite de segurança e conformidade: Os utilitários de teste nunca devem ser conectados a VLANs clínicas sem autorização formal da segurança da informação do hospital. Além disso, as imagens de teste devem consistir inteiramente em aquisições em phantom ou objetos DICOM gerados sinteticamente contendo zero dados demográficos de pacientes ou informações de saúde protegidas.

Teste de aceitação pós-serviço e aprovação clínica

Após qualquer substituição de placa, recarga de software, alteração de rede ou alteração de configuração, teste novamente as funções DICOM antes de retornar o scanner ao uso clínico. As verificações de serviço frequentemente se limitam ao envio de uma única imagem para o PACS, deixando a recuperação sem teste até que um ultrassonografista precise de um estudo anterior.

Utilize o procedimento de paciente de teste designado pela instituição, para que nenhum registro real de paciente seja criado ou alterado, e verifique cada função configurada:

• 1. Verificação (C-ECHO): Realize um teste de ping/echo a partir do console do ultrassom para todos os nós DICOM configurados (arquivo PACS, servidor de Worklist, servidor de Storage Commitment e impressoras DICOM). Confirme o recebimento bem-sucedido da confirmação.
• 2. Modality Worklist (C-FIND): Consulte os pedidos de pacientes agendados para hoje. Selecione um paciente agendado, preencha os dados demográficos do paciente na tela de aquisição e confirme se os números de acesso, as descrições dos estudos e os nomes dos médicos executantes são mapeados corretamente.
• 3. Aquisição e armazenamento (C-STORE): Adquira um loop de Doppler colorido multiframe e imagens estáticas em 2D utilizando um phantom simulador de tecido. Envie o exame concluído para o PACS. Confirme se todas as instâncias são transferidas sem erros e se o arquivo confirma o armazenamento.
• 4. Consulta e recuperação (C-FIND, C-MOVE): consulte o estudo de teste recém-armazenado, recupere-o de volta para o scanner e confirme se as imagens e cine loops abrem e se nenhum status de aviso como B000 é registrado em log. Verifique os relatórios de medição apenas onde o sistema estiver documentado para importá-los e exibi-los.

Aprove formalmente o evento de serviço apenas quando todas as funções configuradas forem aprovadas, para que os ultrassonografistas possam confiar em estudos anteriores durante os exames.

Perguntas frequentes

Um C-ECHO ou uma consulta bem-sucedida comprova que a recuperação também deve funcionar?

Não. Uma Verificação (C-ECHO) ou Consulta (C-FIND) DICOM testa apenas o caminho de rede direto iniciado pelo aparelho de ultrassom até a porta de escuta do arquivo PACS (Associação 1). Uma recuperação por C-MOVE exige que o arquivo PACS inicie uma conexão de rede reversa e separada de volta à porta de escuta do ultrassom (Associação 2). Como firewalls, tabelas de roteamento de rede e políticas locais de segurança do aparelho frequentemente tratam conexões de entrada de modo diferente de conexões de saída, o sucesso no C-ECHO ou no C-FIND oferece zero garantia de que a Associação 2 terá êxito. ^{1 5}

O destino da movimentação é sempre a máquina que enviou a solicitação?

Não necessariamente. No DICOM PS3.4, Seção C.4.2, o atributo Move Destination especifica o Application Entity Title do sistema que receberá as suboperações C-STORE. Embora os ultrassonografistas clínicos normalmente recuperem exames para o carrinho que estão operando, o protocolo C-MOVE permite explicitamente que um solicitante designe qualquer nó de armazenamento DICOM de terceiros como destino — como uma estação de trabalho dedicada, um servidor de visualização 3D ou uma estação de revisão offline. O arquivo sempre resolve o AE Title do Move Destination de forma independente, independentemente de qual cliente iniciou a solicitação. ¹

A movimentação relata sucesso, mas nenhum estudo apareceu — o que deve ser verificado primeiro?

Se a resposta do C-MOVE indicar o status 0000 (Sucesso) e o Número de Suboperações Concluídas coincidir com o número esperado de imagens, a transferência pela rede foi concluída com êxito. Se as imagens não aparecerem na tela do ultrassom, verifique dois fatores imediatos: primeiro, verifique o índice do banco de dados interno de pacientes do ultrassom — alguns sistemas armazenam estudos recuperados em um arquivo local ou diretório de pacientes que deve ser atualizado manualmente ou aberto a partir de uma aba “Estudos Importados”. Segundo, verifique se o AE Title do Move Destination na solicitação foi inadvertidamente configurado para uma máquina física diferente (como outro aparelho de ultrassom ou estação de trabalho de revisão), caso em que as imagens foram entregues com sucesso a esse outro dispositivo. ^{1 6}

Podemos simplesmente abrir o firewall ou redirecionar uma porta para fazer a recuperação funcionar?

Não. Em ambientes hospitalares clínicos, os aparelhos de ultrassom são dispositivos médicos móveis que processam informações de saúde protegidas (PHI). Abrir regras indiscriminadas de firewall, desativar o software de segurança do host ou configurar o redirecionamento de portas não gerenciado viola os padrões de segurança cibernética na área da saúde e as políticas institucionais de segurança. As alterações de rede devem ser formalmente coordenadas com as equipes de TI e de segurança de rede do hospital, restringindo o tráfego a IPs de origem específicos (o servidor PACS), IPs de destino (o carrinho de ultrassom) e portas de escuta DICOM designadas, sem expor sub-redes clínicas ao tráfego não autorizado.

O C-GET ou o DICOMweb evitariam esse problema de conexão reversa?

Em princípio, sim. Com o C-GET (PS3.4, Seção C.4.3), as suboperações C-STORE são executadas na mesma associação da solicitação, e o receptor é sempre o solicitante. A recuperação via DICOMweb também é iniciada pelo cliente por meio de HTTP. Nenhum dos dois precisa que o arquivo abra uma conexão de volta ao aparelho. ¹⁰ Mas ambas as pontas devem suportar a alternativa. A base de conhecimento da Medical Connections, redigida há alguns anos, observou que pouquíssimos servidores DICOM comerciais suportavam o C-GET. ⁶ Verifique ambas as declarações de conformidade. A mudança de protocolos é uma questão de planejamento para o proprietário do PACS, e não uma correção para uma falha de C-MOVE hoje.

Uma falha na recuperação significa que a placa de rede do ultrassom está com defeito?

Pouco provável, se o scanner puder consultar, verificar ou enviar estudos ao PACS pela mesma interface. O hardware de rede transporta pacotes independentemente de eles conterem uma consulta C-FIND ou uma imagem C-STORE. Se a interface estivesse falhando, o tráfego de saída normalmente também seria afetado. Com o DICOM de saída funcionando, uma falha apenas de recuperação é muito mais provável de ser um problema de AE Title, accepted-caller, roteamento ou firewall. Quedas intermitentes de link ou uma interface inoperante são sintomas diferentes, abordados no guia da placa de I/O de rede com link acima.

E se os estudos de pacientes tiverem sido enviados para o destino incorreto?

Trate isso como um potencial incidente de privacidade. Interrompa os testes, registre o horário, o Study Instance UID e o AE Title de destino utilizado e notifique o administrador do PACS e o responsável pela privacidade da instituição. Eles decidem como o dispositivo receptor é verificado e como as cópias encaminhadas incorretamente são removidas.

Onde a Rongtao se encaixa — e onde não se encaixa?

A Rongtao Medical é uma empresa independente de reparo e peças de ultrassom com sede em Guangzhou, na China, que atende a distribuidores, empresas de manutenção e equipes de engenharia hospitalar. Ter clareza sobre onde podemos ajudar poupa o tempo de todos.

Onde a Rongtao se encaixa:

• Isolamento de falhas de hardware: quando o problema realmente é de hardware, por exemplo, ausência de link Ethernet, perda intermitente de link ou falha na placa de I/O ou placa principal, a Rongtao oferece diagnóstico e reparo em nível de placa. Cada placa reparada opera por 48 horas dentro de um sistema de ultrassom real antes da liberação. ⁷
• Placas e peças de reposição: reparo de placas e peças para sistemas OEM suportados. O estoque muda, portanto confirme um número de peça específico por meio do catálogo em tempo real ou de um orçamento. ⁸
• Reparo de transdutores: diagnóstico de falhas e reparo de transdutores lineares, convexos, phased-array, endocavitários, TEE e volumétricos, com garantia típica de 90 dias confirmada por item e serviço. ⁸
• Orientação na triagem de serviço: auxílio para identificar se um sintoma aponta para hardware ou para configuração em outro ponto, para que você possa preparar as evidências de serviço no lado do scanner antes de solicitar peças.

Onde a Rongtao não se encaixa:

• Administração de rede hospitalar e firewall: A Rongtao não configura switches de rede departamentais do hospital, não administra firewalls corporativos, não modifica listas de controle de acesso de VLAN nem gerencia domínios do Active Directory hospitalar.
• Administração de nós de arquivamento PACS: Não gerenciamos, licenciamos nem configuramos arquivos PACS hospitalares, Vendor Neutral Archives (VNAs) ou sistemas de informação em radiologia. Modificações nas tabelas de destino do PACS e nos mapeamentos de AE Title no lado do servidor continuam sendo de responsabilidade exclusiva da administração do PACS hospitalar.
• Representação autorizada de OEM: A Rongtao Medical é uma prestadora de serviços independente e não é agente, distribuidora ou representante autorizada de GE HealthCare, Philips, Siemens Healthineers, Canon Medical Systems, Mindray ou Samsung Medison.

Ao solicitar suporte técnico de hardware ou peças de reposição para falhas persistentes de comunicação, por favor envie as evidências DICOM anonimizadas e os dados do modelo para nossa equipe técnica: marca do OEM, família exata do modelo, versão do software, números de peça do hardware e um resumo anonimizado dos sintomas de erro. Nunca envie informações de saúde de pacientes, imagens de pacientes ou identificadores clínicos por meio de canais de orçamento técnico.