1

Dicom e XML
Roberto de Oliveira Cunha

Departamento de Engenharia de Telecomunicaes Universidade Federal Fluminense
(UFF)
roliveiracunha@yahoo.com.br

Resumo. Este artigo aborda algumas das metodologias de converso de imagens
mdicas no padro DICOM para o padro XML, e um estudo prvio sobre cada
padro, mostrando o que cada um deles , e suas aplicaes.
1. Introduo
A introduo de imagens digitais mdicas 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 mtodo padro para transmisso de imagens mdicas e as informaes
a elas associadas.
A maioria dos dispositivos armazenava imagens em formatos proprietrios, e transferiam os
arquivos pela rede, ou atravs de discos removveis para efetuarem a comunicao das
imagens [2]. Enquanto as verses iniciais do ACR-NEMA criavam terminologias
padronizadas, estrutura de informao, muitos dos mtodos padro de comunicao de
imagens digitais ainda no haviam sido desenvolvidos at o lanamento da verso 3.0. Esta
verso sofreu uma mudana em seu nome, passando a se chamar Digital Imaging and
Communications in Medicine (DICOM).
DICOM foi estruturado como um documento de mltiplas partes para facilitar a extenso
do padro. Tambm foram definidos objetos no s para imagens, mas tambm para
pacientes, relatrios, e outros grupos de dados [2]. Com os aprimoramentos feitos no
DICOM v.3, tambm se tornou possvel o desenvolvimento e expanso do arquivamento de
imagens e sistemas de comunicao (PACS Picture Archiving and communication
systems), permitindo que sistemas de informaes mdicas tenham interfaces prprias para
a exibio do padro.
O DICOM Standards Commitee [2] existe para criar e manter padres internacionais para a
comunicao de diagnsticos biomdicos e informaes teraputicas em disciplinas que
utilizem imagens com dados associados.
DICOM pode ser aplicado a todas as reas mdicas que utilizam imagens digitais, como a
cardiologia, endoscopia, mamografia, oftalmologia, radiologia, cirurgia, etc., tambm se
estendendo a medicina veterinria. DICOM possibilita integrao da informao produzida
pelas vrias especialidades com sistemas de registro mdico eletrnico (EHR).



2
Este trabalho tem como objetivo apresentar uma descrio do padro DICOM e formas de
converso para o formato XML j desenvolvidas at o momento.
O restante do texto est organizado da seguinte forma. A seo 2 apresenta uma breve
descrio da tecnologia e das partes que compem o padro. A seo 3 mostra o modelo
entidade-relacionamento das informaes. A seo 4 apresenta os requisitos a serem
seguidos para realizar a converso, e um exemplo de um arquivo DICOM convertido para
XML, e a seo 5 exibe a concluso do estudo.
2. O Padro DICOM
O padro DICOM referencia os mltiplos nveis do modelo OSI [2] e prov suporte para a
troca de informaes em um meio de troca de dados. DICOM define uma camada de
aplicao chamada ULP upper layer protocol usada sobre o TCP/IP (independente da
rede fsica), mensagens, servios, objetos de informaes, e mecanismos de negociao e
associao. Estas definies garantem que duas implementaes quaisquer que possuam um
conjunto compatvel de servios possam efetivamente se comunicar.

A independncia da tecnologia de rede permite que o DICOM seja desdobrado em vrias
reas de aplicao, incluindo a comunicao em um local simples (como uma rede
ethernet), ou em uma VPN, ou em uma rede metropolitana que use tecnologia ATM,
conexes dial-up, ou outras conexes de acesso remoto, como via modem, ISDN ou DSL.

Na camada de aplicao, os servios e objetos de informao apontam para cinco reas
primrias de funcionalidade [2]:
Transmisso e persistncia dos objetos (como imagens, formatos de ondas e
documentos);
Busca e recuperao de tais objetos;
Performance de aes especficas (ex: impresso de imagens);
Gerenciamento de atividades (ex: listas de atividades e informao do estado);
Qualidade e consistncia da imagem (tanto para exibio quanto para impresso).
DICOM no define a arquitetura de um sistema inteiro, nem especifica requerimentos de
funcionalidade em torno do comportamento definido para servios especficos [2]. Por
exemplo, armazenamento de imagens definido em termos de quais informaes devem ser
transmitidas e capturadas, no como imagens so exibidas. Um outro servio DICOM est
disponvel para especificar como a imagem deve ser apresentada com anotaes ao usurio.
DICOM pode ser considerado como um padro para comunicao atravs das fronteiras
entre aplicaes, dispositivos e sistemas heterogneos ou desiguais.
DICOM v.3 constitudo de 16 partes [1] listadas abaixo. Cada parte do padro se
concentra em diferentes pontos de vista do protocolo DICOM.
Part 1: Introduction and Overview



3
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 padro so relacionadas, mas so documentos independentes. Uma breve
descrio [1, 3] de cada parte ser mostrada a seguir.
PARTE 1 INTRODUO E VISO GERAL:
Prov uma viso geral do padro DICOM. Descreve a histria, escopo, objetivos, e a
estrutura do padro. Em particular, contm uma breve descrio do contedo de cada parte.
PARTE 2 CONFORMANCE
Define regras de implementao que estejam em concordncia com os requisitos
estabelecidos.
PARTE 3 DEFINIES DE OBJ ETOS DE INFORMAO:
Especifica classes de objetos de informao que provem uma definio abstrata de
entidades do mundo real aplicveis a comunicao de imagens mdicas digitais e as
informaes relacionadas (p ex: formato de onda, relatrios, doses quimioterpicas, etc.).
Cada uma dessas classes contm uma descrio de seu propsito e os atributos que o
definem.
Dois tipos de classes so definidos: normalizadas e compostas.
Classes de Objetos de Informao 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



4
paciente, no entanto, no um atributo vlido por ser um atributo do paciente no
qual o estudo foi realizado, e no ao estudo propriamente dito.
Classes de Objetos de Informao Compostos podem adicionalmente incluir
atributos que esto a eles relacionados, mas no inerentes a entidades no mundo
real. Por exemplo: Classe de Objeto de Informao de Tomografia
Computadorizada, que definida como composta, contm tanto atributos essenciais
imagem (como data da imagem), e atributos relacionados, mas no inerentes
imagem (como o nome do paciente).
PARTE 4 ESPECIFICAES DE CLASSES DE SERVIOS:
Uma Classe de Servio associa um ou mais Objetos de Informao a um ou mais
Comandos efetuados sobre estes objetos.


Exemplos de Classes de Servios incluem os seguintes itens:
Armazenamento;
Consulta e recuperao;
Gerenciamento de tarefas;
Gerenciamento de servios de impresso.
PARTE 5 ESTRUTURA DE DADOS E SEMNTICA:
Especifica como aplicaes DICOM constroem e codificam os conjuntos de dados (Data
Sets) resultantes do uso de Objetos de Informao e Classes de Servios definidos nas
partes 3 e 4 do padro DICOM. O suporte a tcnicas de compresso de imagem (como
J PEG com baixa e alta compresso) especificado nesta parte.
Define tambm regras de codificao a construo de fluxo de dados (Data Stream) a serem
transmitidos em uma mensagem, como especificado na parte 7. Tambm so definidas
regras de codificao para conjuntos de caracteres internacionais usados no DICOM.
PARTE 6 DICIONRIO DE DADOS:
Esta parte do padro um registro centralizado que define a coleo de todos os elementos
de dados disponveis para representar informaes.
Para cada elemento, esta parte do padro especifica:
Tag nica, que consiste em um grupo, e nmero do elemento;
Nome;
Seu representao de valores VR (string, inteiro, etc.);
Multiplicidade (quantos valores por atributo);
Quando h excluso.
Para cada item unicamente identificado, especifica:



5
Seu valor nico, que um valor numrico e com mltiplos componentes separados por
pontos decimais e limitado a 64 caracteres;
Seu nome;
Seu tipo, Classe de Objetos de Informao, definio de codificao para transferncia
de dados, ou certas Instancias de Objetos de Informao (Information Object Instances);
Em que parte do padro DICOM est definido.
PARTE 7 TROCA DE MENSAGENS:
Especifica tanto o servio quanto o protocolo usado por uma aplicao para troca de
mensagens. Uma mensagem composta de um Command Stream seguido por um Data
Stream (P. 5) opcional.
PARTE 8 SUPORTE COMUNICAO EM REDE PARA TROCA DE
MENSAGENS:
Especifica os servios de comunicao e protocolos de camada superior necessrios ao
suporte, em ambientes de rede, comunicao entre aplicaes DICOM. Estes servios de
comunicao e protocolos garantem que esta comunicao acontea de maneira coordenada
e eficiente atravs da rede.
PARTE 10 ARMAZENAMENTO EM MDIA E FORMADO DE ARQUIVO:
Especifica um modelo geral de armazenamento de imagens em mdia removvel. O
propsito desta parte prover um framework que permite o intercmbio de vrios tipos de
imagens mdicas e as informaes associadas em um amplo domnio de mdias de
armazenamento removvel.
A Figura 1 mostra como o modelo de intercmbio de mdia se compara ao modelo de rede.




6























PARTE 11 PERFIS DA APLICAO DE ARMAZENAMENTO EM MDIA:
O intercmbio de imagens mdicas e as informaes associadas requerem implementaes
que estejam em concordncia com o conjunto de padres.
PARTE 12 FORMATO DE MDIA E MDIA FSICA PARA INTERCMBIO:
Especifica o intercmbio de informaes entre aplicaes de sistemas mdicos
determinando tanto a estrutura de descrio de relacionamento entre o modelo de
armazenamento em mdia quanto uma mdia fsica especfica e formato de mdia, e tambm
a caracterstica da mdia.
PARTE 14 FUNO DE EXIBIO DE ESCALA DE CINZA:
Padroniza as funes de exibio escala de cinza para imagens apresentadas em diferentes
mdias, como, por exemplo, monitores e impressoras.
Figura 1 Modelo de comunicao DICOM [1].



7
PARTE 15 PERFIS DE SEGURANA E SISTEMA DE GERENCIAMENTO
As implementaes devem estar em conformidade com os perfis de segurana e sistema de
gerenciamento. Estes perfis so definidos usando-se protocolos externos (DHCP, etc.), e
so especificados neste padro DICOM. Estes protocolos tambm devem incluir
criptografia de dados, chave pblica, e smart cards.
PARTE 16 RECURSO DE MAPEAMENTO DE CONTEDO:
Define templates de estruturao de documentos, conjunto de termos codificados,
dicionrio de termos e tradues.
PARTE 17 INFORMAO REDUNDANTE:
Define anexos normativos e informativos incluindo informaes explicativas.
PARTE 18 ACESSO WEB A OBJ ETOS PERSISTENTES DICOM (WADO):
Acesso a objetos persistentes DICOM pode ser realizado atravs de requisies http. A
requisio inclui um ponteiro para o objeto no formato de UID de sua instncia. Este padro
ilustra como esta requisio deve ser iniciada.
A Figura 2 ilustra a arquitetura das partes do padro DICOM


Figura 2 Arquitetura das partes do padro DICOM [5]



8
3. Modelagem da Informao DICOM
O Diagrama entidade-relacionamento ilustrado na Figura 3 exibe alguns objetos de
informao (Information Objects), como Patient, Image, Report, representados pelos
retngulos.




Este modelo mostra como as entidades esto conectadas umas s outras. Os objetos
possuem atributos, que so os elementos de dados do padro DICOM.
Figura 3 Modelo Entidade Relacionamento do DICOM [3]



9
4. Converso de DICOM para XML
Um dos primeiros passos ao se construir um software definir os dados essenciais e criar
uma representao para estes dados [4]. A maneira usual , ou estipular a representao dos
dados por si s, ou utilizar um padro. No mundo da informtica mdica, padres j
existem, e no campo de aplicaes com imagens mdicas, verificamos que o DICOM
domina o setor. Por um lado, isto um bom sinal, pois indica que aplicaes que tratam de
imagens mdicas j adquiriram alguma maturidade. Com este padro, adquirimos a noo
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 padro DICOM incompleto no sentido de que h
ainda uma carncia numa representao de dados conveniente, que seja fcil o suficiente
para que programadores usem-na para transferirem dados dentro e entre seus programas.
Um arquivo binrio DICOM requer que cada programa, ou seus componentes tenham
conhecimento das nuances de como se codifica e decodifica o arquivo. Prope-se aqui uma
maneira alternativa baseada no padro XML para representar os dados DICOM, e realizar o
intercmbio das informaes.
O objetivo que imagens mdicas possam ser transferidas entre programas, abstraindo-se o
quo complexo seja o formato DICOM. Dados podem ser acessados com XML-parsers
comuns. Isto pode tornar menos longas as implementaes de aplicaes mdicas.
Como mostrado anteriormente, o padro 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 mdicas e
outros sistemas em ambientes mdicos [4]. Na prtica, a espinha dorsal deste padro a
definio de vrias classes de servio, onde a comunicao est situada entre os usurios de
classes de servio (SCU Service Class Users) e provedores de classes de servio (SCP
Service Class Providers). Como exemplo, impresso uma classe de servio, enquanto uma
impressora DICOM uma SCP. Qualquer estao de trabalho, equipada com um software
capaz de conectar a impressora e enviar apropriadamente as mensagens DICOM e iniciar a
impresso, pode ser considerado como um DICOM print SCU.
A parte 6 do padro lista todas as tags existentes em um dado. Todas as tags so
identificadas por um par de nmeros de 16 bits. Os nmeros so 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 representao de valores (VR) e sua extenso. Por exemplo,
tags contendo Person Name (PN) como um VR, tem comprimento mximo de 64
caracteres. Outras tags possuem Sequence como VR. Tais tags no tm um valor direto,
mas seqncia de itens como um valor. Isto resulta do fato de que um dado DICOM possui
uma estrutura semelhante rvore [4].
A parte 3 do padro lista quais tags de dados devem estar presentes em cada objeto de
informao. Como exemplo, uma imagem digital de raio-x intra-oral um objeto de



10
informao, e possui o nome do paciente (0010, 0010) e pixel data (7FE0, 0010) como tags
de dados obrigatrias.
H alguns critrios [4] que devemos satisfazer ao representarmos os arquivos em XML, que
sero listados a seguir:
1. A representao deve ter estrutura lgica como a definida no padro DICOM;
2. Deve ser capaz de representar tudo o que o padro DICOM permitir;
3. A representao dos dados deve ser extensvel para suportar novos campos de dados e
novos objetos de informao que podero ser introduzidos;
4. Assegurar compatibilidade com verses anteriores;
5. Independncia de plataforma, se possvel;
6. Baseado em padres conhecidos e populares;
7. Prover uma ferramenta de suporte adequada;
8. Representao dos dados o mais simples possvel;
9. Leitura compreensvel ao homem para facilitar a depurao e a autenticao, caso
solicitada;
10. Todos os documentos criados pelo uso desta representao devem ser plausveis de
interpretao por inteiro, sem nenhuma informao adicional includa pelo criador do
documento.
Se a DTD for cuidadosamente elaborada, antigos programas podero interpretar as verses
recentes, e vice-versa. Os ns que no podem ser entendidos sero ignorados. Se todos os
programas que usam XML forem projetados de tal forma a preservarem todos os dados
XML, mesmo os comandos que no forem compreendidos, podemos garantir que verses
mais antigas do programa sejam capazes de editar verses mais recentes de documentos
XML, sem o risco de perder nenhum dos novos dados.

Os tipos de dados do DICOM, chamados de VRs (value representations) so muito ricos
em restries (constraints). Como exemplo, DICOM define 20 tipos de strings, em termos
de comprimento. Contrastando com isso, a DTD no pode limitar o tamanho da string.
DICOM suporta vrios tipos de dados, como strings, inteiros, ponto flutuante, etc.,
enquanto que a DTD suporta apenas strings [4]. Alguns atributos definidos pelo DICOM
no podem ser expressos com DTD. Alm disso, a DTD no pode forar um elemento ou
atributo a sempre ter um valor no 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 no so o nico problema. Restries lgicas de alto nvel introduzidas no
padro DICOM, como as tags, devem estar presentes em cada objeto de informao, pode
ser representada pela DTD, mas isto fora-la-ia a repetir amplas partes do padro. Uma das
solues abandonar parte dessas restries para encontrar o formato mais simples de
documento XML, que nos permita expressar qualquer tipo de dado DICOM.



11
Consideraremos que as restries sero representadas no documento dicom-xml com um
alto grau de exatido, deixando esta tarefa para a aplicao que manuseia o xml. Alm do
mais, verificar a coerncia dos dados de entrada do usurio (como comprimento do nome)
tarefa da aplicao, e desconsiderando se o esquema XML/DTD permite ou no esta
entrada.
Uma proposta para uma DTD de funcionalidade geral para um documento DICOM-XML
ser apresentada agora.

Examinando-se esta DTD, pode-se observar que nosso XML tem estrutura lgica em rvore
que igual definio do conjunto de dados do DICOM. A Figura 5 contm um exemplo,
onde a informao de uma imagem digital de um raio-x intra-oral apresentado no formato
XML. Para manter nosso formato XML simples, inserimos alguns elementos implcitos e
restries para fazer a leitura e escrita do documento DICOM-XML, que so mostrados na
Tabela 1.



<!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]



12























Tabela 3 Documento DICOM-XML que representa informaes de uma imagem digital
de um raio-X intra-oral
<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>
<dicom_tag group="0x0028" element="0x0010" name="Rows" vr="US">256</dicom_tag>
<dicom_tag group="0x0028" element="0x0011" name="Columns" vr="US">256</dicom_tag>
<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>
4Quando aplicvel, o formato big-endian assumido.
"VR big-endian Explcito" assumido como sintaxe de tansferncia DICOM. Determina p ex. Qual
imagem deve ser interpretada.
Campos multivalorados usam "\" como separado de valor. Todos os campos de valor so codificados
de acordo com a tabela 6.2-1 / Parte 5 do padro DICOM, com as seguintes excees:
1. Campos de tag de atributo, cujo VR AT so codificados como se segue: "gggg,eeee" onde gggg
e eeee so o grupo e nmero 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) so armazenados
como IS (integer string)
Tabela 2 Consideraes usadas na leitura de tipos do dicom [4]
Figura 5 - Imagem digital de um raio-x intra-oral no formato XML [4]



13
5. Concluso
Neste trabalho foram apresentados alguns critrios sobre a converso do formato de um
arquivo binrio DICOM para XML usando DTDs. Ainda no h uma implementao
de um software que obedea a todos os critrios a serem seguidos para que se tenha uma
converso com total compatibilidade com o padro DICOM sem gerar um arquivo final
com muita repetio de informao, mas j existem alguns modelos que podem ser
seguidos para futuras implementaes, facilitando tanto o desenvolvimento de
aplicativos de converso, quanto o entendimento deste complexo padro.
6. Referncias
[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/J aatinenJ umppanenToivanen.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