Visualizador de Imagiologia Médica

Transcrição

1 Visualizador de Imagiologia Médica Fábio Tiago Martins Rodrigues Nº19131 Trabalho realizado sob a orientação de Rui Pedro Lopes

2 Engenharia Informática 2011/2012

3 Visand - Visualizador de Imagiologia Médica Relatório da UC de Projecto Licenciatura em Engenharia Informática Escola Superior de Tecnologia e de Gestão Fábio Rodrigues 2011/2012 iii

4 A Escola Superior de Tecnologia e Gestão não se responsabiliza pelas opiniões expressas neste relatório. iv

5 Certifico que li este relatório e que na minha opinião, é adequado no seu conteúdo e forma como demonstrador do trabalho desenvolvido no âmbito da UC de Projecto. Rui Lopes Orientador Certifico que li este relatório e que na minha opinião, é adequado no seu conteúdo e forma como demonstrador do trabalho desenvolvido no âmbito da UC de Projecto. Arguente v

6 Aceite para avaliação da UC de Projecto

7 vii

8 Agradecimentos Agradeço ao Professor Rui Pedro Lopes, meu orientador, por todo o apoio, dedicação paciência e ajuda durante a realização deste projecto. Sem o seu espirito critico e motivação constantes este projecto não teria sido possível. Aos meus pais, que durante todo o meu percurso académico e especialmente nesta fase final da Licenciatura, se mantiveram sempre apoiantes e motivadores para eu superar com sucesso todas as etapas. Agradeço em especial ao meu irmão e ao meu primo pelo interesse, apoio e amizade com que sempre me presentearam. Agradeço também ao Instituto Politécnico de Bragança pelas condições disponibilizadas para a realização deste projecto. A todos o meu obrigado. viii

9 ix

10 Resumo Com o avanço da tecnologia e a globalização do uso de equipamentos médicos na aquisição de imagens digitais, por exemplo tomografia computadorizada (TC), existe a necessidade de uma arquitectura que permite transmitir, visualizar e armazenar toda esta informação. A implantação de toda esta arquitectura está a cargo do Pacs, que inclui os servidores, base de dados, workstations (visualizadores finais das imagens), equipamentos geradores de imagens, todo o conjunto tecnológico associado a um funcionamento de uma unidade hospitalar; com o standard Dicom, como framework de comunicação e transmissão de ficheiros (imagens) gerados por equipamentos médicos. Considerando os dados dos exames como imagens digitais, este projecto terá como objectivo principal o desenvolvimento e implementação de uma aplicação desktop, que permita transmissão e visualização de imagens de Imagiologia Médica, baptizado de Visand. Espera-se que com esta aplicação se adquirira conhecimento de imagiologia médica, bem como conhecimentos da forma como se processa a comunicação entre servidores e aplicações, e no geral, experiência no desenvolvimento de aplicações vocacionadas para desktop. Palavras-chave: Imagiologia Médica, Pacs, Dicom, Dcm4che x

11 xi

12 Abstract With the advancement in technology and the globalization in using medical equipment for the acquisition of digital images, e.g. Computed Tomography (CT), there is a need for an architecture that allows the transmission, display and storage of all this information. The implementation of all of this architecture is made through Pacs, which includes servers, databases, workstations (final image visualizer), equipment images providers, all technological set associated with the operation of a hospital unit; with the standard Dicom, being the framework for communication and files transmission (images) generated by medical equipment. Considering the clinical exam data as digital images, this project will have as main objective the development and implementation of a desktop application, which allows transmission and visualization of Medical Imaging images, named Visand. It is hoped that with this application, one acquires knowledge in medical imaging, as well as knowledge of how the communication between servers and applications is handled, and in general, experience in developing desktop applications. Keywords: Medical Imaging, Pacs, Dicom, Dcm4che xii

13 xiii

14 Conteúdo 1 Introdução Objectivos e Enquadramento Estrutura Imagiologia Médica Futuro da imagiologia médica DICOM Introdução ao Dicom PACS Tipos de Modelos da arquitectura DICOM com PACS Modelo Dicom História do Dicom DICOM Standard Partes DICOM Definição dos Objectos de Informação Serviços Comunicação Comunicação usando serviços Dicom xiv

15 3.10 Imagem WADO Acesso Web de persistência de objectos Dicom Considerações Desenvolvimento Estado da arte Dcm4che toolkit utilizado Arquitectura Serviço WADO Implementação Arquitectura utilizada no desenvolvimento do projecto Visand Instalação do Servidor, simulando Pacs Interface Conclusões Discussão e Limitações Trabalhos Futuros Bibliografia A Formatos do ficheiro Dicom... 1 B Configuração do servidor... 3 B.1 Servidor dcm4chee no Windows... 3 C Configuração do servidor... 7 C.1 Entidade de Aplicação... 7 C.2 Contexto de aplicação

16 D Classes de Serviço SOP... 9 E Lista de Dados F Instruções básicas G Verificar estado da ligação H Simular equipamento de imagiologia médica I Pesquiza e Aquisição J Configuração do servidor K Diagramas Representativos

17 xvii

18 Lista de Tabelas Tabela 1- Partes Dicom Tabela 2 - N-commands Tabela 3 - C-commands Tabela 4- Tabela de comparação entre os toolkits xviii

19 xix

20 Lista de Figuras Figura 1- Etapas de processamento imagem médica... 7 Figura 2-3D CT... 7 Figura 3 - Visible Human... 8 Figura 4 -- Exemplos de visualizações interactivas... 9 Figura 5 - Componentes do Pacs Figura 6 Hierarquia de informação Dicom Figura 7 - Dados reais para IOD Figura 8 - Serviço Dicom Figura 9- IODs Normalizadas ou Compostas Figura 10 - Exemplo de um Módulo de um IOD & Atributos Figura 11 - Correspondia ao Dicionário de Dados Figura 12 - Processo de Transmissão de imagens Figura 13 - Transmissão de imagens de um equipamento de CR para uma Workstation Figura 14 - Envio de Dados (imagens) de um CT para um servidor Dicom Figura 15- Pesquisa de Dados (imagens) num servidor Dicom Figura 16- Arquitectura da aquisição da imagem Figura 17- Abordagem usando Wado xx

21 Figura 18- Diagrama Dcm4che [Danielson, et al.] Figura 20 - Servidor Web Figura 21 - Arquitectura utilizada no desenvolvimento do projecto Figura 23 Interface do Visualizado e sua ordem de utilização Figura 24- Primeira configuração Figura 25- Escolha dos estudos, series e imagens Figura 26 - Janela das listagens das imagens e as imagens visualizadas Figura 34 - exemplo de um file Dicom... 1 Figura 35- Estrutura das pastas Figura 36- Criar BD Figura 37- Criação das tabelas Figura 38- Criação da BD do ARR Figura 39 - Criação das Tabelas Figura 40 - Alterações para ter-se permissão às BD Figura 41- Comando que liga dcm4chee com JBoss Figura 42- Comando que interliga dcm4chee com ARR... 6 Figura 43 Autenticação na Interface Web Figura 44 - Interface Web... 6 Figura 45 Identificar SOP através da correspondência do UID na tabela Media Storage... 9 Figura 46 - Elemento de dados Figura 22- Semelhança entre um C-FIND e um Select

22 Figura 47 - Esquema de Associação Figura 27 - Diagrama da Aplicação desenvolvida Visand Figura 28 - Packages provenientes do Visand Figura 29 - Conteúdo do package gui Figura 30 - Conteúdo do package dao Figura 31 - Conteúdo do package Dicom Figura 32 - Conteúdo do package entities

23 xxiii

24 Lista de Abreviações AE Application Entity API Application Programming Interface CT Computed Tomography BD Base de Dados JPEG Joint Photographic Experts Group IP Internet Protocol ISSO Internacional Organization For Standardization PACS Picture Archiving and Communication System SCP Service Class Provider SCU Service Class User SOP Service Object Pair SQL Structured Query Language TCP/IP Transmission Controcol/Internet Protocol UID Unique Identifier UML Unified Modeling Language IO InformationObject IOD Information Object Defenition DICOM Digital Imaging and Communication in Medicine xxiv

25 xxv

26

27 Capítulo 1 1 Introdução Nos últimos anos, com o aparecimento de novas tecnologias e evolução de equipamentos (desde smartphones, tablets, leitores de e-books, etc) estas começaram a se generalizar e serem adoptadas em serviços disponibilizados a utente, nomeadamente, e também, em serviços hospitalares, a que o trabalho descrito neste documento diz respeito. Assim tem se vindo a notar cada vez mais a necessidade de que o software existente nestes meios seja adaptado para suportar estas arquitecturas, e que novo software seja criado para dar resposta a essas necessidades. Os centros hospitalares não são mais ambientes estáticos, onde o armazenamento de informação referente aos pacientes se encontra em arquivos de papel. Hoje em dia toda a troca de informação, armazenamento, processamento e sua visualização são realizados de forma computorizada através de dispositivos e software específico, sejam eles, máquinas de exames, estações de trabalho (workstations), visualizadores de exames em ambiente desktop ou móvel, etc. Assim surge a necessidade de existir software específico que consiga tratar de toda esta informação, recebendo-a, armazenando-a e transferindo-a para qualquer terminal dentro de um centro hospitalar. Assim surge a necessidade de servidores voltados para a imagiologia médica, que garantam o tratamento e disponibilidade dos ficheiros provenientes das máquinas de exames, contendo informação do paciente, caso clínico e imagens dos procedimentos. Com 1

28 este tipo de servidores, essa informação fica rapidamente disponível de forma digital para o médico, em qualquer lugar e a partir de qualquer dispositivo. 1.1 Objectivos e Enquadramento O objectivo do projecto teve como intenção inicial a investigação e aquisição de conhecimento referente ao conceito de Imagiologia Médica, de modo a que permitisse perceber toda a ciência relaciona com esta, e assim se poder aplicar o standard Dicom no mundo da imagiologia médica. Será então também necessário dominar o Standard Dicom. Com base nestes conceitos será desenvolvido um modelo computacional que suporta todo o sistema de aquisição, armazenamento, e visualização de dados de exames de pacientes (imagens, informação clínica, etc.). Esta arquitectura é conhecida por Pacs. Assim, a arquitectura desenhada terá que se simular um equipamento médico que disponibilize dados médicos (imagens). É necessária a configuração de um servidor que possibilite a recepção de solicitações dos clientes, de informações (como dados médicos), e por último, e mais importante, a criação de um visualizador de imagens médicas, tendo sido este baptizado com o nome de Visand. Como resultado final do trabalho desenvolvido, e como assimilação de todos estes objectivos, espera-se que a ferramenta desenvolvida, Visand, permita conectar-se ao servidor, responda a queries e possua ligação a uma base de dados, para que, recebidos os pedidos de informação, possa disponibilizar esses dados (imagens, documentação, etc.) ao utilizador. O Visand deverá suportar os serviços Dicom mais importantes, como os de armazenamento e comunicação. Assim a abordagem feita para este projecto, vem expor a necessidade de se adquirir domínio das tecnologias envolvidas. O objectivo central deste projecto é assim, conceber e desenvolver uma solução que permita a um utilizador comum, navegar e visualizar a hierarquia de exames criada pelo Dicom, bem como ter acesso a toda a informação respeitante aos pacientes. 2

29 Solução essa que deverá disponibilizar uma interface que permita efectuar a ligação ao servidor, através do seu IP, porta e um endereço específico (que permite a comunicação autenticada com o servidor). Através dessa interface o utilizador poderá escolher e analisar a informação de um caso concreto, sobre o qual pretenda navegar e explorar a hierarquia de exames a ele referente. 1.2 Estrutura A estrutura deste trabalho foi criada de modo que o leitor perceba o que se pretende, o que se tem, e o que se fez para tal. Este primeiro capítulo visa enquadrar o leitor no tema do projecto, dando a conhecer os objectivos e enquadramento propostos. O segundo capítulo contém uma descrição dos conceitos base da Imagiologia Médica, descrevendo a utilização de equipamentos tecnológicos na área médica, explicando a realização de exames para fins de tratamento e ou diagnóstico, e serão também salientados trabalhos futuros na Imagiologia com base em artigos publicados. O terceiro capítulo contém uma descrição mais detalhada dos conceitos alusivos ao standard Dicom; também é exposto o encadeamento com a arquitectura Pacs, sendo descritos o funcionamento e estruturas do sistema de comunicação e armazenamento. São descritas algumas das partes mais relevantes em que é divido o standard Dicom, abordando-se assim o standard Dicom por completo. No quarto capítulo é feito um Estado da Arte sobre o toolkit, que irá servir de suporte ao desenvolvimento do projecto. É efectuada uma introdução à arquitectura e funcionamento do toolkit escolhido, analisando-se os materiais e modos de desenvolvimento aplicados aos serviços Dicom, que serão implementados por este toolkit. É também descrito o modo de aquisição de imagens por Http (Wado). No quinto capítulo, são definidas as ordens de trabalho e a estratégia de desenvolvimento a ser utilizada, apresentando-se a arquitectura idealizada para a o desenvolvimento da aplicação. É também importante mencionar as decisões tomadas na construção do Pacs, explicando os 3

30 modos como se implementará o servidor (dcm4chee, com o servidor de aplicações JBoss num ambiente Debian); bem como em relação aos simuladores de equipamentos de imagiologia, podendo simular envios de exames (aplicação do serviço disponível dcm4che toolkit). É apresentada a interface com explicações da aplicação desenvolvida (usando dcm4che toolkit). São também indicados alguns exemplos de implementação dos principais serviços propostos, a serem utilizados para todo o funcionamento do sistema. Para terminar seguem as conclusões, indicando-se os objectivos alcançados, debatendo-se as limitações existentes e realçando o possível melhoramento a ser desenvolvido no futuro. 4

31 5

32 Capítulo 2 2 Imagiologia Médica Neste capítulo é explicada a imagiologia médica, fazendo-se referência às partes mais importantes relacionadas com o enquadramento feito a este relatório, sendo esta explicação feita a um nível superficial. A imagiologia médica consiste na utilização de equipamentos tecnológicos na área médica, com o objectivo de se realizarem exames com fins de tratamento e ou diagnóstico. A imagiologia médica abarca uma grande variedade de procedimentos de obtenção de dados, sendo estas técnicas de obtenção de imagem feitas de forma invasiva ou não. Entre estas técnicas de obtenção de imagens médicas (também chamadas de modalidades) as mais conhecidas são: Radiografias - (RX), Tomografias, Ressonância Magnética (RM), Tomografia Computorizada (CT), etc. A estas imagens são adicionados dados de informação relativos ao paciente ou a exames, por exemplo é normal todas as imagens terem os dados referentes a nome paciente, idade, sexo ; outros dados podem variar consoante o tipo de modalidade efectuado (tipo de exame, escala de exame). Só depois de concluída a adição de dados à imagem, ver (Figura 1), feita no equipamento da modalidade ou no servidor, é que ela é enviada. É usual, as imagens, serem comprimidas antes de enviadas com o objectivo de melhorar a performance na comunicação. 6

33 Figura 1- Etapas de processamento imagem médica Quando terminadas todas as etapas descritas anteriormente, o destinatário destas imagens alternará dependendo da arquitectura do sistema usado no hospital. Podendo ser este destinatário um arquivo (que pode ser um servidor de dados) temporário ou workstations, onde o médico visualizará aquilo que pode já ser chamado de ficheiro Dicom, que para pode ser definido como o ficheiro que contém os dados e a imagem associada. Com o aparecimento das imagens 3D na imagiologia médica, ver (Figura 2), que surgiu pelas modalidades de Tomografia e de Ressonância Magnética, estas vieram trazer uma nova experiência e novas ferramentas de manipulação de imagens (como cortes na imagem, manipulação de luz, manipulação da perspectiva, calculo de gradientes). Figura 2-3D CT Entre várias ferramentas usadas na imagem 3D, destaca-se uma em particular: a automatização de diagnósticos. A utilização através de técnicas de reconhecimento baseadas em modelos matemáticos e padrões torna possível detectar anomalias. Por exemplo em exames de Raios-X, se existirem factores na imagem de anomalias de perímetro e anomalias em certas zonas da imagem, poderá indicar um possível tumor. 7

34 Estas novas ferramentas ajudam o médico numa melhor análise de exames médicos provenientes das modalidades descritas. Entre várias ferramentas usadas na imagem 3D, destaca-se uma em particular: a automatização de diagnósticos. A utilização através de técnicas de reconhecimento baseadas em modelos matemáticos e padrões torna possível detectar anomalias. Por exemplo em exames de Raios-X, se existirem factores na imagem de anomalias de perímetro e anomalias em certas zonas da imagem, poderá indicar um possível tumor. Estas novas ferramentas ajudam o médico numa melhor análise de exames médicos provenientes das modalidades descritas. Estas aplicações de imagiologia médica, que usam imagens 3D, já requerem um tipo de processamento mais robusto. A localização deste processamento depende da arquitectura do sistema utilizado, sendo sempre preferível o processamento localizar-se do lado do servidor, de modo a não sobrecarregar as workstations e assim permitir também equipamentos menos dispendiosos. No meio da imagiologia médica, um projecto que demonstra perfeitamente o que é possível ser feito com imagens 3D é o Visible Human [Wetzel], que em 1993, foi criado nos Estados Unidos, permitindo percorrer virtualmente o corpo humano ver (). Figura 3 - Visible Human 8

35 2.1 Futuro da imagiologia médica Com a grande inovação tecnológica, e com o desenvolvimento computacional, cada vez mais se inova na imagiologia médica, e a prova disso é o artigo sobre o futuro da imagiologia médica, From individual to population:challenges in Medical Visualization [Botha, et al., 2012]. Como mostra as imagens da Figura 4, o futuro da imagiologia médica promete ser promissor. Este tipo de resultados apresentados no artigo referido, mostram um salto astronómico em relação á imagiologia médica habitual. Figura 4 -- Exemplos de visualizações interactivas É possível aos médicos num dado diagnóstico, ver cada pequeno detalhe do corpo do paciente sem serem necessárias intervenções cirúrgicas. Segundo o artigo a técnica utilizada possibilita a renderização interactiva dos conjuntos de dados de imagiologia médica com a física apoiada na iluminação. 9

36 Capítulo 3 3 DICOM 3.1 Introdução ao Dicom Um dos maiores e principais standards na imagiologia digital na medicina é o Digital Imaging Commmunications in Medice (DICOM). O Dicom disponibiliza todas as ferramentas necessárias (protocolo para construir visualizadores, transferência dos dados, armazenamento, segurança). Outro termo revelante neste meio é o PACS (Picture Archiving and Communication Systems), sendo este toda a arquitectura IT desenhada para: aquisição, armazenamento, distribuição e visualização de imagens e ou exames médicos. Toda esta arquitectura comunica através da rede contribuindo assim para a integração do sistema PACS O PACS é constituído por vários tipos de componentes, ver, desde equipamentos de aquisição de imagem (modalidades), armazenamento de imagens em arquivos digitais e as workstations para acesso, por pessoal técnico, á visualização das imagens tiradas. 10

37 Aquisição: os sistemas PACS possuem equipamentos para aquisição de imagens; este é o processo de apreensão das imagens; normalmente estes equipamentos já utilizam linguagem PACS [C, et al., 2009]. É aqui que são criadas as imagens que ajudam os médicos no diagnóstico. Distribuição/Armazenamento: é a parte mais importante do sistema; transferência de Figura 5 - Componentes do Pacs dados dos equipamentos de aquisição para o armazenamento; actualiza a base dados; comprime os dados da imagem e disponibiliza serviços de query/retrive [Huang, 2004]. Visualização: em workstations. Única parte do PACS onde é possível a visualização de imagens médicas e consulta da informação que lhe está associada. Estas workstations permitem também aos utilizadores, realizarem pesquisas sobre o armazenamento do PACS Tipos de Modelos da arquitectura Existem três modelos de solução básicos destas arquitecturas: modelo stand-alone, cliente/servidor e web-based. 11

38 Modelo Stand-Alone: Quando os exames estão armazenados numa central de arquivos, eles são enviados automaticamente para as workstations numa abordagem do tipo store-and-forward. As workstations também têm a capacidade de fazer queries e receber dados. Esta abordagem tem muitos benefícios visto que os dados são enviados directamente para as workstations; existem menos riscos de perda de dados; as imagens também podem ser enviadas para mais que uma workstation; Modelo Cliente/Servidor: este modelo é baseado na centralização dos aquivos, num servidor intermediário. Os dados são disponibilizados aos utilizadores das workstations que podem fazer o download ficando os dados nos disco locais dessas workstations. Este modelo está sujeito a venerabilidades de variações de rede. Modelo Web-based: baseado nas soluções web sendo idêntico ao modelo clienteservidor, onde diferença reside no acesso por parte do cliente, que é realizado, neste caso, através de aplicações web, trazendo assim vantagens na portabilidade. No entanto este modelo fica limitado às funcionalidades suportadas pelas aplicações web (performance e número de funcionalidades suportadas) DICOM com PACS A ligação do Dicom com Pacs permite criar a desejada interoperabilidade no sistema. Desde logo que qualquer equipamento Pacs é acompanhado de um Dicom Conformance Statement, documento que indica quais os equipamentos suportados pelo standard do Dicom. Este standard destaca-se também pela capacidade de manipulação de ficheiros com excelente qualidade de imagem, tirando proveito das mais avançadas técnicas de representação de imagens digitais, tendo suporte para vários tipos de aquisição de dados. Isto é, facilita a interpretação, processamento e criação de imagens 3D a partir de sequências de slides 2D. Também são disponibilizados inúmeros atributos através do Data dicitonary, estando assim disponíveis todas as informações de exames, que usufruem de uma clara descrição de imagens 12

39 digitais e suas funcionalidades [NEMA]. É através do PACS que é possível agrupar toda esta informação, esta sendo relativa aos pacientes, estudos, series, etc. 3.2 Modelo Dicom Para poder compreender melhor o modelo Dicom é importante explicado o conceito de ficheiro Dicom no anexo A. De modo a tentar atenuar a complexidade do mundo da imagiologia médica (já notório pelo anexo anterior lido), o standard Dicom aproxima-se novamente do mundo real através da prática do DIM Dicom Information Mode, ver Erro! A origem da referência não foi encontrada. Seguindo então esta hierarquia como num caso real Paciente-Estudo-Series-Imagem, visível na Erro! A origem da referência não foi encontrada., cada uma destas definições será tratada como um objecto, um IOD (Information Object Defenition), onde cada IOD terá atributos a ele relacionado. Por exemplo, um IOD de um Paciente terá atributos do tipo nome, idade, sexo, etc. ver. Figura 6 Hierarquia de informação Dicom 13

40 . Figura 7 - Dados reais para IOD De seguida vem o processamento de informação entre equipamentos. Após o preenchimento do DIM com os dados, passa-se á transmissão e processamento entre os vários equipamentos Dicom. Às associações criadas devido às trocas de dados entre vários serviços de equipamentos/softwares no Dicom, são designadas de SOP Service Object Pair, e os agrupamentos destas, de Class SOP. Num caso real de um exame CT Computed Tomography, o arquivo do sistema PACS entra em comunicação com o equipamento CT do PACS, para proceder à negociação e transmissão de dados ver. O equipamento CT solicita disponibilidade de armazenamento e este equipamento de storage responde ao seu pedido, fornecendo ou não o serviço se se verificar a compatibilidade de serviço e disponibilidade de armazenamento Ver Figura 8. Figura 8 - Serviço Dicom Para ser possível esta associação, o Dicom definiu como cliente o SCU-Service Class User e como servidor o SCP- Service Class Provider. 14

41 A troca de dados é geralmente iniciada pelo SCU recebendo uma resposta do SCP, mas o Dicom permite, que seja qualquer um dos serviços a iniciar a troca de informação [Med12]. Cada troca de informação entre estes dois serviços (SCP e SCU) é chamada de Association. É utilizando estas Associations, que os dois serviços começam a estabelecer conexões, entre as suas AE-Applications Enteties. Estas Entities são utilizadas em Dicom para representar cada end-point de comunicação em ambiente Dicom, existindo assim duas AEs. A solução de comunicação usada para que a Association obtenha Applications Enteties, é denominada de Presentation Context. Caso este contexto coincida em ambos os serviços, prossegue-se à conexão e arranque do processamento SCU-SCP. Devido à elevada quantidade de equipamentos produzidos por diferentes fabricantes, é indispensável o DICOM Conformance Statement, que explica compatibilidades e serviços (SOPs) de cada equipamento, por exemplo, se dado equipamento suporta CT Storage no servidor (SCP) ou CT Storage no cliente (SCU), sendo estas, informações vitais, que precisam de ser conhecidas, para aplicação correcta em serviços. Esta pequena introdução reflecte o cerne da função do DICOM, onde se consegue perceber, à partida, elaborados e complexos conceitos necessários à compreensão do DICOM e seu processo de comunicação entre os serviços por ele criados. Compreender os conceitos no papel é relativamente fácil, aplicá-los a um caso real é onde se depara o desafio. Nos capítulos seguintes estes conceitos são novamente abordados de maneira mais extensa e novos conceitos são introduzidos. 3.3 História do Dicom No início da utilização de imagens médicas em formato digital, por volta dos anos 70, e com o aumento da utilização dos computadores nessa área, começou a sentir-se a necessidade de criar um Standard, que criasse interoperabilidade entre diferentes equipamentos, fossem eles do mesmo fornecedor ou não. Então em 1983 foi criada uma comissão, entre ACR (National Electrical Manufacturers Association) e NEMA (National Electrical Manufacturers Association). Esta comissão 15

42 investigou vários standards já existentes, entre eles consideraram ser o mais razoável o American Association of Physicians in Medicine (AAPM), que tinham um standard que guardava as imagens médicas em fitas magnéticas, com uso de um cabeçalho que tinha uma descrição da imagem com dados do paciente. Começou-se a usar uma ideologia de uso de elementos de dados, que tinham comprimento variável dependendo de identificadores. Estes eram acedidos por meio de Tags (conceito explicado em pormenor à frente). Este tipo de ideologia de Tags funcionou tão bem que ainda hoje é usado. A comissão também definiu no standard protocolos de comunicação, que abrangiam por exemplo: a comunicação de informação da imagem digital, sendo ou não do mesmo fabricante de equipamentos; facilitar o desenvolvimento de sistemas de comunicação e arquivos de imagens nos PACS; permissão na criação de bases de dados de informações de diagnóstico, podendo ser feitas queries a partir de vários dispositivos distribuídos geograficamente [NEMA, 2004]. Desde a união desta comissão ACR-NEMA, foram lançados 3 standards. Em 1985 a comissão fez a sua primeira publicação: DICOM 1.0 ou ACR-NEMA que teve direito a duas versões, primeira versão em Outubro 1986 e a segunda versão em Janeiro Neste mesmo ano, 1988, foi publicada a versão DICOM 2.0 ou ACR-NEMA Esta publicação, além de todo o conteúdo e revisões da v1.0, acrescentava o conceito orientado a objectos, e melhorias nas partes de comunicação entre redes [Castigli, et al.]. Actualmente, e dado por completo, encontra-se na versão Dicom 3.0 publicado no ano de 1993, tornando-se o standard para PACS, envolvendo as versões anteriores, e definindo novas classes de serviços, como recuperação, pesquisa, impressão de imagens, armazenamento, processos de transmissão através de redes, etc. Desde então vem sendo actualizado com publicações de novos documentos, sempre respeitando as instruções da comissão ACR-NEMA [Clunie, 2012]. A esta comissão actualmente juntaram-se quase todos os grandes fabricantes de dispositivos de imagem médica, sendo alguns deles: Agfa, Kodak, Toshiba, Philips, Siemens, American 16

43 College of Radiology, Societe Fraçaise de Radiolgie, Societa Italiana di Radiologia Medica, Korean PACS Standard Committee, entre outros [NEMA, 2012]. Sendo assim esta versão do Dicom 3.0 suportada por um vasto leque de equipamentos, permite uma fácil incorporação num Pacs. 3.4 DICOM Standard O standard Dicom [Alliance, 2012] tem vindo a ser desenvolvido com o objectivo de responder às necessidades dos equipamentos de diferentes fabricantes, que pretendem interoperabilidade entre os seus equipamentos. Desta maneira é possível criar um Pacs como na, com total compatibilidade. Então é necessário um formato comum de imagens médicas digitais, com um protocolo comum de troca de dados e uma estrutura de arquivos. Assim é possível a troca de imagens independentemente do fabricante dos equipamentos como Tomografias, Ressonâncias Magnéticas, Radiografias, etc. Para que essa compatibilidade seja eficaz são obedecidas uma série de regras. Os equipamentos que suportam Dicom podem ser RM (ressonância magnética), Raios-x, TC (tomografia computadorizada), etc. [Wikipedia, 2012]. Todo este complexo sistema possui um documento que esta dividido por partes, permitindo assim uma melhor compreensão de todo o standard Dicom. Todo este complexo sistema possui um documento que esta dividido por partes, permitindo assim uma melhor compreensão de todo o standard Dicom. 3.5 Partes DICOM Pode-se considerar esta secção do capítulo Dicom deste relatório como uma das mais importantes, isto porque se descreve a plataforma Dicom. Devido à sua dimensão e de modo a facilitar o acréscimo de futuras aplicações, o standard Dicom foi divido em partes. Desta 17

44 maneira, os sistemas de informação médicos têm interfaces adequadas para a apresentação do standard. Sempre que se desejar ou houver necessidade em alterar certas partes do standard, estas alterações só irão afectar as partes onde foram realizadas, permanecendo as restantes partes inalteradas. O standard é composto por 18 partes, ver Tabela 1, cada uma dizendo respeito a um assunto específico. Somente as partes mais pertinentes irão ser abordadas em mais pormenor em novos capítulos, e nas restantes é feito um resumo do seu conteúdo nas secções seguintes. Estas partes podem ser consultadas nos sites 1 Tabela 1- Partes Dicom Parte Titulo 1 Introdução e visão geral 2 Conformidade 3 Definição dos objectos de informação (IOD) 4 Especificações das classes de serviços 5 Estrutura de dados e codificação 6 Dicionário de dados 7 Troca de mensagem 8 Suporte á comunicação em rede para troca de mensagem 9 Especificações de interferência ponto a ponto - removido a partir da versão Dicom Armazenamento multimédia e formato de ficheiro para troca de dados 11 Perfis de aplicações de armazenamento em multimédia 12 Formato de multimédia e formatos físicos para troca de dados 13 Gestão de impressão ponto a ponto - removido a partir da versão Dicom Função de apresentação do standard em escala de cinzas 15 Perfis de gestão de segurança e de sistema 16 Recurso de mapeamento de conteúdos - templates de elaboração de documentos, glossário de termos e traduções; 17 Informação explicativa - informação redundante, anexos informativos; 18 WADO Acesso Web de persistência de objectos Dicom - esclarece como devem ser requisitados e iniciados os objectos por via http Introdução e Visão Geral Indica a apresentação global do standard DICOM. Rápida explicação de cada elemento, e uma curta descrição da parte do DICOM. Conformidade Apresenta regras de implementação que devem ser seguidas de acordo com as condições

45 estabelecidas, para que desta maneira o sistema possa realmente estar de acordo com o standard e assim atingir o objectivo de interoperabilidade. Não engloba testes de validação. Para a existência de interoperabilidade entre os equipamentos, é necessário os fabricantes saberem como e o que fazer para alcançar esta interoperabilidade. Para tal, precisam de respeitar a Declaração de Conformidade (Dicom Standards Committee e ACR-NEMA) [NEMA, 2004]. Estrutura de Dados e Codificação Indica como as aplicações Dicom identificam e compilam os Data Sets, que são resultados do uso de Objectos de Informação e das Classes de Serviços definidas acima. São definidas as regras de codificação necessárias para a construção de Data Stream, que será transportado por uma Mensagem (como será visto na parte 7). Este Data Stream é composto por Data Elements que compõem o Data Set. Dicionário de Dados Registo centralizado que define o conjunto de todos os Elementos de Dados Dicom, disponíveis para exibir informações. Exemplos destes elementos são o Tag que identifica de maneira única cada elemento e o UID, uma lista de itens de identificadores únicos. Estes conceitos irão ser mencionados á frente onde se irá perceber melhor o seu uso. Troca de Mensagem Determina o serviço e o protocolo usado na aplicação escolhida que troca Mensagens usando os serviços definidos na parte 8. Esta mensagem é composta por Command Stream seguido por um Data Stream. Suporte à Comunicação em Rede para Troca de Mensagem Define serviços e protocolos ao nível da comunicação em ambiente de rede nas partes 3,4,5,6,7 para troca de mensagens. Estes serviços de comunicação e protocolos garantem que a comunicação entre as aplicações seja executada de forma eficiente através da rede. Apelidam-se estes serviços de Serviços de Camadas Superiores (Upper Layer Service), que permitem que as aplicações estabeleçam comunicações e finalizem as associações. É especificado ainda o uso de um Protocolo de Camada Superior Dicom combinado com o protocolo de transporte TCP/IP. 19

46 Armazenamento multimédia e formato de ficheiro para troca de dados Descreve um modelo geral para armazenar informações. Fornece uma Framework que permite troca de vários tipos de imagens médicas e informações relacionadas, sobre uma grande quantidade de meios de armazenamento físico; Perfis de aplicações de armazenamento em multimédia Conhecidos como Perfis da Aplicação, conjuntos específicos de aplicações que devem estar em conformidade. Funções de Armazenamento, Formatos de Arquivos para Troca de Dados Proporciona a troca de informações entre aplicações de sistemas médicos através de: - Uma construção que descreve a relação entre o modelo de armazenamento e o meio físico e o seu formato; - Características físicas do meio e os formatos agrupados Função de apresentação do standard em escala de cinzas Junta as funções de exibição de imagens em escala cinza; possui métodos de calibração com o propósito de apresentar imagens consistentes. Perfis de gestão de segurança e de sistema Circunscreve o uso de protocolos externos usados para cada perfil de segurança e também inclui o uso de criptografia. São usados protocolos como DHCP. 3.6 Definição dos Objectos de Informação IODs são dos principais elementos usados no standard. São modelos abstractos de informação de uma classe. De uma maneira simples, são estes os objectos de informação que contêm os dados básicos do mundo real, (referenciados também só de objectos no ambiente Dicom), que definem a natureza e atributos relevantes para a classe. 20

47 É utilizando IODs que definimos a informação de uma SOP, podendo existir, IODs, Normalizadas ou Compostas, ver. As Normalizadas possuem só um Information Entity IE (uma imagem, um paciente); por sua vez as Compostas possuem duas ou mais IEs. Esta relação está dependente do modelo de informação Figura 9- IODs Normalizadas ou Compostas Os IODs são também divididos por atributos, estes atributos são organizados em módulos consoante a sua relação, ver Figura 10, no caso onde são guardados dados idênticos e relacionados, estes são agrupados em Módulos de Objecto de Informação IOM. Isto permite assim, que cada imagem contenha um conjunto independente de informações, permitindo assim que os seus atributos semelhantes fiquem agrupados no mesmo módulo. 21

48 Figura 10 - Exemplo de um Módulo de um IOD & Atributos Cada Atributo é defenido pelas as seguintes caracteristicas, ver Figura 10: - Atributo Nome; - Atributo Identificador TAG; - Tipo de Classificação; - Atributo Descrição; - Representaçao de Valor; - Mutilplicidade de Valor. Atributo Identificador TAG As Tags são formadas por 4 dígitos hexadecimais no formato <4g,4e>, onde 4g representa os Figura 11 - Correspondia ao Dicionário de Dados 4 dígitos do grupo, e 4e representa os números dos elementos dentro do grupo. Ver. A Class IOD (Definição dos Objectos de Informação) pode ser considerada especial, porque tem uma conexão directa com a class de serviços SOP, sendo o papel desta, descrever o procedimento de cada um dos equipamentos CSP e SPU, consultar Anexo- D. 22

49 No que diz respeito ao método de organização dos dados estes estão organizados numa lista, Tag, VR, Value lengh, Value field, consultar anexo D para compreender em mais pormenor este método de organização. Igualmente será explicado as sintaxes de transferência que são as sintaxes de transferência definem um conjunto de regras que permitem que as Entidade de Aplicação AE, negociem e acordem estas codificações existentes (do tipo Byte Ordering: Big Endian e Little Endian) antes de passarem para a transferência, consultar Anexo - J. 3.7 Serviços Este capítulo indica quais os tipos de serviços que podem ser utilizados para a comunicação de objectos de informação (rever secção Definição dos Objectos de Informação), e para que dispositivos possam executar serviços de um dado objecto, por exemplo, visualizar, armazenar, etc. Cada comando mostrado a seguir (C-Echo, C-Store, N-Get etc.) possui um UID associado, também podendo ser mencionados por serviços de verificação, armazenamento etc; sobre estes serviços são executados comandos, como se explica a seguir. Os comandos são divididos em dois grupos: C-commands e N-commands, ver Tabela 2, e Tabela 3. A diferença entre eles reside quando estes são utilizados sobre objectos normalizados ou compostos, respectivamente, (ver capítulo 3.6), tendo cada um deles especificações diferentes correspondentes a cada um. Quando há interacção nos serviços, de um modo geral, um dispositivo laça um comando de pedido e o receptor responde com um comando de aceitação. Sendo o modelo de informação orientado a objectos, por vezes um serviço também pode ser referido por Classe de Serviço. Portanto, se um dispositivo alberga serviços, então ele pertence a uma Classe Provedora de Serviços SCP (Service Class Provider), caso use apenas um dispositvo pertence a um Utilizador de Serviços SCU (Service Class User). Dependedo da situação um dispositvivo pode actuar como SCP ou SCU, ou os ambos. 23

50 Serão apresentadas tabelas com os vários comandos existentes, ver Tabela 2, e Tabela 3, porém só serão abordados neste relatório os comandos que serão empregues no desencolvimenteo da aplicação [Connections., 2012]. Tabela 2 - N-commands Comandos Cargo N-Get Aquisição dos valores de um atributo de um objecto N-Set Indicação do valor de um atributo para um objecto N-Create Criação de um objecto N-Delete Exclusão de um objecto N-Action Discriminação da acção para um objecto Tabela 3 - C-commands Comandos Cargo C-Echo Verificação da conexão C-Store Transmissão de instâncias de objectos C-Find Query/Retrieve de informações de uma instâncias de um objecto C-Get Transmissão de instâncias de objectos (Servidor-Cliente) C-Move Transmissão de instâncias de objectos (Servidor-Cliente), podendo o receptor ser o mesmo que o requisitante. Serviços Utilizados no projecto No projecto serão abordados os serviços de visualização de conexão, transmissão, consulta: (C- Echo, C-Get, C-Find) respectivamente. 24

51 C-Echo, este serviço de verificação é idêntico ao utilitário ping 2. Este serviço é usado apenas quando se pretende saber se existe conexão entre dois AEs, dispositivos ou para verificação do estado da conexão destes. Tanto o C-Move como o C-Get são serviços de transmissão e armazenamento, porém para mover dados dentro de uma BD somente é usado o C-Move. Por outro lado o C-Get é usado para adquirir dados num servidor Dicom, onde toda a transferência é feita na mesma associação. Por último, para o serviço de consultas (query/retrieve) é utilizado o comando C-Find. Estas queries utilizam um pequeno conjunto de atributos chave. Este método de queries é um pouco diferente das queries utilizadas regularmente nas BD, ver explicação na secção 1.1. Adicionalmente este serviço disponibiliza ferramentas que permitem adquirir imagens identificadas a priori. Este serviço permite que sejam efectuadas queries de uma AE remota (de outro Pacs), não tendo sido esta funcionalidade abordada neste projecto. 3.8 Comunicação A comunicação no standard Dicom emprega uma norma já existente da comunicação em rede, o modelo OSI (METER AQUI), e é usando este modelo que é realizado a transmissão de informações médicas. Um processo será definido como Serviço, quando, os objectos de informação (dados e imagens), são transmitidos pelas camadas num mesmo dispositivo. Em contrapartida, no standard Dicom, quando estes objectos são transmitidos entre diferentes dispositivos, diz-se que estes dispositivos estabeleceram um Associação. Na Figura 13 pode visualizar-se uma associação criada, entre o equipamento de aquisição de imagem e a Workstation. Esta transmissão de imagens entre dispositivos diferentes segue os seguintes processos (ver ). 2 É um utilitário que usa o protocolo ICMP (Internet Control Message Protocol) para testar a conectividade entre equipamentos. 25

52 Figura 12 - Processo de Transmissão de imagens Figura 13 - Transmissão de imagens de um equipamento de CR para uma Workstation Para aprofundar mais os conceitos mencionados nesta secção refira-se ao Anexo B, onde são explicados conceitos complementares, como Entidade de Aplicação AE, 3.9 Comunicação usando serviços Dicom Após retenção dos conceitos individuais abordados nas secções anteriores (3.7 e 3.8), seguese a demonstração da junção dos dois, podendo ser considerado este um dos capítulos mais importantes, pois aqui se concentra a utilização da maior parte dos conceitos já referidos. 26

53 Como a maior parte do standard Dicom é dividido em duas grandes funcionalidades, enviar e receber imagens, torna-se de todo indispensável explicar este procedimento em mais pormenor. Serão então explicados dois casos. Neste primeiro caso, é explicado o funcionamento do serviço mais simples, envio e recepção de múltiplas imagens, partindo de um equipamento CT para um servidor Dicom, empregando o serviço C-Store, ver Figura 14. Figura 14 - Envio de Dados (imagens) de um CT para um servidor Dicom No segundo caso (envio realizado entre uma Workstation e um servidor) será explicada a operação de aquisição de imagens, mas aplicando-se consultas através do serviço C-Find. Na ver Figura 15, é possível analisar que a Workstation funcionará como SCU (Q/R) e posteriormente SCP (C-Store), pois primeiro precisa consultar os exames e de seguida necessita armazená-los; e o servidor funcionará como SCP - (Q/R) e posteriormente como SCU (C-Store), pois este inverte o papel quando a Workstation necessita armazenar os exames. 27

54 Figura 15- Pesquisa de Dados (imagens) num servidor Dicom 3.10 Imagem O Dicom define que cada ficheiro só pode ter uma imagem, porém não limita o número de frames, o que significa que, desde que tenham o mesmo tamanho e que sejam do mesmo tipo, podem existir inúmeras imagens. Como se pode ver na. Nos casos em que os exames usam vídeos em vez de imagens (que não são mais do que conjuntos de frames animados), alguns dos visualizadores Dicom têm a capacidade de gerar vídeo usando sequências de imagens. As imagens podem ser comprimidas ou não, utilizando técnicas de compressão do tipo JPEG Lossy ou Lossless, sendo que nas imagens comprimidas pode haver perda de informação. A imagem é armazenada com a Tag (7FE0,0010), e no caso de compressão com perdas de 28

55 informação, essa informação é adicionada ao ficheiro levando a Tag (0028,2110), seguida pelas informações relativas ao método e taxa de compressão, que vão nas Tags (0028,2112) e (0028,2114). Figura 16- Arquitectura da aquisição da imagem 3.11 WADO Acesso Web de persistência de objectos Dicom Uma forma alternativa de conseguir aceder ao standard DICOM é através da web. Basicamente neste serviço baseado em Web, a ideologia é a distribuição de toda informação (dados, imagem, etc). O sistema de acesso é feito através de HTTP/HTTPS, utilizando os UID do paciente e do exame, é possível extrair os dados desejados em formato de ficheiro Dicom ou na imagem propriamente dita, por exemplo em formato JPEG. A utilização desta abordagem é uma óptima escolha quando não se tem limitações a nível de conexão de internet, não se é exigente a nível da qualidade de imagem, nem de recursos computacionais, ver Figura 17 [Nema, 2011]. 29

56 Figura 17- Abordagem usando Wado 3.12 Considerações Sendo o Dicom um standard trabalhoso pela sua complexidade, mas muito bem documentado, possibilita a evolução do mesmo. E com a evolução do standard Dicom, aumenta também a oportunidade para organizações médicas melhorarem os cuidados prestados aos pacientes, permitindo que as informações sobre um paciente sejam trocadas entre centros médicos geograficamente distribuídos, tornando a troca de informação mais barata e mais rápida do que outros meios. Além disso, as imagens Dicom não perdem a qualidade, assim os médicos a partir de outro lado do mundo, podem analisar um exame de um utente de outra unidade médica, tendo consciência de que a sua qualidade não foi alterada. 30

57 31

58 4 Desenvolvimento Após entendido o standard Dicom, iremos passar à sua implementação. Definiu-se que a utilização de toolkits que envolvam Dicom eram essenciais, pois a implementação de raiz da especificação Dicom é muito complexa e não seria viável nem objecto deste trabalho. Foi feita uma investigação sobre várias soluções existentes no mercado. No próximo capítulo vai-se fazer uma comparação entre algumas dessas bibliotecas já existentes, de modo a decidir-se qual a que será utilizada. 4.1 Estado da arte Neste subcapítulo, vão ser analisadas várias bibliotecas e ferramentas que poderiam ter sido utilizadas, para assim ser escolhida a biblioteca mais indicada, que pode-se vir a facilitar o desenvolvimento, e permitisse a reutilização de algum código já existente. Assim, os toolkits descritos de seguida visam facilitar o desenvolvimento de aplicações, usando-se como referência de comparação entre estes toolkits o repositório I do Imaging free Medical Imaging software [Crabb, 2012], visto ser um repositório já conhecido no meio da imagiologia para este fim. Assim consegue-se filtrar os toolkits de suporte ao Dicom tendo sido somente seleccionados aqueles que se destacavam, e aqueles que disponibilizavam serviços como: C-Echo-RQ, C-STORE, C-GET, C-FIND, sendo estes os únicos serviços relacionados com Dicom, que são necessários para implementação da aplicação referente a este projecto. Dcmtk [institute, 2012] 32

59 Contém várias bibliotecas, onde se salienta principalmente os serviços de rede do Dicom. Este toolkit é desenvolvido em C e C++, existindo uma maneira não oficial de ser usado com outras linguagens. O Dcmtk já é utilizado em projectos bastante conhecidos e maduros nesta área, como por exemplo, o visualizador Dicom Aeskulap, que utiliza já serviços como (A- Associate, C-Echo, C-STORE, C-GET, C-FIND) Dcm4chee [dcm4che.org, 2012] Possui várias bibliotecas desenvolvidas e suporte a Java. Existem aplicações reconhecidas que usam as bibliotecas dcm4chee, por exemplo Weasis Viewer [dcm4che.org, 2012] e MAYAM [dcm4che.org, 2012]. Este toolkit tem capacidades DICOMDIR além de C-Echo, C-STORE, C-GET, C-FIND; capacidades de rede; uma comunidade activa; é considerada a melhor API para ser utilizada na implementação da especificação Dicom. Dcm4hcee tem mais vantagem nos serviços disponibilizados (ver Tabela 4), pois estes serviços podem ser ou não individualmente implementados, o que pode ajudar a retirar serviços desnecessários, dando vantagem numa possível abordagem futura de uma implementação em Android, já que neste ambiente seria vantajoso retirar-se o maior número possível de dependências desnecessárias. Tabela 4- Tabela de comparação entre os toolkits Dcm4chee Dcmtk Documentação Insuficiente Compreensiva Manutenção Elevada Elevada Sistema Operativo Dicom Serviços DICOM IOD (modalidades suportadas) Bibliotecas, Cliente PACS, Servidor, Utilitários US, CT, MR, SC, DX, XA, VL, RT Bibliotecas, Cliente PACS, Servidor, Visualizadores US, CT, MR, SC, DX, XA, VL, RT Linguagem Java, XML C, C++ Interface Linha de Comandos, Bibliotecas Linha de Comandos, Bibliotecas Formato de entrada DICOM DICOM, Own/Unique Formato de saída DICOM, JPEG DICOM, Own/Unique Mas saliente-se que, segundo as necessidades iniciais, a toolkit que disponibiliza mais base para o desenvolvimento da aplicação seria o Dcmtk, pois possibilita grande quantidade de 33

60 código comentado descritivo e muita documentação, levando a uma aprendizagem e entendimento mais rápidos. Mas visto que se poderia tentar uma abordagem para portabilidade Android, seria uma maisvalia existir, para o toolkit escolhido, uma base em Java, pois é nesta linguagem que a aplicação para desktop será desenvolvida, e sendo esta a linguagem utilizada no desenvolvimento de aplicações para Android. Apesar de, na investigação realizada e nas referências encontradas, existirem alguns recursos que eram possíveis de serem implementados com o toolkit Dcmtk, traduzindo da linguagem C++ para Java, através de uma possível utilização de wrapers, não se conseguiu encontrar algo que desse este suporte de forma estável e isenta de problemas. Sendo assim, e apesar de a documentação em Dcm4che ser escassa, optou-se por se escolher a utilização do toolkit Dcm4chee. [A, et al., 2006] 4.2 Dcm4che toolkit utilizado Como o Dcm4che foi o toolkit escolhido, este irá ser descrito em mais pormenor, no que respeita às suas funcionalidades, serviços e operabilidade, de forma a que se possa tirar melhor partido das características que o Dcm4che dispõem. O dcm4che disponibiliza já um variado conjunto de utilitários que implementam o standard Dicom, o código é aberto, desenvolvido em Java, por isso não é de estranhar a elevada utilização desta biblioteca em aplicações existentes no mercado. Dcm4che é uma colecção de aplicações open source direccionada para a medicina. Está dividida em duas partes: Dcm4che2 toolkit, que tem a implementação do standard Dicom e Dcm4chee, que é um simulador da arquitectura PACS. Poderá existir alguma confusão inicial em distinguir ambas pela nomenclatura, mas repare-se que a diferença entre estas duas é a letra e no final. 34

61 4.2.1 Arquitectura A Arquitectura segue um processo de implementação Cliente Servidor, sendo o dcm4chee o servidor e o dcm4che o cliente, implementado por meio das toolkits (serviços) dcm4che. É utilizado um serviço de aplicações JBoss, podendo trabalhar com diversas base de dados, (usadas para armazenar as informações, qualquer que seja natureza relacionada com o sistema (cabeçalhos, dados de exames, etc.)), por exemplo: PostgreSQL, MySQL, Oracle, SQL Server, DB2, Firebird, HSQL. Como também se pode ver na Figura 18, é possível armazenar imagens tanto online como offline. No modo online as imagens estão sempre disponíveis, quando são requisitadas, sendo o modo offline referente a DVDs, armazenamento jukebox. No modo offline é necessário recuperar a imagem para modo online para esta ser utilizada [Danielson, et al.]. Figura 18- Diagrama Dcm4che [Danielson, et al.]. 35

62 4.2.2 Serviço WADO Abordagem para ter acesso às imagens O modo como um dispositivo se relaciona com o servidor dcm4chee para aquisição de imagens pode ser visto na Figura 19. Figura 19 - Abordagens de aquisição de imagens As workstations que se queiram conectar ao dcm4chee utilizariam o modo de comunicação Dicom, como se pode ver na Figura 19 em (A). Nos casos onde pretende localizar, guardar ou somente ver imagens, o visualizador utilizará o serviço Query (que utiliza o comando C-Find) e Dicom Retrieve (utilizando o comando C-Move). Outra alternativa ao C-Move para armazenamento de imagens é o comando C-Store. Existe também a opção baseada na Web, ver Figura 19 em (B), em que o Dicom utiliza Http para comunicação, usando o serviço Wado (Figura 17), referido no capítulo 3.11, para extracção das imagens para o navegador. Através do serviço Wado só pode ser adquirida uma imagem de cada vez, sendo assim necessários vários pedidos para que se tenha o estudo completo de um paciente (caso este possua muitas imagens). 36

63 Apesar das vantagens que provêm de se desenvolver um visualizador em ambiente Web, (i.e., o poder ser visto em qualquer browser e em qualquer SO), ver Figura 20, são raros os visualizadores que suportam as funcionalidades mais exigentes, pois estão limitados pelos browsers, (por exemplo considerando um caso habitual, onde a quantidade das imagens, estudos, etc., podem chegar facilmente aos milhares, levando a uma elevada sobrecarga em termos de memória cache para os browsers, ou pesada a constante transmissão de dados necessária). As aplicações que usam transferência de imagens via Http, contornam este problema encapsulando as imagens antes de serem transmitidas por Http. Estas imagens só depois são descomprimidas e exibidas no browser. É importante dizer que esta abordagem já requer outro tipo de arquitectura. Neste meio são conhecidas duas grandes aplicações que utilizam esta abordagem, TeraMedica [TeraMedica, 2012] e Agfa [AGFA, 2012], que se destacam no mercado pelo seu sucesso [dcm4che.org, 2007]. Figura 20 - Servidor Web 37

64 5 Implementação Este capítulo será dedicado aos detalhes de implementação da aplicação, seus requisitos, abordagem e arquitectura empregada. Ordem de trabalho Inicialmente começará por se explicar a abordagem feita para o desenvolvimento do visualizador Dicom (simulando uma workstation). Na criação do Pacs será explicado como montar um servidor dcm4chee com uma base de dados e simular o equipamento de imagiologia. Após definida a abordagem e a montagem de todo o PACS, vai ser exibido o Diagrama ER e Casos de Uso, resultante da abordagem feita. Serão também explicadas partes de código mais importantes do desenvolvimento do visualizador. Posteriormente será feita também uma análise ao código da interface desenvolvida que contém o resultado final da aplicação. Estratégia de Desenvolvimento Os requisitos para este projecto têm como propósito o desenvolvimento em Java de um visualizador Dicom, que consiga conectar-se ao servidor, tendo como suporte as bibliotecas disponibilizadas. Este visualizador terá implementado comandos como o C-Echo, C-Find, C- Get, permitindo a manipulação de dados contidos no servidor, criando-se também uma interface para ajuda a esta manipulação. O visualizador deverá requisitar o IP, a porta e AE, para poder configurar e estabelecer conexão com o servidor e assim poderem ser feitas pesquisas e aquisição de imagens. Esta interface permitirá escolher um dado Paciente, os seus estudos e series, exibindo a imagem dos exames seleccionados. 38

65 5.1 Arquitectura utilizada no desenvolvimento do projecto Visand Nesta secção descreve-se a arquitectura que foi desenvolvida de modo a que fosse possível abranger todas as funcionalidades que existem num hospital real, dentro dos parâmetros estabelecidos do projecto. Como se pode ver na, foram simulados equipamentos de imagiologia, criados servidores, desenvolvido e implementado um visualizador de imagens médicas (Visand) e utilizada uma BD. De notar, na, que as setas a tracejado são formas possíveis de comunicação entre os equipamentos, sendo conexões com base em ligações web, as quais têm vantagem a nível de distribuição dos dispositivos, mas limitações quanto à velocidade de através da Internet; as setas com linhas contínuas são ligações que podem ser feitas directamente, sem necessidade de internet, sendo estas mais rápidas e menos dispendiosas, mas proporcionando menos capacidade de distribuição dos dispositivos locais. Reparando então, na, pode ver-se que o equipamento de imagiologia pode enviar dados (imagens) directamente para Workstations, ou, pode enviar esses dados através da Web. A Workstation, por seu lado, irá procurar esses dados ao servidor, ou de outra forma, o equipamento de imagiologia pode enviar os dados directamente para o servidor, e a Workstation, através da Web, ir recolher esses dados. Esta abordagem permite-nos perceber que existem inúmeras formas de se realizar as conexões entre equipamentos e entender a forma como estes se interligam. Assim, com o desenvolvimento desta arquitectura, é possível cobrir todos os objectivos definidos. Na secção a seguir são demonstrados e explicados cada um dos passos realizados neste desenvolvimento. 39

66 Figura 21 - Arquitectura utilizada no desenvolvimento do projecto Será demonstrado em anexos exemplos de código com os passos base para a implementação de alguns serviços explicados nesta arquitectura. Instruções básicas de implementação ver Anexo - F, seguindo a ordem, para verificar o estado da ligação pode-se examinar o Anexo G, para ver o código que demostra como é implementado a simulação de um equipamento medico ver Anexo H e por último a implementação de como as pesquizas e aquisições são feitas ver o Anexo I. 5.2 Instalação do Servidor, simulando Pacs Na investigação feita para a instalação do servidor escolhido Dcm4chee, a fim de simular um Pacs real, encontraram-se várias alternativas para ambiente Windows, Linux e OSX, porém não houve uma escolha imediata, pois nenhumas destas eram suficientemente esclarecedora e 40

67 específica, debatendo-se sempre com bastantes dificuldades na instalação do servidor devido a pouca documentação deste toolkit escolhido Dcm4chee. Foram então testados dois servidores, em ambiente Windows (ver instalação em anexo A) e Linux, porém, após investigação dos passos de instalação de ambos, optou-se por se utilizar a versão em Linux, devido à exigência de pacotes excessivos e desnecessários do servidor Windows. Assim, e do estudo feito a vários tutoriais explicativos e elucidativos da instalação do servidor em ambiente Linux, foi encontrado um servidor previamente configurado e optimizado, contendo apenas os pacotes e serviços essenciais para a execução do toolkit, sendo este servidor preparado num ISO [M.D., 2012] a correr em ambiente Linux Debian. Com a utilização deste servidor conseguimos excluir serviços como: dcm4chee-arr; dcm4chee-cdw; e dcm4chee-xds, visto que não vamos usar o Audit record repositor 3 - ARR, nem vamos exportar exames para CD. 5.3 Interface Neste capítulo será apresentado o interface do visualizador. Por de traz de cada janela estão vários dos serviços Dicom implementados: desde o, C-GET, C-FIND, etc. Todo o processo que é feito no Visualizador é com o intuito final de serem mostradas imagens de um certo estudo relativamente a um paciente escolhido. Portanto depois de configurada a conexão, para se obterem as imagens é necessário passar pelas hierarquias do Dicom (Paciente-Estudos- Series-Imagens) ver Figura 22. Conforme vão sendo mostradas as interfaces irão ser feitas breves descrições sobre as mesmas. 3 Audit record repositor ARR, permite a auditoria das operações realizadas. 41

68 Figura 22 Interface do Visualizado e sua ordem de utilização. No arranque do Visualizador a primeira janela que aparecerá será para indicar os atributos necessários, para se estabelecer uma conexão com o servidor. Então no caso indicado, ver, é introduzido o IP e Porta referente ao servidor; é também necessário indicar a AE que terá sido criada a priori no servidor. 42 Figura 23- Primeira configuração.

69 Depois de serem preenchidos os dados, e estabelecida a conexão, são feitas as pesquisas ao servidor Dicom. Nesta primeira pesquisa serão listados todos os pacientes que se encontram registados no servidor. Assim, tem-se a capacidade de se poder escolher dessa lista, a quais os pacientes se deseja que sejam mostrados os exames ver Figura 25. Após ser escolhido o paciente, vai ser escolhido o estudo desejado, sendo este processo idêntico ao da escolha do paciente e aos próximos dois passos: escolha das series e escolha das imagens a serem visualizadas. A diferença está na implementação, onde variam entre nos respectivos níveis de queries e nos tipos de queries feitas ver Figura 26. Então escolhidas as series e as imagens a serem visualizadas, temos a hierarquia Dicom criada, com um paciente, estudos, serie e imagens, específicas, como se pode ver na Figura 24. Figura 24- Escolha dos estudos, series e imagens. Com a última janela ( Imagens ), podemos visualizar as imagens disponibilizadas perante as escolhas feitas na hierarquia anterior, assim, será gerada uma janela nova a cada imagem escolhida para ser visualizada, como se pode ver na Figura

70 Figura 25 - Janela das listagens das imagens e as imagens visualizadas. Na secção a seguir conseguira-se ganhar uma melhor percepção da estrutura que engloba todas estas interfaces. É aconselhável examinar o anexo K, para consultar os Diagramas de Classes resultantes do desenvolvimento do Visand. 44

71 45

72 Conclusões 6.1 Discussão e Limitações Este trabalho teve como principal objectivo o desenvolvimento de uma aplicação que permitisse explorar a hierárquica do Dicom até visualizar as imagens provenientes dos exames, através dos diversos serviços fornecidos pelo Dicom: C-Move, C-Find, C-Store, os quais auxiliam na comunicação com o Pacs, servidores e workstations. Da investigação realizada, concluiu-se que seria benéfica a utilização do toolkit Dcm4che, entre outros estudados; e apesar da falta de documentação que auxilia-se na implementação de aplicações que utilizem os serviços Dicom, foi possível o desenvolvimento e implementação de uma aplicação (Visand) que permitisse o acesso, por parte dos utilizadores, aos serviços disponibilizados pelo Dicom, contendo um modelo de integração de ferramentas de processamento de imagens, e disponibilizasse uma interface coerente para a possibilidade de visualização de exames médicos de forma transparente para o utilizador. Para isto foi também necessário encontrar um servidor que proporcionasse o suporte à arquitectura a ser implementada, assim foram investigados dois tipos de servidor (em ambiente Windows e Debian, tendo sido este último o utilizado no projecto), ambos instalados e configurados para interacção com os equipamentos de aquisição de imagiologia médica e workstations. A aplicação desenvolvida suporta a visualização de exames médicos no formato Dicom e JPEG, não tendo sido implementados outros formatos no escopo deste trabalho, estando assim limitado nos tipos de formato de leitura de ficheiros. Esta limitação pode ser ultrapassada 46

73 quando capturados os ficheiros no formato Dicom aplicar sobre estes uma biblioteca de com ferramentas de conversão de formatos de imagem, JAI (Java Advanced Imaging) Image I/O. (sendo usado para descomprimir imagens JPEG2000, que são os formatos habituais das imagens comprimidas utilizadas no standard Dicom, e dada a investigação realizada parece haver pouca alternativa além do JAI). Assim, do trabalho realizado e descrito neste documento, pode-se concluir que os objectivos inicialmente propostos foram atingidos com sucesso. Apesar disto, da investigação feita, é possível constatar possíveis implementações de funcionalidades futuras, podendo haver assim algum trabalho futura de forma a acrescentar ou melhorar certas funcionalidades, que não foram implementadas, ou por não serem do interesse do presente trabalho ou por exigirem uma abordagem diferente à arquitectura do trabalho realizado neste projecto. Na secção seguinte descrevem-se algumas das possíveis contribuições para esse trabalho futuro. 6.2 Trabalhos Futuros À medida que o projecto foi amadurecendo, foram identificadas várias oportunidades de melhor ou complementar a solução idealizada e construída ao longo deste projecto. Uma futura implementação seria a utilização de Web services, ver imagem Figura 26 de modo a maximizar o potencial da interoperabilidade entre os serviços. Deste modo é bastante fácil disfarçar a complexidade do sistema. A ideia futura seria implementar um front-end que serviria como um consumidor de serviços, e um back-end como um provedor. Consequentemente o utilizador que irá possuir o front-end só necessitaria de um visualizador (possivelmente em HTML5 ou Flex) toda a camada de negócio estaria implementada num servidor que iria possuir a camada DICOM. Logo seria bastante alargado o leque de soluções para o utilizador final, já que só serão invocados serviços. 47

74 48 Figura 26 - Arquitectura duma abordagem futura

75 Bibliografia 5, NEMA Part Digital Imaging and Communications in Medicine (DICOM) Part 5: Data Structures and Encoding A, Vázquez, et al Evaluation of Open Source DICOM Frameworks AGFA AGFA HealthCare Alliance, Medical Imaging & Technology The DICOM Standard Altova Altova UModel 2012 Enterprise Edition Bauermann, Gabriela Formato de arquivos DICOM Botha, C. P., et al From individual to population: Challenges in Medical Visualization C, Costa, et al Indexing and retrieving DICOM data in disperse and unstructured archives pp Castigli, Martin M., et al. DICOM Comunicação de imagens digital em medicina. Clunie, David A DICOM Standard Status Connections., Medical Basic DICOM Operations Crabb, Andrew I Do Imaging Free Medical Imaging Software Danielson, Jason, Garland, Eric e Holder, Andrew. dcm4che Architecture and Implementation. dcm4che.org DCM4CHEE Installation Instructions dcm4che.org Image Viewing dcm4che.org MAYAM - A Cross-platform DICOM Viewer

76 dcm4che.org Open Source Clinical Image and Object Management dcm4che.org Weasis dcmecho, dcm4che.org dcmecho EnterpriseDB The Enterprise PostgreSQL Company Huang, H K PACS and imaging informatics : basic principles and applications. [ed.] N J Hoboken. 2º. s.l. : Wiley-Liss, p institute, OFFIS computer science DCMTK - DICOM Toolkit JBoss Simple, modern, productive. The JBoss Way Library, DICOM DICOM Library Anonymize, Share, View DICOM Files Online M.D., Pablo Sau DCM4CHEE VIRTUAL MACHINE Medical Connections. NEMA. DICOM Digital Imaging and Communications in Medicine. NEMA DICOM Part 9, Point to Point Communication Support for Message Exchange NEMA Digital Imaging and Communications in Medicine (DICOM) NEMA MEMBERS of the DICOM STANDARDS COMMITTEE Nema, Medical Digital Imaging and Communications in Medicine (DICOM) Part 18: Web Access to DICOM Persistent Objects (WADO) TeraMedica TeraMedica The Vendor Neutral Archive Company Titani-Spirit Titani-Spirit Wetzel, Arthur W. Providing Novel Views of Visible Human Data for Anatomy Training. 50

77 Wikipedia Modalidades Dicom

78

79 A Formatos do ficheiro Dicom Na área da saúde as imagens sem informação não fazem sentido, precisa-se de informação relacionada com a imagem médica, como por exemplo nome do paciente, idade, tipo de Figura 27 - exemplo de um file Dicom exame, data de exame, toda a informação importante relacionada com a imagem. Toda esta informação agrupada ao Dicom File, ver Figura 27, (desde dados de nível médico, nível de exame e nível do paciente) é bastante útil para o médico fazer um bom diagnóstico [Bauermann, 2008]. Cada Dicom-file que poderá de extensão (.dcm ou. DICOM) só poderá conter uma instância de SOP, por outras palavras, um ficheiro Dicom só pode ter um paciente por ficheiro não podendo também misturar modalidades de exames. Como se pode ver na Figura 27, o ficheiro Dicom pode ser dividido em dois grandes grupos: Cabeçalho, sendo este dividido em três partes, um preâmbulo, sequência de caracteres e um conjunto de Meta dados. Imagem propriamente dita, que pode ser acedida através de 1

80 comandos de serviços ou a um nível mais baixo, através de combinação de várias tags, possibilitando assim a reconstrução da imagem [NEMA]. 2

81 B Configuração do servidor Para configuração do servidor Dcm4chee em Windows 7 versão 32 bits, foi seguido o tutorial disponibilizado em [dcm4che.org, 2012]. Neste anexo serão assim demonstrados os passos que foram feitos para a montagem do servidor, com a base de dados PostgreSQL. B.1 Servidor dcm4chee no Windows Para se poder continuar a instalação é necessário fazer download do seguinte software: JDK (configurar variáveis de ambiente); PostgreSQL [EnterpriseDB, 2012], o servidor de aplicações JBoos [JBoss, 2012], e o mais importante o dcm4chee [dcm4che.org, 2012]. E além destes é instalado um módulo Audit Record Repository (ARR), [dcm4che.org, 2012] que permite a auditoria das operações realizadas. Estrutura de pastas Despois de feito o download de todo o software é necessário descomprimi-lo para uma pasta, por exemplo C\dicom\, como se pode ver na Figura 28 3

82 Figura 28- Estrutura das pastas. Criação da Base de Dados A criação da BD pode ser feita através do comando: >createdb U postgres pacsdb, este comando tem que ser executado debaixo do caminho : PostgresSQL\8.4\bin\ ver Figura 29. Figura 29- Criar BD. A criação das tabelas da BD está disponível no ficheiro create.psql, que se encontra na pasta sql, na raiz de instalação do dcm4chee. No mesmo caminho PostgresSQL\8.4\bin\ executa-se o comando psql que leva como parâmetros o nome da BD, pacsdb, e o ficheiro que contém o script. Fica portanto assim: psql -d pacsdb -U postgres -f C:\dicom\dcm4chee psql\sql\create.psql ver Figura 30. Figura 30- Criação das tabelas. A seguir é necessário construir a BD do ARR, com o nome arrdb. É executado então o comando createdb -U postgres arrdb, -- verfigura Figura 31- Criação da BD do ARR.

83 De seguida executar o comando psql ficando: psql -d arrdb -U postgres -f C:\dicom\dcm4chee-arr psql\sql\dcm4chee-arr-sql.ddl ver Figura 32. Figura 32 - Criação das Tabelas. Para que o ARR e o dcm4chee tenham acesso às bases de dados é preciso dar permissões de acesso a este, para isso altera-se o ficheiro pg_hba.conf, que está no C:\Program Files\PostgreSQL\8.4\data. As mudanças necessárias resumem-se à adição de duas linhas, como se pode ver na Figura 33. Figura 33 - Alterações para ter-se permissão às BD. O próximo passo é a execução do script install_jboss.bat, que está na pasta bin da raiz, aceitando como parâmetros a raiz de instalação do JBoss. Assim o comando fica: install_jboss C:\dicom\jboss GA, ver Figura 34. Figura 34- Comando que liga dcm4chee com JBoss. Por fim executar a script que vai interligar o dcm4chee com ARR, executando o script install_arr.bat que esta na pasta bin da raiz de instalação do dcm4chee, o comando fica com este aparência, ver Figura 35 5

84 Figura 35- Comando que interliga dcm4chee com ARR A instalação fica concluída com este último comando. Para se ter a certeza que o servidor ficou a funcionar correctamente, introduz-se o URL no browser, com o login admin e password admin ver Figura 36. Se o servidor for bem instalado vai abrir o visualizador Web ver Figura 37. Figura 36 Autenticação na Interface Web. Figura 37 - Interface Web Existe também opção de poder executar o servidor dcm4chee como serviço ao iniciar o Windows, mas no âmbito do projecto não será necessário. 6

85 C Configuração do servidor C.1 Entidade de Aplicação Umas das inquietações quando se toca no assunto de comunicações, é como as aplicações podem interligar-se umas com as outras. No Dicom, mesmo antes de serem acordadas regras e combinadas instâncias SOP, a resolução passa inicialmente por Entidades de Aplicação AE: por exemplo, numa rede, os equipamentos conhecem-se uns aos outros, no standard Dicom é oferecida essa escolha através Entidades de Aplicação - (AE Application Entities). As AEs disponibilizam funções que permitem estabelecer conexões e transferir as informações, para isso a AE possui um Application Title que é usado no estabelecimento da comunicação. Por outras palavras, numa rede real um Application Title é um endereço onde o formato varia dependendo do protocolo utilizado. Habitualmente a maioria das aplicações Dicom usam TCP/IP, desta maneira o endereço é mapeado para um socket TCP/IP; no caso de ser utilizado um protocolo de rede do tipo OSI, o endereço é mapeado num PSAP. C.2 Contexto de aplicação Numa ligação entre dois AEs, o contexto de aplicação dos dois AEs é identificado pelo seu UID (identificador no standard Dicom). Este UID é transferido para o outro AE e neste caso, o AE receptor, decide se é capaz de manipular o pedido. De seguida responde ao AE inicial, com a capacidade de aceitação da associação, ou não, desse pedido. O standard Dicom utiliza por defeito o UID de contexto de aplicação com o valor Concluindo, este processo de comunicação além de ajustar o tipo de serviço, também negoceia a sintaxe de transmissão (podendo ser sintaxe por padrão ou uma sintaxe específica 7

86 de compressão do tipo JPEG, que possibilita a transmissão da informação num menor período de tempo). Através do documento Dicom Conformance Statement é possível saber se cada equipamento suporta as funcionalidades que vão sendo requisitadas, assim determina-se de imediato se os equipamentos são compatíveis ou não. Só depois dos processos acima terem sido terminados é que se tem conhecimento das condições, limitações e capacidades de cada AE, e só assim se pode seguir para a transferência de informação. Com o conceito SOP é possível poupar em quantidade mensagens trocadas, libertando a comunicação, pois é enviado um só pacote com comando/acção e a informação. 8

87 D Classes de Serviço SOP Como já foi indicado, os equipamentos podem variar entre servidores (CSP) e clientes (SPU). O papel do SOP é descrever o procedimento de cada um desses equipamentos, ex.: guardar diferentes tipos de imagem; sendo os serviços realizados à custa de grupos de serviço. Quando dois equipamentos entram em negociação, é combinado um uso de uma classe SOP, onde estes dois equipamentos devem se assegurar que cumprem os papéis já definidos no Presentations Contexts, explicado na secção Comunicação. Assim antes do início de transferência de dados a identificação do SOP deve ser conhecida. A relação que define abstractamente o SOP pode ser definida da seguinte maneira: SOP = DADOS + ACÇÃO Então, quando existe uma acção sobre IODs, considera-se que a acção é definida pelo SOP, onde os dados podem compreender informação do paciente ou dos exames e a acção pode, por exemplo, variar entre enviar ou receber informações dos AE. SOPs são identificadas recorrendo a UIDs (conceito de identificador em Dicom), visível na Figura 38. Depois de se possuir o SOP Class UID basta fazer-se um enquadramento na tabela Media Sorage Standard para perceber qual o melhor tipo de SOP com que se está lidar. Figura 38 Identificar SOP através da correspondência do UID na tabela Media Storage 9

88 E Lista de Dados Esta lista de dados basicamente é um modo de organização dos dados nos atributos, como se pode ver na Figura 39. Para cada atributo encontram-se muitos dados, estes dados estão contidos numa lista denominada em Dicom como Data Set. Relembrando, as definições já descritas, um Atributo é constituído por: Tag -par ordenado de 16 bits o <Grupo><Elemento> VR - 16 bits char o 2 caracteres de conjunto por omissão do Dicom Value lengh - Unsigned Int o Número de bytes do Value Field Value field - número par de bytes o Contém o valor propriamente dito Figura 39 - Elemento de dados 10

89 F Instruções básicas Depois de interiorizados todos os conceitos necessários, será demonstrado como se procedeu à implementação dos serviços definidos para o desenvolvimento do Visualizador. Nesta secção, vão assim ser explicados excertos de código fundamentais. Antes de se passar para o estabelecimento da comunicação com o servidor, foram realizados testes com o objectivo de se tentar perceber quais seriam as bibliotecas necessárias do toolkit para se trabalhar com os Objectos Dicom. Para criar um objecto Dicom simples, é necessário uma das seguintes instruções, recorde-se a secção BasicDicomObject dcm = new BasicDicomObject();// Instanciando com o Objecto padrão dicom ou BasicDicomObject dcm = new BasicDicomObject(DicomObject);//Sendo um objecto Dicom, como já visto, um conjunto de dados e de linhas de elementos A classe DicomObject possibilita a manipulação dos seus elementos, como é demonstrado no código em baixo. dcm.putnull(tag, VR); // adicionar um item vazio dcm.putxpto(tag, VR, XPTO); // XPTO= string byte [], int, float, data dcm.add(dicomelement); // XPTO= string byte [], int, float, data Iterator<DicomElement> iterator();//para poder ter acesso novamente a leitura dcm.get(tag); //pretender o conteúdo determinado Tag Para se poder ler a partir de um ficheiro Dicom, é necessária utilizar a classe DicomObject. Para isto é necessário chamar o método readdicomobject(). 1. DicomInputStream dis = new DicomInputStream(new File("DICOM.dcm")); 2. DicomObject dio = dis.readdicomobject(); 3. dis.close(); 11

90 Para se escrever num ficheiro Dicom, é necessário abrir um output stream para guardar o Dicom dataset, como é demonstrado no código seguinte. 1. FileOutputStream fos = new FileOutputStream(new File("file.dcm")); 2. BufferedOutputStream bos = new BufferedOutputStream(fos); 3. DicomOutputStream dos = new DicomOutputStream(bos); 4. dos.writedicomfile(dicom); 5. dos.close(); Apresentados os conceitos básicos de manipulação do Dicom, de seguida descreve-se todo o processo dos serviços que foram implementados no visualizador desenvolvido. 12

91 G Verificar estado da ligação Antes de ser feita qualquer troca de dados com o servidor, é aconselhável fazer-se um ping ao servidor, relembre-se a secção referente aos serviços Dicom em 3.7. Embora exista a opção de efectuar a verificação, utilizando o serviço disponibilizado no dcm4che (numa ferramenta integrada no toolkit) [dcmecho, 2006], achou-se conveniente desenvolver esta opção no próprio visualizador. O código exibido a seguir mostra a simplicidade deste processo, sendo este o serviço mais simples existente na toolkit Dcm4che. 1. decho = new DcmEcho("DCMECHO"); 2. decho.setlocalhost("localhost"); 3. decho.setcalledaet("dcm4chee", false); 4. decho.setremotehost("localhost"); 5. decho.setremoteport(11112); 6. decho.open(); 7. decho.echo(); 8. decho.close(); Neste bloco de código, e como em qualquer um que comunique com o servidor, terá que ser feita a configuração da conexão ao servidor. Definir o IP correspondente ao servidor: setlocalhost("localhost"); Definir a Entidade de Aplicação: setcalledaet("dcm4chee", false); Definir a porta do servidor: setremoteport(11112); Nos exemplos de código indicados no seguinte deste relatório estas linhas de código não serão novamente explicadas. 13

92 H Simular equipamento de imagiologia médica Não existindo um equipamento de imagiologia médica, foi realizada uma simulação virtual do mesmo, reveja-se a Aquisição na secção PACS. Esta simulação foi realizada utilizando-se, por exemplo, um serviço do toolkit Dcm4chee DCMSND ou alternativamente, através do software TIANI DICOM Modality Workstation SCU [Titani-Spirit, 2012]. Como seria de esperar, será implementado, no visualizador, uma versão idêntica ao serviço disponibilizado nas bibliotecas do toolkit Dcm4chee DCMSND. Assim, só serão implementadas as funcionalidades que sejam realmente utilizadas segundo a abordagem definida, permitindo assim excluir muitas funcionalidades do dcmsnd, que não serão utilizadas nesta abordagem. No código apresentado a seguir, depois de criado um novo objecto DcmSnd, é configurada a conexão ao servidor; posteriormente é adicionado um novo ficheiro (a ser enviado) á instância do DcmSnd ; e mesmo antes de se estabelecer a conexão e enviar o ficheiro é obrigatório chamar o método de configuração de transmissão (linha 5), que é usualmente a causa de muitos problemas neste serviço, devido a falha na sua configuração por parte dos desenvolvedores. 1. DcmSnd ds = new DcmSnd(); 2....//definir ip, port, Aet do servitor 3. ds.addfile(new File("dicomFile1")); 4. if(ds.getnumberoffilestosend() > 0){ 5. ds.configuretransfercapability(); // configuração de transmissão 6. ds.open(); // estabelecer conexão com servidor 7. ds.send(); // enviar os dados 8. ds.close(); // fechar conexão 14

93 Após serem enviadas imagens para o servidor, podemos prosseguir com a explicação dos outros serviços implementados, que sem quaisquer dados no servidor não faziam sentido. 15

94 I Pesquiza e Aquisição Reveja-se a secção referente ao serviço de pesquisas 3.7. Antes de se avançar na aquisição das imagens é necessário fazer pesquisas no servidor, de modo a descobrir qual o utente e exames desejados. Por outras palavras, antes de se mover e guardar imagens (C-Move/C-Store), é necessário utilizar o comando C-FIND. A um pedido do (C-FIND-RQ) vem uma resposta (C-FIND-RSP). O comando C-FIND-RQ tem um conjunto de atributos que podem ter dois significados diferentes dependem do seu valor de resposta: os atributos de um C-FIND-RQ, que não possuam dados (ou seja que contenham strings vazias), são chamados de returnig keys, sendo estes os campos que devem ser retornados com informação; por outro lado, C-FIND-RQ com atributos possuindo valores diferentes de vazio, são chamados de matching keys. Podemos comparar o matching keys ao Select na sintaxe SQL, onde são obtidas somente as informações que tenham o valor do conteúdo correspondente ao do matching keys. Podemos constatar a semelhança entre um C-FIND-RQ e o Select do SQL na Figura 40. Figura 40- Semelhança entre um C-FIND e um Select Como dito em cima, a resposta é feita através do C-FIND-RSP. O processo é idêntico ao C- FIND-RQ, só que agora os campos contêm a informação que foi requisitada. O conteúdo deste comando é de todo semelhante ao C-FIND-RQ com a diferença de que, os campos vazios estão agora preenchidos com os resultados encontrados pelo servidor. O uso de comandos C-GET e C-MOVE já foi amplamente mencionado neste relatório, mas só agora se fará uma explicação da sua implementação. Porém, para se referirem estes comandos 16

95 é necessário fazer-se também menção às queries, pois esses comandos necessitam de ter os dados provenientes das queries sendo neles que irão actuar. Por exemplo, as queries irão receber os dados correspondentes a um determinado Paciente Dicom, em que posteriormente irá ser adquirido o ficheiro Dicom que lhe corresponde, através do C-GET, ou do C-MOVE. 1. DcmQR dcmqr = new DcmQR(); 2....//definir ip, port, Aet do servitor 3. String[] ts = { UID.JPEGBaseline1 }; 4. dcmqr.addstoretransfercapability(uid.vlmicroscopicimagestorage, ts); 5. dcmqr.setquerylevel(level.patient); 6. dcmqr.addmatchingkey(tag.totagpath("patientid"), "TIAGO12323"); 7. dcmqr.addmatchingkey(tag.totagpath("patientname"), "Tiago"); 8....// 9. dcmqr.setcget(true); Em relação ao código acima, antes de se fazerem as queries, é necessário indicar o tipo Sintaxe de Transferência (TS), visível na linha 3 do código. Definida a Sintaxe de Transferência (TS), é necessário indicar o SOPClassUID, linha 4, primeiro parâmetro do. Depois de definidos a TS e o SOPClassUID, estes serão passados como parâmetros no método addstoretransfercapability, ver linha 4 no código acima. Criando assim o Presentation Context que é trocado durante a configuração, veja-se o Anexo B.2 - Contexto de aplicação. Na linha 5 do código, é definido o nível ao qual as queries irão ser feitas, podendo variar entre os níveis do tipo Patient, Study ou Series. Após a anterior definição dos parâmetros para configuração da conexão ao servidor, bem como definição dos tipos de sintaxe a serem transferidos, procede-se à criação das queries propriamente ditas. Nas linhas 6 e 7 do código anterior, é possível constatar que vão ser feitas queries à entidade Paciente havendo um Select ao PatientID = TIAGO12323; PatientName = Tiago. 10. dcmqr.setstoredestination("c:\\destino"); // 17

96 12. dcmqr.setmovedest("dcm4chee_2"); 13. dcmqr.setcalling("dcm4chee_2"); 14. dcmqr.setlocalport(11113); 15. dcmqr.setlocalhost("localhost"); // 17. dcmqr.start(); // 19. dcmqr.open(); 20. List<DicomObject> obj = dcmqr.query(); // 22. dcmqr.move(obj); 23. //***** OU 24. dcmqr.get(obj); // 26. dcmqr.close(); 27. dcmqr.stop(); No excerto de código acima, encontra-se bastante informação omitida, para facilitar na compreensão do código, só são indicadas as linhas principais para a implementação da pesquisa e aquisição de imagens. Feita a configuração do servidor e implementadas as queries, prossegue-se, no caso do C- GET, com a indicação de onde irá ser o destino de armazenamento de um objecto Dicom; no caso do C-MOVE o destino é substituído pelo que está declarado nas linhas 12,13,14,15, visto que no C-MOVE, o armazenamento de destino poderá ser a Base de Dados do mesmo Pacs ou não, (nesta implementação o servidor é o mesmo, mas com a porta, e a AE diferentes). Seguindo para a linha 20, pode ser visto que o conteúdo das queries é adicionado a uma lista de objecto Dicom, prosseguindo para Get ou Move dessa lista de objectos Dicom. Após aquisição desses objectos Dicom, pode-se passar à leitura destes através de alguns dos comandos indicados na secção inicial 18

97 19

98 J Configuração do servidor Por exemplo, dependendo do tipo de VR (tipo de codificação explicado no capítulo anterior), cada AE irá ter o seu tipo de sintaxe de transferência. Desta forma, como se pode ver na Figura 47, duas entidades de aplicação - AE, podem acertar um conjunto de métodos de codificação suportados por ambas. Quando a AE receptora não suporta alguma das sintaxes de transmissão, os pedidos são rejeitados. No momento em que são negociadas as Associações para a transferência de informação, a sintaxe de transferência vai contida no contexto de apresentação. Estas sintaxes são utilizadas quando pretendemos incluir uma imagem comprimida numa mensagem Dicom (usando codificações específicas para pixels), onde cada tipo de conversão tem um UID associado. Por exemplo o Dicom define por defeito a sintaxe de transferência Implicit VR Little Endian, que é suportada por qualquer aplicação. Esta sintaxe tem por UID de sintaxe de transferência o valor

99 Nas seguintes referências 4 é possível encontrar vários tipos de variantes de sintaxe de transferência, bem como a norma 5 do Dicom que tem informação útil de consulta. Figura 41 - Esquema de Associação 4 [5, 2004]; [Library, 2012] 21

100 K Diagramas Representativos Nesta secção irão ser exibidos os Diagramas de Classes que resultam do desenvolvimento da aplicação Visand. Os diagramas foram gerados através do software [Altova, 2012]. Na, está representado o diagrama de classes que compõe toda a arquitectura da aplicação utilizada, podendo-se ver os packages, classes, relações e dependências. Posteriormente, será visualizado em mais pormenor, cada uma das classes representadas neste digrama. Figura 42 - Diagrama da Aplicação desenvolvida Visand Na, é possível visualizar os packages resultantes da implementação e desenvolvimento do Visand. 22

101 Figura 43 - Packages provenientes do Visand Em relação ao package gui este engloba as seguintes classes, ver. Neste package estão todas as classes que dizem respeito à interface, proporcionando assim um nível de abstracção e facilidade de uso das janelas, controlos etc., onde cada classe contém os seus métodos respectivos. Figura 44 - Conteúdo do package gui Seguindo o encadeamento, no package dao, na estratégia de implementação optou-se por usar singleton, permitindo assim haver um pouco mais de controlo ao instanciar-se várias cópias do objecto. Por outras palavras, ter-se-á uma classe que só tem uma instância de cada vez, ver, onde se pode observar os métodos incluídos. Pode-se reparar que na VisandFactory implementa-se também um conceito de Factory, permitindo assim, também, adiar as instâncias para VisandDicomFactory. Com esta estratégia e separação de noções alcança-se um comportamento consistente e centralizado. 23

102 Figura 45 - Conteúdo do package dao No package dicom está definida a implementação crucial referente ao standard Dicom propriamente dito, aqui empregando-se algumas das partes dos excertos de implementação presentes nas secções, 1.1 ver. Figura 46 - Conteúdo do package Dicom Por último, no package entities, estão todas as classes com os construtores respectivos de forma gerar o modelo Dicom, pode-se observar que contém uma estrutura hierática idêntica à do Dicom ver. Figura 47 - Conteúdo do package entities 24