DICOM (Digital Imaging and Communications in Medicine) é o padrão internacional que torna possível a troca de imagens médicas entre equipamentos, estações de trabalho e sistemas de arquivamento em qualquer hospital do mundo. Sem ele, cada fabricante falaria um idioma diferente — e o caos reinaria nos departamentos de radiologia. Este guia prático condensa os conceitos essenciais do padrão DICOM, desde a estrutura de dados até os protocolos de rede, passando pela integração com prontuários eletrônicos e workflows clínicos. O objetivo é oferecer a você, profissional de radiologia ou TI em saúde, um mapa completo para navegar o ecossistema DICOM com segurança.
O conteúdo deste hub é baseado no livro Digital Imaging and Communications in Medicine (DICOM): A Practical Introduction and Survival Guide, de Oleg S. Pianykh (2ª edição, Springer, 2012) — uma das referências mais acessíveis e práticas sobre o tema. Ao longo dos cinco artigos-satélite (spokes), exploramos cada parte do livro com exemplos reais, dicas de implementação e links para o padrão oficial. Se você precisa instalar um PACS, configurar associações DICOM ou entender por que uma modalidade não consegue enviar imagens, este é o ponto de partida.
- O que é DICOM e por que ele importa
- Introdução ao DICOM e Dados Clínicos
- Objetos de Comando DICOM e Exemplos Práticos
- Comunicações DICOM e Protocolos de Rede
- Integração com Prontuários e Identificação de Pacientes
- Workflows Clínicos e Interoperabilidade
- O Data Dictionary na prática
- PACS e DICOM: a dupla inseparável
- Segurança e conformidade
- Conclusão e próximos passos
O que é DICOM e por que ele importa
DICOM é, em essência, uma língua franca para imagens médicas. Ele define como cada pixel de uma tomografia, ressonância ou radiografia é armazenado, descrito e transmitido — junto com os metadados clínicos do paciente, do estudo e da série. Antes do DICOM, migrar de um equipamento GE para um Siemens significava reconverter milhares de arquivos manualmente. Hoje, graças ao padrão, uma imagem gerada em Tóquio pode ser visualizada em São Paulo sem perda de informação.
O padrão é mantido pela NEMA (National Electrical Manufacturers Association) em conjunto com a ACR (American College of Radiology) e está em constante evolução. A versão mais recente — disponível em dicomstandard.org — já ultrapassa 20 partes e milhares de páginas. Não se assuste: a maioria dos profissionais precisa dominar apenas os conceitos centrais, que é exatamente o que este guia oferece.
Se você está começando, recomendo também a leitura do nosso artigo DICOM na Prática Clínica, que traz cenários do dia a dia em um departamento de radiologia.
Introdução ao DICOM e Dados Clínicos
O DICOM começa pelos dados — e entendê-los é metade do caminho. Cada arquivo DICOM é composto por um cabeçalho (header) repleto de atributos organizados em tags numéricas e um bloco de pixel data que contém a imagem propriamente dita. As Partes I e II do livro de Pianykh cobrem essa fundação: o que é o padrão, como surgiu, e como os dados são estruturados internamente.
O Data Dictionary é o coração do DICOM. Ele lista todas as tags reconhecidas pelo padrão — de (0008,0018) SOP Instance UID a (7FE0,0010) Pixel Data. Cada tag tem um VR (Value Representation) que define o tipo de dado: DA para datas, PN para nomes de pacientes, UI para identificadores únicos, e assim por diante. Dominar o Data Dictionary significa conseguir ler qualquer cabeçalho DICOM e extrair a informação que você precisa — seja o nome do paciente, a espessura do corte ou os parâmetros de aquisição.
Os Value Representations (VRs) merecem atenção especial. Um erro comum é tratar o VR errado ao processar dados DICOM programaticamente. Por exemplo, confundir um campo DS (Decimal String) com um IS (Integer String) pode causar erros silenciosos em cálculos de dose ou posicionamento. O padrão define dois modos de codificação de VR: explícito e implícito. No modo explícito, o VR vem embutido em cada elemento de dados; no implícito, é preciso consultar o Data Dictionary para saber o tipo. A recomendação moderna é usar sempre o modo explícito (Explicit VR Little Endian), que é menos ambíguo.
Outro conceito fundamental é a hierarquia de dados DICOM: Patient → Study → Series → Instance. Cada nível possui identificadores únicos (UIDs) que permitem rastrear uma imagem desde o paciente até o pixel. Essa hierarquia espelha o fluxo clínico: um paciente faz um estudo (exame), que contém uma ou mais séries (sequências), cada uma com múltiplas instâncias (imagens individuais).
👉 Leia o artigo completo: Introdução ao DICOM e Dados Clínicos
Objetos de Comando DICOM e Exemplos Práticos
Se o Data Dictionary define o que os dados significam, os objetos de comando definem o que fazer com eles. É aqui que o DICOM ganha vida operacional. Os command objects são as mensagens que transitam entre dispositivos para executar ações como armazenar uma imagem (C-STORE), buscar um estudo (C-FIND), mover séries entre nós (C-MOVE) ou verificar conectividade (C-ECHO).
Cada comando é composto por um DIMSE (DICOM Message Service Element) emparelhado com um IOD (Information Object Definition). Pense no IOD como um formulário padronizado — ele define quais campos são obrigatórios, opcionais ou condicionais para um determinado tipo de imagem ou relatório. Uma CT Image IOD, por exemplo, exige atributos como Slice Thickness e Image Position (Patient) que não fazem sentido para uma radiografia convencional.
O Private Data Dictionary é outro tópico que Pianykh aborda com clareza. Fabricantes podem estender o padrão com tags proprietárias — sempre em grupos ímpares (por convenção). Isso permite armazenar informações específicas do equipamento (como parâmetros de reconstrução ou dados de calibração) sem violar o padrão. O risco? Se você migrar de fornecedor, esses dados privados podem se perder ou ser ignorados pelo novo sistema.
dcmdump (parte do DCMTK) para inspecionar cabeçalhos DICOM. O comando dcmdump arquivo.dcm exibe todas as tags, incluindo as privadas, em formato legível.A Conformance Statement é o documento que cada fabricante publica descrevendo quais SOP Classes (serviços + IODs) seu equipamento suporta, em quais papéis (SCU/SCP) e com quais Transfer Syntaxes. Antes de integrar qualquer dispositivo ao PACS, o primeiro passo é sempre ler a Conformance Statement. Ela evita surpresas como descobrir que o novo ultrassom não suporta C-MOVE ou que a ressonância só exporta em JPEG 2000 lossless.
👉 Leia o artigo completo: Objetos de Comando DICOM e Exemplos Práticos
Comunicações DICOM e Protocolos de Rede
O DICOM funciona sobre TCP/IP — e isso é ao mesmo tempo sua força e sua complexidade. A Parte III do livro de Pianykh mergulha nos protocolos de rede: como dois nós DICOM negociam uma conexão, trocam dados e encerram a sessão de forma ordenada. Entender esse fluxo é essencial para diagnosticar problemas de conectividade que, na prática hospitalar, são a causa número um de chamados técnicos.
Tudo começa com a Association — o equivalente DICOM de um handshake. O nó que inicia a conexão (SCU — Service Class User) envia um A-ASSOCIATE-RQ ao servidor (SCP — Service Class Provider), propondo uma lista de SOP Classes e Transfer Syntaxes que deseja utilizar. O SCP responde com A-ASSOCIATE-AC (aceitando) ou A-ASSOCIATE-RJ (rejeitando). Esse mecanismo de negociação garante que ambos os lados concordem sobre formato de dados e serviços antes de qualquer transferência.
Os DICOM Services mais utilizados no dia a dia são:
- C-ECHO — Verificação de conectividade (o “ping” do DICOM)
- C-STORE — Envio de imagens de uma modalidade para o PACS
- C-FIND — Consulta ao banco de dados do PACS (worklist, estudos)
- C-MOVE — Solicitação para que o PACS envie imagens a outro nó
- C-GET — Similar ao C-MOVE, mas a resposta retorna pela mesma conexão
Cada nó DICOM é identificado por um AE Title (Application Entity Title) — uma string de até 16 caracteres que funciona como um “nome de rede” do dispositivo. A configuração correta dos AE Titles, endereços IP e portas é o passo mais básico (e mais frequentemente errado) na integração DICOM. Um AE Title digitado com espaço a mais ou caixa errada pode impedir toda a comunicação.
As Transfer Syntaxes definem como os dados são codificados na transmissão: ordem dos bytes (Little/Big Endian), VR explícito ou implícito, e tipo de compressão (JPEG, JPEG 2000, JPEG-LS, RLE). A Transfer Syntax padrão — Implicit VR Little Endian — é obrigatória para todos os dispositivos, mas na prática convém negociar Explicit VR Little Endian ou uma syntax com compressão para reduzir o tráfego de rede, especialmente em links WAN.
Para entender como o PACS se encaixa nesse cenário de rede, veja nosso artigo sobre a evolução histórica do PACS e RIS.
👉 Leia o artigo completo: Comunicações DICOM e Protocolos de Rede
Integração com Prontuários e Identificação de Pacientes
O DICOM não existe em um vácuo — ele precisa conversar com o restante do ecossistema hospitalar. A Parte IV do livro de Pianykh explora a integração com prontuários eletrônicos (EMR/EHR), sistemas de informação hospitalar (HIS) e o padrão HL7, que cuida dos dados administrativos e clínicos fora do domínio de imagens.
A identificação do paciente é o ponto mais crítico dessa integração. No DICOM, o paciente é identificado por Patient ID (0010,0020), Patient Name (0010,0010) e, opcionalmente, por Issuer of Patient ID (0010,0021). No HIS/EMR, o mesmo paciente pode ter um MRN (Medical Record Number), um número de convênio e um CPF. Manter esses identificadores sincronizados é fundamental para evitar o pesadelo da misidentification — quando imagens de um paciente são atribuídas a outro.
O HL7 (Health Level Seven) é o padrão de mensageria que rege a comunicação entre sistemas administrativos: admissão, alta, transferência (ADT), pedidos de exame (ORM) e resultados (ORU). Quando um médico solicita uma tomografia no sistema de pedidos, uma mensagem HL7 ORM é enviada ao RIS, que por sua vez cria uma Worklist entry acessível via DICOM Modality Worklist (MWL). A modalidade consulta essa worklist, preenche automaticamente os dados do paciente e do estudo, e envia as imagens ao PACS com os identificadores corretos.
O conceito de Account Number (0008,0050 — Accession Number no DICOM) funciona como elo de ligação entre o pedido médico no HIS e o estudo no PACS. Ele garante que, ao abrir o resultado no prontuário, o sistema consiga localizar exatamente as imagens correspondentes. Problemas com Accession Number duplicados ou ausentes são uma das causas mais comuns de estudos “perdidos” no PACS.
Para um panorama completo de como o PACS se integra ao atendimento ao paciente, leia também PACS na Saúde: melhorando o atendimento por meio da tecnologia.
👉 Leia o artigo completo: Integração com Prontuários e Identificação de Pacientes
Workflows Clínicos e Interoperabilidade
Interoperabilidade não é apenas conectar dois sistemas — é garantir que eles trabalhem juntos de forma previsível e confiável. O último bloco do livro de Pianykh aborda os workflows clínicos que orquestram o fluxo de informações desde a solicitação do exame até a entrega do laudo, passando pela aquisição, processamento e arquivamento das imagens.
O HL7 versão 3 (e seu sucessor funcional, o FHIR — Fast Healthcare Interoperability Resources) representa uma evolução significativa em relação ao HL7 v2.x. Enquanto a versão 2 usa mensagens baseadas em pipes e segmentos de texto, a v3 adota um modelo de referência baseado em XML (RIM — Reference Information Model). O FHIR, por sua vez, combina o melhor dos dois mundos: a simplicidade do REST com recursos estruturados em JSON ou XML. Para a radiologia, o FHIR abre portas para integração com apps móveis, dashboards em tempo real e inteligência artificial.
O IHE (Integrating the Healthcare Enterprise) não é um padrão em si, mas um framework que define perfis de integração — receitas passo a passo para resolver problemas reais de interoperabilidade usando padrões existentes (DICOM, HL7, FHIR). Os perfis mais relevantes para radiologia incluem:
- SWF (Scheduled Workflow) — Orquestra o fluxo desde o pedido até o arquivamento
- PIR (Patient Information Reconciliation) — Corrige inconsistências de identificação do paciente
- XDS-I (Cross-Enterprise Document Sharing for Imaging) — Compartilhamento de imagens entre instituições
- WADO (Web Access to DICOM Objects) — Acesso a imagens via HTTP/HTTPS, essencial para viewers web
As Transfer Syntaxes voltam a ser relevantes aqui, agora sob a ótica do workflow. Um fluxo bem desenhado considera qual compressão usar em cada etapa: JPEG 2000 lossless para arquivamento de longo prazo, JPEG com perdas para visualização rápida em dispositivos móveis, e sem compressão para processamento em estações de diagnóstico. A escolha errada pode degradar a qualidade diagnóstica ou consumir bandwidth e armazenamento desnecessários.
Um workflow robusto também precisa lidar com exceções: exames de urgência que chegam sem pedido, pacientes não identificados (“John Doe”), estudos que precisam ser corrigidos após o arquivamento (Correction Workflow) e imagens que precisam ser compartilhadas com instituições externas (Image Sharing). O IHE oferece perfis específicos para cada um desses cenários.
👉 Leia o artigo completo: Workflows Clínicos e Interoperabilidade
O Data Dictionary DICOM na prática
Conhecer o Data Dictionary na teoria é uma coisa; usá-lo no dia a dia é outra. Na prática, você vai consultar o dicionário sempre que precisar: filtrar estudos por critérios específicos em uma query C-FIND, mapear campos entre DICOM e HL7, ou debugar por que um atributo chega vazio ao PACS.
Algumas tags que todo profissional de imagem médica deveria conhecer de cor:
- (0008,0060) Modality — CT, MR, US, CR, DX, etc.
- (0008,0050) Accession Number — Liga o estudo ao pedido
- (0010,0020) Patient ID — Identificador do paciente
- (0020,000D) Study Instance UID — Identificador único do estudo
- (0020,000E) Series Instance UID — Identificador único da série
- (0008,0018) SOP Instance UID — Identificador único da instância
- (7FE0,0010) Pixel Data — Os pixels propriamente ditos
Quando um atributo não está no dicionário público, ele é provavelmente uma tag privada (Private Data Element). Tags privadas vivem em grupos ímpares e são prefixadas por um Private Creator Element que identifica o fabricante. Ao migrar dados entre fornecedores, tags privadas costumam ser ignoradas ou removidas — por isso, nunca armazene informações clínicas críticas exclusivamente em tags privadas.
PACS e DICOM: a dupla inseparável
Um PACS (Picture Archiving and Communication System) é, na essência, um servidor DICOM com esteroides. Ele recebe imagens via C-STORE, responde a consultas via C-FIND, distribui estudos via C-MOVE e arquiva tudo em storage de longo prazo. Sem DICOM, o PACS simplesmente não existiria — pelo menos não de forma interoperável.
A arquitetura típica de um PACS inclui:
- Gateway/Router — Recebe imagens das modalidades e aplica regras de roteamento
- Archive — Armazenamento de curto e longo prazo (online/nearline/offline)
- Workstation/Viewer — Onde o radiologista visualiza e lauda os exames
- Web Server — Acesso via WADO para clínicos e especialistas remotos
A evolução do PACS e RIS ao longo das últimas décadas mostra como a tecnologia saiu de arquivos em filme para sistemas totalmente digitais que processam milhões de imagens por ano. E o DICOM acompanhou — e viabilizou — cada etapa dessa transformação.
Atualmente, a tendência é o PACS na nuvem — ou VNA (Vendor Neutral Archive) — que separa o armazenamento do viewer e permite acesso de qualquer lugar. Nesse modelo, as imagens continuam sendo DICOM, mas a distribuição pode usar DICOMweb (WADO-RS, STOW-RS, QIDO-RS) sobre HTTPS, eliminando a necessidade de VPNs ou portas DICOM dedicadas.
Segurança e conformidade no ecossistema DICOM
Segurança em DICOM não é opcional — é uma exigência regulatória. A LGPD no Brasil e a HIPAA nos EUA impõem requisitos rigorosos sobre como dados de saúde são armazenados, transmitidos e acessados. O padrão DICOM oferece mecanismos nativos de segurança, mas eles precisam ser corretamente configurados.
O DICOM TLS (Transport Layer Security) criptografa a comunicação entre nós DICOM, impedindo que dados de pacientes trafeguem em texto claro pela rede. Embora o suporte a TLS seja parte do padrão desde 2000 (Suplemento 31), muitas instalações ainda operam sem criptografia — um risco inaceitável em redes que não são fisicamente isoladas.
A anonimização de dados DICOM é necessária para pesquisa, ensino e compartilhamento externo. O perfil de de-identificação do DICOM (Parte 15, Anexo E) lista quais tags devem ser removidas, substituídas ou pseudonimizadas. Ferramentas como o DICOM Anonymizer do CTP (Clinical Trial Processor) ou o módulo de anonimização do Orthanc automatizam esse processo.
Conclusão e próximos passos
O DICOM é muito mais do que um formato de arquivo — é a infraestrutura invisível que sustenta toda a radiologia digital moderna. Dos pixels na tela do radiologista até a integração com prontuários eletrônicos e sistemas de inteligência artificial, o padrão permeia cada etapa do fluxo de trabalho em imagem médica.
Este hub reúne cinco artigos-satélite que aprofundam cada aspecto do ecossistema DICOM:
- Introdução ao DICOM e Dados Clínicos — Data Dictionary, VRs e hierarquia de dados
- Objetos de Comando e Exemplos Práticos — DIMSE, IODs e Conformance Statements
- Comunicações DICOM e Protocolos de Rede — Associations, AE Titles e Transfer Syntaxes
- Integração com Prontuários e Identificação — HL7, MWL e Accession Numbers
- Workflows Clínicos e Interoperabilidade — IHE, FHIR e perfis de integração
Se você trabalha com imagens médicas — seja como radiologista, físico médico, engenheiro biomédico ou profissional de TI em saúde — dominar o DICOM não é opcional. É o que separa o profissional que resolve problemas do que apenas reinicia equipamentos. Comece pelo artigo que mais se relaciona com seu desafio atual e construa seu conhecimento de forma modular.
E se você quer ver como tudo isso se aplica no mundo real, não deixe de conferir o nosso guia DICOM na Prática Clínica, com cenários e soluções do dia a dia em departamentos de radiologia.
