O que são arquivos DICOM e por que sua estrutura importa?
Arquivos DICOM são a espinha dorsal da troca de dados em imagens médicas fora do ambiente de rede. Quando falamos de CDs de pacientes, pen drives com exames ou mesmo anexos de e-mail com imagens radiológicas, estamos lidando com arquivos DICOM — e compreender sua anatomia interna é essencial para quem trabalha com integração de sistemas de imagem.
Na prática diária, a maioria dos profissionais interage com esses arquivos sem pensar duas vezes sobre o que acontece nos bastidores. Mas se você já teve que lidar com um CD de exame que “não abre” em outro sistema, ou tentou importar dados que simplesmente não foram reconhecidos pelo PACS receptor, provavelmente o problema estava na estrutura do arquivo. Para uma visão completa do ecossistema DICOM, confira nosso guia completo sobre DICOM na prática clínica.
Anatomia de um arquivo DICOM: do preâmbulo ao objeto de dados
Todo arquivo DICOM segue uma estrutura rigorosamente definida pelas partes PS3.10, PS3.11 e PS3.12 do padrão. Essa estrutura é composta por quatro seções sequenciais, e entender cada uma delas evita muita dor de cabeça.
Preâmbulo e prefixo DICM
Os primeiros 128 bytes de qualquer arquivo DICOM constituem o preâmbulo. O padrão DICOM não define um conteúdo específico para essa área — cada aplicação pode utilizá-la como quiser. Na prática, a maioria dos softwares simplesmente preenche esses 128 bytes com zeros. Logo em seguida, nos bytes 129 a 132, encontramos as quatro letras maiúsculas D I C M: o prefixo que identifica inequivocamente um arquivo DICOM.
Este é, aliás, o único método realmente confiável para identificar se um arquivo é DICOM ou não. Esqueça a extensão “.dcm” — ela é apenas uma convenção, e o próprio padrão oscila entre proibi-la e exigi-la em diferentes contextos. Se você estiver escrevendo software para identificar arquivos DICOM, pule os primeiros 128 bytes e verifique o prefixo DICM. Ponto.
Grupo 0002: metadados do arquivo
A partir do byte 133, começa a File Meta Information — um conjunto de atributos DICOM pertencentes ao grupo 0002. Esses elementos são sempre codificados com VR explícito, independentemente da codificação do objeto de dados propriamente dito. Entre os atributos mais importantes estão:
- Media Storage SOP Class UID (0002,0002): identifica o tipo do objeto armazenado (CT, MR, US, etc.)
- Media Storage SOP Instance UID (0002,0003): identificador único da instância
- Transfer Syntax UID (0002,0010): define como o objeto de dados está codificado — este é provavelmente o atributo mais crítico de todo o grupo
- Implementation Class UID (0002,0012): identifica a implementação que criou o arquivo
Na minha experiência, o Transfer Syntax UID é onde muitos problemas de interoperabilidade começam. Na comunicação de rede DICOM, a Transfer Syntax é negociada durante o estabelecimento da associação. Em arquivos, ela fica registrada no cabeçalho — e se o software receptor não a interpretar corretamente, simplesmente não consegue decodificar as imagens.
O objeto de dados
Após o grupo 0002, encontramos o objeto DICOM propriamente dito — as mesmas estruturas de dados utilizadas na comunicação de rede. A numeração dos grupos começa em 0008, facilitando a identificação de onde termina a meta informação e onde começam os dados clínicos. Como discutido no post sobre objetos DICOM e codificação de dados, a codificação VR define como cada atributo é interpretado.
Um cuidado fundamental: o grupo 0002 sempre usa VR explícito, mas o objeto de dados pode usar VR implícito, dependendo da Transfer Syntax indicada no campo (0002,0010). Softwares que não fazem essa troca na leitura irão falhar. Por essa razão, o padrão DICOM recomenda VR explícito para todo o arquivo — embora a Transfer Syntax padrão do DICOM seja Implicit Little Endian.
DICOMDIR: o índice que organiza (e complica) tudo
O DICOMDIR é um arquivo DICOM especial que funciona como um índice — uma espécie de banco de dados miniatura que lista todos os arquivos DICOM presentes em um determinado diretório. Ele organiza as informações em quatro níveis hierárquicos: Patient → Study → Series → Image.
Quando você insere um CD DICOM em uma estação PACS, o software normalmente lê primeiro o DICOMDIR para apresentar a lista de pacientes, estudos e séries contidos na mídia. Nomes de pacientes, datas de estudo, modalidades — tudo extraído das chaves de seleção armazenadas no DICOMDIR.
Internamente, o DICOMDIR utiliza uma sequência SQ (0004,1220) que contém todos os registros do diretório. Cada entrada possui dados de dois tipos: chaves de seleção para busca (como modalidade e nome do paciente) e informações do Basic Directory Information Object (grupo 0004), que armazena IDs de arquivo e relacionamentos entre os registros.
Os problemas práticos do DICOMDIR
Na prática, DICOMDIRs apresentam limitações significativas. Existem pelo menos três razões concretas para desconfiar deles:
1. Utilidade questionável. Qualquer software DICOM bem projetado deveria escanear todos os arquivos de uma pasta, identificando os que estão em formato DICOM. Mesmo um DVD cheio de dados pode ser varrido rapidamente. Para importação em PACS ou visualização — os dois usos mais comuns — o DICOMDIR adiciona eficiência negligível ao processo.
2. Fragilidade. Quando exportamos dados para mídia removível, os usuários inevitavelmente copiam, renomeiam e reorganizam arquivos. Qualquer dessas ações invalida o DICOMDIR. Se o software receptor depender exclusivamente dele para importar, os resultados serão incorretos. Existem até ferramentas dedicadas exclusivamente a corrigir DICOMDIRs inválidos — o que por si só já demonstra o tamanho do problema.
3. Complexidade de manutenção. O DICOMDIR precisa ser atualizado sempre que qualquer arquivo no diretório muda. Em mídias com gravação única (CD-R), ele deve ser o último arquivo gravado para refletir o conteúdo correto.
Serviços de arquivo e papéis de aplicação DICOM
O padrão DICOM define cinco serviços de mídia que gerenciam operações com arquivos: M-WRITE (criar), M-READ (ler), M-DELETE (excluir), M-INQUIRE FILE-SET (consultar espaço) e M-INQUIRE FILE (consultar data/hora de criação). A partir desses serviços, qualquer Application Entity assume um dos três papéis:
- File Set Creator (FSC): cria o DICOMDIR e os arquivos DICOM
- File Set Reader (FSR): apenas lê, sem modificar nenhum arquivo
- File Set Updater (FSU): pode ler, criar e excluir — na prática funciona como FSC + FSR com capacidade de M-DELETE
A comparação com a comunicação de rede DICOM é instrutiva. No modelo de rede, os Application Profiles são negociados durante o estabelecimento da associação. Com arquivos, essa negociação simplesmente não existe — os perfis precisam ser compatíveis a priori. Se uma aplicação grava imagens de MR e a outra espera CT, não há mecanismo de erro amigável. Isso levou o padrão a definir Application Profiles extremamente detalhados, como mostra o artigo sobre fundamentos DICOM: objetos, comunicação e dados.
Segurança em arquivos DICOM: criptografia e assinaturas
Uma diferença fundamental entre transmitir objetos DICOM pela rede e trocá-los como arquivos é o escopo dos riscos de segurança. Interceptar mensagens de rede exige habilidades específicas; copiar, excluir ou modificar um arquivo é algo que qualquer pessoa pode fazer.
O formato de arquivo DICOM seguro oferece três propriedades de proteção:
- Confidencialidade: o arquivo inteiro é criptografado e ilegível sem a chave correta
- Autenticação de origem: certificados e assinaturas digitais identificam quem criou ou modificou o arquivo
- Integridade: checksums e assinaturas impedem alterações não detectadas em dados como nome do paciente ou data do laudo
Na prática, a adoção de arquivos DICOM seguros ainda é bastante limitada. Poucos softwares PACS implementam esse recurso, e a definição no padrão permanece superficial. Se a segurança de dados em mídia removível é uma preocupação — e deveria ser, considerando regulamentações como LGPD e HIPAA — a melhor estratégia continua sendo eliminar a mídia física do processo.
Erros comuns e como evitá-los
Ao longo de anos de integração DICOM, alguns problemas se repetem com frequência preocupante:
1. Confiar no nome do arquivo para identificação. A extensão “.dcm” não é padronizada. Muitas implementações usam SOP UIDs como nomes de arquivo, resultando em strings longas e potencialmente problemáticas. Sempre identifique arquivos DICOM pelo prefixo DICM no cabeçalho.
2. Não tratar a mudança de VR entre cabeçalho e dados. O grupo 0002 é sempre Explicit VR. Se a Transfer Syntax do objeto indicar Implicit VR, o software precisa fazer essa troca. Esse é um dos bugs mais frequentes em leitores DICOM.
3. Usar barras invertidas em File IDs. O separador de componentes do File ID usa backslash (\), que também é o caractere curinga DICOM para “OU lógico”. Quebrar nomes de arquivo com backslash em componentes separados é um dos bugs mais comuns. Use barras normais (/) como alternativa.
Quando NÃO usar mídia DICOM
A troca de mídia física DICOM deveria ser evitada sempre que possível. Cenários em que a rede DICOM ou soluções web devem ser preferidas:
- Transferências frequentes entre instituições: redes VPN com DICOM C-Store são infinitamente mais eficientes que ciclos de gravação/envio/importação de CDs
- Médicos solicitantes externos: soluções de teleradiologia web permitem acesso imediato sem depender de software DICOM instalado
- Qualquer cenário onde reenvio é provável: gravar um CD, enviar pelo correio, descobrir que faltam cortes finos, regravar… esse ciclo é improdutivo e custoso
O conceito de medialess tem ganhado tração na comunidade: eliminar completamente CDs e DVDs do fluxo de troca de dados. Se você pode adotar essa abordagem, faça-o. Sem mídia = sem problemas de mídia.
Para uma análise mais aprofundada da comunicação de rede DICOM como alternativa à troca de mídia, veja nosso artigo sobre comunicação DICOM: SOPs, DIMSE e rede na prática. Para entender a codificação dos objetos armazenados nesses arquivos, confira o post sobre objetos DICOM e estrutura de dados.
O futuro: armazenamento DICOM além das limitações
O modelo atual de armazenamento DICOM em mídia é, francamente, excessivamente detalhado em aspectos que não deveria controlar — como setores de boot e regras de nomes de arquivo específicas por tipo de mídia. Ao mesmo tempo, deixa lacunas onde a flexibilidade seria mais útil.
Uma proposta interessante seria a criação de um utilitário de empacotamento — algo como um “DICOMPack” que funcionasse de forma análoga aos compactadores ZIP e RAR, mas com recursos específicos para imagens médicas: compressão JPEG2000 ou JPEG-LS (muito mais eficiente que ZIP para dados de imagem), suporte a criptografia, divisão de arquivos e até anonimização integrada. Essa abordagem eliminaria a dependência de mídia específica, tornando a troca de dados mais portátil e segura.
O padrão DICOM já admite o uso de ZIP para comprimir pastas DICOM (Anexo L do PS3.11) e arquivar file sets (Anexo V do PS3.12), mas com restrições que limitam sua utilidade prática — nomes predefinidos, apenas um file set por arquivo, ausência de compressão específica para imagem. A evolução natural passa por abstrair a camada de mídia e focar na funcionalidade de empacotamento inteligente.
Enquanto essas melhorias não chegam, a recomendação prática é investir em infraestrutura de rede e soluções de acesso remoto, reservando a mídia física apenas para situações onde realmente não há alternativa.
