Dicom e XML. Roberto de Oliveira Cunha

Transcrição

1 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

2 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

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

4 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

5 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

6 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

7 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

8 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

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

10 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

11 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

12 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 / 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"> </dicom_tag> <dicom_tag group="0x0008" element="0x0018" name="sopinstanceuid" vr="ui"> </dicom_tag> <dicom_tag group="0x0008" element="0x0020" name="studydate" vr="da"> </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"> aabbccddeeff</dicom_tag> <dicom_tag group="0x0010" element="0x0010" name="patientsname" vr="pn">octavius^otto</dicom_tag> Tabela 3 Documento DICOM-XML que representa informações de uma imagem digital de um raio-x intra-oral <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> Figura 5 - Imagem digital de um raio-x intra-oral no formato XML [4] 12

13 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) [2] DICOM parts - National Electrical Manufacturers Association (NEMA) [3] [4] Medical Imaging Data Representation with DICOM-XML - [5] Brent K Stewart. Imaging informatics. mywebs/rad_res_noon_lecture_imaging_informatics pdf 13