Visualizador de Imagiologia Médica

Visualizador de Imagiologia Médica
Fábio Tiago Martins Rodrigues Nº19131
Trabalho realizado sob a orientação de
Rui Pedro Lopes
Engenharia Informática
2011/2012
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
A Escola Superior de Tecnologia e Gestão não se responsabiliza pelas opiniões expressas
neste relatório.
iv
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
Aceite para avaliação da UC de Projecto
vii
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
ix
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
xi
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
xiii
Conteúdo
1
Introdução .......................................................................................................................... 1
1.1
Objectivos e Enquadramento ........................................................................................ 2
1.2
Estrutura ........................................................................................................................ 3
2
Imagiologia Médica ........................................................................................................... 6
2.1
3
Futuro da imagiologia médica ...................................................................................... 9
DICOM ............................................................................................................................. 10
3.1
Introdução ao Dicom................................................................................................... 10
3.1.1
PACS .................................................................................................................... 10
3.1.2
Tipos de Modelos da arquitectura ........................................................................ 11
3.1.3
DICOM com PACS .............................................................................................. 12
3.2
Modelo Dicom ............................................................................................................ 13
3.3
História do Dicom ....................................................................................................... 15
3.4
DICOM Standard ........................................................................................................ 17
3.5
Partes DICOM ............................................................................................................ 17
3.6
Definição dos Objectos de Informação ....................................................................... 20
3.7
Serviços ....................................................................................................................... 23
3.8
Comunicação............................................................................................................... 25
3.9
Comunicação usando serviços Dicom ........................................................................ 26
xiv
4
5
6
3.10
Imagem .................................................................................................................... 28
3.11
WADO – Acesso Web de persistência de objectos Dicom ..................................... 29
3.12
Considerações .......................................................................................................... 30
Desenvolvimento .............................................................................................................. 32
4.1
Estado da arte .............................................................................................................. 32
4.2
Dcm4che – toolkit utilizado ........................................................................................ 34
4.2.1
Arquitectura .......................................................................................................... 35
4.2.2
Serviço WADO .................................................................................................... 36
Implementação ................................................................................................................. 38
5.1
Arquitectura utilizada no desenvolvimento do projecto Visand ................................. 39
5.2
Instalação do Servidor, simulando Pacs...................................................................... 40
5.3
Interface ...................................................................................................................... 41
Conclusões ........................................................................................................................ 46
6.1
Discussão e Limitações ............................................................................................... 46
6.2
Trabalhos Futuros ....................................................................................................... 47
Bibliografia ............................................................................................................................. 49
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 ................................................................................................... 7
15
D Classes de Serviço SOP ..................................................................................................... 9
E
Lista de Dados .................................................................................................................. 10
F
Instruções básicas ............................................................................................................ 11
G
Verificar estado da ligação .......................................................................................... 13
H
Simular equipamento de imagiologia médica ............................................................ 14
I
Pesquiza e Aquisição ....................................................................................................... 16
J
Configuração do servidor ............................................................................................... 20
K
Diagramas Representativos ......................................................................................... 22
16
xvii
Lista de Tabelas
Tabela 1- Partes Dicom ............................................................................................................ 18
Tabela 2 - N-commands ........................................................................................................... 24
Tabela 3 - C-commands ........................................................................................................... 24
Tabela 4- Tabela de comparação entre os toolkits ................................................................... 33
xviii
xix
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 .............................................................................................. 11
Figura 6 – Hierarquia de informação Dicom ........................................................................... 13
Figura 7 - Dados reais para IOD .............................................................................................. 14
Figura 8 - Serviço Dicom ......................................................................................................... 14
Figura 9- IODs Normalizadas ou Compostas .......................................................................... 21
Figura 10 - Exemplo de um Módulo de um IOD & Atributos ................................................. 22
Figura 11 - Correspondia ao Dicionário de Dados ................................................................... 22
Figura 12 - Processo de Transmissão de imagens .................................................................... 26
Figura 13 - Transmissão de imagens de um equipamento de CR para uma Workstation........ 26
Figura 14 - Envio de Dados (imagens) de um CT para um servidor Dicom ............................ 27
Figura 15- Pesquisa de Dados (imagens) num servidor Dicom ............................................... 28
Figura 16- Arquitectura da aquisição da imagem .................................................................... 29
Figura 17- Abordagem usando Wado ...................................................................................... 30
xx
Figura 18- Diagrama Dcm4che [Danielson, et al.]. ................................................................. 35
Figura 20 - Servidor Web ......................................................................................................... 37
Figura 21 - Arquitectura utilizada no desenvolvimento do projecto ........................................ 40
Figura 23 – Interface do Visualizado e sua ordem de utilização. ............................................ 42
Figura 24- Primeira configuração. ........................................................................................... 42
Figura 25- Escolha dos estudos, series e imagens. ................................................................... 43
Figura 26 - Janela das listagens das imagens e as imagens visualizadas. ................................ 44
Figura 34 - exemplo de um file Dicom ...................................................................................... 1
Figura 35- Estrutura das pastas. ................................................................................................. 4
Figura 36- Criar BD. .................................................................................................................. 4
Figura 37- Criação das tabelas. .................................................................................................. 4
Figura 38- Criação da BD do ARR. ........................................................................................... 4
Figura 39 - Criação das Tabelas. ................................................................................................ 5
Figura 40 - Alterações para ter-se permissão às BD. ................................................................. 5
Figura 41- Comando que liga dcm4chee com JBoss. ................................................................ 5
Figura 42- Comando que interliga dcm4chee com ARR ........................................................... 6
Figura 43 – Autenticação na Interface Web. .............................................................................. 6
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 ................................................................................................. 10
Figura 22- Semelhança entre um C-FIND e um Select ............................................................ 16
21
Figura 47 - Esquema de Associação ........................................................................................ 21
Figura 27 - Diagrama da Aplicação desenvolvida Visand ....................................................... 22
Figura 28 - Packages provenientes do Visand ......................................................................... 23
Figura 29 - Conteúdo do package gui ...................................................................................... 23
Figura 30 - Conteúdo do package dao ...................................................................................... 24
Figura 31 - Conteúdo do package Dicom................................................................................. 24
Figura 32 - Conteúdo do package entities ................................................................................ 24
22
xxiii
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
xxv
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
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
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
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
5
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
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
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
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
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.
3.1.1 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
 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.
3.1.2 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
 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).
3.1.3 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
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á
Figura 6 – Hierarquia de informação Dicom
atributos a ele relacionado. Por exemplo, um IOD de um Paciente terá atributos do tipo nome,
idade, sexo, etc. ver .
13
.
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
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
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 300-1985 que teve
direito a duas versões, primeira versão em Outubro 1986 e a segunda versão em Janeiro 1988.
Neste mesmo ano, 1988, foi publicada a versão DICOM 2.0 ou ACR-NEMA 300-1988. 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
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
http://medical.nema.org/standard.html 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
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 sites1
Tabela 1- Partes Dicom
Parte
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
Titulo
Introdução e visão geral
Conformidade
Definição dos objectos de informação (IOD)
Especificações das classes de serviços
Estrutura de dados e codificação
Dicionário de dados
Troca de mensagem
Suporte á comunicação em rede para troca de mensagem
Especificações de interferência ponto a ponto - removido a partir da versão Dicom 3.0
Armazenamento multimédia e formato de ficheiro para troca de dados
Perfis de aplicações de armazenamento em multimédia
Formato de multimédia e formatos físicos para troca de dados
Gestão de impressão ponto a ponto - removido a partir da versão Dicom 3.0
Função de apresentação do standard em escala de cinzas
Perfis de gestão de segurança e de sistema
Recurso de mapeamento de conteúdos - templates de elaboração de documentos, glossário de
termos e traduções;
Informação explicativa - informação redundante, anexos informativos;
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
1
http://www.dclunie.com/dicom-status/status.html; http://medical.nema.org/dicom/2004.html
18
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
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
É 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
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
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 3.6 -- 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
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
C-Echo, este serviço de verificação é idêntico ao utilitário ping2. 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
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
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
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
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
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
31
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
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 (AAssociate, 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
Documentação
Manutenção
Sistema Operativo
Dicom Serviços
DICOM IOD (modalidades
suportadas)
Linguagem
Interface
Formato de entrada
Formato de saída
Dcm4chee
Insuficiente
Elevada
Dcmtk
Compreensiva
Elevada
Bibliotecas,
Cliente PACS,
Servidor,
Utilitários
US, CT, MR,
SC, DX, XA, VL,
RT
Java, XML
Linha de
Comandos,
Bibliotecas
DICOM
DICOM, JPEG
Bibliotecas, Cliente
PACS, Servidor,
Visualizadores
US, CT, MR, SC,
DX, XA, VL, RT
C, C++
Linha de Comandos,
Bibliotecas
DICOM, Own/Unique
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
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
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
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
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
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, CGet, 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
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
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
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 repositor3- 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-EstudosSeries-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
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.
Figura 23- Primeira configuração.
42
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 25.
43
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
45
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
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
Figura 26 - Arquitectura duma abordagem futura
48
Bibliografia
5, NEMA Part. 2004. Digital Imaging and Communications in Medicine (DICOM) Part 5:
Data Structures and Encoding. 2004.
A, Vázquez, et al. 2006. Evaluation of Open Source DICOM Frameworks . 2006.
AGFA. 2012. AGFA HealthCare. 2012.
Alliance, Medical Imaging & Technology. 2012. The DICOM Standard. 2012.
Altova. 2012. Altova UModel 2012 Enterprise Edition. 2012.
Bauermann, Gabriela. 2008. Formato de arquivos DICOM. 2008.
Botha, C. P., et al. 2012. From individual to population: Challenges in Medical
Visualization. 2012.
C, Costa, et al. 2009. Indexing and retrieving DICOM data in disperse and unstructured
archives. 2009. pp. 71-77.
Castigli, Martin M., et al. DICOM Comunicação de imagens digital em medicina.
Clunie, David A. 2012. DICOM Standard Status. 2012.
Connections., Medical. 2012. Basic DICOM Operations. 2012.
Crabb, Andrew. 2012. I Do Imaging Free Medical Imaging Software. 2012.
Danielson, Jason, Garland, Eric e Holder, Andrew. dcm4che Architecture and
Implementation.
dcm4che.org. 2012. DCM4CHEE 2.17.1 Installation Instructions. 2012.
dcm4che.org. 2007. Image Viewing. 2007.
dcm4che.org. 2012. MAYAM - A Cross-platform DICOM Viewer. 2012.
49
dcm4che.org. 2012. Open Source Clinical Image and Object Management. 2012.
dcm4che.org. 2012. Weasis . 2012.
dcmecho, dcm4che.org. 2006. dcmecho. 2006.
EnterpriseDB. 2012. The Enterprise PostgreSQL Company. 2012.
Huang, H K. 2004. PACS and imaging informatics : basic principles and applications. [ed.]
N J Hoboken. 2º. s.l. : Wiley-Liss, 2004. p. 648.
institute, OFFIS computer science. 2012. DCMTK - DICOM Toolkit. 2012.
JBoss. 2012. Simple, modern, productive. The JBoss Way. 2012.
Library, DICOM. 2012. DICOM Library Anonymize, Share, View DICOM Files Online.
2012.
M.D., Pablo Sau. 2012. DCM4CHEE VIRTUAL MACHINE. 2012.
Medical Connections.
NEMA. DICOM Digital Imaging and Communications in Medicine.
NEMA. 2004. DICOM Part 9, Point to Point Communication Support for Message
Exchange. 2004.
NEMA. 2004. Digital Imaging and Communications in Medicine (DICOM). 2004.
NEMA. 2012. MEMBERS of the DICOM STANDARDS COMMITTEE. 2012.
Nema, Medical. 2011. Digital Imaging and Communications in Medicine (DICOM) Part 18:
Web Access to DICOM Persistent Objects (WADO). 2011.
TeraMedica. 2012. TeraMedica The Vendor Neutral Archive Company. 2012.
Titani-Spirit. 2012. Titani-Spirit. 2012.
Wetzel, Arthur W. Providing Novel Views of Visible Human Data for Anatomy Training.
50
Wikipedia. 2012. Modalidades Dicom. 2012.
51
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
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
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
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\dcm4chee2.17.0-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 31.
Figura 31- Criação da BD do ARR.
4
De seguida executar o comando “psql” ficando: “psql -d arrdb -U postgres -f
C:\dicom\dcm4chee-arr-3.0.11-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-4.2.3.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
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 “http://localhost:8080/dcm4chee-web” 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
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 ”2.840.10008.3.1.1.1”.
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
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
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
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
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 1.1 - .
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
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
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
H Simular
médica
equipamento
de
imagiologia
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 3.1.1 - 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
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
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 CFIND-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
é 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");
11. . . .//
17
12. dcmqr.setMoveDest("DCM4CHEE_2");
13. dcmqr.setCalling("DCM4CHEE_2");
14. dcmqr.setLocalPort(11113);
15. dcmqr.setLocalHost("localhost");
16. . . .//
17. dcmqr.start();
18. . . .//
19. dcmqr.open();
20. List<DicomObject> obj = dcmqr.query();
21. . . .//
22. dcmqr.move(obj);
23. //***** OU
24. dcmqr.get(obj);
25. . . .//
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 CGET, 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
19
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 1.2.840.10008.1.2
20
Nas seguintes referências4 é 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
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
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
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