Dicom e XML

Roberto de Oliveira Cunha

Departamento de Engenharia de Telecomunicações – Universidade Federal Fluminense

(UFF)
roliveiracunha@yahoo.com.br

Resumo. Este artigo aborda algumas das metodologias de conversão de imagens

médicas no padrão DICOM para o padrão XML, e um estudo prévio sobre cada
padrão, mostrando o que cada um deles é, e suas aplicações.

1. Introdução
A introdução de imagens digitais médicas em 1970 e o uso de computadores no
processamento destas imagens impulsionaram a American College of Radiology (ACR) e o
National Electrical Manufacturers Association (NEMA) [1] a formarem um comitê com o
objetivo de criar um método padrão para transmissão de imagens médicas e as informações
a elas associadas.
A maioria dos dispositivos armazenava imagens em formatos proprietários, e transferiam os
arquivos pela rede, ou através de discos removíveis para efetuarem a comunicação das
imagens [2]. Enquanto as versões iniciais do ACR-NEMA criavam terminologias
padronizadas, estrutura de informação, muitos dos métodos padrão de comunicação de
imagens digitais ainda não haviam sido desenvolvidos até o lançamento da versão 3.0. Esta
versão sofreu uma mudança em seu nome, passando a se chamar Digital Imaging and
Communications in Medicine (DICOM).
DICOM foi estruturado como um documento de múltiplas partes para facilitar a extensão
do padrão. Também foram definidos objetos não só para imagens, mas também para
pacientes, relatórios, e outros grupos de dados [2]. Com os aprimoramentos feitos no
DICOM v.3, também se tornou possível o desenvolvimento e expansão do arquivamento de
imagens e sistemas de comunicação (PACS – Picture Archiving and communication
systems), permitindo que sistemas de informações médicas tenham interfaces próprias para
a exibição do padrão.
O DICOM Standards Commitee [2] existe para criar e manter padrões internacionais para a
comunicação de diagnósticos biomédicos e informações terapêuticas em disciplinas que
utilizem imagens com dados associados.
DICOM pode ser aplicado a todas as áreas médicas que utilizam imagens digitais, como a
cardiologia, endoscopia, mamografia, oftalmologia, radiologia, cirurgia, etc., também se
estendendo a medicina veterinária. DICOM possibilita integração da informação produzida
pelas várias especialidades com sistemas de registro médico eletrônico (EHR).

1
Este trabalho tem como objetivo apresentar uma descrição do padrão DICOM e formas de
conversão para o formato XML já desenvolvidas até o momento.
O restante do texto está organizado da seguinte forma. A seção 2 apresenta uma breve
descrição da tecnologia e das partes que compõem o padrão. A seção 3 mostra o modelo
entidade-relacionamento das informações. A seção 4 apresenta os requisitos a serem
seguidos para realizar a conversão, e um exemplo de um arquivo DICOM convertido para
XML, e a seção 5 exibe a conclusão do estudo.

2. O Padrão DICOM
O padrão DICOM referencia os múltiplos níveis do modelo OSI [2] e provê suporte para a
troca de informações em um meio de troca de dados. DICOM define uma camada de
aplicação chamada ULP – upper layer protocol – usada sobre o TCP/IP (independente da
rede física), mensagens, serviços, objetos de informações, e mecanismos de negociação e
associação. Estas definições garantem que duas implementações quaisquer que possuam um
conjunto compatível de serviços possam efetivamente se comunicar.

A independência da tecnologia de rede permite que o DICOM seja desdobrado em várias

áreas de aplicação, incluindo a comunicação em um local simples (como uma rede
ethernet), ou em uma VPN, ou em uma rede metropolitana que use tecnologia ATM,
conexões dial-up, ou outras conexões de acesso remoto, como via modem, ISDN ou DSL.

Na camada de aplicação, os serviços e objetos de informação apontam para cinco áreas

primárias de funcionalidade [2]:
• Transmissão e persistência dos objetos (como imagens, formatos de ondas e
documentos);
• Busca e recuperação de tais objetos;
• Performance de ações específicas (ex: impressão de imagens);
• Gerenciamento de atividades (ex: listas de atividades e informação do estado);
• Qualidade e consistência da imagem (tanto para exibição quanto para impressão).
DICOM não define a arquitetura de um sistema inteiro, nem especifica requerimentos de
funcionalidade em torno do comportamento definido para serviços específicos [2]. Por
exemplo, armazenamento de imagens é definido em termos de quais informações devem ser
transmitidas e capturadas, não como imagens são exibidas. Um outro serviço DICOM está
disponível para especificar como a imagem deve ser apresentada com anotações ao usuário.
DICOM pode ser considerado como um padrão para comunicação através das fronteiras
entre aplicações, dispositivos e sistemas heterogêneos ou desiguais.
DICOM v.3 é constituído de 16 partes [1] listadas abaixo. Cada parte do padrão se
concentra em diferentes pontos de vista do protocolo DICOM.
Part 1: Introduction and Overview

2
Part 2: Conformance
Part 3: Information Object Definitions
Part 4: Service Class Specifications
Part 5: Data Structure and Encoding
Part 6: Data Dictionary
Part 7: Message Exchange
Part 8: Network Communication Support for Message Exchange
Part 9: Retired
Part 10: Media Storage and File Format for Media Interchange
Part 11: Media Storage Application Profiles
Part 12: Media Formats and Physical Media for Media Interchange
Part 13: Retired
Part 14: Grayscale Standard Display Function
Part 15: Security and System Management Profiles
Part 16: Content Mapping Resource
Part 17: Explanatory Information
Part 18: Web Access to DICOM Persistent Objects (WADO)
Estas partes do padrão são relacionadas, mas são documentos independentes. Uma breve
descrição [1, 3] de cada parte será mostrada a seguir.
PARTE 1 – INTRODUÇÃO E VISÃO GERAL:
Provê uma visão geral do padrão DICOM. Descreve a história, escopo, objetivos, e a
estrutura do padrão. Em particular, contém uma breve descrição do conteúdo de cada parte.
PARTE 2 – CONFORMANCE
Define regras de implementação que estejam em concordância com os requisitos
estabelecidos.
PARTE 3 – DEFINIÇÕES DE OBJETOS DE INFORMAÇÃO:
Especifica classes de objetos de informação que provêem uma definição abstrata de
entidades do mundo real aplicáveis a comunicação de imagens médicas digitais e as
informações relacionadas (p ex: formato de onda, relatórios, doses quimioterápicas, etc.).
Cada uma dessas classes contém uma descrição de seu propósito e os atributos que o
definem.
Dois tipos de classes são definidos: normalizadas e compostas.
• Classes de Objetos de Informação Normalizadas incluem somente os atributos
inerentes a entidades do mundo real representadas. Por exemplo, atributos de data e
hora de um estudo de caso, por serem inerentes a um estudo atual. Nome do

3
 paciente, no entanto, não é um atributo válido por ser um atributo do paciente no
qual o estudo foi realizado, e não ao estudo propriamente dito.
• Classes de Objetos de Informação Compostos podem adicionalmente incluir
atributos que estão a eles relacionados, mas não inerentes a entidades no mundo
real. Por exemplo: Classe de Objeto de Informação de Tomografia
Computadorizada, que é definida como composta, contém tanto atributos essenciais
à imagem (como data da imagem), e atributos relacionados, mas não inerentes à
imagem (como o nome do paciente).
PARTE 4 – ESPECIFICAÇÕES DE CLASSES DE SERVIÇOS:
Uma Classe de Serviço associa um ou mais Objetos de Informação a um ou mais
Comandos efetuados sobre estes objetos.

Exemplos de Classes de Serviços incluem os seguintes itens:

• Armazenamento;
• Consulta e recuperação;
• Gerenciamento de tarefas;
• Gerenciamento de serviços de impressão.
PARTE 5 – ESTRUTURA DE DADOS E SEMÂNTICA:
Especifica como aplicações DICOM constroem e codificam os conjuntos de dados (Data
Sets) resultantes do uso de Objetos de Informação e Classes de Serviços definidos nas
partes 3 e 4 do padrão DICOM. O suporte a técnicas de compressão de imagem (como
JPEG com baixa e alta compressão) é especificado nesta parte.
Define também regras de codificação a construção de fluxo de dados (Data Stream) a serem
transmitidos em uma mensagem, como especificado na parte 7. Também são definidas
regras de codificação para conjuntos de caracteres internacionais usados no DICOM.
PARTE 6 – DICIONÁRIO DE DADOS:
Esta parte do padrão é um registro centralizado que define a coleção de todos os elementos
de dados disponíveis para representar informações.
Para cada elemento, esta parte do padrão especifica:
• Tag única, que consiste em um grupo, e número do elemento;
• Nome;
• Seu representação de valores – VR (string, inteiro, etc.);
• Multiplicidade (quantos valores por atributo);
• Quando há exclusão.
Para cada item unicamente identificado, especifica:

4
• Seu valor único, que é um valor numérico e com múltiplos componentes separados por
pontos decimais e limitado a 64 caracteres;
• Seu nome;
• Seu tipo, Classe de Objetos de Informação, definição de codificação para transferência
de dados, ou certas Instancias de Objetos de Informação (Information Object Instances);
• Em que parte do padrão DICOM está definido.
PARTE 7 – TROCA DE MENSAGENS:
Especifica tanto o serviço quanto o protocolo usado por uma aplicação para troca de
mensagens. Uma mensagem é composta de um Command Stream seguido por um Data
Stream (P. 5) opcional.
PARTE 8 – SUPORTE À COMUNICAÇÃO EM REDE PARA TROCA DE
MENSAGENS:
Especifica os serviços de comunicação e protocolos de camada superior necessários ao
suporte, em ambientes de rede, à comunicação entre aplicações DICOM. Estes serviços de
comunicação e protocolos garantem que esta comunicação aconteça de maneira coordenada
e eficiente através da rede.
PARTE 10 – ARMAZENAMENTO EM MDIA E FORMADO DE ARQUIVO:
Especifica um modelo geral de armazenamento de imagens em mídia removível. O
propósito desta parte é prover um framework que permite o intercâmbio de vários tipos de
imagens médicas e as informações associadas em um amplo domínio de mídias de
armazenamento removível.
A Figura 1 mostra como o modelo de intercâmbio de mídia se compara ao modelo de rede.

5
 Figura 1 – Modelo de comunicação DICOM [1].

PARTE 11 – PERFIS DA APLICAÇÃO DE ARMAZENAMENTO EM MÍDIA:

O intercâmbio de imagens médicas e as informações associadas requerem implementações
que estejam em concordância com o conjunto de padrões.
PARTE 12 – FORMATO DE MÍDIA E MÍDIA FÍSICA PARA INTERCÂMBIO:
Especifica o intercâmbio de informações entre aplicações de sistemas médicos
determinando tanto a estrutura de descrição de relacionamento entre o modelo de
armazenamento em mídia quanto uma mídia física específica e formato de mídia, e também
a característica da mídia.
PARTE 14 – FUNÇÃO DE EXIBIÇÃO DE ESCALA DE CINZA:
Padroniza as funções de exibição escala de cinza para imagens apresentadas em diferentes
mídias, como, por exemplo, monitores e impressoras.

6
PARTE 15 – PERFIS DE SEGURANÇA E SISTEMA DE GERENCIAMENTO
As implementações devem estar em conformidade com os perfis de segurança e sistema de
gerenciamento. Estes perfis são definidos usando-se protocolos externos (DHCP, etc.), e
são especificados neste padrão DICOM. Estes protocolos também devem incluir
criptografia de dados, chave pública, e “smart cards”.
PARTE 16 – RECURSO DE MAPEAMENTO DE CONTEÚDO:
Define templates de estruturação de documentos, conjunto de termos codificados,
dicionário de termos e traduções.
PARTE 17 – INFORMAÇÃO REDUNDANTE:
Define anexos normativos e informativos incluindo informações explicativas.
PARTE 18 – ACESSO WEB A OBJETOS PERSISTENTES DICOM (WADO):
Acesso a objetos persistentes DICOM pode ser realizado através de requisições http. A
requisição inclui um ponteiro para o objeto no formato de UID de sua instância. Este padrão
ilustra como esta requisição deve ser iniciada.
A Figura 2 ilustra a arquitetura das partes do padrão DICOM

Figura 2 – Arquitetura das partes do padrão DICOM [5]

7
3. Modelagem da Informação DICOM
O Diagrama entidade-relacionamento ilustrado na Figura 3 exibe alguns objetos de
informação (“Information Objects”), como Patient, Image, Report, representados pelos
retângulos.

Figura 3 – Modelo Entidade Relacionamento do DICOM [3]

Este modelo mostra como as entidades estão conectadas umas às outras. Os objetos
possuem atributos, que são os elementos de dados do padrão DICOM.

8
4. Conversão de DICOM para XML
Um dos primeiros passos ao se construir um software é definir os dados essenciais e criar
uma representação para estes dados [4]. A maneira usual é, ou estipular a representação dos
dados por si só, ou utilizar um padrão. No mundo da informática médica, padrões já
existem, e no campo de aplicações com imagens médicas, verificamos que o DICOM
domina o setor. Por um lado, isto é um bom sinal, pois indica que aplicações que tratam de
imagens médicas já adquiriram alguma maturidade. Com este padrão, adquirimos a noção
de que tipos de dados e que tipos de objetos do mundo real existem, e como eles trabalham
juntos.
Por outro lado, podemos afirmar que o padrão DICOM é incompleto no sentido de que há
ainda uma carência numa representação de dados conveniente, que seja fácil o suficiente
para que programadores usem-na para transferirem dados dentro e entre seus programas.
Um arquivo binário DICOM requer que cada programa, ou seus componentes tenham
conhecimento das nuances de como se codifica e decodifica o arquivo. Propõe-se aqui uma
maneira alternativa baseada no padrão XML para representar os dados DICOM, e realizar o
intercâmbio das informações.
O objetivo é que imagens médicas possam ser transferidas entre programas, abstraindo-se o
quão complexo seja o formato DICOM. Dados podem ser acessados com XML-parsers
comuns. Isto pode tornar menos longas as implementações de aplicações médicas.
Como mostrado anteriormente, o padrão consiste em dezesseis partes, e o objetivo deste
trabalho é mostrar uma maneira de representar os dados definidos nas partes 3, 5 e 6.
O objetivo do DICOM é atingir compatibilidade entre sistemas de imagens médicas e
outros sistemas em ambientes médicos [4]. Na prática, a espinha dorsal deste padrão é a
definição de várias classes de serviço, onde a comunicação está situada entre os usuários de
classes de serviço (SCU – Service Class Users) e provedores de classes de serviço (SCP –
Service Class Providers). Como exemplo, impressão é uma classe de serviço, enquanto uma
impressora DICOM é uma SCP. Qualquer estação de trabalho, equipada com um software
capaz de conectar a impressora e enviar apropriadamente as mensagens DICOM e iniciar a
impressão, pode ser considerado como um DICOM print SCU.
A parte 6 do padrão lista todas as tags existentes em um dado. Todas as tags são
identificadas por um par de números de 16 bits. Os números são chamados de group-
member e element-member. Como exemplo de tags, temos nome do paciente (0010, 0010),
pixel data (7FE0, 0010), e valor do menor pixel da imagem (0028,0106) [4].
Na parte 5, temos os tipos de representação de valores (VR) e sua extensão. Por exemplo,
tags contendo Person Name (PN) como um VR, tem comprimento máximo de 64
caracteres. Outras tags possuem Sequence como VR. Tais tags não têm um valor direto,
mas seqüência de itens como um valor. Isto resulta do fato de que um dado DICOM possui
uma estrutura semelhante à árvore [4].
A parte 3 do padrão lista quais tags de dados devem estar presentes em cada objeto de
informação. Como exemplo, uma imagem digital de raio-x intra-oral é um objeto de

9
informação, e possui o nome do paciente (0010, 0010) e pixel data (7FE0, 0010) como tags
de dados obrigatórias.
Há alguns critérios [4] que devemos satisfazer ao representarmos os arquivos em XML, que
serão listados a seguir:
1. A representação deve ter estrutura lógica como a definida no padrão DICOM;
2. Deve ser capaz de representar tudo o que o padrão DICOM permitir;
3. A representação dos dados deve ser extensível para suportar novos campos de dados e
novos objetos de informação que poderão ser introduzidos;
4. Assegurar compatibilidade com versões anteriores;
5. Independência de plataforma, se possível;
6. Baseado em padrões conhecidos e populares;
7. Prover uma ferramenta de suporte adequada;
8. Representação dos dados o mais simples possível;
9. Leitura compreensível ao homem para facilitar a depuração e a autenticação, caso
solicitada;
10. Todos os documentos criados pelo uso desta representação devem ser plausíveis de
interpretação por inteiro, sem nenhuma informação adicional incluída pelo criador do
documento.
Se a DTD for cuidadosamente elaborada, antigos programas poderão interpretar as versões
recentes, e vice-versa. Os nós que não podem ser entendidos serão ignorados. Se todos os
programas que usam XML forem projetados de tal forma a preservarem todos os dados
XML, mesmo os comandos que não forem compreendidos, podemos garantir que versões
mais antigas do programa sejam capazes de editar versões mais recentes de documentos
XML, sem o risco de perder nenhum dos novos dados.

Os tipos de dados do DICOM, chamados de VR’s (value representations) são muito ricos
em restrições (constraints). Como exemplo, DICOM define 20 tipos de strings, em termos
de comprimento. Contrastando com isso, a DTD não pode limitar o tamanho da string.
DICOM suporta vários tipos de dados, como strings, inteiros, ponto flutuante, etc.,
enquanto que a DTD suporta apenas strings [4]. Alguns atributos definidos pelo DICOM
não podem ser expressos com DTD. Além disso, a DTD não pode forçar um elemento ou
atributo a sempre ter um valor não vazio. Esquemas XML estendem as capacidades do
DTD, mas todas as constraints dos tipos de dados DICOM continuam sem poder serem
expressos pela DTD.
Tipos de dados não são o único problema. Restrições lógicas de alto nível introduzidas no
padrão DICOM, como as tags, devem estar presentes em cada objeto de informação, pode
ser representada pela DTD, mas isto força-la-ia a repetir amplas partes do padrão. Uma das
soluções é abandonar parte dessas restrições para encontrar o formato mais simples de
documento XML, que nos permita expressar qualquer tipo de dado DICOM.

10
Consideraremos que as restrições serão representadas no documento dicom-xml com um
alto grau de exatidão, deixando esta tarefa para a aplicação que manuseia o xml. Além do
mais, verificar a coerência dos dados de entrada do usuário (como comprimento do nome) é
tarefa da aplicação, e desconsiderando se o esquema XML/DTD permite ou não esta
entrada.
Uma proposta para uma DTD de funcionalidade geral para um documento DICOM-XML
será apresentada agora.

<!DOCTYPE dicom_item [
<!ELEMENT dicom_item (dicom_tag*, dicom_sequence*)>
<!ELEMENT dicom_tag (#PCDATA)>
<!ELEMENT dicom_sequence (dicom_item*)>

<!ATTLIST dicom_tag
group CDATA #REQUIRED
element CDATA #REQUIRED
name CDATA #IMPLIED
vr CDATA #IMPLIED

<!ATTLIST dicom_sequence
group CDATA #REQUIRED
element CDATA #REQUIRED
name CDATA #IMPLIED
vr CDATA #IMPLIED
]>

Figura 4 – DTD de funcionalidade geral para um arquivo DICOM [4]

Examinando-se esta DTD, pode-se observar que nosso XML tem estrutura lógica em árvore
que é igual à definição do conjunto de dados do DICOM. A Figura 5 contém um exemplo,
onde a informação de uma imagem digital de um raio-x intra-oral é apresentado no formato
XML. Para manter nosso formato XML simples, inserimos alguns elementos implícitos e
restrições para fazer a leitura e escrita do documento DICOM-XML, que são mostrados na
Tabela 1.

11
4Quando aplicável, o formato big-endian é assumido.

"VR big-endian Explícito" é assumido como sintaxe de tansferência DICOM. Determina p ex. Qual
imagem deve ser interpretada.
Campos multivalorados usam "\" como separado de valor. Todos os campos de valor são codificados
de acordo com a tabela 6.2-1 / Parte 5 do padrão DICOM, com as seguintes exceções:
1. Campos de tag de atributo, cujo VR é AT são codificados como se segue: "gggg,eeee" onde gggg
e eeee são o grupo e número do elemento da tag de atributo, em hexadecimal.
2. Tipos FL (floating point single) e FD (floating point double) are armazenados como DS (decimal
string)
3. SL (signed long), SS (signed short), US (unsigned short) and UL (unsigned long) são armazenados
como IS (integer string)
Tabela 2 – Considerações usadas na leitura de tipos do dicom [4]

<dicom_item>
<dicom_tag group="0x0008" element="0x0008" name="ImageType" vr="CS">DERIVED\PRIMARY\</dicom_tag>
<dicom_tag group="0x0008" element="0x0016" name="SOPClassUID"
vr="UI">1.2.840.10008.5.1.4.1.1.1.3.1</dicom_tag>
<dicom_tag group="0x0008" element="0x0018" name="SOPInstanceUID" vr="UI">
1.2.840.113999.1002.2251242514.1093085408.2748659660416602047
</dicom_tag>
<dicom_tag group="0x0008" element="0x0020" name="StudyDate" vr="DA">20031222</dicom_tag>
<dicom_tag group="0x0008" element="0x0030" name="StudyTime" vr="TM">104818</dicom_tag>
<dicom_tag group="0x0008" element="0x0060" name="Modality" vr="CS">IO</dicom_tag>
<dicom_tag group="0x0008" element="0x0068" name="PresentationIntentType" vr="CS">FOR
PROCESSING</dicom_tag>
<dicom_tag group="0x0008" element="0x0070" name="Manufacturer" vr="LO">ACME CORP.</dicom_tag>
<dicom_sequence group="0x0008" element="0x2228" name="PrimaryAnatomicStructureSequence" vr="SQ">
<dicom_item>
<dicom_tag group="0x0008" element="0x0100" name="CodeValue" vr="SH">T-54280</dicom_tag>
<dicom_tag group="0x0008" element="0x0102" name="CodingSchemeDesignator" vr="SH">SNM3</dicom_tag>
<dicom_tag group="0x0008" element="0x0104" name="CodeMeaning" vr="LO">Maxillary right central
incisor tooth</dicom_tag>
</dicom_item>
<dicom_item>
<dicom_tag group="0x0008" element="0x0100" name="CodeValue" vr="SH">T-54290</dicom_tag>
<dicom_tag group="0x0008" element="0x0102" name="CodingSchemeDesignator" vr="SH">SNM3</dicom_tag>
<dicom_tag group="0x0008" element="0x0104" name="CodeMeaning" vr="LO">Maxillary left central
incisor tooth</dicom_tag>
</dicom_item>
</dicom_sequence>
<dicom_tag group="0x000D" element="0x0010" name="" vr="LO">ACME_PRIVATE_IDENT_CODE</dicom_tag>
<dicom_tag group="0x000D" element="0x1000" name="AcmeProprietaryInfo"
vr="OB">00112233445566778899AABBCCDDEEFF</dicom_tag>
<dicom_tag group="0x0010" element="0x0010" name="PatientsName" vr="PN">OCTAVIUS^OTTO</dicom_tag>
Tabela 3 –group="0x0028"
<dicom_tag Documento DICOM-XML quename="Rows"
element="0x0010" representa vr="US">256</dicom_tag>
informações de uma imagem digital
de um raio-X intra-oralvr="US">256</dicom_tag>
<dicom_tag group="0x0028" element="0x0011" name="Columns"
<dicom_tag group="0x0028" element="0x0100" name="BitsAllocated" vr="US">16</dicom_tag>
<dicom_tag group="0x0028" element="0x0101" name="BitsStored" vr="US">12</dicom_tag>
<dicom_tag group="0x0028" element="0x1050" name="WindowCenter" vr="DS">1328</dicom_tag>
<dicom_tag group="0x0028" element="0x1051" name="WindowWidth" vr="DS">2656</dicom_tag>
</dicom_item>

Figura 5 - Imagem digital de um raio-x intra-oral no formato XML [4]

12
5. Conclusão
Neste trabalho foram apresentados alguns critérios sobre a conversão do formato de um
arquivo binário DICOM para XML usando DTD’s. Ainda não há uma implementação
de um software que obedeça a todos os critérios a serem seguidos para que se tenha uma
conversão com total compatibilidade com o padrão DICOM sem gerar um arquivo final
com muita repetição de informação, mas já existem alguns modelos que podem ser
seguidos para futuras implementações, facilitando tanto o desenvolvimento de
aplicativos de conversão, quanto o entendimento deste complexo padrão.

6. Referências
[1] DICOM parts - National Electrical Manufacturers Association (NEMA)
http://medical.nema.org/dicom/2006/

[2] DICOM parts - National Electrical Manufacturers Association (NEMA)

http://medical.nema.org/dicom/2006/Strategy.pdf

[3] http://cyclops.telemedicina.ufsc.br/index.php?lang=en&page=pacs
www.abo.fi/~peklund/utbildning/medinfo/papers/JaatinenJumppanenToivanen.pdf

[4] Medical Imaging Data Representation with DICOM-XML -

www.tbs.ts.it/europacs2004/papers/99.pdf

[5] Brent K Stewart. Imaging informatics. http://faculty.washington.edu/bstewart/

mywebs/Rad_Res_Noon_Lecture_Imaging_Informatics-030807.pdf

13