Nomes de pacientes em chinês falham na exportação: rastreie conjuntos de caracteres DICOM em ultrassom

O sintoma no console: por que os nomes em chinês falham downstream?

Considere um teste de aceitação fictício em uma instituição de ultrassom bilíngue. O scanner exibe o nome de teste 张小东 corretamente, e um envio subsequente relata êxito. Na estação de trabalho PACS, no entanto, o nome aparece como pontos de interrogação ou texto corrompido. Essa discrepância é suficiente para investigar a entrega dos dados demográficos, mesmo quando a imagem está visível; não se trata de um diagnóstico do scanner ou do arquivo.

Três desfechos superficialmente semelhantes exigem evidências diferentes: um glifo de substituição na tela, bytes literais de ponto de interrogação em um objeto e um estudo rejeitado pelo receptor. Apenas o primeiro descreve a apresentação; o segundo identifica uma representação danificada no salto inspecionado; o terceiro necessita de um código de status e do log do receptor antes que sua causa seja conhecida. Preserve os artefatos originais e compare etapas adjacentes em vez de inferir uma causa a partir de uma captura de tela.

Para equipes de gerenciamento de tecnologias em saúde (HTM), empresas independentes de manutenção e distribuidores que recebem sistemas usados ou reparados, a decisão imediata é quem deve investigar. Se a associação e o envio de imagens funcionam enquanto apenas o texto do nome falha, verifique primeiro a codificação, o mapeamento e a renderização do aplicativo. Isso não certifica cada placa como íntegra. Sintomas de conectividade distintos pertencem ao nosso guia sobre falhas de saída DICOM e PACS de ultrassom; reúna evidências de hardware antes de solicitar o reparo de componentes.

Os atributos de texto DICOM contêm dados de caracteres codificados, e a exibição no console não precisa usar a mesma representação que o objeto exportado. A resposta da Modality Worklist (MWL), a instância criada pelo scanner, o banco de dados do arquivo e o visualizador podem, portanto, divergir. O rastreamento útil associa uma declaração aos bytes e ao valor decodificado em cada limite, mantendo atualizações demográficas autorizadas separadas de falhas de codificação. ^{1 3}

Specific Character Set do DICOM (0008,0005): quais codificações em chinês são permitidas?

Specific Character Set (0008,0005) controla o repertório estendido para as Value Representations (VRs) de texto afetadas, incluindo SH, LO, ST, LT, PN, UC e UT. Ele não redefine todos os atributos: campos restritos, como identificadores exclusivos (UIDs) e datas, mantêm suas próprias regras. Verifique Patient’s Name (0010,0010) especificamente, em vez de tratar uma anotação legível em pixels como prova de um valor de PN correto. ^{1 2}

Quando a declaração está ausente: a PS3.5 especifica o repertório padrão ISO-IR 6 e proíbe a extensão de código para esses campos de texto. Bytes em chinês fornecidos sem uma declaração válida não estão em conformidade com essa codificação. O padrão não prescreve um desfecho universal de rejeição ou remoção: um receptor específico pode armazenar bytes opacos, substituir caracteres ou rejeitar a instância. Registre o comportamento observado e a política documentada do produto. ^{1 11}

Para os caminhos em chinês considerados aqui, distinga a extensão de código ISO 2022 de uma codificação multibyte única. Um termo válido ainda necessita de suporte em cada endpoint relevante:

1. Extensão de código: ISO 2022 IR 58 identifica o repertório GB2312. No exemplo em chinês da norma, ISO 2022 IR 58 apresenta um primeiro valor vazio, significando o repertório padrão, seguido pelo conjunto em chinês. ISO_IR 58 não é um termo definido. A combinação suportada e o tratamento de escape devem ser verificados na implementação. ^{2 4 5}
2. Um único conjunto multibyte: ISO_IR 192 (UTF-8), GB18030 e GBK exigem, cada um, um valor único em (0008,0005), sem extensão de código ISO 2022. Um objeto que declare ISO_IR 192ISO 2022 IR 58 viola essa regra. O UTF-8 exige codificação de comprimento mínimo; alterar apenas a declaração não transcodifica os bytes existentes. ^{1 2}

Grupos de componentes de Person Name (PN): por que os Hanzi pertencem ao grupo ideográfico?

Uma declaração válida de conjunto de caracteres não estabelece por si só um layout correto de Person Name (PN). O DICOM PS3.5, Seção 6.2.1.2, separa as partes de um nome, como sobrenome e prenome, em componentes. Ele separa representações alfabéticas, ideográficas e fonéticas em grupos de componentes. Verifique tanto a codificação quanto essa estrutura ao comparar o nome de origem com a exibição do receptor. ³

Dentro de qualquer representação única, um nome pode conter até cinco componentes separados por caracteres circunflexo (^): FamilyName^GivenName^MiddleName^Prefix^Suffix. Para dar suporte a fluxos de trabalho de assistência à saúde multilíngues em que os indivíduos possuem tanto transliterações romanizadas (como Pinyin) quanto escritas ideográficas ou fonéticas nativas, o DICOM estabelece até três grupos de componentes, separados por delimitadores de sinal de igual (=): Alphabetic Group = Ideographic Group = Phonetic Group.

Posicionamento sob UTF-8: A PS3.5 6.2.1.2 restringe o grupo alfabético a U+0020–U+1FFF mais pontuação especificada e kana quando UTF-8, GB18030 ou GBK for utilizado. Hanzi como 张 estão fora desse intervalo e pertencem ao grupo ideográfico. Um nome apenas ideográfico pode, portanto, começar com =, por exemplo =张^小东. Mantenha o posicionamento de grupo e a decodificação de bytes como verificações separadas. ³

O exemplo informativo da norma: O Anexo K.2 ilustra Zhang^XiaoDong=张^小东= com ISO 2022 IR 58. Trata-se de um exemplo de codificação, não de evidência de que um scanner específico ofereça suporte a esse caminho. ⁵

• Grupo alfabético: Zhang^XiaoDong usa o repertório padrão neste exemplo, sem sequência de escape no primeiro grupo.
• Grupo ideográfico: após =, o exemplo designa ISO-IR 58 para G1 com 1B 24 29 41 antes de 张; seus bytes GB2312 são D5 C5.
• Próximo componente do nome: após ^, o exemplo repete 1B 24 29 41 antes de 小东. O ASCII permanece em G0, portanto não há escape adicional de volta para o ASCII antes do delimitador neste exemplo específico de G1.
• Grupo final opcional: o = final marca um grupo fonético vazio; um grupo vazio final e o delimitador podem ser omitidos. Nomes no idioma chinês também podem ter representações fonéticas. ^{3 5}

Layout versus corrupção: se um valor recebido contiver 张^小东 no primeiro grupo, registre esse layout separadamente de uma falha de decodificação. Um visualizador pode exibi-lo, enquanto outro pode impor a restrição de grupos de componentes da norma. Não rotule um nome legível como irrecuperavelmente corrompido, não deduza quão comum é esse layout nem reescreva registros clínicos históricos para fazer um teste passar. Defina a representação esperada com os responsáveis pela modalidade e pelo archive. ³

Triagem: quais evidências localizam o primeiro salto alterado?

A Tabela 2 lista hipóteses, e não diagnósticos diretos um para um. Compare os artefatos não modificados da origem e do receptor para a mesma instância fictícia. Se uma exibição mostrar pontos de interrogação, mas o PN armazenado ainda contiver Hanzi válidos, os caracteres não foram perdidos desse objeto. Se uma cópia posterior contiver bytes 3F enquanto a cópia anterior não contiver, investigue a conversão intermediária. Uma inspeção de bytes deve usar uma ferramenta que exponha o valor original, e não apenas sua saída de texto decodificada. ^{11 13 14}

Leitura da Declaração de Conformidade: o que o scanner e o archive realmente suportam?

Utilize o modelo exato, a versão de software e a declaração de conformidade da entidade de aplicação em ambos os lados. O PS3.2 fornece um modelo padronizado de divulgação; ele não constitui, por si só, uma obrigação legal nem prova de que dois produtos interoperam. Declarações mais antigas podem usar números de seção diferentes. Faça a correspondência com o conteúdo abaixo em vez de exigir que o PDF de um dispositivo antigo contenha os rótulos de tabela atuais. ^{6 7}

Procure por quatro divulgações, mantendo separados os suportes de entrada, saída e exibição:

• Conjuntos suportados: a Tabela N.1-15 do modelo atual lista os termos DICOM e os nomes IANA. A lista real de um produto, e não as linhas de exemplo do modelo, determina o suporte declarado por ele. ⁷
• Apresentação e edição de atributos: a Tabela N.5-164a questiona quais campos suportam caracteres estendidos e como fontes ou substituições são tratadas. O suporte a Patient’s Name não estabelece suporte equivalente para todos os campos descritivos. ⁶
• Mapeamento de instâncias recebidas para criadas: a Tabela N.5-165 descreve conversões, incluindo valores de MWL usados em instâncias criadas. Seu exemplo de japonês para UTF-8 demonstra como documentar um mapeamento; ele não é uma regra padrão para dados em chinês. ⁶
• Comportamento para conjuntos não suportados: localize a resposta documentada do produto e eventuais limitações de configuração. Distinga armazenamento, exibição, consulta e exportação; o sucesso em uma operação não estabelece o mesmo para as outras. ⁶

Dois exemplos específicos de produtos: estes documentos ilustram por que a aparência e a marca são substitutos inadequados para uma verificação de capacidade específica da versão. Eles não estabelecem o suporte para o sistema instalado do leitor.

• TOMTEC-ARENA TTA2: a declaração D.32.0131-16 hospedada pela Philips é datada de 17 de novembro de 2021. As seções 7/7.1, páginas impressas 29–30, listam ISO_IR 192 e GB18030 para suporte a decodificação/exibição. A seção 5.2.2, página impressa 27, afirma que a codificação de sua exportação de mídia é UTF-8. Essa declaração específica de mídia não deve ser generalizada para todos os caminhos de exportação de rede. ⁸
• Philips Lumify R5.0: HSDP-1299212, versão 01 datada de 17 de agosto de 2023, a Tabela 37 na página 35 lista ISO_IR 100 como seu conjunto estendido suportado; as tabelas de instâncias criadas também declaram esse termo. A declaração não lista nenhum conjunto compatível com chinês. Ela não estabelece se o aplicativo móvel aceita entrada em chinês ou como um nome não suportado é tratado. Confirme essas questões com a documentação aplicável do OEM e um teste sintético. ⁹

A conclusão para os especialistas em engenharia clínica é clara: nunca presuma os recursos de conjuntos de caracteres DICOM com base na aparência do equipamento, no preço do carrinho ou na reputação do fabricante. O modelo exato e a revisão de software de cada sistema devem ser verificados em relação à sua declaração de conformidade antes de se projetar um fluxo de trabalho de integração.

Realidade downstream: arquivamento no PACS, coerção e renderização no visualizador

Assim que uma instância de Par Serviço-Objeto (SOP) deixa o carrinho de ultrassom, verifique o armazenamento no arquivo, as atualizações demográficas e a renderização no visualizador separadamente. Um objeto armazenado e um nome legível em um cliente não estabelecem a apresentação correta em todos os visualizadores necessários. Os exemplos abaixo mostram por que cada operação precisa de suas próprias evidências.

Archive versus Health Level Seven (HL7): a documentação do dcm4che Archive 5 lista ISO 2022 IR 58, ISO_IR 192, GB18030 e GBK para decodificação/exibição em DICOM. Ela afirma separadamente que sequências de escape para múltiplos conjuntos de caracteres em mensagens HL7 v2 não são suportadas. Este é o limite de um produto, não uma regra de que todas as interfaces hospitalares exijam um gateway UTF-8. Mantenha qualquer verificação de interface HL7 com a equipe de integração da instituição. ¹⁰

Atualizações autorizadas versus falhas de decodificação: a declaração do Sectra PACS 28.1, de março de 2026, seção 8.1.4 e Tabela 8.3, lista Patient’s Name entre os campos que podem ser modificados durante a exportação. Ela atribui a coerção a informações atualizadas do sistema de informação hospitalar/HL7, agrupamento de importação ou configuração. Compare o histórico de auditoria e a origem de uma atualização antes de classificar qualquer nome alterado como erro de codificação. Uma funcionalidade suportada do produto não autoriza um engenheiro a editar um registro clínico. ¹⁶

Limites de toolkits: a descrição do DCMTK feita por J. Riesmeier em novembro de 2011 explica que os bytes de cadeias de caracteres podiam ser armazenados sem verificar a precisão da declaração de Specific Character Set. Este exemplo histórico explica por que uma operação de arquivo bem-sucedida não valida necessariamente o texto. Ele não estabelece o comportamento de todos os toolkits ou appliances atuais. Um dump decodificado pode ocultar substituições ou transcodificações; preserve a instância original e utilize um método apropriado de inspeção de valores brutos. ¹¹

Casos datados de implementação: o tópico 50545 do Conquest (julho de 2023) registra apresentações diferentes de chinês tradicional entre os caminhos de servidor/banco de dados/visualizador; o mantenedor descreve um conversor que presume ISO_IR 100. Na issue 938 do fo-dicom 4.03 (2019), um parâmetro explícito de UTF-8 removeu a substituição de um trema por ponto de interrogação, mas a consulta ainda assim falhou; o relator posteriormente utilizou uma codificação diferente. A issue 4778 do Slicer (março de 2020) registra uma regressão de exibição e discussões sobre versões preliminares e páginas de código do Windows, com uma discrepância remanescente. Esses casos reforçam a verificação de cada camada; eles não comprovam uma correção universal, perda irrecuperável na origem ou falha em produtos atuais. ^{12 13 14}

Protocolo de verificação sintética de ida e volta

Apresenta-se a seguir uma proposta de fluxo de trabalho de aceite para os responsáveis pela modalidade e pelo PACS/TI da instituição. Adapte-o às capacidades documentadas e às representações de nomes exigidas pelas versões instaladas. A aprovação nele demonstra o caminho de texto testado; ela não substitui verificações de segurança elétrica, de qualidade de imagem ou outros testes para retorno ao serviço.

Utilize dados demográficos fictícios aprovados pela instituição e um destino de teste isolado com controle de acesso. Mantenha os objetos de teste claramente identificados e fora dos fluxos de trabalho clínicos de conciliação/laudos. Trate qualquer discrepância clínica existente segundo o processo de privacidade e correção de registros da instituição. Para envio para reparo, siga o procedimento em separado de transferência com exportação e exclusão de dados de pacientes. Preserve os originais e os registros de auditoria; redigitar um nome exibido não é evidência de que a falha geradora tenha sido corrigida.

1. Defina o contrato de teste: registre as versões do scanner, da worklist, do archive e do visualizador; os grupos de nomes esperados; os conjuntos suportados por cada operação; e qualquer conversão aprovada. Crie um pedido fictício na worklist. Utilize Zhang^XiaoDong=张^小东= como um valor de teste, além de um valor fictício escolhido pela instituição que represente quaisquer sistemas de escrita adicionais necessários. Não presuma que o GB2312 cubra todos os caracteres.
2. Compare a resposta do MWL e o console: a equipe autorizada de worklist/modalidade registra (0008,0005), os bytes de PN e os grupos decodificados na resposta. Compare o console com as representações que ele documenta, em vez de exigir que todo dispositivo exiba três grupos simultaneamente. Mantenha qualquer evidência de substituição ou truncamento.
3. Inspecione a instância criada pelo scanner: gere um objeto de teste sem dados de paciente com suporte do OEM e envie-o ao receptor de teste aprovado. Inspecione a instância armazenada com uma ferramenta compatível com DICOM, mantendo os bytes originais separadamente de um dump decodificado. Associe (0008,0005) a (0010,0010). Para o exemplo de ISO 2022 IR 58, verifique os escapes de componentes; para UTF-8, verifique seus próprios bytes sem escapes de ISO 2022. Documente qualquer conversão deliberada a partir da resposta da worklist.
4. Compare o objeto recuperado do arquivo: recupere a mesma instância fictícia por meio de um fluxo de trabalho aprovado e compare sua declaração, grupos decodificados de PN e valor bruto com a saída do scanner. Explique qualquer conversão de codificação ou atualização demográfica autorizada a partir da documentação e do registro de auditoria do arquivo. Se os bytes foram substituídos, localize o artefato mais antigo que ainda contenha os caracteres pretendidos. A responsabilidade pelo arquivo e a exclusão são uma decisão separada abordada no guia de storage commitment; o commitment não comprova que um nome seja legível.
5. Verifique os visualizadores exigidos e faça a aprovação: verifique cada visualizador utilizado no escopo de aceitação, sua versão de software e a representação de nome exigida. Registre a primeira divergência, o responsável e o resultado do reteste. Uma captura de tela comprova apenas a apresentação. Mantenha discrepâncias demográficas não resolvidas fora do fluxo de trabalho aceito até a disposição da instituição, e coordene outras verificações por meio da lista de verificação de manutenção e aceitação.

Se um salto não puder suportar os caracteres exigidos: pare de tratar o UTF-8 como uma chave universal. Pergunte aos fornecedores responsáveis e ao proprietário da instituição se uma atualização com suporte ou uma conversão validada pode preservar todos os caracteres e grupos de nomes exigidos. A transliteração em ASCII não preserva o Hanzi, e um repertório mais restrito pode não representar um caractere raro. Documente qualquer fluxo de trabalho reduzido aprovado como uma limitação em vez de alegar aceitação multilíngue completa; mantenha correções clínicas sob o processo de governança da instituição.

Gatilhos para reverificação: repita o teste sintético acordado após uma migração de worklist/PACS, alteração no software da modalidade, atualização do visualizador ou revisão relevante da declaração de conformidade. Os links da norma referem-se à edição online atual revisada em 11 de outubro de 2026; documentos de produtos e relatórios de problemas citados nominalmente são exemplos datados, não afirmações sobre todas as versões atuais.

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

Esclarecer os limites operacionais entre a engenharia de software clínico e a manutenção de hardware médico protege as instituições de saúde contra reparos direcionados incorretamente e de alto custo, além de tempo de inatividade prolongado dos equipamentos.

A Rongtao Medical oferece reparo de placas de ultrassom em nível de componentes, serviços em transdutores e peças testadas. Seus dados de serviço publicados especificam teste em equipamento real de 48 horas para cada placa reparada, prazo padrão de 5–8 dias úteis para reparo de placa e garantia tipicamente de 90 dias. Confirme o escopo, a disponibilidade, o prazo e a garantia específicos do item no orçamento; a declaração de testes não estabelece carga de trabalho clínica completa nem a validação da integração multilíngue de um hospital. ¹⁵

Encaminhe para o serviço de hardware quando uma investigação qualificada identificar uma falha física ou sintomas separados de conectividade/inicialização. Um nome corrompido, isoladamente, não identifica uma placa, conector ou transceptor com defeito. Mantenha os logs de sintomas e as evidências de modelo/revisão para que um prestador de serviços possa avaliar a questão real de hardware.

A configuração de PACS e de sistema de informação em radiologia (RIS), o mapeamento de interfaces e a reconciliação de registros clínicos competem às equipes de TI, arquivo e OEM da instituição. Os serviços documentados de placas/peças da Rongtao não estabelecem uma oferta de integração de PACS ou consultoria em banco de dados. Se as evidências da aplicação identificarem uma incompatibilidade de charset, trate essa via de software suportada antes de comprar hardware; continue a avaliar quaisquer sintomas independentes de hardware com base em suas próprias evidências.

A legibilidade do nome é um critério de aceitação. A entrega de medições numéricas é uma tarefa diferente: o guia de entrega de medições DICOM SR explica esse caminho. A emissão de laudos baseada em imagens pode permanecer válida onde atender aos requisitos da instituição; ela não é automaticamente defeituosa por não possuir campos estruturados.

Encaminhamento de hardware pronto para orçamento: se um problema de hardware persistir, envie as evidências abaixo pelo canal de contato aprovado. Mantenha dados demográficos de pacientes e imagens clínicas fora de uma consulta comercial; logs fictícios ou evidências tarjadas são suficientes para a discussão inicial de escopo.

• Equipamento: OEM, modelo exato, versão do software e revisão de hardware relevante.
• Componente: número de peça do fabricante e revisão constantes na etiqueta, além de fotos nítidas da etiqueta. Apenas profissionais qualificados devem remover uma placa; solicite ambos os lados quando ela já tiver sido removida com segurança.
• Sintomas: falha/erro observado, momento em que ocorre, sintomas separados de conectividade ou inicialização e histórico de serviços anterior. Forneça evidências diagnósticas aprovadas, tarjadas ou fictícias.
• Solicitação de fornecimento: quantidade, preferência por reparo ou substituição e país de destino. Confirme a compatibilidade, a disponibilidade atual e os termos com base no item real.

Para diagnósticos de hardware verificados, trocas de placas de circuito ou reparos em transdutores de ultrassom, explore nossas capacidades em Serviços de Reparo da Rongtao Medical ou envie sua consulta técnica de reparo diretamente pelo Contato da Rongtao Medical.