Um estudo de ultrassom aparece no dia errado: compare o horário local e o deslocamento UTC

Qual data a tela realmente representa?

Considere um chamado de serviço fictício: um exame de ultrassom aparece no dia 23 de outubro no equipamento, mas no dia 22 de outubro no sistema de arquivamento e comunicação de imagens (PACS). O solicitante suspeita do relógio do equipamento. Uma captura de tela de cada sistema registra a divergência, mas ainda não localiza sua causa.

Para uma equipe de engenharia clínica hospitalar ou uma empresa independente de manutenção, a primeira decisão é definir quem deve investigar. Determine qual evento e representação cada tela exibe antes de tratar a diferença de calendário como um sintoma de hardware. O relógio atual do equipamento, o horário de início do exame e o horário de recebimento no arquivo respondem a perguntas diferentes.

Comece pelas definições de evento. Os campos Study Date e Study Time do DICOM descrevem o início do estudo. O Acquisition DateTime descreve o início da aquisição de dados que resultou na instância. Nenhuma das duas definições torna o registro de data e hora uma garantia medida da precisão do relógio. ^{7 8}

• Início do estudo: Compare (0008,0020) e (0008,0030) com o evento documentado de início do exame para a versão instalada do scanner.
• Início da aquisição: Se (0008,002A) estiver presente, identifique a aquisição que ele descreve. Não substitua pelo horário de congelamento, salvamento, término do exame ou envio pela rede.
• Criação da instância: (0008,0012) e (0008,0013) dizem respeito à criação da instância SOP e à atribuição de seu UID, e não ao recebimento no arquivo. ²
• Receptor e exibição: Pergunte ao responsável pelo PACS o que representa uma data em coluna de lista, sobreposição (overlay) ou portal. Registre qualquer política de conversão e o contexto de fuso horário do usuário ou cliente separadamente dos valores de origem.

Duas datas podem descrever o mesmo instante corretamente após a conversão. Elas também podem descrever eventos diferentes ou refletir dados de origem incorretos. Trate cada uma como uma hipótese até que os valores, os significados dos eventos e as configurações do sistema sustentem uma explicação. Uma diferença plausível de duas horas, por si só, não verifica o registro completo.

O que o registro de evidências deve registrar antes que as configurações sejam alteradas?

Preserve uma linha de base antes de alterar as configurações. Caso contrário, uma comparação posterior poderá misturar um objeto exportado mais antigo com um relógio recém-corrigido ou um perfil de exibição diferente. Registre quem coletou cada observação, de qual sistema e quando. Mantenha as evidências originais que contenham dados de pacientes dentro de canais aprovados pela instituição; uma consulta de serviço deve usar achados anonimizados ou um exemplo sintético.

Utilize o registro abaixo para organizar uma comparação autorizada em modo somente leitura. Para cada linha, retenha a string bruta, se ela está ausente ou vazia, o objeto de onde se originou e a interpretação proposta. Um inspetor de tags pode ajudar, mas uma visualização de cabeçalho exibida não deve ser tratada automaticamente como uma cópia inalterada do objeto transmitido originalmente. Quando necessário, solicite aos responsáveis pelo sistema que comparem as instâncias de origem retidas e as recebidas.

Uma comparação útil apresenta uma constatação e seu limite: “A mesma instância recebida mostra Study Date 20261023 na visualização de tags e 22 de outubro na lista de estudos; o fuso horário da lista ainda não está confirmado.” Isso é mais consistente do que chamar o cabeçalho de corrompido. Também informa ao responsável pelo PACS exatamente quais evidências estão faltando.

Como campos separados de data e hora diferem de uma data/hora com deslocamento?

A representação de valor (VR) do DICOM determina como um campo é codificado. As três formas relevantes são Data (DA), Hora (TM) e Data/Hora (DT). Mantenha a sintaxe de codificação separada da comprovação de que o relógio estava correto. ¹

• DA: Uma data do calendário como 20261023, sem um deslocamento UTC em linha.
• TM: Um horário como 010000, sem uma data ou deslocamento em linha.
• DT: Um valor de data/hora que pode incluir um deslocamento com sinal, como 20261023010000+0200. A precisão pode variar. Sem um sufixo, aplica-se a interpretação local do criador, a menos que o atributo de deslocamento separado especifique o contrário. ¹

Portanto, Study Date e Study Time necessitam de contexto para permitir a comparação com uma exibição em UTC. Mantenha o par bruto unido e, em seguida, identifique o deslocamento aplicável a partir do objeto ou da configuração de origem verificada. Não deduza um fuso horário a partir do nome do hospital, da localização do receptor ou do relógio da estação de trabalho no momento da investigação.

Em SOP Common, Timezone Offset From UTC é opcional (Tipo 3). Ele fornece contexto para valores DA/TM e para valores DT sem um deslocamento explícito. Um valor DT com seu próprio deslocamento mantém esse contexto de forma independente. ²

Se o deslocamento separado estiver ausente, esse atributo não identifica o deslocamento local. A ausência não é uma declaração de UTC. Da mesma forma, um fallback do receptor é uma questão de implementação: estabeleça a política documentada e o contexto real de origem antes de decidir que ele interpretou o valor incorretamente. ²

Um deslocamento é uma relação numérica com o UTC, não o nome de um fuso horário ou uma política completa de horário de verão. Duas leituras idênticas de relógio local podem descrever instantes diferentes se os seus deslocamentos forem diferentes. Se o contexto necessário não puder ser recuperado, preserve essa incerteza em vez de reconstruir uma cronologia precisa apenas a partir de uma string de data.

O Timezone Module separado torna o deslocamento Tipo 1 dentro desse módulo. Seu requisito deve ser interpretado no contexto da definição de objeto de informação e da implementação aplicáveis. Nem essa linha nem a linha opcional de SOP Common, por si só, comprovam que um objeto de ultrassom completo seja conforme ou não conforme. ³

Uma conversão correta pode mover um estudo de ultrassom através da meia-noite?

Sim. Compare um único instante totalmente especificado antes de diagnosticar uma falha. Os exemplos a seguir utilizam apenas deslocamentos numéricos fixos. Eles não representam uma cidade específica, uma transição real de horário de verão, um evento de paciente ou o comportamento testado em um PACS específico.

Em um registro de teste fictício, o início do estudo e o início da aquisição ocorrem em 23 de outubro de 2026 às 01:00 com deslocamento +02:00. Os valores ilustrativos são:

• Data do estudo (0008,0020): 20261023
• Hora do estudo (0008,0030): 010000
• Deslocamento de fuso horário em relação ao UTC (0008,0201): +0200
• Data e hora de aquisição (0008,002A): 20261023010000+0200

Se um receptor exibir esse instante em UTC, a subtração do deslocamento de duas horas resulta em:

2026-10-23 01:00:00 (+02:00) menos 2 horas = 2026-10-22 23:00:00 (UTC)

A data do calendário passa a ser 22 de outubro, enquanto o instante permanece inalterado. A conversão é de duas horas; não é uma alteração de 24 horas no tempo decorrido. Portanto, uma exibição correta em UTC e uma exibição local correta podem mostrar dias adjacentes. Se uma aplicação específica executa essa conversão deve ser determinado a partir de sua documentação e configuração.

O Caso D precisa de um resultado diferente dos outros casos: deixe a interpretação em UTC não resolvida. Solicite a configuração de fuso horário de origem e a política de fallback do receptor. Um deslocamento adivinhado pode produzir uma conversão organizada e, ainda assim, estar incorreto. Registre se cada deslocamento foi codificado, documentado na configuração ou meramente presumido.

O início do estudo e a aquisição poderiam simplesmente ser eventos diferentes?

Datas de eventos diferentes também podem explicar a observação sem nenhuma conversão de fuso horário. O início do estudo não é o início da aquisição, e nenhum dos dois é o recebimento pelo arquivo. A sequência fictícia a seguir utiliza um deslocamento fixo de +00:00 em toda a extensão. ^{7 8}

Suponha que a implementação de teste registre os seguintes eventos. O exemplo ilustra o significado do evento; ele não afirma que todos os scanners atribuam carimbos de data/hora ao mesmo pressionamento de botão.

1. O início do estudo é registrado às 23:45 em 22 de outubro.
2. A aquisição de dados para uma instância posterior começa às 00:15 em 23 de outubro.
3. O receptor registra o recebimento ainda mais tarde. Esse carimbo de data/hora de recebimento pertence ao evento do receptor.

As duas primeiras datas podem estar ambas corretas. Verifique qual campo a interface de usuário identifica como data do exame e qual campo o filtro dela utiliza. Não presuma que uma data de lista, uma sobreposição de imagem e um portal de laudos selecionem todos o mesmo evento. O exemplo do Lumify abaixo mostra por que o mapeamento de eventos específico de cada versão é importante.

Se, em vez disso, os registros sugerirem uma ordem impossível de eventos clínicos, encaminhe essa questão aos responsáveis clínicos e de registros competentes. Este registro técnico não pode determinar o que aconteceu com um paciente. Uma equipe de manutenção deve relatar os valores observados e a incerteza sem alterar silenciosamente a identificação do estudo para fazer duas telas coincidirem.

Por que uma consulta filtrada por data pode não encontrar um registro existente?

Quando um exame estiver ausente de uma lista filtrada por data, identifique primeiro o caminho de busca. O filtro de worklist de um aplicativo pode ser uma operação de banco de dados local; uma consulta ao arquivo pode utilizar DICOM Query/Retrieve (Q/R); um scanner que recupera pedidos agendados pode utilizar Modality Worklist (MWL). Chamar todos os três de “consulta de worklist” oculta as evidências necessárias.

Em uma investigação aprovada, um estudo conhecido encontrado por meio de outra busca pode mostrar que um filtro de data o excluiu. Isso não estabelece o motivo. Preserve os limites solicitados, o campo pesquisado, a resposta e qualquer filtragem adicional do cliente. Solicite ao responsável que reproduza a seleção com um registro sintético antes de alterar uma consulta em produção.

Para a correspondência de valor único em Q/R, a PS3.4 C.2.2.2.1.3 exige ajuste quando o Timezone Query Adjustment é negociado e o deslocamento é fornecido no identificador. A declaração de conformidade descreve o comportamento da implementação. Não existe uma regra geral de que toda consulta não negociada compare strings literais. ⁴

• Correspondência por intervalo: Um intervalo de TM não pode cruzar a meia-noite. Intervalos de DT consideram offsets codificados. A correspondência combinada negociada de DA/TM pode tratar os limites pareados como um intervalo contínuo; as regras de intervalo também permitem o ajuste de offset independentemente de outra negociação estendida. Verifique as chaves suportadas e a implementação exata. ⁵
• Consultas de DT com offset negativo: Um offset negativo entra em conflito com o hífen utilizado para a correspondência de valor único versus intervalo. Trata-se de uma restrição de sintaxe de consulta, e não de invalidade de DT com offset negativo em objetos armazenados. A construção da consulta cabe ao responsável pela integração. ⁴
• Solicitação de evidências: Para uma consulta DICOM, retenha o serviço/SOP Class, as chaves suportadas, a solicitação e a resposta brutas, o offset e a negociação relevante. Para um filtro de interface de usuário, retenha sua política de campos e de fuso horário. Uma captura de tela por si só não pode estabelecer nenhum dos algoritmos de correspondência.

O MWL possui condições separadas de offset para solicitação/resposta em K.4.1.1.3. K.6 especifica um intervalo contínuo de início agendado quando ambas as chaves de data e hora agendadas utilizam correspondência por intervalo. Não transponha a regra de negociação de Q/R para o MWL, nem presuma que o filtro de um visualizador implemente qualquer um dos serviços. ^{6 15}

O que os documentos exatos do Lumify e do PACS estabelecem?

Os documentos abaixo estabelecem comportamentos selecionados em diferentes camadas. Eles não constituem uma classificação de compatibilidade nem um emparelhamento testado de emissor/receptor. O nome de um produto sem o seu release é insuficiente: obtenha a declaração correspondente ao software instalado e solicite ao responsável pelo sistema que confirme a configuração local.

Utilize o comportamento documentado para formular uma pergunta testável. Mantenha as incógnitas ao lado dos fatos, especialmente ao ler material histórico. Uma declaração de conformidade descreve uma implementação; ela não certifica as condições de uma instalação.

Uma verificação cruzada útil é o manual da Dedalus: ele já explica claramente a apresentação de fuso horário para sua própria aplicação. A contribuição prática aqui é o pacote de evidências entre sistemas e a decisão de atribuição de responsabilidade. Para um incidente real, compare as etapas de origem, recepção e exibição, em vez de tratar qualquer manual isolado como uma explicação universal.

Quem é responsável pelas investigações de exibição, metadados de origem e relógio?

A matriz de direcionamento a seguir é um auxílio editorial para uma investigação conjunta. Ela não estabelece um diagnóstico remoto nem substitui as responsabilidades da instituição. As equipes locais podem distribuir essas funções de forma diferente; identifique um responsável nominal e a próxima solicitação de evidências antes de fechar o chamado.

Faça o direcionamento com base na observação verificada. Onde uma linha ainda permitir várias explicações, mantenha-as em aberto até que a comparação seguinte as diferencie.

Um sintoma de relógio no lado do scanner pode justificar uma avaliação adicional sem justificar uma placa de reposição. Evite procedimentos improvisados de desconexão de energia ou medição de tensão da bateria provenientes de um artigo genérico. Use as orientações existentes para separar um problema de saída de uma questão na placa de E/S e direcione os sintomas reais de inicialização ou retenção de relógio para o fluxo de manutenção qualificada do sistema host.

Como uma verificação sintética de aceitação deve preservar o registro?

Para aceitação ou alteração de software/configuração, acorde um teste sintético com os responsáveis pela modalidade e pelo PACS. Utilize um ambiente de teste aprovado e uma identidade de teste da instituição, mantendo os registros de teste fora das listas de trabalho clínicas, a menos que a instituição possua um fluxo de trabalho controlado explícito. Uma simulação pode testar a aritmética sem alterar o relógio de um scanner em produção.

A lista de verificação abaixo propõe as evidências a serem retidas. Ela não é um procedimento do fabricante (OEM), um padrão de tolerância de relógio ou prova de adequação para uso clínico. O escopo, as ações permitidas, os critérios de aceitação e a aprovação formal pertencem ao plano aprovado pela instituição.

Preserve o registro clínico original. Não use reescritas ad hoc de tags, exclusão ou reenvio como atalho para fazer uma data coincidir com a tela. Uma correção confirmada requer o responsável autorizado pelos registros e o processo de governança da instituição.

O DICOM fornece mecanismos para registrar valores anteriores de atributos e o contexto de modificação. Esses mecanismos não fornecem uma política completa de retificação legal ou institucional. Uma explicação técnica da discrepância deve acompanhar qualquer correção autorizada, incluindo o que mudou, por que mudou e o que permanece incerto. ²

Mantenha decisões adjacentes separadas. A incerteza quanto à identidade requer o caminho de reconciliação de identidade do paciente. Um pedido concluído que permanece aberto tem uma investigação de estado do MPPS. A responsabilidade de arquivamento e a retenção local exigem evidência de compromisso de armazenamento; o resultado de um filtro de data não pode definir essa decisão.

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

Os serviços publicados da Rongtao incluem reparo de placas/conjuntos de ultrassom, diagnósticos em nível de sistema e peças de reposição testadas. Este relatório ajuda a preparar as evidências técnicas para uma avaliação de serviço; ele não estabelece nenhuma capacidade específica de reparo de RTC, disponibilidade de peças ou caso de fuso horário bem-sucedido. ¹⁴

Onde a Rongtao Medical se enquadra:

• Quando o serviço no scanner permanecer relevante: Envie o sintoma do dispositivo observado de forma independente e a configuração instalada para que o escopo proposto possa ser avaliado. O modelo, a revisão da placa e as evidências de falha devem preceder uma recomendação de peça.
• Quando a evidência pertencer a outra área: A política de exibição do arquivo, a integração de worklist e as retificações de registros clínicos necessitam das equipes responsáveis da instituição e do suporte do fornecedor. Este relatório não é uma oferta para administrar esses sistemas.
• Antes de um orçamento: Revise o processo de serviço documentado e acorde a avaliação, os testes e os entregáveis para o item real. Não infira compatibilidade ou reparabilidade a partir de uma diferença de data de um dia.

A Rongtao é uma fornecedora independente de serviços e peças. Os nomes de OEMs aqui identificam equipamentos ou softwares documentados; eles não implicam autorização ou endosso do OEM.

• Mantenha estudos, cabeçalhos e registros identificáveis dentro dos canais aprovados pela instituição. Apenas a remoção do nome do paciente não torna um objeto DICOM completo adequado para uma consulta comercial.
• Forneça fotos existentes de etiquetas ou placas apenas quando disponíveis com segurança por meio de manuseio qualificado. Não desmonte o equipamento apenas para obter uma fotografia para orçamento.

Para uma consulta anonimizada de serviço do sistema, forneça o OEM, modelo exato, software instalado, texto do sintoma/erro, quando a discrepância ocorre, qual evento cada tela exibe e o contexto de deslocamento conhecido. Se houver envolvimento de hardware, inclua o número de peça/revisão do fabricante e fotos da etiqueta ou de ambos os lados disponíveis com segurança. Informe a quantidade e o país de destino. Solicite a avaliação do sintoma observado em vez de indicar uma placa com falha não verificada.

Perguntas frequentes

Um campo de deslocamento de fuso horário ausente significa UTC?
Não. Não infira deslocamento zero a partir da ausência. Um sufixo DT explícito pode fornecer contexto; caso contrário, obtenha o contexto de origem e verifique a interpretação documentada do receptor antes de converter.

Um estudo pode começar antes da meia-noite e conter aquisições posteriores?
Sim. São eventos diferentes. Verifique suas definições e deslocamentos antes de considerar as datas inconsistentes. O início da aquisição não é automaticamente o instante de congelamento ou salvamento da imagem.

O envio bem-sucedido de uma imagem prova que a data exibida está correta?
Não. O status de transferência não valida o evento selecionado para exibição nem sua conversão. Confirme os valores reais e a política de apresentação separadamente; use a orientação de responsabilidade de arquivamento para decisões de retenção.

O Modality Worklist e o Query/Retrieve do arquivo utilizam correspondência de datas idêntica?
Não. Eles possuem disposições de correspondência distintas. O filtro de data de um visualizador pode ser ainda diferente. Identifique o serviço e a configuração reais antes de aplicar qualquer regra de consulta.

Alterar o relógio hoje pode reparar datas já armazenadas no PACS?
Alterar apenas o relógio de origem não reescreve instâncias geradas anteriormente. O comportamento futuro também depende da configuração e do mapeamento de eventos. Correções históricas exigem o fluxo de trabalho de registros autorizado, em vez da suposição de que uma alteração no relógio atualiza estudos antigos.

Uma diferença de um dia deve desencadear a substituição de uma placa?
Não. Trata-se de evidência insuficiente de falha em um componente. Determine se o problema diz respeito ao significado do evento, à interpretação do deslocamento, a uma consulta ou a um sintoma do scanner observado de forma independente. Uma avaliação qualificada deve determinar qualquer necessidade de reparo.