UNIVERSIDADE FEDERAL DE LAVRAS

Uma sugesto para o desenvolvimento de software baseado no

protocolo DICOM: Caso Invesalius

SAULO ALDIGHIERI MORAES

LAVRAS
MINAS GERAIS BRASIL
2008

SAULO ALDIGHIERI MORAES

Uma sugesto para o desenvolvimento de software baseado no

protocolo DICOM: Caso Invesalius

Monografia apresentada ao Departamento de Cincia da Computao

da Universidade Federal de Lavras, como parte das exigncias do
curso de Ps-Graduao Lato Sensu em Produo de Software Livre,
para a obteno do ttulo de especializao.

Orientadora
Professora ngela Maria Alves

LAVRAS
MINAS GERAIS BRASIL
2008

SAULO ALDIGHIERI MORAES

Uma sugesto para o desenvolvimento de software baseado no

protocolo DICOM: Caso Invesalius

Monografia apresentada ao Departamento de Cincia da Computao

da Universidade Federal de Lavras, como parte das exigncias do
curso de Ps-Graduao Lato Sensu em Produo de Software Livre,
para a obteno do ttulo de especializao.

APROVADA em ____ de ___________ de _____.

Prof. ________________________________
Prof. ________________________________

Prof. ______________________________________
UFLA
(Orientador)

LAVRAS
MINAS GERAIS BRASIL
2008

Dedico este trabalho a todos que

colaboram com o software InVesalius,
direta ou indiretamente.

AGRADECIMENTOS

Primeiramente agradeo Deus pela oportunidade de fazer este trabalho.

A professora ngela Maria Alves que nos direcionou corretamente para
iniciarmos todo esse trabalho.
Agradeo aos meus amigos Antnio, Fernando, Flvio e Sandro pela vontade
e pacincia que demonstraram nesse projeto.
E agradeo a Simone, minha namorada, que me ajudou e incentivou a concluir
este trabalho.

SUMRIO
LISTA DE FIGURAS........................................................................................................1
LISTA DE TABELAS.......................................................................................................2
1. INTRODUO............................................................................................................. 4
2. InVesalius...................................................................................................................... 5
3. DICOM.......................................................................................................................... 6
3.1 Histria.................................................................................................................... 6
3.2 Definio..................................................................................................................7
3.3 Picture Archiving and Communications Systems (PACS)....................................10
4 Modelos de Interface de Comunicao para o InVesalius.........................................11
4.1 A proposta do projeto............................................................................................ 11
4.2 Modelos de Interface de Comunicao para o InVesalius.........................................13
4.2.1.1 UCDMC...................................................................................................14
4.2.1.2 pydicomlib............................................................................................... 14
4.2.1.3 dcmtk....................................................................................................... 14
4.2.1.4 openDICOM.NET................................................................................... 15
4.2.1.5 Charrua DICOM Toolkit ........................................................................ 15
4.2.1.6 DCF (DICOM Connectivity Framework)................................................15
4.2.1.7 Imebra...................................................................................................... 16
4.2.1.8 Lista de Referncia.................................................................................. 16
4.3 Implementar a comunicao do protocolo DICOM usando socket....................... 17
4.4 Implementar a comunicao do protocolo DICOM usando Twisted Framework e
WADO.........................................................................................................................19
5 Arquitetura da Comunicao do InVesalius com a PACS........................................ 20
6 - Concluso................................................................................................................... 24
7. REFERNCIAS BIBLIOGRAFICAS ........................................................................25
ANEXOS......................................................................................................................... 26
ANEXO A Modalidades DICOM.................................................................................27
ANEXO B Documento de Estrias.............................................................................. 28
Desenvolvimento do Sistema de comunicao via Internet que possibilitar a
importao de dados para o software InVesalius.............................................................28
(Demanda de desenvolvimento do InVesalius: Software Pblico Brasileiro).................28
ANEXO C Cdigo fonte do A_Associate_RQ desenvolvido pelo CTI....................... 35

LISTA DE FIGURAS
Figura 1. Principais bibliotecas e ferramentas usadas no InVesalius................................ 5
Figura 2. Exemplo da estrutura de um arquivo DICOM................................................... 7
Figura 3 Composio do Service-Object Pair (SOP)....................................................10
Figura 4. Arquitetura de uma PACS................................................................................11
Figura 5. Wado Interface................................................................................................. 19
Figura 6. Estabelecimento de Comunicao A-Associate............................................... 20

LISTA DE TABELAS
Tabela 1 Exemplo de Classes de Servios......................................................................9
Tabela 2 Service-Object Pair UIDs.............................................................................. 10
Tabela 3 Lista de Frameworks e bibliotecas DICOM.................................................. 17

Sistema de importao de dados de clnicas radiolgicas para

o projeto InVesalius: Proposta Para a Interface De
Comunicao
Saulo Aldighieri Moraes
Departamento de Cincia e Computao Universidade Federal de Lavras (UFLA)
Caixa Postal 3142 37.200-000 Lavras MG Brasil
saulo@gmx.com

Abstract. This monograph examining proposals for the development of a

communication interface to be part of the project ponto DICOM allowing the
importation of data from clinical radiology to InVesalius. In addition to the
proposals is also exemplified how the code can be built.
Resumo. Esta monografia analisa propostas para o desenvolvimento da
interface de comunicao que ser parte do projeto ponto DICOM que
permitir a importao de dados de clnicas radiolgicas no InVesalius. Alm
das propostas tambm exemplificado como o cdigo pode ser construdo.

1. INTRODUO
Com o objetivo de desenvolver um projeto de software livre, reuniu-se uma equipe de
alunos da UFLA, atravs da professora orientadora ngela Maria Alves, para realizar
um contato com um dos responsveis pelo portal do Software Pblico Brasileiro (SPB),
Corinto Meffe. Uma lista de projetos que necessitavam de colaborao foi enviada para
a equipe e desta lista os alunos da UFLA escolheram o projeto InVesalius, um Software
Livre e Pblico, atualmente mantido pelo Centro de Tecnologia da Informao Renato
Archer, conhecido como CTI. Dentro das propostas do InVesalius, que um software
usado na visualizao de imagens mdicas, haviam trs demandas de desenvolvimento
da qual foi escolhido desenvolver um Sistema de Importao de Dados de Clnicas
Radiolgicas.
Neste cenrio o projeto se consiste em criar um mdulo para o InVesalius que
adicionar a funcionalidade de importar e exportar imagens de servidores PACS, que
so servidores que armazenam imagens mdicas.
A equipe foi formado por 4 alunos, onde cada um se encarregou de elaborar e
planejar uma parte do desenvolvimento, assim este trabalho parte de um conjunto de 4
monografias que visam ser um ponto de referncia para o desenvolvimento da camada
de comunicao do InVesalius. Neste trabalho descrito possveis maneiras de se
desenvolver o cdigo do protocolo de comunicao, utilizando bibliotecas e frameworks
disponveis no mercado. E nas outras monografias so discutidos o processo de
desenvolvimento XP, que ser utilizado para a criao deste software, a camada de
interface grfica com o usurio e tambm uma discusso sobre todos os softwares e
processo de configurao referente ao InVesalius e os servidores PACS.
Em 5 captulos abordada a base para o desenvolvimento, fazendo uma
descrio sobre o InVesalius, o protocolo DICOM, estrutura do arquivo e tipo de servio
e comunicao, bibliotecas livres e proprietrias que ajudam na implementao e a
propsta final.
O texto a seguir estruturado da seguinte forma:
Captulo 2, InVesalius, o objetivo apresentar o InVesalius fazendo uma
abordagem rpida dos seus conceitos e idias para uma compreenso melhor do
trabalho.
No Captulo 3, DICOM, o objetivo apresentar o DICOM, abordando sua
estrutura de funcionamento e as funcionalidades de comunicao em uma rede.
No Captulo 4, Modelos de Interface de Comunicao para o InVesalius, o
objetivo apresentar idias e ferramentas que possam ajudar na implementao de uma
interface de comunicao.
No Captulo 5, Arquitetura da Comunicao do InVesalius com a PACS, o
objetivo propor o modelo de comunicao que ser desenvolvido.
Finalmente no Captulo 6, Concluso, proposio final que se chega aps
desenvolvermos este projeto.

Proceedings of the XII SIBGRAPI (October 1999) 101-104

2. InVesalius
O InVesalius uma ferramenta que faz reconstruo 3D de imagens mdicas utilizando
imagens 2D, o que torna a prototipagem mais rpida, atualmente mantido pelo CTI
(antigo CENPRA), distribudo sob a licena GNU GPL v2 e est disponvel para
Microsoft Windows e Linux tanto na verso 1 como na verso 2.
O nome dado ao software InVesalius foi uma homenagem a Andreas Vesalius
(Bruxelas, 31 de Dezembro de 1514 - Zkinthos, 1564), um mdico belga considerado o
pai da anatomia moderna e autor da publicao De Humani Corporis Fbrica, um
famoso livro de anatomia publicado em 1543.
Hoje em dia h vrias ferramentas com o mesmo objetivo do InVesalius, como o
Analyze desenvolvido pelo Mayo Clinic e o Mimics desenvolvido pela Materialize. Mas
esses softwares possuem licena e manuteno muito caras o que os tornam inviveis
para os hospitais brasileiros.
Assim com o InVesalius, cirurgies e estudantes de medicina podem usar dados
de topgrafos e aparelhos de ressonncia magntica, que exportem para um formato
digital especfico de imagem, para fazerem pesquisa e prototipagem rpida em modelos
tridimensionais de craniofaciais por exemplo, facilitando assim o planejamento e
documentao do procedimentos cirrgicos sem gastos.
Para o desenvolvimento foi usado a linguagem Python devido a portabilidade,
usabilidade e a syntax simples que a linguagem oferece, apesar de perder em
performance para linguagens como C e C++. A figura abaixo mostra as bibliotecas
empregadas no desenvolvimento.

Figura 1. Principais bibliotecas e ferramentas usadas no InVesalius

Apesar do desenvolvimento se basear na linguagem Python, algumas

ferramentas C/C++ foram utilizadas o VTK e Slicer 3D. O VTK (Visualization ToolKit)
uma biblioteca que executa funes grficas orientado a objetos, escrito em C++ e
multi-plataforma, no InVesalius usado gerando-se um wrapper para Python.
O Slicer 3D usado, apesar de no existir um wrapper oficial para o Python 2.5,
foi realizado alteraes no cdigo original e foi gerado um wrapper do Slicer 3D junto
ao VTK, assim o Slicer 3D usado em funes como criao de "mscaras" sobre
imagens bidimensionais e para leitura de arquivos DICOM.
5

Para realizar as equaes matemticas, manupulao simples de dados das

imagens e operaes especficas do sistema foram usadas a NumPy, PIL (Python
Imaging Library) e pywin32, respectivamente.
O wxPython substituiu o Tkinter, a partir da verso 2 do InVesalius, e passou a
ser usado para gerar a interface grfica de interao com o usurio, a vantagem que o
wxPython, um wrapper do WxWidget a maior portabilidade e como o wxWidgets
utiliza um wrapper sobre a biblioteca grfica padro do sistema operacional (GTK no
Linux e MFC no Windows) a aplicao fica com a aparncia nativa (look and feel) do
Sistema Operacional.

3. DICOM
DICOM (Digital Imaging Communications in Medicine) um padro que define um
formato de arquivo de imagem e protocolo de comunicao em uma rede, usado para
tratamento, armazenamento, impresso e transmisso de informao mdica num
formato eletrnico.
Com este padro podemos trocar informaes entre os equipamentos de
diagnstico geradores de imagens, computadores e hospitais, criando se assim uma
linguagem comum entre os equipamentos de marcas diferentes, que geralmente no so
compatveis, e entre equipamentos de imagem e computadores, estejam esses em
hospitais, clnicas ou laboratrios.
O protocolo de comunicao padro utilizado para se comunicar com outros
sistemas o TCP/IP, assim arquivos DICOM podem ser trocados entre dois
dispositivos, atualmente o InVesalius utiliza apenas a especificao de definio de
imagem do DICOM, para a partir de vrias imagens em duas dimenses 2D criar
modelos tridimensionais.

3.1 Histria
At meados de 1980, cada fabricante de equipamentos mdicos tinha que criar o seu
prprio protocolo para troca de dados entre as mquinas mdicas e os computadores,
isso significa que a comunicao existia apenas entre produtos de mesmo fabricante. O
que gerava grandes custos e esforo para integrao de equipamentos de outros
fabricantes.
Para resolver este problema, em 1983 o ACR (American College of
Radiologists) e o NEMA (National Electrical Manufacturers Association) formaram um
comit, o ACR-NEMA Digital Imaging and Communications Standards Committee, com
o objetivo de desenvolver uma interface para comunicaes entre equipamentos de
imagem. Alm da especificao de um protocolo de comunicao, o novo padro
tambm deveria incluir uma especificao de armazenamento da imagem, incluindo
compactao.
Aps 2 anos de trabalho, em 1985, a primeira verso do padro foi lanada,
chamada de ACR-NEMA Version 1.0 (ou ACR-NEMA 300-1985), e a partir desta,
vrias melhorias foram sugeridas. Ento em 1988 a ACR-NEMA Version 2.0 (tambm
conhecida como ACR-NEMA 300-1988) foi lanada.
6

Com a verso 2 havia a definio de uma interface entre equipamentos de

imagem e a rede, mas os usurios queriam elementos para uma comunicao mais
robusta. Por exemplo, a verso 2 no foi projetada para conectar equipamentos
diretamente a uma rede, por isso o comit resolveu que verses futuras poderiam no ter
compatibilidade com as verses anteriores.
Em 1993 o ACR-NEMA DICOM (ou apenas DICOM 3.0) estava concludo.

3.2 Definio
Um arquivo DICOM contm cabealho e definies de imagem. O cabealho possui
informaes como nome do paciente, tipo de equipamento usado para gerar a imagem,
dimenses da imagem, etc. J as definies da imagem possuem informaes referentes
imagem em si.
Arquivos DICOM tambm permitem que as imagens sejam compactadas para
reduzir o tamanho, para melhorar o desempenho na transferncia em uma rede. Os tipos
de compresso usados podem ser as lossy (com perda de dados) ou lossless (sem perda
de dados) ambas variantes do formato JPEG.
No incio de cada arquivo, antes do cabealho, so definido dois valores: o
Prembulo, que so os primeiros 128 bytes do arquivo e geralmente no contm
informaes, pois so reservadas para comentrios, e em seguida temos o Prefixo, que
um espao que valida um arquivo como sendo um arquivo DICOM. Este possui 4 bytes
e deve ser preenchido com o valor D, I, C e M. Conforme ilustrado a imagem
abaixo:

Figura 2. Exemplo da estrutura de um arquivo DICOM

O Prembulo no tem nenhuma estrutura ou formato definido na especificao

do DICOM. Ele apenas definido para facilitar o acesso a imagens e outras informaes
7

em arquivos DICOM providos por diferentes fabricantes de ferramentas que geram

arquivos DICOM ou permitir acesso randmico, de algumas aplicaes multimdia, ao
contedo do arquivo de imagem por exemplo. Como o Prembulo requer nenhuma
informao obrigatria, caso ele no seja usado, o arquivo deve ter os primeiros 128
bytes com os valores 00 Hex.
No cabealho os campos presentes em um arquivo podem variar de um arquivo
para outro, por exemplo, considerando a figura XYZ temos um grupo 0008,0060 que
define a modalidade como MR. Cada grupo tem um valor especfico e uma funo
especfica e isso faz com que por exemplo um arquivo com modalidade diferente possa
ter campos diferentes.
Se por exemplo o arquivo tivesse um grupo (os 4 primeiros digitos) com o
nmero 0010 isso significaria que todos esses valores seriam referentes a informaes
dos pacientes, assim 0010,0010 seria referente ao Nome do Paciente por exemplo, a
especificao do DICOM define vrios grupos.
Outro grupo importante o 0002,0010 que define a 'Transfer Syntax Unique
Identification' esse valor se refere a como a imagem foi compactada, alguns exemplos
so:

1.2.840.10008.1.2.1 significa sem compreenso

1.2.840.10008.1.2.4.xx com xx sendo um valor entre 50 e 64 significa

compreeso Lossy JPEG

1.2.840.10008.1.2.4.xx com xx sendo um valor entre 65 e 70 significa

compreeso Lossless JPEG

Os grupos como os referenciados acima so chamados de Information Object

Definition (IOD) e como podemos ver, a quantidade de grupos e elementos nesses
grupos bem grande, por isso cada IOD possui um UID (Unique Identifier) que so os
valores como o 0002,0001, definido na figura 2 acima.
Como os IOD so divididos em grupos que so separados por tipo de
informaes, como informaes referentes a imagens, relatrios, pacientes, etc.. Esses
grupos dos IOD constituem a chamada Data Dictionary.
O objetivo dos IOD definir classes que descrevem objetos do mundo real com
suas caractersticas e funes, para isso h dois tipos de classes, a Normalizada que
possui informaes de um nico objeto do mundo real e a classe Composta que possui
informaes de mltiplos objetos do mundo real. Um exemplo de IOD da classe
Composta um arquivo originado de uma tomografia computadorizada (CT-image)
porque ele descreve informaes de estudo, sries e paciente.
O DICOM promove servios padronizados que so usados para comunicao em
rede, principalmente em comunicao com PACS. Esses servios so divididos em
classes Normalizadas e Compostas, como, na classe Composta h 5 DIMSE-C (DICOM
Message Service Elements - Compose) e para classe Normalizada h 6 DIMSE-N
(DICOM Message Service Elements - Normalized).
DIMSE-C Services:

C-ECHO: Servio usado para verificar a comunicao entre os pontos da

conexo.

C-FIND: Servio usado para fazer uma pesquisar por uma String

C-GET: Servio usado para buscar informaes em uma servidor DICOM

C-MOVE: Servio usado para mover dados dentro de uma base de dados

C-STORE: Servio usado para requisitar um armazenamento

DIMSE-N Services:

N-CREATE: Servio usado para criar uma instncia de um IOD

N-GET: Servio usado para buscar informaes de um outro servio

N-SET: Servio usado para modificar informaes de um outro servio

N-ACTION: Servio usado para buscar status de outro servio que j esteja em
uso

N-DELETE: Servio usado para apagar um IOD especfico

N-EVENT-REPORT: Servio usado para fazer um aviso quando um evento

acontecer.

Os DIMSE so separados por duas Classes de Servio distintas, o SCU (Service

Class User) e o SCP (Service Class Provider), a tabela abaixo mostrar um exemplo:
Nome
Storage SCU

Descrio
Dispositivo que usa o servio DICOM C-

Storage SCP

STORE
Dispositivo que prove o servio DICOM

Query SCU

C-STORE
Dispositivo que usa o servio DICOM CFIND

Tabela 1 Exemplo de Classes de Servios

O SCU e SCP se referem a um modelo cliente servidor, onde o cliente (SCU)

quem requisita o servio, podendo este ser at mesmo um servidor de imagem
requisitando algo.
No DICOM, esses servios DIMSE so combinados com os IODs para gerar os
Service-Object Pair (SOP). Isso significa que para se fazer o armazenamento de uma
imagem, por exemplo, necessrio que se tenha o IOD que ser o objeto a ser
armazenado e o servio a ser utilizado para o armazenamento. A figura abaixo
representa como o SOP formado:

Figura 3 Composio do Service-Object Pair (SOP)

Para cada DICOM SOP, tambm existe um Identificador nico (UID) e um

Nome, veja alguns exemplos na tabela abaixo:
Armazenamento (Storage Service Class)
SOP Class Name

UID

CR Image Storage

1.2.840.10008.5.1.4.1.1.1

CT Image Storage

1.2.840.10008.5.1.4.1.1.2

US Image Storage

1.2.840.10008.5.1.4.1.1.6

US Multi-frame Image Storage

1.2.840.10008.5.1.4.1.1.3

MR Image Storage

1.2.840.10008.5.1.4.1.1.4

Standalone Overlay Storage

1.2.840.10008.5.1.4.1.1.8
Query/Retrieve Service Class

Patient Root Find

1.2.840.10008.5.1.4.1.2.1.1

Patient Root Move

1.2.840.10008.5.1.4.1.2.1.2

Study Root Find

1.2.840.10008.5.1.4.1.2.2.1
Tabela 2 Service-Object Pair UIDs

3.3 Picture Archiving and Communications Systems (PACS)

PACS so computadores e redes dedicadas a armazenar imagens mdicas, onde o
formato mais usado DICOM, o uso de servidores para armazenar imagens mdicas
teve inicio com a Tomografia Computadorizada nos anos 70 e com o passar dos anos
outras modalidades diagnsticas (ver Anexo A para obter a lista completa de
modalidades suportadas no DICOM) tambm comearam a usar imagens
computadorizadas.
Como o preo de solues em armazenamento digital cada vez menor, o PACS
oferece menor custo a longo prazo, melhor forma de armazenamento se comparado a
imagens radiogrficas e permite um acesso rpido a imagens, o que possibilita
diagnsticos e estudos a distncia e diferentes instituies compartilhando e acessando
as mesmas informaes.
Os sistemas PACS hoje em dia so oferecidos s instituies de sade por
empresas especializadas na rea de desenvolvimento de solues mdicas, tais como
Carestream Health, Sectra, Siemens, General Electric, Philips, Fujifilm, Agfa, Pixeon,
Medilab, etc...
Mas ainda h algumas dificuldades nesta rea. A PACS, por exemplo, precisa
interpretar um arquivo DICOM mas a especificao do DICOM no define totalmente
os metadados armazenados com as imagens, o que permite que cada fabricante crie a
seu prprio DICOM padronizado o que pode gerar diferenas nesses metadados,
dificultando que a PACS os leiam.
10

A arquitetura de uma rede PACS consiste basicamente de um servidor central

que se conecta via LAN ou WAN com os clientes e responsvel por armazenar as
imagens. PACS modernas utilizam a internet como meio de comunicao e cada
imagem fica disponvel em uma url diferente, nesses casos a transferncia de
informaes feita por VPN (Virtual Private Network) ou SSL (Secure Sockets Layer).
As imagens mdicas obtidas atravs de equipamentos de ultra-sonografia,
ressonncia magntica, tomografia computadorizada, endoscopia, etc.. so enviadas a
um servidor PACS (ex.: o dcm4chee) uma vez armazenado na PACS, esse contedo
pode ser facilmente acessado por aplicaes DICOM clientes e viewers para que seja
feito um estudo das imagens.

Figura 4. Arquitetura de uma PACS

4 Modelos de Interface de Comunicao para o InVesalius

4.1 A proposta do projeto
Este trabalho se baseia em analisar algumas propostas de como adicionar ao InVesalius
a funcionalidade de se comunicar com um servidor PACS.
Na elaborao do projeto ficou definido o uso da metodologia XP para o
desenvolvimento desta proposta, assim foram criadas 12 Estrias divididas em 5 Temas
diferentes abordando todas as partes necessrias para a concluso deste projeto, abaixo
segue a lista de Temas criados:

Ponto DICOM Receptor

Ponto DICOM Transmisso

11

Ponto DICOM Importar

Ponto DICOM Log de Comunicao

Ponto DICOM Exportar

Abaixo esto listadas as Estrias que esto diretamente relacionadas ao uso do

DICOM e todas as Estrias completas podem ser encontradas no Anexo B.
TEMA 2: Ponto DICOM Transmisso
Verificar status dos servidores
<06>

Prioridade

Estimativa

Nome do teste

Alta

3 dias

VerStatusServ

Emite um comando, para cada servidor, para saber o status do mesmo.

TEMA 3: Ponto DICOM Importar
Conectar ao servidor PAC
<08>

Prioridade

Estimativa

Nome do teste

Alta

5 dias

ConecServPAC

O servidor que o usurio escolher no US<07> dever fazer autenticao no servidor

PAC.

Pesquisa no servidor PAC

<09>

Prioridade

Estimativa

Nome do teste

Alta

3 dias

PesqServPAC

Aps o usurio estiver conectado ao servidor PAC, ele poder fazer a pesquisa no
banco de dados.

Importar dados do PAC e armazenar no cliente

<10>

Prioridade

Estimativa

Nome do teste

Alta

5 dias

ImpArmDadosPAC

Aps o usurio receber a lista da pesquisa US<09> e clicar no item almejado, ser
realizado a importao dos arquivos mostrados na pesquisa e armazenados no diretrio

12

padro que foi configurado no US<01>.

Alm das estrias, o grupo do CTI, responsvel pelo desenvolvimento do

InVesalius, elaborou alguns requisitos bsicos para que a implementao seja aceita
como parte oficial do InVesalius, necessrio que:

Todo cdigo desenvolvido esteja disponvel sob licena GNU GPL ou BSD;

Se alguma biblioteca for usada ela deve estar disponvel sob licena GNU GPL
ou BSD;

Todo cdigo deve ser desenvolvido em Python ou deve haver um biding para
Python;

O cdigo deve se portvel para Microsoft Windows, GNU/Linux e

opcionalmente para MacOS;

No se deve usar Java ou outra plataforma que dependa de uma virtual machine

No se deve usar PHP;

A comunicao com a PACS deve ser compatvel com a PACS dcm4chee;

4.2 Modelos de Interface de Comunicao para o InVesalius

A proposta de adicionar servios DICOM de rede ao InVesalius no exige que se
implemente todos os servios da especificao, apenas as seguintes funes so
necessrias:

A-Associate-RQ

C-Echo-RQ

C-STORE

C-GET

C-FIND

A-Release-RQ

Dos servios definidos como necessrios o mais critico o C-STORE, pois trata
de um arquivo muito grande para ser enviado pela rede, principalmente em locais com
banda limitada como em muito casos que utilizam internet. O C-STORE neste caso se
trata do envio do arquivo DICOM da PACS para o InVesalius.
Abaixo foram divididos em 3 tpicos abordando possveis alternativas a serem
usadas no desenvolvimento.
4.2.1 Utilizar biblioteca DICOM j existente
Nesta alternativa analisada as principais bibliotecas, framework e ferramentas atuais
para propor caminhos para facilitar o desenvolvimento reutilizando algum cdigo j
existente.

13

Pois o fato de codificar um toolkit seguindo a especificao do DICOM muito

dispendiosa e ainda como h vrios projetos open source com este mesmo objetivo, essa
proposta se mostra bastante interessante j que pode permitir a colaborao em algum
outro projeto.
Abaixo foram listados alguns toolkits que possuem objetivo de facilitar o
desenvolvimento de aplicaes que envolvam o DICOM. A lista no inclui apenas
toolkits que suportam troca de informao via rede mais inclui todas os toolkits
considerados importantes, para que a lista sirva como referncia completa para
desenvolvedores de aplicaes que utilizam o DICOM.
4.2.1.1 UCDMC
Desenvolvido pela Universidade da Califrnia, essa implementao tinha objetivo de
implementar toda a especificao do transporte sobre protocolo TCP/IP do DICOM,
apesar dos esforos ela no se tornou uma biblioteca muito usada mas serviu como
referncia e base para o desenvolvimento de vrias outras bibliotecas importantes, como
o dicomlib e a Charrua DICOM Toolkit que sero referenciados mais adiante.
O UCDMC roda em vrias plataformas, como WindowsNT, WindowsNT Alpha
AXP, Solaris, SunOS, Irix 4 MIPS, DEC Ultrix MIPS, Macintosh Power PC.
4.2.1.2 pydicomlib
O pydicomlib uma biblioteca python, sob a licena GNU GPL, com o objetivo de
facilitar a criao de scripts para tarefas como abrir arquivos DICOM para leitura e
modificao ou at mesmo para se comunicar com servidores DICOM atravs do CFIND, C-MOVE, etc.. atualmente suporta ambientes Microsoft Windows XP,
GNU/Linux e Sun Solaris.
Derivada do dicomlib, um toolkit reescrito do UCDMC, o pydicomlib no
possui uma boa documentao ainda, pois seu desenvolvimento no contnuo e como
o dicomlib escrito em C++ (e depende do Boost.Python) necessrio um wrapper do
dicomlib para que o pydicomlib funcione.
Assim, usar o pydicomlib no seria uma alternativa muito elegante, visto que
dicomlib e Boost.Python so dependncias muito grandes para serem usados no
InVesalius, adicionariam muitas funcionalidades que no seriam usadas, e todas as
dependncias para rodar o pydicomlib j seriam maior do que o prprio InVesalius.
4.2.1.3 dcmtk
O DCMTK contm vrias bibliotecas e aplicaes que implementam a especificao
DICOM, distribudo sob a licena BSD, assim os desenvolvedores podem reutilizar o
cdigo j existente para implementar aplicaes DICOM de maneira mais rpida. O
DCMTK foca principalmente nos servios de rede do DICOM.
Desenvolvido em ANSI C e C++, o DCMTK ainda no possui uma maneira
oficial de ser usado com outras linguagens, como python, apesar de ser possvel gera um
wrapper para python e compilar em ambiente Microsoft Windows XP, GNU/Linux,
Sun Solaris, QNX, IRIX, Free/Net/OpenBSD e MacOS X.
Um exemplo de software livre utilizando o DCMTK o Aeskulap, um DICOM
Viewer bastante utilizado e que j est maduro o suficiente para ser utilizado como
14

referncias para outros projetos. Assim, a idia de reutilizar parte do cdigo do

Aeskulap, que distribudo sob a licena GPL, no desenvolvimento do projeto
InVesalius bem aceita, pois como j h uma aplicao Livre com todas as
funcionalidades que precisamos implementar, seria mais interessante reutilizar e ao
mesmo tempo contribuir evoluindo ou apenas verificando se h bugs no cdigo
reutilizado.
Na verso mais atual do Aeskulap, as chamadas para servios A-Associate, CEcho, C-STORE, C-GET, C-FIND e A-Release esto concludas e testadas o que
significa que todo o cdigo necessrio para ser adicionado no InVesalius s depende de
um wrapper para python.
4.2.1.4 openDICOM.NET
Disponvel sob a licena LGPL, o openDICOM.NET implementa uma API, em C#, que
pode ser usada tanto pelo framework Microsoft .NET ou Mono, as vantagens desta API
poder tratar arquivos DICOM como XML, o que facilita a manipulao dos dados e
simplifica o cdigo.
Disponvel sob a licena LGPL o openDICOM.NET implementa uma API, em
C#, que pode ser usada tanto pelo framework Microsoft .NET ou Mono, as vantagens
desta API poder tratar arquivos DICOM como XML, o que facilita a manipulao dos
dados e simplifica o cdigo.
A utilizao do openDICOM.NET no InVesalius traria vantagens mais tornaria a
aplicao dependente de uma mquina virtual para rodar, o que vai contra os requisitos
especificados.
4.2.1.5 Charrua DICOM Toolkit
Distribudo sob a licena GPL (apesar de possuir uma verso comercial) o Charrua
um Toolkit bem bsico com a inteno de ser o mais compacto possvel, baseado na
biblioteca UCDMC, apresenta apenas servios bsico de rede. Infelizmente, a
documentao bem escassa e nem mesmo o cdigo suficientemente comentado.
4.2.1.6 DCF (DICOM Connectivity Framework)
Desenvolvido pelo Laurel Bridge Software, o DCF foca apenas em prover os servios
de rede do DICOM mas apesar disto um dos mais modernos e eficientes Frameworks
Dicom que existe, foi desenvolvido para ser portvel, robusto e com alta performance.
Disponvel apenas comercialmente, possui verses em linguagem C++, Java ou
Microsoft COM/.NET e suporta ambientes Windows, Linux, Solaris e outros ambientes
Unix-like.
A arquitetura do DCF baseada em web services, em multi-threaded e tambm
possui uma vasta documentao grtis, incluindo exemplos de aplicaes e ferramentas
para automao e validao de teste e um monitorador e gerador de estatsticas em
tempo real.
Infelizmente, o DFC no possui uma verso livre para ser usada com o
InVesalius e sua eficiente, porm, complexa arquitetura possui muito mais
funcionalidade do que necessrio para se implementar o InVesalius.

15

4.2.1.7 Imebra
O Imebra uma biblioteca C++ para DICOM, desenvolvida pela empresa Puntoexe, que
distribuda sob a licena GPL v2 e possui outra verso comercial. O que chama a
ateno no Imebra que ele foi desenvolvido buscando um alto nvel de portabilidade,
atualmente a verso livre suporta ambientes Windows, Linux, Max OS X e Pocket PC.
Essa biblioteca suporta os servios padro de rede no trazendo grandes
vantagens nesse ponto, tambm suporta o padro Unicode, mas o grande diferencial nos
servios est para o tratamento de imagem, pois o Imebra suporta imagens Jpeg,
DICOM e NEMA, suporta vrias opes pra compresso e descompresso e permite a
converso da imagem de maneira simples.
A utilizao do Imebra no InVesalius parece ser uma boa alternativa, mas
infelizmente no h um wrapper para python e como utiliza esquema de duas licenas,
sendo uma livre e uma comercial, o InVesalius estaria sempre usando uma verso
inferior, o que inviabiliza o uso dela, pois h vrias alternativas livres que apresentam as
mesmas funcionalidades.
4.2.1.8 Lista de Referncia
Aqui so listados alguns toolkits que no foram analisados com profundidade por serem
produtos comerciais ou pouco usados. A lista serve apenas como referncia e possui
apenas informaes bsicas.
Empresa /

Toolkit

Licena

Principais Caractersticas

DeJarnette

Comercial

Enviar e Receber mensagens DICOM, segue a

Autor
AN/API

Research

especificao DICOM

Systems

Plataforma Suportadas: "Sun/OS, Solaris, IRIX, HPUX, Digital UNIX, AIX, o Windows 3.1, Windows
95, Windows NT, Windows 2000, DOS, OS/2,

Mallinckrodt

Central Test

Proprietary

Macintosh System 7 e embedded systems

Inclui vrias bibliotecas de baixo nvel para

Institute of

Node (CTN)

OSS

manipulao de estruturas de dados DICOM e de

Radiology

mtodos de acesso a servidores DICOM, uma sute

para testes, no faz manipulao de imagem, inclui
servidor de imagem, gestor de servidor de impresso
e cpia. Plataformas Suportadas: Solaris, Linux e

Marcel van

ConQuest

Proprietary

Windows, IRIX, AIX

Acompanha Servidor DICOM, baseado na

Herk and

DICOM

OSS

biblioteca UCDMC mas tem pouca documentao

Lambert Zijp
Laurel Bridge

Library
DICOM

Comercial

disponvel grtis
No faz manipulao de imagem, implementa toda a

Software, Inc.

Connectivity

especificao de rede do DICOM, acompanha vrias

Framework

ferramentas de linha de comando

(DCF)

Plataforma Suportada: Suporta 2 plataformas .NET

16

ou JAVA e oficialmente funciona em Windows,

ETIAM

DICOM Suite

Comercial

Linux, Solaris (SPARC)

Possui funes de rede do DICOM, manipulao de
imagem e impresso

CoreWare

DICOM

Plataformas Suportada: apenas Windows

Manipulao de imagem

Comercial

Toolkit (DTK)

Plataformas Suportada: apenas Windows

(grtis para
entidades de

Medical

DicomObjects

ensino)
Comercial

Transmisso de imagem, funes de query em

Connections

AccuSoft

servidores DICOM, verificao de arquivos,

ImageGear

(possui

compresso JPEG, acompanha um visualizador de

verso trial

imagem

por 60 dias)

Plataformas Suportada: apenas Windows roda em

Comercial

plataforma .NET ou COM/ActiveX

Possui funes para manipulao de imagens,

MD

compresso JPEG, RLE e JPEG 2000 e no tem

suporte a funes de rede

AccuSoft

ImageTranspo

Comercial

rt MD

Plataformas Suportada: Linux e Windows

Suporte para funes de rede, impresso de imagens
e manipulao de informaes em arquivos DICOM.
Plataformas Suportada: apenas Windows
Suporte a comunicao com servidores DICOM

LEAD

LEADTOOLS

Technologies,

Medical

Inc.
Merge

Imaging SDK
MergeCOM-3

Healthcare

Advanced

Plataformas Suportada: Linux, Windows, Mac OS,

Integrator's

AIX, IRIX e embedded systems

MultiTech

Toolkit
msiCOM3

Comercial

Plataformas Suportada: apenas Windows

Comercial

Comercial

Suporte a comunicao com servidores DICOM

Manipulao de imagem e suporte a comunicao

com servidores DICOM

Tabela 3 Lista de Frameworks e bibliotecas DICOM

4.3 Implementar a comunicao do protocolo DICOM usando socket

A proposta desta alternativa de desenvolver a especificao do DICOM inteiramente
em python, ou seja, utilizar apenas bibliotecas que dem suporte a socket.
Seguindo esta idia o desenvolvimento seria muito mais trabalhoso e a
quantidade de cdigo gerado seria maior, pois todo cdigo referente a especificao
DICOM teria que ser codificado, o que significa que os desenvolvedores teriam que
17

estudar e conhecer a fundo a especificao. Mas essa alternativa j foi analisada

anteriormente pelo grupo do CTI e como conseqncia um pequeno cdigo de exemplo
foi desenvolvido e est disponvel no Anexo C.
Como parte do cdigo, usando s a biblioteca socket do python, j foi
implementada e apenas 6 Servios DICOM sero implementados essa alternativa parece
ser bem vivel, abaixo segue um exemplo de como pode ser usado socket para se
comunicar com uma PACS:
"""
Importa a biblioteca socket
"""
import socket
"""
Cria um socket , definindo AF_INET pois ser usado um domnio da Internet, defini o
tipo de protocolo a ser usado SOCK_STREAM por ser o TCP (poderia ser
SOCK_DGRAM caso optassemos pelo UDP).
"""
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM, 0)
"""
Conecta com o host, no exemplo ser definido o IP vlido de uma PACS pblica
oferecida para teste pelo fabricante da PACS DicomObjects.
"""
s.connect((217.160.210.147, 11112))
"""
Chamada a uma PACS requisitando o servio A_Associate_RQ, como neste exemplo
essa funo no necessria ela foi omitida.
"""
#menssage = A_Associate_RQ(0x00).getMessage()
#print 'Enviando uma mensagem A_Associate_RQ:', menssage.__repr__()
#s.send(menssage)
"""
Termina a interao.
"""
s.close()

18

4.4 Implementar a comunicao do protocolo DICOM usando Twisted Framework

e WADO
A comunicao do InVesalius com a PACS deve ser implementada visando
compatibilidade com a PACS DCM4CHEE, sendo assim uma alternativa ao uso de
socket ou uma biblioteca de terceiros seria utilizar o Twisted Framework e se comunicar
atravs do WADO com o DCM4CHEE.
O Twisted um engine para rede, sob a licena MIT Free Software e totalmente
escrito em python, suporta vrios protocolos como TCP, UDP, SSL/TLS, multicast,
Unix sockets, HTTP, NNTP, IMAP, SSH, IRC, FTP e outros. E tambm inclui um web
server, vrios clientes de chats, servidores chat, servidor de email, etc...
A vantagem de fazer o acesso ao DCM4CHEE utilizando WADO a facilidade
e simplicidade do processo, o WADO uma padro que especifica uma interface Web
para acessar servios DICOM em uma PACS e outros repositrios de objetos DICOM.
A figura mostra como o WADO aplicado.

Figura 5. Wado Interface

A grande vantagem de utilizar esta abordagem a boa documentao disponvel

no site do DCM4CHEE, onde h tambm cdigo em Java que pode ser reescrito em
python, o que tornaria a implementao muito mais rpida.
As desvantagens desta forma de implementao que o InVesalius apenas
funcionaria com PACS que implementam a interface WADO, apesar do requisito de
desenvolver visando compatibilidade apenas com o DCH4CHEE, uma implementao
genrica do DICOM tornaria o InVesalius flexvel o bastante para rodar com qualquer
servidor PACS.
Outro problema do WADO no suportar querying por DICOM imagens, o que
torna a implementao limitada.

19

5 Arquitetura da Comunicao do InVesalius com a PACS

Dentre os possveis modelos de comunicao propostos, os mais eficientes so utilizar o
DCMTK ou implementar as especificaes utilizando SOCKETS sem nenhuma
biblioteca DICOM.
Para exemplificar o desenvolvimento, ser abordado a implementao do servio
A-Associate-RQ, esse servio define um modelo bsico de comunicao para o
estabelecimento da comunicao, entre o PACS e o requisitante, ver figura abaixo.

Figura 6. Estabelecimento de Comunicao A-Associate

Este processo de associao tem quatro etapas, como podemos ver na imagem,
primeiro a aplicao requisitante envia uma requisio de associao para a PACS,
nessa mensagem h informaes de que tipo de servio que o requisitante est
solicitando e quais as sintaxes de transferncia suportadas.
Quando a PACS recebe a requisio de associao ela verifica quais dos servios
presentes na mensagem so suportados e define qual sintaxe de transferncia ser
utilizada, caso alguma sintaxe ou o algum servio no seja suportado, o servio
marcado como rejeitado.
Assim quando a PACS termina de verificar os servios e sintaxes requisitadas,
ela responde com uma lista com todos os servios e sintaxes que foram aceitos e
rejeitados, o requisitante verifica a resposta e inicia a seqncia de solicitao de
servios.
Abaixo segue o exemplo de um cdigo de como seria implementado o
A_Associate_REQ, esse cdigo foi desenvolvido pelo prprio CTI e foi um pouco
alterado para se adequar a este exemplo.

import random
import socket
import struct
class A_Associate_RQ(object):
self.PresentationContextID = id

20

def getApplicationContext(self):
#See PS 3.7-2008 page 83 A.2.1 for this magic value
applicationContextName = '1.2.840.10008.3.1.1.1'
return struct.pack('>BBH', 0x10, 0x00,
applicationContextName

len(applicationContextName))

def getAbstractSyntax(self):
abstractSyntaxName = '1.2.840.10008.1.1'
return struct.pack('>BBH', 0x30, 0x00, len(abstractSyntaxName)) + abstractSyntaxName
def getTransferSyntax(self):
transferSyntaxName = '1.2.840.10008.1.2'
return struct.pack('>BBH', 0x40, 0x00, len(transferSyntaxName)) + transferSyntaxName
def getPresentationContext(self):
subContext = struct.pack('>BBBB', self.PresentationContextID, 0x00,
0x00, 0x00) +\
self.getAbstractSyntax() + self.getTransferSyntax()
return struct.pack('>BBH', 0x20, 0x00, len(subContext)) + subContext
def getUserInformation(self):
userData = self.getMaximumLength() +\
self.getImplementationClassUID() +\
self.getAsyncOperationsWindow() +\
self.getImplementationVersionName()
return struct.pack('>BBH', 0x50, 0x00, len(userData)) + userData
def getMaximumLength(self):
return struct.pack('>BBHI', 0x51, 0x00, 0x4, 1024*16)
def getImplementationClassUID(self):
implementationClassUID = '1.2.40.0.13.1.1'
return struct.pack('>BBH', 0x52, 0x00, len(implementationClassUID)) +\
implementationClassUID
def getAsyncOperationsWindow(self):
return struct.pack('>BBHHH', 0x53, 0x00, 0x04, 0x01, 0x01)
def getImplementationVersionName(self):
version = 'dcm4che-2.0'
return struct.pack('>BBH', 0x55, 0x00, len(version)) + version
def getPDU(self):
subPDU = struct.pack('>HH16s16s32s',
0x01,
0x00,
'DCM4CHEE'.ljust(16),
'DCMECHO'.ljust(16), '')
self.getApplicationContext() + \
self.getPresentationContext() + \
self.getUserInformation()
return struct.pack('>BBI', 0x01, 0x00, len(subPDU)) + subPDU
def getMessage(self):
"""
Returna a mensagem A-Associate-RQ
"""
return self.getPDU()

21

def AssociateRQ():
"""
Importa a biblioteca socket
"""
import socket
"""
Cria um socket , definindo AF_INET pois ser usado um domnio da Internet, defini o
tipo
de protocolo a ser usado SOCK_STREAM por ser o TCP (poderia ser SOCK_DGRAM
caso optassemos pelo UDP).
"""
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM, 0)
"""
Conecta com o host, no exemplo ser definido o IP vlido de uma PACS pblica
oferecida para teste pelo fabricante da PACS DicomObjects.
"""
s.connect((217.160.210.147, 11112))
"""
Chamada a uma PACS requisitando o servio A_Associate_RQ
"""
menssage = A_Associate_RQ(0x00).getMessage()
print 'Enviando uma mensagem A_Associate_RQ:', menssage.__repr__()
s.send(menssage)
"""
Termina a interao.
"""
s.close()
if __name__ == '__main__':
AssociateRQ()

Como forma de comparao tambm foi implementado um exemplo para

referncia do desenvolvimento do A-Associate-RQ utilizando a biblioteca DCMTK.
Abaixo segue o cdigo em linguagem C:

#include "dimse.h"
#include "assoc.h"
void main(void)
{
T_ASC_Network *net;
T_ASC_Parameters *params;
T_ASC_Association *assoc;
// Define a PACS dicomserver.medicalconnections.co.uk para se conectar
ASC_setPresentationAddresses(params,
"217.160.210.147",
"dicomserver.medicalconnections.co.uk:11112");
// Inicializa a Rede
OFCondition cond = ASC_initializeNetwork(NET_REQUESTOR, 0, 1000, &net);

22

// Tenta estabelecer a conexo

printf("Requesting Association\n");
cond = ASC_requestAssociation(net, params, &assoc);
if (cond.bad()) {
if (cond == DUL_ASSOCIATIONREJECTED)
{
T_ASC_RejectParameters rejec;
ASC_getRejectParameters(params, &rejec);
errmsg("Associao Rejeitada:");
ASC_printRejectParameters(stderr, &rejec);
exit(1);
}
else {
errmsg("Associao Falhou:");
DimseCondition::dump(cond);
exit(1);
}
}
}

evidente a diferena da complexidade e tamanho do cdigo gerado, enquanto

desenvolver em python utilizando sockets cria um cdigo independente de dependncias
para o InVesalius ele gera um cdigo extenso e complexo que requer grande
conhecimento da especificao do DICOM.
Por outro lado utilizar a biblioteca DCMTK iria gerar uma dependncia a mais
para o InVesalius, o que poderia ser um problema ao tentar portar o InVesalius ou
apenas fazer a manuteno para manter a compatibilidade com futuras verso do
DCMTK.

23

6 - Concluso
O DICOM um padro complexo, porm necessrio e muito bem documentado. Na
internet possvel achar vrias bibliotecas e frameworks livres ou pagos para todo tipo
de linguagem e plataforma.
J o InVesalius sem uma conexo com um PACS se torna uma ferramenta
isolada e menos aceita pelos usurios, uma vez que depende do usurio ter as imagens
no disco local, por isso o projeto ponto DICOM muito importante para a evoluo do
projeto InVesalius.
Dentre as alternativas apresentadas neste trabalho, ficou evidente que a
biblioteca DICOM livre mais usada nos dias de hoje o DCMTK. Tanto a
documentao disponvel quanto a grande quantidade de cdigo de exemplo abrem um
caminho rpido para desenvolvedores que no possuem muito conhecimento do
funcionamento do DICOM em uma rede.
A idia de se desenvolver todo o cdigo em python utilizando sockets tambm
se mostrou ser muito eficiente, evitando a necessidade de um wrapper para usar
bibliotecas em outras linguagens e no aumentando o nmero de dependncias do
InVesalius, porm seria necessrio um conhecimento muito maior da especificao do
InVesalius e muito mais cdigo seria gerado.

24

7. REFERNCIAS BIBLIOGRAFICAS
Medical Imaging & Technology Alliance, Disponvel em: http://medical.nema.org.
Acesso em: Setembro/2008.
DICOM
introduction
and
free
software,
Disponvel
http://www.sph.sc.edu/comd/rorden/dicom.html. Acesso: em Setembro/2008.

em:

Portal Software Livre, Disponvel em: http://www.softwarelivre.gov.br. Acesso em:

Outubro, 2008.
Python Programming Language - Official
http://www.python.org. Acesso em: Outubro, 2008.

Website,

Disponvel

em:

DICOM Software made by OFFIS DCMTK DICOM Toolkit, Disponvel em:

http://dicom.offis.de/dcmtk.php.en. Acesso em: Outubro 2008.
PACS Developer Community, Disponvel em: http://pacs.pe.kr/techdoc/dicom.php,
Acesso em: Outubro/2008.
Christian Sonek - Dicom Introduction, Disponvel em: http://www.christiansonek.de/dicom/dicom_introduction.html. Acesso em: Novembro/2008.
Web Access to DICOM Objects (WADO) Service, Disponvel em:
http://www.haifa.ibm.com/projects/software/wado/index.html. Acesso em: Novembro /
2008.

25

ANEXOS

26

ANEXO A Modalidades DICOM

Exemplos de Modalidades Suportadas:
AS = Angioscopy
BI = Biomagnetic Imaging
CD = Color Flow Doppler
CF = Cinefluorography (retired)
CP = Colposcopy
CR = Computed Radiography
CS = Cystoscopy
CT = Computed Tomography
DD = Duplex Doppler
DF = Digital Fluoroscopy (retired)
DG = Diaphanography
DM = Digital Microscopy
DS = Digital Subtraction Angiography
DX = Digital Radiography
EC = Echocardiography
ES = Endoscopy
FA = Fluorescein Angiography
FS = Fundoscopy
HC = Hard Copy
LP = Laparoscopy
LS = Laser Surface Scan
MA = Magnetic resonance angiography
MG = Mammography
MR = Magnetic Resonance
MS = Magnetic Resonance Spectroscopy
NM = Nuclear Medicine
OT = Other
PT = Positron Emission Tomography (PET)
RF = Radio Fluoroscopy
RG = Radiographic Imaging (conventional film screen)
RTDOSE = Radiotherapy Dose
RTIMAGE = Radiotherapy Image
RTPLAN = Radiotherapy Plan
RTSTRUCT = Radiotherapy Structure Set
ST = Single-photon Emission Computed Tomography
TG = Thermography
US = Ultrasound
VF = Videofluorography (retired)
XA = X-Ray Angiography
XC = eXternal Camera
ECG = Electrocardiograms
BMD = Bone Mineral Densitometry
BDUS = Ultrasound Bone Densitometry

27

ANEXO B Documento de Estrias

UFLA - UNIVERSIDADE FEDERAL DE LAVRAS

USER STORIES
VERSO 1.2

Desenvolvimento do Sistema de comunicao via Internet que possibilitar a

importao de dados para o software InVesalius

(Demanda de desenvolvimento do InVesalius: Software Pblico Brasileiro)

28

1 - HISTRICO DE ALTERAES
Verso

Data Alterao

Responsvel

Descrio

1.0

03/09/2008

Equipe UFLA

Verso Inicial

1.1

18/09/2008

Fernando

Definio de
prioridade

1.2

18/09/2008

Fernando

Definio de
estimativa

2 - INTRODUO
Este documento descreve os User Stories necessrios aos desenvolvedores as
para a execuo e implementao do projeto o mdulo de comunicao do InVesalius
com servidores PACS, que adicionar a funcionalidade de importao de dados para o
InVesalius.
Os User Stories foram divididos em 5 temas sendo eles:

Ponto DICOM Receptor

Ponto DICOM Transmisso

Ponto DICOM Importar

Ponto DICOM Log de Comunicao

Ponto DICOM Exportar

3 USER STORIES
TEMA 1: Ponto DICOM Receptor
Criao da janela do Ponto DICOM Receptor
<01>

Prioridade

Estimativa

Nome do teste

Mdia

1 dia

janPDR

Criao de uma janela mostrando para o usurio os seguintes campos:

AETitle

TCP/IP

Nmero da porta do TCP/IP

Nome Computador + Domnio

Verificao de atualizao

Time-out de comunicao

Tempo de armazenamento de log

29

Diretrio

Essa janela estar disponvel a partir do MENU:

PREFERNCIASTRANSMISSO VIA REDERECEPTOR
Estes dados tambm podero ser modificados pelo usurio e dever haver ajuda para
todos os campos.
As configuraes ficaro salvas em um arquivo.

Identificao de informaes do computador local

<02>

Prioridade

Estimativa

Nome do teste

Alta

2 dias

InfoCompLocal

Identifica a configurao do computador local e informa ao usurio na janela do

US<01>, sendo que a preferncia de certos campos so dada pelo arquivo salvo com as
modificaes feita pelo usurio anteriormente. Abaixo mostrado os dados que so
pegos no computador local, os dados com um * na frente, so os que tem como o
arquivo salvo no computador como prioritrio.

TCP/IP

Nmero da porta do TCP/IP

Nome Computador + Domnio

*Verificao de atualizao

*Time-out de comunicao

*Tempo de armazenamento de log

*Diretrio (Onde o invesalius setar corretamente o endereo do diretrio que

armazenar os arquivos, Padro no Linux: /home/nome-usuario/invesalius e
Padro no Windows: C:\Documents and Settings\usuario\invesalius).

Obs.: Na primeira execuo do InVesalius, dever ser criado um arquivo com estes
dados.

Limpeza do arquivo de log

<03>

Prioridade

Estimativa

Nome do teste

Baixa

1 dia

LimpArqLog

O arquivo de log dever ser verificado e limpo conforme o nmero de semanas definido
na tela de definio do Ponto DICOM Receptor no US<01>.
30

Salvar Configurao
<04>

Prioridade

Estimativa

Nome do teste

Alta

2 dias

SalConf

Ao clicar em "OK" na janela do ponto DICOM receptor no US<01> haver uma

verificao se houve alterao das configuraes e se houver, armazena as novas
configuraes para que o InVesalius possa utiliz-las.
TEMA 2: Ponto DICOM Transmisso
Criao de janela do Ponto DICOM Transmisso
<05>

Prioridade

Estimativa

Nome do teste

Mdia

1 dia

janPDT

Criao de uma janela que permita adicionar, remover e alterar informaes usadas
para acesso aos servidores PACS, os seguintes campos so necessrios:

AETitle

Endereo TCP/IP

Porta TCP/IP

Descrio

Lista de Servidores

Campos de autenticao (Usurio e Senha)

Essa janela estar disponvel a partir do MENU:

PREFERNCIASTRANSMISSO VIA REDETRANSMISSO
O usurio poder acrescentar novos servidores, sendo que os campos Endereo e Porta
TCP/IP so campos obrigatrios.
Caso algum servidor necessite de autenticao o usurio j poder fornecer quando
acrescentar servidor.
O usurio poder selecionar um servidor da "Lista de Servidores" e utilizar as opes
REMOVE ou ALTER para remover ou alterar algum servidor.
O usurio poder clicar em C-ECHO para verificar se os servidores esto disponveis.
Os

configuraes

ficaro

salvas

em

um

arquivo.

obs: O boto ADD mudar para ALTER caso o usurio clique em um dos servidores da
lista.

31

Verificar status dos servidores

<06>

Prioridade

Estimativa

Nome do teste

Alta

3 dias

VerStatusServ

Emite um comando, para cada servidor, para saber o status do mesmo.

TEMA 3: Ponto DICOM Importar
Criao da janela do ponto DICOM Importar busca
<07>

Prioridade

Estimativa

Nome do teste

Mdia

1 dia

janPDIbusca

Criao de uma janela que permitir ao usurio fazer uma busca nos servidor PACS, a
busca pode ser feita utilizando um dos campos pr definidos:

AETitle

Nome do Paciente

Modalidade

Idade

Sexo

Data de Aquisio

Essa

janela

estar

disponvel

partir

do

MENU:

NOVO BUSCA NO SERVIDOR

O usurio pode escolher que tipo de busca deseja fazer no servidor PACS, escolhendo
entre informaes do Paciente, Estudo, Series, Equipamento, Referencia do Frame e da
Imagem. Os dados retornados so listados na tabela de RESULTADO onde o usurio
poder selecionar qual Imagem deseja abrir no InVesalius.
Para importar a imagem no InVesalius o usurio deve clicar sobre a informao no
tabela resultado e clicar na opo OK.

Conectar ao servidor PAC

<08>

Prioridade

Estimativa

Nome do teste

Alta

5 dias

ConecServPAC

O servidor que o usurio escolher no US<07> dever fazer autenticao no servidor

PAC.
32

Pesquisa no servidor PAC

<09>

Prioridade

Estimativa

Nome do teste

Alta

3 dias

PesqServPAC

Aps o usurio estiver conectado ao servidor PAC, ele poder fazer a pesquisa no
banco de dados.

Importar dados do PAC e armazenar no cliente

<10>

Prioridade

Estimativa

Nome do teste

Alta

5 dias

ImpArmDadosPAC

Aps o usurio receber a lista da pesquisa US<09> e clicar no item almejado, ser
realizado a importao dos arquivos mostrados na pesquisa e armazenados no diretrio
padro que foi configurado no US<01>.
TEMA 4: Ponto DICOM Log de Comunicao
Criar tabela de Erros
<11>

Prioridade

Estimativa

Baixa

1 dia

Nome do teste

Criar uma tabela de erros para o sistema com: Cdigo do ERRO e Descrio, usada
pelo sistema pra definir os erros.

Visualizar LOG de Comunicao

<12>

Prioridade

Estimativa

Nome do teste

Baixa

1 dia

VisLogCom

33

Permite a visualizao dos erros ocorridos nos mdulo ponto DICOM.

Os campos armazenados so:
Essa janela estar disponvel no MENU:
PREFERNCIASVISUALIZAR LOG DE COMUNICAO

AETitle

Endereo TCP/IP

Porta TCP/IP

Descrio do Evento

Data e Hora

Esta informao estar disponvel a partir no MENU:

PREFERNCIASVISUALIZAR LOG DE COMUNICAO

34

ANEXO C Cdigo fonte do A_Associate_RQ desenvolvido pelo CTI

Abaixo segue o cdigo original desenvolvido pelo CTI, referente ao servio
A_Associete_RQ.
A_Associete_RQ.py
import random
import socket
import struct
class A_Associate_RQ(object):
"""
Implements the A-Associate-RQ Message.
"""
def __init__(self, id):
"""
id -> Presentation-context-id, must be a odd number between 1 and 255,
"""
self.PresentationContextID = id
def getApplicationContext(self):
"""
See PS 3.8-2008 page 36, table 9-12
Composed by:
item type(B) -> 0x10
reserved(B) -> 0x00
item length(H) -> the length of the application context name, the next
field
application context name -> A valid application-context-name
"""
#See PS 3.7-2008 page 83 A.2.1 for this magic value
applicationContextName = '1.2.840.10008.3.1.1.1'
return struct.pack('>BBH', 0x10, 0x00, len(applicationContextName)) +
applicationContextName
def getAbstractSyntax(self):
"""
See PS 3.8-2008 page 37, table 9-14
composed by:
item type(B) -> 0x30
reserved(B) -> 0x00
item-length(H) -> length of the abstract-syntax-name, the next field
abstract-syntax-name -> a valid abstract-syntax-name
"""
abstractSyntaxName = '1.2.840.10008.1.1'
return struct.pack('>BBH', 0x30, 0x00, len(abstractSyntaxName)) + abstractSyntaxName
def getTransferSyntax(self):
"""
See PS 3.8-2008 page 37, table 9-15
composed by:
item type(B) -> 0x40
reserved(B) -> 0x00

35

item-length(H) -> length of the transfer-syntax-name, the next field

abstract-syntax-name -> a valid transfer-syntax-name
"""
transferSyntaxName = '1.2.840.10008.1.2'
return struct.pack('>BBH', 0x40, 0x00, len(transferSyntaxName)) + transferSyntaxName
def getPresentationContext(self):
"""
See PS 3.8-2008 page 36, table 9-13
Composed by:
Item type(B) -> 0x20
Reserved(B) -> 0x00
item-length(H) -> length from the next field to the end of
abstract/transfer syntax sub-items
presentation-context-id(B) -> an odd number between 1 and 255
reserved(B) -> 0x00
reserved(B) -> 0x00
reserved(B) -> 0x00
Abstract/transfer syntax sub-items -> composed by one abstract syntax
and one or more transfer syntax
"""
subContext = struct.pack('>BBBB', self.PresentationContextID, 0x00,
0x00, 0x00) +\
self.getAbstractSyntax() + self.getTransferSyntax()
return struct.pack('>BBH', 0x20, 0x00, len(subContext)) + subContext
def getUserInformation(self):
"""
See PS 3.8-2008 page 40, table 9-20
composed by:
item type(B) -> 0x50
reserved(B) -> 0x00
item length(H) -> the length of the user-data field, the next field
User-data -> composed by the Maxymum length, Implementation Class UID
and Implementation Version Name
"""
userData = self.getMaximumLength() +\
self.getImplementationClassUID() +\
self.getAsyncOperationsWindow() +\
self.getImplementationVersionName()
return struct.pack('>BBH', 0x50, 0x00, len(userData)) + userData
def getMaximumLength(self):
"""
See PS 3.8-2008 page 49, table D.1-1
composed by:
item type(B) -> 0x51
reserved(B) -> 0x00
item length(H) -> The lenght of maximum-length-received, the next field
maximum-length-received(I) -> Maximum length of the P-Data sent by the
acceptor
"""
return struct.pack('>BBHI', 0x51, 0x00, 0x4, 1024*16)
def getImplementationClassUID(self):
"""
See PS 3.7-2008 page 102, table D.3-1

36

composed by:
item type(B) -> 0x52
reserved(B) -> 0x00
item lenght(H) -> the length of implementation-class-uid, the next field
implemententation-class-uid -> A valid implementation-class-uid
"""
implementationClassUID = '1.2.40.0.13.1.1'
return struct.pack('>BBH', 0x52, 0x00, len(implementationClassUID)) +\
implementationClassUID
def getAsyncOperationsWindow(self):
"""
See PS 3.7-2008 page 106, table D.3-7
composed by:
item type(B) -> 0x53
Reserved(B) -> 0x00
item length(H) -> 0x04
maximum-number-operations-invoked(H) -> See PS 3.7-2008 section D.3.3.3
Maximum-number-operations-performed(H) -> See PS 3.7-2008 section D.3.3.3
"""
return struct.pack('>BBHHH', 0x53, 0x00, 0x04, 0x01, 0x01)
def getImplementationVersionName(self):
"""
See PS 3.7-2008 page 103, table D.3-3
composed by:
item type(B) -> 0x55
reserve(B) -> 0x00
item length(H) -> the length of the implementation-version-name, the
next field
implementation-version-name -> a valid value
"""
version = 'dcm4che-2.0'
return struct.pack('>BBH', 0x55, 0x00, len(version)) + version
def getPDU(self):
"""
See PS 3.8-2008 page 35, table 9-11
Associate-RQ PDU is composed by
PDU-type(B) -> 0x1, means a A-Associate-RQ message
Reserved(B) -> 0x0
PDU-length(I) -> length of the rest of this message
Protocol-version(H) -> protocol suported by the calling system( that is me )
Reserved(H) -> 0x0
Called-AE-title(16s) -> AE title from server
Calling-AE-title(16s) -> AE title from client
Reserved(32s) -> shall be sent filled with 0x0 values
Variable items -> Composed by Aplication Context, one or more
Presentation context and User information
"""
subPDU = struct.pack('>HH16s16s32s', 0x01, 0x00, 'DCM4CHEE'.ljust(16),
'DCMECHO'.ljust(16), '') + \
self.getApplicationContext() + self.getPresentationContext() + \
self.getUserInformation()
return struct.pack('>BBI', 0x01, 0x00, len(subPDU)) + subPDU
def getMessage(self):
"""

37

Returns a A-Associate-RQ message

"""
return self.getPDU()
def testeAssociateRQ():
import socket
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.connect(('127.0.0.1', 11112))
message = A_Associate_RQ(0x01).getMessage()
print 'Mandando a mensagem:', message.__repr__()
s.send(message)
print '\nRecebendo a mensage:', s.recv(1024).__repr__()
s.close()
if __name__ == '__main__':
testeAssociateRQ()

38