Objetos DICOM e Codificação de Dados: O Que Todo Profissional Precisa Saber
Se você trabalha com imagens médicas, já deve ter se deparado com situações em que um exame simplesmente “não abre” ou aparece corrompido em outro sistema. Na maioria das vezes, o problema está na forma como os dados DICOM são codificados e estruturados internamente. Entender como objetos DICOM funcionam não é apenas curiosidade técnica — é uma habilidade que diferencia o profissional que resolve problemas daquele que apenas os reporta.
Neste artigo, vamos mergulhar na anatomia dos objetos DICOM: como elementos de dados são codificados, a diferença entre codificação implícita e explícita, o funcionamento das sequências SQ e a hierarquia Patient-Study-Series-Image. Para uma visão geral completa do padrão DICOM, confira nosso guia prático de DICOM para sistemas de imagem médica.
Neste Artigo
Dicionário de Dados Privados e Comandos DICOM
O Dicionário de Dados DICOM (PS3.6) mapeia cada atributo do mundo real para uma tag numérica no formato (Grupo, Elemento). Mas o que acontece quando um fabricante precisa armazenar informações proprietárias que não existem no dicionário padrão?
A resposta está nos grupos privados — grupos com numeração ímpar reservados exclusivamente para dados proprietários. Por exemplo, a TeraRecon utiliza o grupo 0077 no seu sistema Aquarius para armazenar atributos como (0077,0010) para UIDs originais de séries e (0077,0020) para nomes de dados binários. Cada fabricante escolhe seu próprio grupo ímpar, garantindo que seus dados proprietários não colidam com o padrão.
Já os comandos DICOM — como Print, Store, Move e Get — são codificados no grupo reservado 0000. O elemento (0000,0100) identifica o tipo de comando, enquanto (0000,0110) armazena o ID da mensagem. Diferentemente dos elementos de dados, o DICOM não permite atributos de comando proprietários, o que limita a flexibilidade do protocolo para cenários modernos como telerradiologia.
Limitações do Sistema de Comandos Atual
O conjunto de comandos DICOM foi projetado para arquiteturas PACS locais, que se tornam progressivamente obsoletas. Projetos modernos de imagem digital, como telerradiologia e integração em nuvem, demandam estruturas de comando mais flexíveis. A impossibilidade de criar tags proprietárias em comandos é uma restrição que a comunidade DICOM ainda debate. Para entender como os comandos operam na prática, o artigo sobre fundamentos DICOM de objetos e comunicações explora os serviços DIMSE com mais detalhes.
Codificação Implícita vs. Explícita: Como o DICOM Escreve Dados
Toda informação em DICOM é convertida em sequências de bytes por meio de dois métodos fundamentais de codificação: implícita e explícita. A escolha entre os dois afeta diretamente como seus sistemas interpretam os dados.
Codificação Implícita (VR Implícito)
Na codificação implícita — o padrão DICOM —, cada elemento de dado é escrito com a seguinte estrutura:
- Tag: 4 bytes (2 para Grupo + 2 para Elemento)
- Comprimento do valor: 4 bytes (inteiro de 32 bits)
- Valor: $L$ bytes de dados
Considere o nome do paciente “Smith^Joe”: o elemento (0010,0010) é codificado em 18 bytes. Os primeiros 4 bytes representam a tag em Little Endian (10 00 10 00), os próximos 4 bytes indicam o comprimento $L = 10$ (0A 00 00 00), e os últimos 10 bytes contêm a string “Smith^Joe ” com espaço de preenchimento para manter comprimento par.
0010 é escrito como 10 00 na sequência binária.
Codificação Explícita (VR Explícito)
A codificação explícita adiciona o tipo VR ao elemento, dividindo-se em duas variantes:
Para VRs padrão (exceto OB, OW, OF, SQ, UT, UN): o campo de 4 bytes do comprimento é substituído por 2 bytes de tipo VR + 2 bytes de comprimento. Para o mesmo “Smith^Joe”, veríamos: 10 00 10 00 50 4E 0A 00 53 6D... — onde 50 4E são os caracteres ASCII “PN” indicando Person Name.
Para VRs especiais (OB, OW, OF, SQ, UT, UN): após os 2 bytes do VR, há 2 bytes reservados (sempre 0000) seguidos de 4 bytes para o comprimento. Essa variante acomoda elementos com dados potencialmente muito grandes, como buffers de pixels.
Quando Usar Cada Método?
Não é possível misturar codificação implícita e explícita no mesmo objeto DICOM. A decisão é negociada entre as aplicações antes de qualquer troca de dados, por meio dos Transfer Syntaxes. Na minha experiência, a codificação explícita é preferível em cenários de interoperabilidade porque carrega informação de tipo junto aos dados, reduzindo erros de decodificação — especialmente com atributos proprietários ausentes do dicionário padrão.
Objetos DICOM e Sequências SQ: Estruturas Aninhadas
Um objeto DICOM é, essencialmente, uma coleção ordenada de elementos de dados. Cada imagem médica, comando ou relatório é encapsulado nesse formato. Os elementos dentro de um objeto são organizados em ordem crescente de tags — essa ordenação não é apenas convenção, mas uma ferramenta de validação: se um elemento com tag menor aparece após um maior, o objeto está corrompido.
A complexidade real surge com o tipo VR SQ (Sequence). Elementos SQ não contêm dados simples — eles encapsulam sequências de outros objetos DICOM, criando uma estrutura em árvore. Pense em um livro: capítulos contêm seções, que contêm subseções. Da mesma forma, um objeto DICOM pode conter objetos aninhados em múltiplos níveis.
Codificação de Sequências SQ
Cada objeto dentro de uma sequência SQ é precedido pela tag de delimitação (FFFE,E000), seguida por:
- Comprimento explícito: um valor numérico indicando quantos bytes o objeto ocupa
- Comprimento indefinido: o valor
FFFFFFFF, onde o fim do objeto é marcado pela tag(FFFE,E00D)
A sequência SQ inteira também pode ter comprimento explícito ou indefinido. No segundo caso, o fim é marcado por (FFFE,E0DD). Essa abordagem com delimitadores é análoga às tags XML de abertura e fechamento — e, na prática, é mais confiável que o comprimento explícito.
Exemplo Prático: Referenced Series Sequence
Um caso real de aninhamento SQ é o atributo (0008,1115) — Referenced Series Sequence. No nível 0, temos o SQ; no nível 1, aparece o Series Instance UID (0020,000E) junto com outra sequência (0008,114A); e no nível 2, encontramos os UIDs de referência (0008,1150) e (0008,1155). Se você programa codificação SQ, implementá-la com recursão é natural — assim como qualquer estrutura de dados em árvore.
Hierarquia de Informação DICOM: Patient-Study-Series-Image
O DICOM organiza toda informação em quatro níveis hierárquicos que refletem o fluxo clínico real: Paciente → Estudo → Série → Imagem.
- Paciente: identificado pelo Patient ID
(0010,0020) - Estudo: identificado pelo Study Instance UID
(0020,000D) - Série: identificada pelo Series Instance UID
(0020,000E) - Imagem: identificada pelo SOP Instance UID
(0008,0018)
Essa hierarquia existe porque na prática clínica, um paciente pode ter múltiplos estudos (CT, RM, US), cada estudo contém séries com diferentes protocolos, e cada série possui uma ou mais imagens. UIDs garantem que cada entidade seja globalmente única — formato UI com até 64 caracteres compostos por dígitos e pontos, como 1.2.840.10008.1.2.
Identificadores Únicos (UIDs): Por Que São Globais?
Imagine uma imagem de raio-X copiada, anotada e enviada para telerradiologia em outro país. Agora existem várias instâncias da mesma imagem original, cada uma potencialmente modificada. Como diferenciá-las? Através de UIDs distintos para cada instância. A estrutura de um UID é <org root>.<suffix>, onde o root identifica a organização e o sufixo garante unicidade dentro do escopo.
Erros Comuns na Estruturação DICOM e Como Evitá-los
Após anos trabalhando com integração de sistemas de imagem, alguns problemas aparecem com frequência preocupante:
1. Patient ID inconsistente: Hospitais que atribuem IDs diferentes ao mesmo paciente dependendo da modalidade ou destino das imagens. Já vi casos onde o ID “W/I” (without ID) era atribuído a todos os pacientes sem cadastro, efetivamente fundindo dezenas de pacientes em um só registro no PACS. Se não há ID disponível, usar iniciais com data de nascimento (ex: JS19670102) é infinitamente melhor que um valor genérico.
2. Elementos obrigatórios ausentes: Digitalizadores de filmes frequentemente encapsulam imagens em DICOM sem incluir todas as tags obrigatórias (Tipo 1). Um Patient ID em branco pode ser interpretado como wildcard, mesclando pacientes diferentes no arquivo. Objetos DICOM sem elementos requeridos são considerados ilegais pelo padrão.
3. Group Length tags incorretas: A tag (gggg,0000) armazenava o comprimento total de um grupo. Embora aposentada desde 2008, muitas implementações ainda a escrevem incorretamente. O resultado? Software DICOM conservador pode rejeitar o objeto inteiro. A recomendação atual é: não inclua, mas saiba lê-la se presente.
Quando NÃO Tentar Interpretar Dados DICOM Manualmente
Há cenários onde tentar parsear objetos DICOM manualmente causa mais problemas do que resolve:
- UIDs como fonte de dados: Nunca extraia informações (data, ID do paciente) a partir do UID. O DICOM proíbe explicitamente essa prática — UIDs podem ser alterados a qualquer momento
- Conversão implícita para explícita com tags proprietárias: Se um atributo de grupo ímpar não existe no dicionário padrão, a conversão para VR explícito pode falhar. Use o tipo UN (Unknown) nesses casos
- Objetos com SQ de múltiplos níveis e comprimento explícito: Um erro de 1 byte no valor de comprimento torna toda a sequência subsequente ilegível. Prefira delimitadores de comprimento indefinido
A compreensão profunda da codificação DICOM é o que permite diagnosticar problemas de interoperabilidade que ferramentas automatizadas não conseguem resolver. Se você quer dominar os conceitos fundamentais do padrão, não deixe de ler nosso guia completo sobre DICOM na prática clínica.
