Estudo de ultrassom parece duplicado após reenvio: verifique a identidade da instância

Por que um estudo de ultrassom reenviado aparece duplicado no PACS?

O console de ultrassom pode indicar uma transferência não confirmada enquanto o sistema de arquivamento e comunicação de imagens (PACS) já contém alguns ou todos os objetos enviados. Uma nova tentativa posterior pode, então, gerar contagens inesperadas, uma imagem inalterada ou uma entrada de estudo com aparência duplicada. Essas observações descrevem problemas distintos. Registre qual deles ocorreu: duas entradas de estudo, séries repetidas, quadros de imagem adicionais, uma mensagem de erro ou alterações ausentes após um reenvio bem-sucedido.

Para as equipes hospitalares de gestão de tecnologia em saúde (HTM), engenharia clínica e empresas independentes de manutenção, a decisão imediata é determinar quem precisa de quais evidências. O fornecedor do aparelho investiga a geração na origem; o responsável pelo arquivo investiga a ingestão e a indexação; o responsável clínico da instituição decide se os registros obrigatórios estão completos e utilizáveis. Sem essa separação, um problema ambíguo de exibição pode se transformar em um pedido desnecessário de reparo ou em uma alteração insegura de registros. Este guia não estima a frequência com que o software ou o hardware é o responsável.

Mantenha o envio original e a nova tentativa distintos no registro do incidente. A alegação de que “enviamos duas vezes” não comprova que ambas as tentativas continham os mesmos objetos. Registre a ação exata realizada no console: uma nova tentativa automática, uma repetição de trabalho na fila, uma nova exportação a partir da revisão ou uma exportação após a adição de conteúdo. Não deduza o comportamento de UID do equipamento a partir do rótulo do botão. Preserve quaisquer cópias enviadas disponíveis e os logs correlacionados do receptor antes que a rotação rotineira de logs os elimine.

Este artigo aborda a identidade do objeto após um reenvio. Se o problema for especificamente a recuperação de estudos anteriores por meio de C-MOVE, use o guia separado para rastrear a conexão de recuperação. A entrega bem-sucedida de imagens de saída e uma falha na recuperação são caminhos diferentes; nenhum deles, isoladamente, estabelece por que o visualizador exibe entradas duplicadas.

Qual identidade foi alterada entre o envio original e a nova tentativa?

O DICOM (Digital Imaging and Communications in Medicine) utiliza identificadores únicos (UIDs) para estudos, séries e instâncias individuais de Service-Object Pair (SOP) em diferentes níveis. Um único objeto cine com múltiplos quadros pode conter muitos quadros, portanto, uma contagem de quadros exibidos não é necessariamente uma contagem de instâncias. Utilize os seguintes campos para a comparação; não substitua UIDs por nomes de arquivos, rótulos de séries ou números de acesso. ^{1 2 3}

• Study Instance UID (0020,000D): identifica o estudo. Accession Number e Study ID são campos separados; a correspondência de seus valores exibidos não estabelece Study Instance UIDs iguais. ²
• Series Instance UID (0020,000E): identifica a série dentro do estudo. Series Number (0020,0011) é um atributo separado e não deve ser usado como substituto. ³
• SOP Instance UID (0008,0018): identifica o objeto individual. Compare cada objeto de imagem estática, cine ou relatório necessário em vez de tratar o estudo como um único arquivo. ¹
• SOP Class UID (0008,0016): identifica a classe do objeto. Quando os valores de classe e instância são codificados no conjunto de dados, eles devem coincidir com suas identidades DIMSE e file-meta correspondentes. Uma representação conflitante requer investigação. ¹

Três fluxos de trabalho possíveis ilustram por que o payload real é importante. Estes são casos de investigação, não afirmações sobre todos os modelos de ultrassom ou versões de software. O padrão define o significado dos identificadores; a declaração de conformidade do equipamento instalado e a transação capturada estabelecem o que sua função de reenvio realmente realizou.

Nova tentativa enfileirada: Se a fila retransmitir os mesmos objetos armazenados, os identificadores devem ser iguais na comparação. Verifique isso a partir do payload real da nova tentativa ou dos logs disponíveis. A ausência de resposta no remetente não comprova que o receptor descartou o primeiro objeto. Evite chamar os dois arquivos de “idênticos bit a bit”, a menos que tenham sido realmente comparados.

Nova exportação a partir da revisão: Compare seu conjunto de objetos com o envio inicial. Se surgirem identificadores diferentes de estudo, série ou instância, consulte o fornecedor do equipamento para verificar se o fluxo de trabalho documentado de exportação ou correção os explica. Um novo UID é evidência de uma identidade diferente, e não, por si só, prova de falha no equipamento. Se a atribuição do paciente divergir, encaminhe essa questão por meio do processo de reconciliação de identidade do paciente e do emissor da instituição antes de discutir a consolidação de registros.

Conteúdo adicional salvo: Um exame com imagens adicionadas pode conter tanto instâncias enviadas anteriormente quanto novas. Faça a contabilização de cada conjunto separadamente. Não presuma que a reabertura de um exame deva criar uma nova série, nem que todo reenvio deva preservar a identidade original do estudo. O comportamento suportado depende do fluxo de trabalho e da versão exatos.

Utilize a Tabela 1 como um registro conjunto de evidências. Preencha as células indisponíveis explicitamente, em vez de copiar um valor do receptor para a coluna de envio original. Um arquivo recuperado agora do PACS é evidência do estágio retido; ele não é automaticamente uma cópia intacta do que originalmente saiu do scanner. Mantenha identificadores vinculados a pacientes, detalhes de rede e arquivos dentro dos sistemas aprovados da instituição.

O que o archive reteve após o reenvio?

As definições de identidade do DICOM não estabelecem a disposição configurada de um objeto repetido em um receptor específico. Solicite ao administrador do PACS o produto/versão, as regras ativas, o registro de transação relevante e uma cópia autorizada do que agora pode ser recuperado. Mantenha o objeto armazenado separado dos metadados do banco de dados e da apresentação no visualizador: uma alteração em um deles não é prova de que todos os três foram alterados.

Duas referências principais de implementação demonstram a necessidade dessa verificação. Elas são exemplos, não um ranking de PACS, lista de compatibilidade ou instrução para alterar configurações de produção. A documentação é pública; nenhum archive instalado foi testado para este artigo.

A narrativa de Storage do dcm4che Archive 5 documenta diversas políticas de tratamento de repetições. O mesmo site de documentação descreve os controles de incompatibilidade relacional separadamente em sua referência de configuração da Archive Network Application Entity (AE). Trate os nomes de políticas abaixo como resumos desses documentos, e não como uma receita de configuração; confirme a versão implantada e os controles em vigor com o respectivo responsável. ^{8 12}

• Separe a política do resultado: registre a configuração aplicável no momento do evento, e não apenas a configuração atual. Pergunte se um intermediário aplicou suas próprias regras antes do arquivo final.
• Separe a substituição da exibição: pergunte qual objeto foi mantido ou substituído e quais atualizações de banco de dados ou de visualizador ocorreram. Um registro de data e hora de ingestão mais recente, por si só, não estabelece um conteúdo clínico mais recente.

O Orthanc adiciona outra consideração de identidade: seu identificador de instância é um hash de Patient ID, Study Instance UID, Series Instance UID e SOP Instance UID. O Book descreve a manutenção do primeiro objeto por padrão quando esse identificador do Orthanc coincide, com a substituição disponível por meio de OverwriteInstances. Portanto, comparar apenas o SOP Instance UID não reproduz a chave de indexação do Orthanc. ⁹

Se o incidente também levantar uma decisão de retenção, revise a responsabilidade pelo arquivamento antes de alterar a retenção. Nem uma mensagem de duplicata nem uma miniatura inalterada autorizam a remoção da cópia local ou de um registro de arquivo clínico.

O erro descreve o Storage de imagens ou uma operação DICOM diferente?

A operação do DICOM Message Service Element (DIMSE) deve acompanhar qualquer status. Registre se a resposta diz respeito ao Storage C-STORE de imagens, ao N-CREATE de Modality Performed Procedure Step (MPPS) ou a outro serviço, e identifique o objeto afetado. Um rótulo “failed” no nível do estudo pode combinar várias tarefas; ele é uma evidência insuficiente de qual imagem ou relatório falhou.

A PS3.7 C.5.8 define 0111H como Duplicate SOP Instance. A Tabela B.2-1 da PS3.4 lista separadamente as respostas de C-STORE de Storage: sucesso 0000H, avisos incluindo coerção B000H e faixas de falha como A7xx, A9xx e Cxxx. Ela não lista 0111H como um desfecho padrão de duplicata em C-STORE. Não transforme a definição genérica de status em uma regra universal de reenvio de imagens. Se esse código aparecer em um log de Storage, preserve-o e consulte a documentação exata de implementação do receptor. ^{5 6}

O Philips Lumify R5.0, documento HSDP-1299212, fornece um exemplo útil e específico de ultrassom. Sua Tabela 18 lista 0111H sob respostas de MPPS N-CREATE. Essa tabela não estabelece o resultado de um C-STORE de imagem. Um objeto MPPS e uma instância de imagem são registros diferentes. Use o guia relacionado para separar o status da etapa do procedimento da entrega da imagem; verifique a entrega da imagem de forma independente em vez de presumir sucesso ou falha a partir do MPPS. ¹⁰

Aplique a mesma disciplina no nível de objeto quando um envio incluir tanto imagens quanto um Relatório Estruturado (SR). Identifique a Classe SOP e a Instância SOP com falha em vez de presumir que cada objeto seguiu o mesmo caminho. Este artigo não infere a disponibilidade de medições discretas a partir de miniaturas de imagens nem prescreve uma classe de SR específica para todos os sistemas de ultrassom.

Como devem ser investigados identificadores correspondentes com conteúdo diferente?

Uma diferença de conteúdo com a mesma identidade é motivo para preservar evidências e investigar sua origem. Primeiro, estabeleça o que difere: codificação do arquivo, metadados de paciente/estudo, conteúdo de pixels, contagem de quadros ou valores de relatórios. Registre qual comparação foi efetivamente realizada. Uma captura de tela pode revelar uma diferença de exibição; ela não pode estabelecer o conteúdo de cada instância armazenada.

Um checksum do arquivo completo pode identificar a igualdade de bytes nas cópias comparadas, mas checksums diferentes não comprovam, por si só, conteúdo clínico alterado. Informações de metadados do arquivo, codificação ou alterações documentadas de atributos podem diferir. Da mesma forma, UIDs ou miniaturas correspondentes não comprovam equivalência. Os responsáveis qualificados pelos sistemas da instituição devem interpretar as diferenças de conteúdo utilizando ferramentas com suporte; este guia não fornece nenhum limiar universal de aceitação para checksum ou diferença de pixels.

O DICOM contempla explicitamente algumas alterações do lado do receptor. A PS3.4 B.4.1.3 permite a coerção para o modelo de consulta do receptor, especifica uma resposta de Aviso para tal modificação e adverte sobre a integridade referencial. A PS3.3 também descreve registros opcionais de coerção, correção ou conversão. Portanto, uma transformação explicada e uma alteração não explicada no conteúdo de origem não devem ser classificadas juntas. ^{1 7}

• Verifique o escopo exato: A Tabela B.4-1 cita Patient ID, Issuer of Patient ID, Other Patient IDs Sequence, Study Instance UID e Series Instance UID. A seção também discute a conversão de sequências de códigos e observa que outros atributos podem ser corrigidos. Isso não é uma autorização geral para que engenheiros de campo editem registros clínicos. ⁷
• Compare os avisos com a configuração: o padrão exige um Aviso para a coerção especificada. A documentação do dcm4che informa que seu retorno B000 fica desativado por padrão. A ausência desse aviso, portanto, não pode estabelecer que nenhuma alteração ocorreu em um receptor implantado. ^{6 7 8}
• Solicite um registro de antes/depois: Original Attributes Sequence e Instance Coercion DateTime podem ajudar quando preenchidos; não presuma que eles existam. Alterações de estudo/série podem invalidar referências; portanto, pergunte ao responsável pelo sistema como os objetos relacionados foram reconciliados. ^{1 7}

Se a exportação alterada envolver compressão ou derivação, use o guia separado para rastrear o histórico de compressão. Mantenha essa análise distinta de uma decisão sobre política de repetição. O fato de a sintaxe de transferência negociada ter mudado não estabelece, por si só, uma nova aquisição clínica ou um objeto corrompido.

Os casos a seguir são resultados de comparação hipotéticos. Eles identificam a próxima solicitação de evidência e o responsável; não autorizam uma mesclagem, uma limpeza de fila, uma reescrita de UID ou uma retransmissão.

O que uma verificação de aceitação sintética autorizada pode determinar?

Quando um incidente não puder ser resolvido a partir dos registros existentes, o fornecedor do scanner e os responsáveis pela instituição podem acordar um teste sem pacientes por meio de seu processo de controle de mudanças aprovado. Use um ambiente de teste designado ou um destino especificamente autorizado com tratamento controlado de registros de teste. Não interrompa uma rede clínica nem injete objetos de teste em registros de atendimento ativos apenas para reproduzir um reenvio.

Defina a questão em comum acordo antes do teste. Por exemplo: a nova tentativa enfileirada documentada preserva as identidades dos objetos observados, e o que este receptor retém? Uma nova exportação após uma edição suportada é um caso de teste separado. O texto a seguir é uma lista de verificação de planejamento, não um procedimento do fabricante ou uma norma de aceitação clínica:

1. Nomeie a configuração e os responsáveis. Registre scanner/versão de compilação (build), receptor/versão, rota, política de repetição em vigor, destino aprovado e quem controla os registros de teste. Obtenha o procedimento exato e suportado de reenvio.
2. Defina o conjunto esperado de objetos. Use material sintético ou phantom aprovado pela instituição e apropriado para o sistema. Liste os objetos esperados de imagens estáticas, cine e relatórios, quando relevante; este guia não especifica uma contagem arbitrária de quadros, configuração de phantom ou tolerância de medição.
3. Preserve as evidências do primeiro envio. Capture o registro disponível de identidade/conteúdo de saída e os resultados da operação antes de uma nova tentativa. Verifique separadamente as cópias de teste retidas pelo receptor. Se a carga útil de origem não puder ser acessada por meios suportados, documente essa limitação.
4. Execute apenas o caso de nova tentativa acordado. Use o fluxo de trabalho suportado sob a supervisão dos responsáveis. A simulação de falhas requer um método aprovado em separado; não desconecte um cabo de rede de produção nem altere os controles de segurança com base neste artigo.
5. Preencha o registro de três etapas. Compare identidades, conteúdo no escopo e a destinação real. Registre avisos, falhas e evidências indisponíveis. Se a edição/reexportação suportada também for testada, preserve isso como um evento separado.
6. Conclua com um resultado delimitado. Declare o que foi demonstrado para esta versão, rota, conjunto de objetos e configuração, o que permanece não testado e quem aprova a próxima ação. A instituição mantém a autoridade sobre a destinação dos registros de teste e o retorno ao uso clínico.

Um teste bem-sucedido demonstra apenas a transação testada. Ele não pode reconstruir uma carga útil clínica original perdida nem comprovar o comportamento para todo fluxo de trabalho do operador, SOP Class ou versão futura. Verifique novamente após atualizações de scanner/arquivo, migrações ou alterações de políticas. Nenhum scanner, instalação de PACS ou corpus de imagens de pacientes foi testado na elaboração deste guia.

Quais evidências pertencem ao PACS e quando a manutenção de hardware do scanner é relevante?

A manutenção de hardware torna-se relevante quando uma investigação qualificada fornece evidências independentes de falha no lado do scanner. A exibição duplicada de um estudo, um UID recém-gerado ou um tempo limite esgotado por si só não identificam uma placa de E/S, unidade de disco ou placa-mãe com falha. Mantenha os diagnósticos suportados separados da investigação do registro clínico e preserve os logs antes de qualquer recuperação autorizada de software ou trabalho em peças.

Use a Tabela 4 para direcionar a próxima pergunta. Estes são encaminhamentos propostos, não diagnósticos remotos ou promessas sobre qual componente pode ser reparado.

Onde a Rongtao se enquadra — e onde não se enquadra

A Rongtao Medical oferece reparo de placas e conjuntos de ultrassom, manutenção de transdutores e diagnósticos em nível de sistema. Uma consulta sobre hardware é apropriada quando o registro do incidente dá suporte à manutenção no lado do scanner, e não meramente a uma exibição aparentemente duplicada no PACS. Solicite uma avaliação específica para o caso; este guia não estabelece compatibilidade de componentes, estoque, capacidade de reparo, preço ou prazo de atendimento garantido. ¹¹

Para esta investigação, a administração do arquivo e a reconciliação do registro clínico permanecem com a instituição e seus fornecedores de sistemas. O serviço de reparo da Rongtao não é evidência de que um arquivo tenha aceitado uma instância específica ou preservado o conteúdo correto. Nomes de OEM identificam equipamentos; eles não implicam autorização ou endosso do OEM.

Antes de uma consulta externa, prepare um resumo anonimizado da observação e das constatações da instituição. Mantenha objetos DICOM originais, UIDs vinculados a pacientes, números de acesso (accession numbers), imagens, endereços de rede e logs clínicos brutos dentro dos canais de suporte aprovados da instituição. Apenas remover o nome visível de um paciente não torna uma exportação adequada para um formulário comum de orçamento.

Se a manutenção de hardware for respaldada por esses achados, consulte os serviços de reparo de ultrassom e envie os detalhes do equipamento para análise de triagem. Forneça:

• OEM, modelo exato do scanner e versão do software host.
• Número de peça do fabricante e revisão, se já identificados por meio de manutenção autorizada; fotos nítidas da etiqueta e de ambos os lados da placa apenas quando disponibilizadas com segurança por pessoal qualificado.
• Sintoma descaracterizado e texto exato de erro/status, com a operação e a sequência de eventos. Mantenha informações de pacientes e detalhes de rede privada fora do orçamento.
• Diagnósticos suportados já realizados e o que os responsáveis pelo PACS/TI estabeleceram; identifique evidências ausentes em vez de adivinhar.
• Quantidade solicitada, país de destino e necessidades de prazo, para um orçamento específico para o caso e termos de serviço.

Perguntas frequentes

Números de estudo ou contagens de imagens iguais comprovam uma duplicata?

Não. Um rótulo de estudo ou uma contagem igual pode ocultar conjuntos de objetos diferentes. Compare identificadores e conteúdo delimitado entre os estágios original, de nova tentativa e retido. Se apenas uma amostra foi examinada, informe quais objetos foram verificados e quais permanecem não verificados. Correspondência de pacientes, identidade de objetos e completude clínica são conclusões separadas.

O 0111 sempre significa que um reenvio de C-STORE falhou?

Não. Preserve a operação e o objeto afetado. A definição genérica de duplicata do padrão não estabelece um resultado universal de Storage, e a tabela citada do Lumify diz respeito ao MPPS N-CREATE. O status por si só não comprova a entrega completa de imagens nem a retenção segura; solicite ao responsável pelo arquivo que verifique os objetos necessários. ^{5 6 10}

Um envio bem-sucedido pode deixar o objeto anterior no lugar?

Sim — o exemplo NEVER do dcm4che retorna explicitamente sucesso enquanto ignora a repetição. Solicite evidências do conteúdo retido e da política aplicável. “Enviado com sucesso” não é suficiente para determinar se uma versão posterior de anotação ou de laudo substituiu uma anterior. ⁸

Devemos gerar novos UIDs para que o estudo seja aceito?

Não improvise novos UIDs para contornar a rejeição. O DICOM adverte contra a derivação de novos identificadores pela adição de sufixos a UIDs atribuídos em outros locais. A correção ou derivação legítima pertence a fluxos de trabalho suportados e controlados pelos responsáveis pelos sistemas, com a proveniência e as referências mantidas. Isso é diferente de uma solução alternativa de campo que oculta a discrepância original. ⁴

E se o objeto de saída original não estiver mais disponível?

Marque esse estágio como indisponível. Busque os logs restantes do remetente e do receptor, mas verifique o que eles realmente contêm: o escopo de log, a retenção e os identificadores variam. Um registro de transação pode ajudar a reconstruir a cronologia e o desfecho sem preservar o payload original. Se ele não puder estabelecer o que mudou, deixe essa conclusão em aberto em vez de inferi-la a partir da captura de tela atual.