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).

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

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 OBJETOS 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 3

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 JPEG 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: 4

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.

Figura 1 Modelo de comunicao DICOM [1].

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. 6

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

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.

Figura 3 Modelo Entidade Relacionamento do DICOM [3]

Este modelo mostra como as entidades esto conectadas umas s outras. Os objetos possuem atributos, que so os elementos de dados do padro DICOM.

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 groupmember 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

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.

10

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

11

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]

<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" element="0x0010" name="Rows" informaes de uma imagem digital <dicom_tag Documento DICOM-XML que representa vr="US">256</dicom_tag> <dicom_tag group="0x0028" element="0x0011" name="Columns" vr="US">256</dicom_tag> de um raio-X intra-oral <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. 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/JaatinenJumppanenToivanen.pdf [4] Medical Imaging Data Representation www.tbs.ts.it/europacs2004/papers/99.pdf [5] with DICOM-XML -

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

mywebs/Rad_Res_Noon_Lecture_Imaging_Informatics-030807.pdf

13