PADRÃO DE COMUNICAÇÃO DE IMAGENS MÉDICAS

DICOM V3.0 1

Ronaldo Gomes da Silva 2

Orientador: Prof. Milton Sampaio3

RESUMO
O padrão DICOM ( Digital Imaging Communication in Medicine ) especifica um protocolo de
transferência de dados, formato de imagem digital, e uma estrutura de arquivo para imagens
médicas e informações co-relatas. O objetivo deste trabalho é estudar o padrão DICOM v3.0,
seus protocolos, suas aplicações e limitações.

Palavras-Chave: DICOM, Telemedicina, Teleradiologia.

O tema deste artigo é o padrão DICOM versão 3.0 ou simplesmente DICOM ( Digital
Imaging and Communication in Medicine ). O DICOM é um padrão desenvolvido
pelo American College of Radiology ( ACR ) em associação com National Electronics
Manufacturer’s Association ( NEMA ), ele permite que dispositivos que criam ou
trabalham com imagens médicas troquem estas imagens assim como informações
relacionadas a elas. O artigo se justifica pois O DICOM é largamente usado hoje em
dia pela maioria dos fabricantes de equipamentos médicos.
O Objetivo do trabalho é estudar o padrão DICOM, estabelecer uma visão geral do
seu funcionamento, apresentar informações relevantes para o seu entendimento e
implementação.
Embora o padrão não tenha sido alterado, 23 suplementos foram adicionados para
tratar de mudanças e necessidades que surgiram desde a criação do padrão
original. Atualmente o padrão DICOM consiste em 18 volumes contendo
informações sobre protocolos de transferência de dados , formato de imagem digital
e estrutura de arquivo para imagens médicas e informações co-relatas. O objetivo
específico do artigo é colher as informações relevantes do padrão, descrevendo
suas funções e mostrando exemplos.

VISÃO GERAL
O DICOM estabelece informações detalhadas de como devem ser projetadas as
interfaces que possibilitarão a intercomunicação de equipamentos de aquisição de

1
Artigo final da especialização em Redes de Computadores 2002 da Universidade Salvador – UNIFACS
2
Graduado em engenharia Elétrica pela UFBA, pós-graduando em Redes de Computadores pela Universidade
Salvador – UNIFACS. E-mail ronaldog2207@uol.com.br
3
Mestre em Informação Estratégica pela UFBA - Universidade Federal da Bahia, Especialista em Administração
pela UNIFACS - Universidade Salvador, Graduado em engenharia Mecânica pela UFRJ - Universidade Federal
do Rio de Janeiro, Professor de cursos de Extensão e Graduação e Pós-graduação na UNIFACS _ Universidade
Salvador, FTE - Faculdade de Tecnologia Empresarial e de Graduação nas Faculdades Jorge Amado, Consultor
nas áreas de Gestão Estratégica, Gestão do Conhecimento e Inteligência Competitiva, Membro Consultivo da
EngenAr - Empresa Júnior de Engenharias e Arquitetura da UNIFACS - Universidade Salvador. E-mail
miltonsampaio@aol.com
 2

imagem médica, estações de trabalho de visualização e processamento de imagem,

unidades de arquivo e impressoras de filme ou papel, de diversos fabricantes e
modalidades. O padrão descreve como formatar e transferir os arquivos de imagens
médicas, dentro do mesmo hospital ou para fora do mesmo.
O padrão DICOM é baseado no modelo de referência para Interconexão de
Sistemas Abertos (Open System Interconnection - OSI ) desenvolvido pela ISO -
International Organization for Standardization, com o propósito de padronizar a
comunicação entre sistemas de processamento heterogêneos. O modelo OSI é
composto de 7 camadas, embora as 4 primeiras camadas ( física, enlace, rede e
transporte ) não sejam tratadas pelo o padrão DICOM, este apresenta total
compatibilidade com o protocolo TCP/IP. Através de uma camada de interface, as
entidades de aplicação estabelecem associações, transferem mensagens e
terminam associações, isolando a camada de aplicação DICOM da pilha de
protocolos de comunicação das camadas inferiores.
A troca de mensagens utilizando o DICOM começa com o estabelecimento de uma
associação, para isso é utilizado o protocolo ACSE (Association Control Service
Element ) que é baseado no modelo OSI, após a associação o padrão DICOM utiliza
o protocolo DIMSE para a troca de informação.
O DICOM utiliza os conceitos de classe de serviço e definição de objeto para
implantar as funcionalidades necessárias para a troca de imagens médicas. Através
da definição de objeto as entidades de aplicação partilham uma visão comum das
informações que serão trocadas, e da classe de serviço, os tipos de tarefas que
devem ser implementas pelos dispositivos.
Para entendermos as funcionalidade do modelo DICOM tomemos como exemplo
uma aplicação básica do protocolo DICOM, a transferência de imagens de uma
equipamento médico para outro equipamento ou para uma estação de trabalho. O
DICOM oferece funcionalidades importantes que não estão presentes em um
protocolo de transferência de arquivos genérico.
Tendo um conhecimento comum entre cliente e servidor da estrutura de informação
dos objetos, ou seja das propriedades de cada tipo de imagem incluindo
informações a respeito de como estas imagens foram adquirida ( data, equipamento,
técnicas utilizadas, etc.. ) e dados pessoais dos pacientes ( Nome, idade, sexo ). O
receptor, ciente da estrutura da informação que irá receber, pode realizar diversas
funções como permitir ao software receptor alocar recursos de acordo com o tipo de
imagem que irá ser transferida, arquivar e armazenar estas imagens utilizando uma
indexação baseada nos atributos das imagens como nome do paciente, data do
exame, tipo de imagem, entre outros, ao invés de utilizar simplesmente o nome do
arquivo transferido, e fazer a busca de imagens tanto remotamente como
localmente, utilizando também atributos do objeto como o nome do paciente, nome
do médico, idade, etc..

MENSAGEM DICOM
Informação é comunicada através da interface de rede em uma mensagem DICOM.
Esta mensagem é composta de um conjunto de comandos seguido de um conjunto
de dados. O conjunto de comando é usado para indicar operação e notificação que
serão executados no conjunto de dados. A estrutura geral de uma mensagem
DICOM é mostrada na figura 3.1
 3

Figura 3.1

CONJUNTO DE COMANDO

Um conjunto de comando é composto de elementos de comando. Esses elementos

contêm os valores codificados de cada campo de acordo com a semântica
especificada pelo protocolo DIMSE que veremos a seguir.
Os elementos de comando no conjunto de comando devem vir em ordem crescente
de acordo com o número da etiqueta ( Comand Element Tag ). A etiqueta identifica o
elemento de comando unicamente e deve aparecer no máximo uma vez no conjunto
de comando, a codificação do elemento de comando deve ser na ordem de byte
Little Endian.

CONJUNTO DE DADOS

Figura 3.2
O conjunto de dados ( Data Set ) é composto de diversos elemento de dados fig.
3.2, cada elemento de dado é composto de três ou quatro campos, etiqueta ( tag ),
representação de valor ( VR ), tamanho do valor, e campo de dados. Os elementos
de dados são definidos unicamente por uma etiqueta (Tag). Os elementos de dados
devem ser ordenados de acordo com a etiqueta em ordem crescente.
 4

Etiqueta VR Tamanho Valor

Número do Número do Caractere de 2 Reservado Tamanho em

Grupo Elemento bytes bytes do campo
estabelecendo a valor
representação
do valor ( tipo
do dado)

2 bytes 2 bytes 2 bytes 2 bytes 4 bytes Variável

ETIQUETA

A etiqueta é composta de 32 bits ( 4 bytes ), 2 bytes para o grupo e 2 bytes para o

elemento, os grupos pares são os que são definidos pelo padrão DICOM e podem
ser encontrados na parte 6 do padrão, os grupos impares são para uso privado.
Exemplo de Grupos

Grupo Descrição

0002 Grupo de meta-elementos

0008 Grupo de identificação

0018 Grupo de Aquisição

0028 Grupo de apresentação das imagens

Exemplo de Etiquetas

Grupo Elemento Titulo Descrição

0002 0010 Transfer Index UID Define a sintaxe de transferência

0002 0016 AE Fonte Título da entidade de aplicação.

0008 0016 SOP Class UID Define a classe par serviço-objeto (SOP)

0008 0060 Modalidade Modalidade da imagem ( MR, CT, XR)

0008 0070 Fabricante GE, Siemens, Toshiba

0018 0050 Espessura do Corte Parâmetro de aquisição da imagem

7FE0 0010 Pixel Data Imagem

REPRESENTAÇÃO DE VALOR ( VR)

O campo VR ( Value Representation ) do elemento de dados deve conter 2 bytes

que especificam o tipo de dados e a sintaxe de transferência que estará no campo
 5

de dados, o VR pode ser explícito ou implícito, no implícito os dados são utilizados

na sintaxe de transferência padrão DICOM ( implicit VR Little Indian ). Quando o VR
for explícito, a representação dos dados será data pelas definições contidas na parte
5 do padrão DICOM de acordo com o valor do VR, na tabela abaixo podemos ver
alguns exemplos de VRs.

VR Definição Tipo de Caracteres Tamanho

AE Application Caracteres que definem a entidade Alfanumérico 16 bytes máximo

Entity de aplicação

DT Data e hora “0”-“9”,”.” 26 bytes máximo

OW Texto cuja a codificação é N/A Depende da Sintaxe de

especificada na sintaxe de transferência
transferência

UID Identificador único “0” – “9” 64 Bytes máximo

IDENTIFICADORES ÚNICOS ( UID )

UID ( unique Identifiers ) é um número de identificação único utilizado nas

mensagens DICOM, associado a uma organização e a uma função específica e é
utilizado para definir a comunicação numericamente. Este número é composto por
duas partes UID = <prefixo (org root) >. <sufixo>
O prefixo identifica uma organização ( ex: fabricante, organização de pesquisa,
NEMA ). A parte <sufixo> do UID representa a aplicação ( ex: transferência de
imagens de tomografia na função de Usuário ) e deve ser único dentro do prefixo
<org root>. Isto implica que a organização identificada como raiz (org root) é
responsável pela garantia da unicidade do sufixo.
O sufixo (org root) “1.2.840.10008” é reservado para itens do padrão DICOM, e não
deve ser utilizado para definir itens privados. A organização responsável pela
definição e registro deste UIDs é a NEMA.
Outros prefixos privados podem ser utilizados com o DICOM, porém estes UIDs não
serão registrados pela NEMA. As organizações que definem seus UIDs privados são
responsáveis por registrar seus UIDs e garantir sua unicidade. UIDs privados só
devem ser utilizados quando não houver UIDs DICOM referentes aquela função
desejada. UID deve ter um Limite máximo de 64 Caracteres incluindo os
separadores .
Existem diversos tipos de UIDs mas os principais são aqueles que definem a classe
SOP ( service-object pair ) que será vista mais a frente e aqueles que definem a
sintaxe de transferência.

SINTAXE DE TRANSFERÊNCIA

A sintaxe de transferência que é estabelecida na etiqueta chamada transfer index

(0002,0010) define um conjunto de regras que permite às entidades negociar as
técnicas de codificação dos dados, este parâmetro tem influencia direta em como os
dados de imagem ( 7FE0,0010) serão codificados, as imagens podem ser enviadas
 6

tanto de forma nativa ( sem compressão ) como comprimidas por algum formato que
não esteja no padrão DICOM .
A sintaxe de transferência é definida pelo UID visto no item anterior, para forma
nativa temos:

Tipo UID

Implicit VR, 1.2.840.10008.1.2

Explicit VR – LE 1.2.840.10008.1.2.1

Explicit VR – Big Endian 1.2.840.10008.1.2.2

Para as formas que utilizam compressão podemos ter:

Tipo UID

RLE 1.2.840.10008.1.2.5

JPEG 1.2.840.10008.1.2.4.50

JPEG-LS 1.2.840.10008.1.2.4.80

JPEG 2000 1.2.840.10008.1.2.4.90

PROTOCOLOS

DIMSE ( DICOM MESSAGE SERVICE ELEMENT )

DICOM estabelece um protocolo para a troca de mensagens chamado DIMSE, este

protocolo vai oferecer as condições de operação dos serviços DICOM chamados
DIMSE-C e DIMSE-N. O funcionamento destes serviços esta descrito na parte 7 do
padrão DICOM.
O DIMSE oferecem dois tipos de serviço de transferência de informação que são
usados pelas entidades DICOM, Notificação e Operação. O DIMSE-C atende a
operações associadas a classes SOP composta e o DIMSE-N atende a operações
associadas a classes SOP normalizada. O conceito de SOP ( Service-Object Pair)
será visto mais a frente neste artigo.

Nome Grupo Tipo

C-STORE DIMSE-C Operação

C-GET DIMSE-C Operação

C-MOVE DIMSE-C Operação

 7

C-FIND DIMSE-C Operação

C-ECHO DIMSE-C Operação

N-EVENT REPORT DIMSE-N Notificação

N-GET DIMSE-N Operação

N-SET DIMSE-N Operação

N-ACTION DIMSE-N Operação

N-CREATE DIMSE-N Operação

N-DELETE DIMSE-N Operação

ACSE ( ASSOCIATION CONTROL SERVICE ELEMENT )

O ACSE é o elemento básico da camada de aplicação. Ele é o responsável pelo

estabelecimento e pela liberação da associação entre duas entidades de aplicação
que queiram ou estejam trocando informações.
O usuário iniciador da associação requisita ao ACSE os serviços oferecidos por uma
entidade de aplicação através de seu nome. Este nome independe de informações
sobre endereçamento e sobre roteamento.
Os serviços ACSE

NOME TIPO

A-ASSOCIATE Confirmado

A-REALEASE Confirmado

A-ABORT Não confirmado

A-P-ABORT Iniciado pelo provedor

P-DATA Não confirmado

DEFINIÇÃO DE OBJETO DE INFORMAÇÃO - IOD

O DICOM trabalha com a definição de objeto de informação IOD ( Information Object
Definition ). Um IOD é um modelo de dado orientado a objeto utilizado para
especificar objetos reais. Com base nos IODs, as entidades de aplicação partilham
uma visão comum das informações que serão trocadas. Os IODs estão
especificados na parte 3 do padrão DICOM.
Um IOD não representa especificamente um objeto real mas sim, uma classe de
objetos reais que partilham a mesmas propriedades ou atributos.
Um IOD utilizado para representar uma única classe de objetos reais é chamado de
IOD normalizado. Um IOD que inclui informações sobre objetos reais relacionados é
chamado de IOD composto.
 8

IOD NORMALIZADO

OS IODs normalizados representam uma única entidade no modelo DICOM, estes

IODs estão descritos no apêndice B da parte 3 do padrão DICOM. Como exemplo
de IOD normalizado temos: Patient ( Paciente ), Study ( estudo ), VOI LUT, Storage
Commitment ( compromisso de armazenamento ), Print Queue ( fila de impressão).
Como exemplo, veremos o IOD Patient com mais detalhes
Patient IOD
A definição de objeto de informação Paciente é uma abstração da informação que
descreve um paciente no qual os exames médicos foram realizados. O IOD
Paciente, ou “Patient”, é útil as definições de classe de serviço que utilizam serviços
que facilitam a troca de informações relacionadas ao paciente entre entidades de
aplicação DICOM.

Módulo Referência Descrição

SOP Common C.12.1 Contem as informação SOP

Patient Relationship C.2.1 Referencia a SOPs relacionados

Patient Identification C.2.2 Identifica o paciente

Patient Demographic C.2.3 Descreve o paciente

Patient Medical C.2.4 Informações médicas sobre o paciente

A tabela acima identifica e define os módulos que compõem o IOD Patient, cada
módulo faz referência a outra tabela que possui os atributos de cada modulo, todos
estes dados podem ser encontrados detalhados no padrão DICOM parte 3 apêndice
B e C.
Destacamos abaixo os atributos mais importantes deste IOD, assim como a etiqueta
relativa aos mesmos e o módulo a que o atributo pertence.

Módulo Nome do Atributo Etiqueta Descrição do Atributo

Patient Identification Patient’s Name (0010,0010) Nome completo do paciente

Patient Identification Patient´s ID (0010,0020) Código do paciente emitido pelo

hospital

Patient Identification Patient’s Birth Name (0010,1005) Nome de nascimento do paciente

Patient Demografic Patient’s Birth Date (0010,0030) Data de Nascimento do paciente

Patient Demografic Patient’s Sex (0010,0040) Sexo do paciente

Patient Medical Medical Alerts (0010,2000) Condições que a equipe médica deve
estar alerta
 9

IOD Composto

Um IOD composto representa partes de várias entidades incluídas no modelo

DICOM do mundo real.
Os IOD estão descritos na parte 3 do padrão DICOM, alguns exemplos são

IOD Descrição

CR Radiografia Digital

CT Tomografia Computadorizada

MR Ressonância Magnética

NM Medicina Nuclear

SC Filmes Escaneados

US Ultrassom

XA Angiografia

XA Angiografia Bi-Plana

XR Fluoroscopia

O IOD composto chamado MR especifica uma imagem que foi criada por um
equipamento de ressonância magnética. O IOD MR deve conter todas as
informações relevantes para este tipo de imagem, a tabela abaixo mostra alguns dos
atributos que fazem parte deste IOD. A lista completa dos atributos para qualquer
IOD composto pode ser encontrada nos apêndices A, B e C da parte 3 do padrão
DICOM.

Entidade Módulo Atributo Etiqueta Descrição

Patient General Patient’s Name (0010,0010) Nome do paciente

Patient
Patient’s ID (0010,0020) Identidade do paciente

Patient’s Birth (0010,0030) Data de nascimento paciente

Study General Study UID (0020,000D) Identificador único do estudo

Study
Study Date (0008,0020) Data do estudo

Study Desc. (0008,1030) Descrição do estudo

Series General Modality (0008,0006) Modalidade (CT, MR, XR)

Series
Protocol name (0018,1030) Nome do protocolo utilizado

Body Part (0018,0015) Descrição da parte do corpo examinada

 10

Image General P. Orientation (0020,0020) Orientação do paciente

Image
Images Acqui. (0010,1002) Numero de imagens na aquisição

MR Image Image Type (0008,0008) Tipo da imagem

Echo Time (0018,0081) Parâmetro de aquisição de imagem

SOP SOP Class UID (0008,0016) Identificador único da classe SOP ( 6.1)
Common

Como podemos ver um IOD composto possui atributos de diversas entidades, ao

contrário do IOD normalizado que possui atributos de apenas uma entidade.

CLASSES SERVIÇOS
O DICOM especifica tipos de comunicação chamadas classes de serviço DICOM. A
funcionalidade do DICOM é expandida quando classes de serviços são adicionadas.
As entidades podem exercer tanto a função de usuário como de provedor de um
determinado serviço, a esta função chamamos respectivamente SCU ( service
Class User ) e SCP ( Service Class Provider ). A interação entre as entidades de
aplicação ocorre em um modelo cliente-servidor, o SCU atua como cliente e o SCP
como servidor. As funções SCU/SCP são determinadas durante o estabelecimento
da associação.
Como o protocolo DICOM cobre quase todos os aspectos da transmissão de
informação relevantes para as aplicações de radiologia, nenhum fabricante
implementa todas as classes de serviço que o protocolo oferece. Cada fabricante
escolhe implementar uma parte dos serviços DICOM que aumentarão a
funcionalidade de um sistema em particular. Por exemplo um CT ( tomografia
computadorizada ) não necessita ser uma impressora de imagens também, portanto
os CTs somente implementam aquelas classes de serviço que estão alinhadas com
a sua finalidade.
As classes de serviço são:
Verificação
Protocolo de comunicação para assegurar que os dispositivo de rede estão
conectados corretamente antes do inicio da comunicação.
• Gerenciamento de listagens das modalidades ( Modality Worklist
Management )
Gerencia o fluxo de dados da rede interna do hospital ( utilizando um servidor RIS –
Radiology Informaton System) para o equipamento de imagem. O servidor RIS
funciona como um SCU que envia a informação de agendamento para o
equipamento que funciona como SCP.
• PPS - Performed Procedure Step
Uma vez que o exame já foi realizado o equipamento comunica com o servidor RIS
através do serviço DICOM PPS, para avisar que o exame foi concluído. Desta vez o
 11

equipamento médico funciona como cliente (SCU) e o servidor RIS como provedor (
SCP)
• Store
Serviço utilizado para armazenamento de imagem, o equipamento como cliente
(SCP) utiliza este serviço para enviar uma imagem para uma estação de trabalho ou
para uma arquivo de imagem (SCP)
• Storage Commit
É importante que o equipamento gerador da imagem saiba que as imagem foram
guardadas com sucesso no arquivo de imagem, para que as mesmas possam ser
apagadas do equipamento de origem liberando espaço em disco. Através do serviço
Store Commit o arquivo de imagem informa ao equipamento médico que agora é
responsável pela as imagens transmitidas
• Print
Serviço que possibilita as funcionalidades necessárias para a transferências de
imagem de um equipamento ou estação de trabalho para uma impressora de papel
ou de filme fotográfico.
• Query/Retrieve
Serviço que permite ao usuário (SCU) visualizar a lista de exames do provedor
(SCP) e transferir as imagens desejadas. Ao utilizar este serviço, um usuário em
uma estação de trabalho pode visualizar a lista de exame de um equipamento
médico remoto, escolher os exames desejados e visualiza-los em sua estação.

CLASSE DE PARES DE SERVIÇO-OBJETO ( SOP )

Uma classe SOP ( Service-Object Pair ) é definida pela união de um IOD com um
grupo de serviço. A definição de determinada classe SOP contem as regras e a
semântica que podem restringir o uso de serviços no grupo de serviço e/ou nos
atributos do IOD.
A seleção da classe SOP é utilizada pela entidade de aplicação para estabelecer um
conjunto de capacidades que atendam a sua interação.
Um exemplo de classe SOP seria a classe chamada “CT image store”, proveniente
da união do serviço de armazenamento ( store ) com o IOD CT Image, nesta classe
estariam as regras e serviços utilizados para o armazenamento de imagens geradas
por um tomógrafo. As classes SOP são determinadas de acordo com o identificador
único UID, visto anteriormente
Exemplos UID Classe SOP

Tipo UID

MR Store 1.2.840.10008.5.1.4.1.1.4

CT Store 1.2.840.10008.5.1.4.1.1.2

GE Private DICOM 3D Object 1.2.840.113619.4.26

 12

CONSIDERAÇÕES FINAIS
Desde a descoberta do raio-x em 1895 até bem pouco tempo atrás, a única forma de
visualizar uma imagem médica era através de um filme radiográfico colocado em um
negatoscópio. Com o aparecimento dos equipamentos digitais, essas imagens
passaram ser transmitidas e armezadas digitalmente. A questão central passou a
ser o compartilhamento da informação.
O compartilhamento das informações, através das tecnologias de redes, permite que
médicos possam obter segundas opiniões de especialistas em qualquer parte do
mundo, possibilita que mais de um médico possa acessar exames
simultaneamente. O armazenamento digital permite manter o histórico de um
paciente de modo que qualquer médico possa acessa-lo quando for necessário.
Novas possibilidades, ainda pouco exploradas, como a teleradiologia, permitem que
médicos possam ver seus exames e fazer seus laudos mesmo que seus pacientes
estejam a milhares de quilômetros de distância. Os novos monitores de alta
definição possibilitam que os médicos vizualizem seus exames sem a necessidade
de impressão em pelicula, reduzindo os custos e aumentando a eficiencia e rapidez
dos sistemas de saúde.
Tudo isso torna-se possível através das operações com imagens médicas digitais,
tais como armazenamento, transferência e impressão. Como vimos neste artigo,
essas operações seriam muita mais trabalhosas, e muitas vezes inviáveis se
utilizassemos protocolos de comunicação genéricos ao invés dos procolos descritos
no padrão DICOM, estes oferecem funcionalidades que resultam em uma total
integração dos diversos dispositivos em uma rede de imagens médicas. Através do
padrão DICOM, que hoje é aceito por toda indústria médica, a informação pode ser
compartilha facilmente independente do tipo de equipamento que a gerou, do
fabricante ou da sua localização.

REFERÊNCIAS

National Electronics Manufacturer’s Association - NEMA, ”The DICOM standards”,

disponível em http://medical.nema.org/. Acesso em Novembro de 2004

Bidgood, W. Dean Jr., Horii, Steven C., Prior, Fred W., and Syckle, Donald E. Van,
“Understanding and Using DICOM, the Data Interchange Standard for Biomedical Imaging”,
Journal of the American Medical Informatics Association Volume 4 Number 3 May / Jun
1997

ACR American College of Radiology, “Technical Standard for Teleradiology” , disponível

em http://www.acr.org. Acesso em Novembro de 2004

Clunie, David A. “Lossless Compression of Grayscale Medical Images - Effectiveness of

Traditional and State of the Art Approaches”, 2000 disponível em http://www.dclunie.com/ .
Acesso em Novembro de 2004

Clunie, David A., “DICOM Compression 2002”, 2002

 13

Rorden, Chris, “An introduction to the DICOM single-file format”, disponível em

http://www.psychology.nottingham.ac.uk/staff/cr1/dicom.html#intro. Acesso em Novembro
de 2004

Barré, Sébastien, “Medical Image Samples”, disponível em

http://www.barre.nom.fr/medical/samples/#transfer-syntax. Acesso Novembro de 2004