S @ DE
Joana Torhrella Valadão
VALADÃO, JOANA TORTURELLA Streaming de Imagens Médicas [Rio de Janeiro] 2004
X, 65 p. 29,7 cm (COPPEIUFRJ, M.Sc.,
Engenharia de Sistemas e Computação, 2004)
Tese - Universidade Federal do Rio de
Janeiro, COPPE
1. Streaming de Imagens Médicas
2. Padrões Internacionais da Área Médica (HL7, HIS, PACS e DICOM)
Dedico esta conquista aos meus pais, ismão e meu marido, por todo o apoio, paciência, e por estarem sempre ao meu lado, sem me deixar desanimar em um só momento. E a Deus, por me guiar em minha jornada.
Agradecimentos
Aos meus orientadores, Edilberto Strauss e Antonio Oliveira, pela orientação, apoio e incentivo.
Ao Marcos pelas nossas conversas, e por acompanhar o desenvolvimento deste trabalho.
Às professoras Aura Conci e Fabiana Rodrigues Leta por aceitarem participar da banca.
Aos professores e alunos do Laboratório de Computação Gráfica (LCG).
A
equipe do Hospital Quinta D'or por terem pemitido que eu conhecesse um ambientehospitalar de perto, para desenvolver o meu trabalho.
Ao pessoal administrativo da COPPEISistemas.
Resumo da Tese apresentada a COPPEtUFRJ como parte dos requisitos necessários para a obtenção do grau de Mestre em Ciências (M.Sc.)
STREAMING DE IMAGENS &DICAS
Joana Torturella Valadão Janeiro/2004
Orientador: Antonio Alberto Fernandes de Oliveira
Programa: Engenharia de Sistemas e Computação
A medicina moderna encontra-se baseada em uma gama significativa de
modalidades de exames integrados à característica digital. A imagem médica di
transformou-se em elemento essencial na obtenção de um diagnóstico e prognóstico
médico mais seguro e padronizado da tecnologia digital sobre os aspectos de
armazenarnento, transmissão e manipulação das imagens digitais. Para isso, surgem os
sistemas PACS (Pichire Archive Communication System) sobre o padrão internacional DICOM (Digital Imaging and Communication in Medicine), normalizados pela ANSI-
HL7 (Health Leve1 Seven).
Essa dissertação descreve um conjunto de técnicas implementadas para a
otimização do arrnazenamento, do processamento e da visualização de imagens médicas
sobre o padrão web. O Sistema Web ) foi desenvolvido em Java,
sobre uma arquitetura em quatro camadas, para melhor atender aos p
comunicagão Intemet/Intranet. A arquitetura implementada garante, a wn baixo custo
computacional, um acesso remoto a exames médicos, com alta complexidade de
S o m a ç ã o associada. ado a um sistema PACS-Ho
seguindo os padrões DICOM (versão 3) descrito da norma HL7, garantindo um
Abstract of Thesis presented to COPPEKJFRJ as a partia1 fulfillment of the requirements for the degree of Master of Science (M.Sc.).
STREAMING OF MEDICAL IMAGES Joana Torturella Valadão
Januaryl2004
Advisor: Antonio Alberto Fernandes de Oliveira
Department: System and Computing Engineering
Modern Medicine is based on a variety of integrated digital exams. The medical digital image transform itself in an essencial element to obtain a precision and safe medica1 diagnosis and prognosis. These exams, which are more complex, need a continuous and standardized advance in many technologies, like: storage, transmission and manipulation of digital images.
For that, there are systems like PACS (Picture Archival Communication System), which use an internacional standard named DICOM (Digital Imaging and Communication in Medicine), standardized by ANSI-HL7 (Health Leve1 Seven).
This dissertation describes a set of optimation techniques implemented by
storage, processing, and visualizing medica1 images in web form. The system
WebMedViewer ( ) were developed in Java, based on four layers arquitecture, for
better attend the internacional intranet and internet standars. The arquitecture implemented, guarantees, a low computacional cost, remote exams acess with complex
infomation assotiated. ated with System ACS-Hospital, folowing
internacional s rsion 3) described in HL7, gaanting an efficient
...
2.2 A TÉCNICA DE STREAMING 5
...
2.3 FORMATOS DE ARQUIVOS 'i'
...
2.3.1 TAG IMAGE FILE FORMAT
-
TIFF 72.3.2 PICT
...
4...
2.3.3 ENCAPSULATED POSTSCRIPT
-
EPS .8...
2.3.4 GRAPHICS INTERCHANGE FORRZAT
-
GIF...
2.3.5 JOINT PHOTOGRAPHIC EWERTS GROUP . R E G 8
...
2.3.6 WINDOWS BITMAP . BMP -9
...
.2.3.7 DIGITAL IMAGING AND COMIVIUNICATION IN MEDICINE DICOM 9
...
2.4 STREAMING DE IMAGENS MÉDICAS 10
...
3.
O SISTEMA HOSPITALAR 14...
3.1 INTRODUÇÃO 14...
3.2 HEALTHLEVELSEVEN-HL3 15...
3.3 HOSPITAL INFORMATION SYSTEM (WIS) 16
3.4 PICTURE ARCHIVAL COMMUNICATION SYSTEM . PACS
...
14.
...
3.5 DIGITAL WGING AND COMMUNICATION IN ~ D I C I N E DICOM 19
...
3 .5.1 IMAGENS DICOM 20...
3.5.2 COMUNICAÇÃO 21...
3.5.3 O MODELO DE DADOS - 2 4 vii...
4.4.1 PESQUISA 3 '7...
4.4.2 VISUALIZAÇÃO DE ESTUDOS -40...
4.4.3 VISUALIZADOR DE SÉRIES -41...
4.5 STREAMING -48...
4.5.1 HISTOGRAMA -48...
4.5.2 ENDEREÇO 50...
4.5.3 QUICKSORT 51...
4.5.4 SUBTRAÇÃO 52...
4.5.5REDUÇÃO
53...
5.
CONSIDEWÇ~ES FINAIS 58...
Figura 2- 1 : Arquivo de imagem do Zoomi@ 1 0
Figura 2-2: Resultado do Streaming
...
11...
Figura 3-1 : O Sistema de Informação Hospitalar (HIS) 17
...
Figura 3-2: Componentes de um sistema PACS 18
...
Figura 3-3: Escopo do padrão DICOM -19
...
Figura 3-4: Ilustrando um arquivo DICBM -20
...
Figura 3-5: Detalhando um arquivo DICOM 21
...
Figura 3-6: Modelo de comunicação 22
...
Figura 3-7: Arquitetura de Comunicação DICOM 23
...
: Comunicação Ponto-a-Ponto com OS1 24
...
Figura 3-9: Modelo de Dados DICOM 25
...
Figura 3- 10: Modelo DICOM Simplificado 26
...
Figura 3
.
1 1 : Integração HIS/PACS/DICOM - 2 6...
Figura 4- 1 : Arquitetura Cliente-Servidor -28
Figura 4-2: Arquitetura em duas camadas
...
29...
Figura 4-3: Arquitetura em três camadas 30
...
Figura 4-4: Arquitetura em quatro camadas 31
Figura 4-5: Arquitetura com os componentes utilizados
...
32 Figura 4-6: Conquest e SQL Server...
33...
Figura 4-7: Máquina Virtual Java para diversas plataformas 34
Figura 4-8: Transformando uma imagem em um array
...
36...
Figura 4-9: Applet de Pesquisa 37
...
Figura 4.10. Pesquisa por Estudo -39
...
Figura 4.1 1 : Resultado da Pesquisa 40
...
Figura 4.12. Visualiz or de Estudo 41
...
Figura 4.1 3 : Visualizador de Série 42
Figura 4.14. Barra de Tarefas do Visualizador
...
42...
Figura 4.15. Botões de manipulação da área de visualização 43
Figura 4.16. Botões de inversão de cor, bnilho/contraste
...
-43: Função de Inversão de Cores, Brilho e Contraste
...
4 4...
: Botões de rotação 44
...
...
ais luncionalidades -45
...
Figura 4.2 1 : Zoom. Centralização e Translação -46
Figura 4.22. Sistemas de Coordenadas
...
4'7 Figura 4.23. Restaurando uma Imagem...
47 Figura 4.24. Imagem e seu histograma...
49...
Figura 4-25: Estrutura para armazenar o histograma -49
Figura 4-26: Envio de pixels para o usuário
...
50...
Figura 4-27: Histograma e Endereço 51
Figura 4-28: Redução da imagem com fator de redução 2
...
53 Figura 4-29: Comparação entre a imagem completa e as imagens reduzidas...
54 Figura 4-30: Realocando os pixels na imagem...
55...
Figura 4-3 1 : Completando a imagem 5 6
Figura 4-32: Resultado da 66propagação"
...
56 Figura 4-33: Imagem totalmente carregada...
5'7 Tabela 5-1 : Comparação dos tempos de carga...
60No mundo atual, as instituições médicas vêm enfrentando uma série de desafios focando principalmente a melhoria na qualidade dos serviços clínicos e hospitalares, sem com isso aumentar demasiadamente os já altos custos operacionais.
Para isso, é importante a absorção dos avanços tecnológicos requeridos pela medicina
moderna, permitindo o gerenciamento das informações médicas e administrativas de maneira eficiente, tomando o acesso às informações mais rápido e seguro.
Um marco no avanço tecnológico da medicina foi a descoberta do Raio-X, em 1895, que iniciou uma nova fase: o diagnóstico por imagens. Depois do Raio-X, surgiram novas modalidades de obtenção de imagens, como a cintilografia, a ultra- sonografia, a tomografia computadorizada, a ressonância magnética, etc, sendo que a própria imagem originada nos exames evoluiu das imagens em filmes radiológicos para as digitais (REZENDE, 2002). Alem dos avanços na área de exames, com a dihsão dos computadores, diversos sistemas foram criados a fim de facilitar o gerenciamento das informações médico-administrativas.
Foi neste contexto que surgiram diferentes sistemas computacionais de apoio. Dentre eles o armazenamento de imagens médicas no formato digital (Picture Archival
Communication System - PACS), o padrão DICOM (Digital Imaging and
Communication in Medicine) que fornece maior suporte ao PACS, através da padronização da comunicação entre os diversos equipamentos hospitalares, culminando
em complexos sistemas de informação (Hospital Infirmation System - HIS),
responsáveis pela integração de informações de natureza financeira até prontuários médicos. Regendo este complexo sistema hospitalar (o HIS), há ainda o Health Leve1
Seven (HL7), que é um padrão que tem como objetivo regulamentar toda a troca de
informação entre os diversos sistemas hospitalares.
O armazenamento das imagens em formato digital trouxe uma série de
vantagens para o setor médico-hospitalar. Essas vanta ens n2io se resumem apenas na redução de custo dos filmes radiológicos. Mas também, na facilidade de amazenamento, recuperação e manipulação das imagens. Os filmes são impresso^^^
apenas no momento em que o exame vai ser entregue ao paciente, evitando desperdícios.
Uma outra importante vantagem da tecnologia digital é facilitar o acesso às
imagens, disponibilizando-as na Intranet, bem como na Internet, através de sites seguros, e com acesso restrito, otimizando assim os procedimentos operacionais de médicos e técnicos radiológicos. Porém, a disponibilização destas informações em rede, traz algumas complicações como, por exemplo, a relação entre o tamanho das imagens e sua transferência. Ou seja, para imagens muito grandes (como por exemplo, uma
imagem RX digital de mão que possui um tamanho médio de 2500 x 2048 pixels) o
tempo de espera associado ao download e a visualização é demasiadamente longo.
O problema de arquivos grandes que devem sofrer download antes de serem
executados é algo comum na Internet. Arquivos de áudio e de vídeo são um bom
exemplo. Assim como as imagens médicas, eles devem ser carregados completamente para serem visualizados. O ideal seria disponibilizar a visualização da imagem, ou do vídeo, ou do áudio, durante o download. Este objetivo foi atingido com a criação das técnicas de streamingl.
A fim de pemiitir a visualização do arquivo durante seu download, esta técnica promove a segrnentação do arquivo, facilitando sua transmissão na rede. Além disso, os segmentos enviados sofiem urna transformação no computador cliente, permitindo a
visualização do arquivo. O resultado é a possibilidade de assistir ao vídeo ou ouvir a
música, por exemplo, sem longos tempos de espera. Quando se trata de imagens digitais, as partes mais significativas são enviadas primeiro, fornecendo ao usuário uma primeira percepção da imagem, reduzindo a sensação de espera.
Um cuidado que se deve ter ao utilizar técnicas de streaming é referente a compressão de dados. A maior parte dessas técnicas realiza a compressão, em geral com perda de informação, a fim de que o arquivo fique menor, e seja mais fácil de transmitir
pela rede. Porém, devido à própria natureza das imagens médicas, não é aconselhável o
uso de compressões com perda, pois a perda de informações pode prejudicar a análise dos exames.
Existem diversas técnicas de streaming para arquivos de áudio e vídeo, porém muito pouco para imagens, e menos ainda para imagens médicas. As que existem, em sua grande maioria, são pr
1
Streaming é a denominação da técnica que promove a segregação de um arquivo grande, para que ele seja transmitido e seus fragmentos sejam "executados" no computador cliente, em tempo real.
Devido aos altos custos dos sistemas comerciais destinados ao streaming de imagens médicas e, em alguns casos, a não concordância com o padrão DICOM, desenvolveu-se um sistema em tempo real para a transmissão de imagens médicas através de uma rede de comunicação DICOM (Digital Imaging and Communications in Medicine), permitindo que os usuários, utilizando uma rede IntranetIInternet, tenham acesso rápido e seguro aos exames radiológicos (imagens digitais), independente de onde estejam localizados fisicamente, sem a necessidade da instalação de algum sofiare especial.
O sistema implementado, baseado em técnicas de streaming, também se destina a possibilitar a análise de exames. Desta forma, foram disponibilizadas funções
de manipulação para que o usuário consiga simular o que é possível realizar com as
imagens em filmes radiológicos.
Esta dissertação está dividida em 5 capítulos, incluindo a presente introdução. Os próximos capítulos abordarão os seguintes assuntos:
: este capítulo apresenta o processo geral envolvido
nas técnicas de streaming, ressaltando as particularidades necessárias para o streaming de imagens médicas, os formatos de arquivo existentes, e algumas técnicas de streaming de imagem disponíveis.
ar: apresenta uma visão geral do sistema
hospitalar, apresentando as tecnologias envolvidas, como os padrões Health
Leve1 Seven ( K 7 ) , Digital Imaging and Communication in Medicine
(DICOM), os sistemas Picture Archival Communication System (PACS) e o Hospital Injbrmation System (HIS).
are: apresenta uma revisão das arquiteturas física e lógica existentes, e a escolhida na implementação do software. Descreve a linguagem de programação utilizada, a interface com o usuário desenvolvida, e a técnica de streaming implementada.
inaais: conclui a dissertação Pàzendo
Inicialmente proposta em 1995, a tecnologia de streaming vem sendo cada vez mais utilizada na Intemet para a disponibilização de arquivos, principalmente, de áudio
e vídeo. Porém, para entender a necessidade desta tecnologia, é necessário compreender
como funciona o mundo da World Wide Web (WWW
-
Web), e suas lirnitagões(BATTISTI, 2002b) (KENNEDY, 1999).
No mundo web, quando um servidor recebe uma requisição de informação, ele procura obtê-la e enviá-la ao cliente que a solicitou o mais rápido possível. Após o
envio, quando a transação foi completada, o mesmo se "de~conecta~~, e fica esperando
por uma nova solicitagão. No cliente, o navegador recebe a informação, a exibe na tela, e ignora o servidor web até que o usuário acesse um outro link (BATTISTI, 2002b) (KENNEDY, 1999).
Esse procedimento é muito eficiente para textos e gráficos, que são
idomações pequenas e estáticas. Porém, para a transmissão de vídeo e áudio, por
exemplo, esta técnica não é eficiente, por exigir o completo download do arquivo para
que o mesmo seja acessado. Desta forma, para arquivos grandes, é requerido muito
tempo de download gerando um descodorto para o usuário (BATTISTI, 2002b) (KEIWEDY, 1999).
É neste contexto que surge a necessidade de uma nova técnica que seja capaz
de exibir o conteúdo solicitado para o usuário, de forma mais rápida. Uma alternativa é
iniciar a exibição enquanto o arquivo está sendo carregado. Esta técnica é denominada
ATTISTI, 2002b) (KEIWEDY, 1999).
Este capítulo apresenta na sua seg a sessão, uma descrição genérica das
técnicas de streaming e suas classificações. A terceira sessão apresenta os formatos de arquivos disponíveis para imagens digitais e suas principais características. A quarta sessão traz as técnicas e streaming para imagens, e um resumo
Streaming é um processo em que áudio, vídeo, ou qualquer outro arquivo multimídia, pode ser acessado em tempo real através da Internet ou Lneranet. Essa
tecnologia é composta de componentes de hardware e software que trabalham juntos
para criar, armazenar e distribuir os arquivos pela web, permitindo que múltiplos
usuários acessem um arquivo ao mesmo tempo (STREM~CRrlEDM, 2002).
O processo de streaming ocorre de forma similar a execução de um arquivo de vídeo ou áudio que se encontra em um CD-ROM ( S T R E M G m D I A , 2002). O arquivo a ser executado é escolhido, e então se inicia a transferência de partes do arquivo que serão executadas. Essas "partes" vão sendo exibidas, enquanto as seguintes são transferidas, até que todo o arquivo tenha sido exibido.
É importante observar que existem diferenças entre os dois processos. Em
geral, durante o streaming, o arquivo sofre uma compressão, sendo convertido para um formato especial, o que não ocorre no caso de CD-ROM9s. Além disso, ele fica armazenado em um servidor remoto, sendo acessado através da Internet/Intranet.
No streaming, estão envolvidos diversos passos, que vão desde a aquisição do arquivo, até a exibição do mesmo no computador cliente. Durante a aquisição do
arquivo, seja ele áudio, vídeo, ou ambos, a qualidade é um ponto fundamental, pois
como tem-se compressão com perda, a mesma é reduzida. Logo, se o arquivo a ser
transmitido estiver ruim, ele chegará ainda pior para o usuário. Caso o arquivo não esteja no formato digital, é necessário ainda convertê-lo, para que possa ser transmitido.
Após a aquisição do que se deseja transmitir pela Internet/Intranet, é necessário promover a compressão do arquivo, o que, em geral, já o converte para um formato especial destinado a transmissão em rede. A partir daí, ele é transmitido, de forma segmentada. O computador cliente se encarrega de receber o arquivo segmentado e convertê-lo, transformando os segmentos, para um formato que permita sua exibição.
De uma forma geral, este é o processo envolvido na tecnologia streaming. Porém, algumas diferenças e particularidades, envolvidas neste processo, permitem a classificação das técnicas em dois grupos, que são:
: onde pequenas porções do arquivo são enviadas
: realiza o download
de uma parte significativa do arquivo, antes que a visualização inicie.
Além dessa divisão, as técnicas também podem ser classificadas por utilizarem,
ou não, um servidor de Streaming (HüNTER et all, 1997). As que não possuem um
servidor utilizam o próprio protocolo WTTP, e seu servidor, para transmitir o arquivo.
As vantagens de não haver um servidor de Streaming são que há um sofhuare a menos
para se aprender, e um servidor a menos para se gerenciar, o que acaba tomando a solução economicamente mais barata.
Por outro lado, a existência do servidor toma mais eficiente a utilização da rede, além de: oferecer um arquivo de melhor qualidade ao cliente; suportar
simultaneamente um maior número de usuários; etc. Softwares comerciais como o Real
Player, o Stream Works e VDOnet S VDOLive são exemplos de produtos de streaming
de vídeo que utilizam servidor. Já o Shockwave e o VivoActive são exemplos dos que
adotam a solução sem servidor (HUNTER et all, 1997).
A técnica de streaming tem sido amplamente utilizada na atualidade, e não só
para assistir "filmes9', ou ouvir música na Internet. Muitas empresas estão utilizando
esta técnica para a comunicação Business-to-Business @2B), ensino a distância, etc.
O Iàto de a técnica de streaming permitir a visualizagão de um arquivo mesmo
antes de seu download ter sido concluído, a toma muito interessante e atrativa para ser
utilizada na área médica.
As imagens dos exames médicos são grandes, algumas chegando a ter mais de 10MBytes. Isso toma sua visualização através da rede, seja Intranet ou Intemet, algo
muito custoso e demorado. O objetivo da técnica de streaming, aplicada à área médica,
é tomar esta visualizagão mais rápida para seus usuários.
Porém, como descrito anteriormente, o processo de streaming, em geral,
envolve a compressão com perda do arquivo para reduzir seu tamanho, e tomar mais fácil e rápida a sua transmissão. Sendo assim, há uma perda na qualidade do arquivo
(BATTISTI, 2002b). Este é um grande problema, quando se trata de imagens de exames
médicos, pois a perda de qualidade pode resultar em uma análise errada do exame, ou
até mesmo impedi-la. Ou seja, é necessário o desenvolvimento de uma técnica de
Por trabalhar com o arquivo, segmentando-o para transmiti-lo na rede, é
necessário conhecer o arquivo, seu formato, e seus metadados, para se criar uma eficiente técnica de streaming.
Durante os últimos anos, diversos formatos de imagens foram criados, em sua maioria por fabricantes de hardware e software. Desta forma, gerou-se um problema: não é possível visualizar a imagem em qualquer computador d o u plataforma que se deseje (KODAK, 2003).
Com a grande demanda de aplicações, os fabricantes passaram a criar formatos mais compatíveis com as diversas plataformas, e com os diferentes fornecedores de
produtos. Com isso, é possível salvar ou abrir imagens, não só no formato proprietário,
mas também em formatos mais genéricos, como GIF, REG, dentre outros.
Desenvolvido por Aldus Corporation em 1986, e comprado pela Acrobat, este formato de arquivo foi criado especialmente para salvar imagens de scanners,
programas de retoque, etc. O
T
talvez seja um dos mais versáteis e c ~ ~ á v e i sformatos, sendo suportado em diversas plataformas (KODAK, 2003)(WAYNE, 2003). Ele escreve em arquivos grandes, utilizando esquemas de compressão com ou
sem perda. A desvantagem é que o arquivo se toma grande, sendo assim, não é muito
apropriado para a transmissão através da Internet (WAYNE, 2003).
O TIFF é um padrão quase universal, sendo utilizado por diversos fabricantes
de scanners, por exemplo. Porém, ele possui uma série de variações, como o utilizado
para o envio de documentos através do fax. Isso compromete sua portabilidade, pois é
possível que um computador não seja capaz de abrir todas as variações deste formato de arquivo (KODAK, 2003) (WAYNE, 2003).
Este formato, nativo do Macintosln, surgiu em 1 e é muito utilizado em
sem perda, porém não pode ser visualizado por programas "Windows" (KODAK, 2003) (WAYNE, 2003), comprometendo sua portabilidade.
Criado na década de 80, este é o formato utilizado para armazenar imagens de
alta resolução em arquivos PostScript, podendo ser utilizado por usuários de Windows e Macintosh (KODAK, 2003).
O EPS possui, em geral, duas partes: texto, que descreve como a imagem deve ser gerada; e, opcionalrnente, uma imagem no formato PILT para visualização antes da impressão.
Desenvolvido em 1987 pela CompuServe, é um dos formatos de arquivo de
maior sucesso, pela compressão alcançada (KODAK, 2003)(WAYNE, 2003). O G define um protocolo para transmissão e visualização, tornado-o mais independente da plataforma (KODAK, 2003).
é definido em termos de blocos e sub-blocos, que possuem as
informações necessárias para a montagem da imagem. Ele possui uma paleta de 256
cores (que é o número máximo de cores que uma imagem neste formato pode ter),
sendo que essas 256 cores podem ser quaisquer cores, não havendo necessidade de um padrão, ou algo semelhante, para a escolha delas (KODAK, 2003) (WAYNE, 2003). A
compressão usada é a LZW, que é uma técnica de compressão sem perda.
O formato de arquivo JPEG é um dos mais eficientes no que diz respeito à
redução do tamanho da imagem. Porém, isso tem um preço. Para conseguir esta
redução, é usada compressão com perda, o que sacrifica a qualidade, que não tem como
ser recuperada. Essa per a ocorre toda vez que se salva o arquivo, ocasionando a perda
de bits (dados), piorando a qualidade da imagem. Por isso, não é aconselhável
É possível utilizar o R E G em imagens coloridas, ou em tons de cinza, e até
mesmo para imagens reais, como fotografias, por exemplo. Ele é muito uiilizado na
transmissão de imagens, e em sites web, devido a seu tamanho reduzido (KODAK, 2003).
Existe também o JPE62000 que é uma evolução do formato JPEG. Ele pode
ser encarado como um mecanismo padronizado de compressão de imagem. O REG2000 pode reduzir um arquivo, utilizando compressão sem perda, de 69
1 l.$Mb, por exemplo. Al6m disso, ele preserva a transparência da imagem, e é um
formato eficiente para armazenar imagens de alta qualidade ( M I L B W , 2003).
Geralmente, este formato não possui perda de informação. Com isso, seus arquivos se tornam muito grandes. Além disso, eles só podem ser visualizados nos computadores que possuem os sistema operacional Windows, prejudicando sua portabilidade (WAYNE, 2003).
O DICOM não é um formato de arquivo propriamente dito. Usado na área
médica, ele é um padrão que especifica como as infomrações da imagem devem estar, e
como elas devem ser transmitidas entre os diversos equipamentos hospitalares (HORII, 2002).
Este formato foi desenvolvido diante da necessidade de se ter um padrão
internacional que fosse aceito por todos os fabricantes de equipamentos hospitalares, para a unificação da comunicação da informação médica sem a dependência de
programas de interface. O capítulo 3 apresentará maiores detalhes deste padrão.
É importante ser observado que o formato de imagem utilizado na
implementação deste trabalho é o DICOM, por estar em conformidade com o padrão
internacional estabelecido pelo ML7 (Health Leve1 Seven). É sobre ele que foi
As técnicas de strearning de imagens, disponíveis hoje são proprietárias. Sendo
assim, não se tem muita informação sobre como o processo de streaming é realizado.
Algumas empresas, como a Zoomzfi e RealTime Irnage, possuem famílias de softwares que permitem a transmissão de imagens grandes, em t a p o real, e com pequeno tempo de espera.
A empresa Zoornzfi possui uma série de softwares que realizam o streaming de imagens. Alguns deles, servindo como "plug-ins" para outros so@ares (como por exemplo o Flash da Macrornedia), permitem acoplar imagens grandes a filmes e animações ( Z O O m Y , 2003).
Para a realizagão do strearning, a imagem é copiada diversas vezes, com
resoluções diferentes. Depois, as imagens são "cortadas" em pedaços menores, que são guardados em um arquivo juntamente com um índice, que indica a localização exata de cada pedaço. Desta forma, tem-se uma pirâmide de resolução, como exemplifica a figura 2.1 (ZOOMIFY, 2003).
.I: Arquivo de imagem do Zoomifj
Quando a imagem é visualizada pela primeira vez, a imagem de menor
resolução na pirâmide é envidada para o usuário.
A
medida que ele solicita o zoom,apenas os pedaços necessários para completar a imagem são enviados, reduzindo o
A figura 2.2 (ZOOMIFY, 2003) exemplifica o resultado de um zoom imagem.
Imagem de Exemplo em com Zoom Imagem apOç Sfreaming
m uma
: Resultado do Streaming
Desenvolvido pela RealTime Image (que tem como parceira a empresa
Vuestec), o iPACS realiza a transmissão de imagens médicas, através de técnicas de streaming. Utilizando-se de um PC padrão, uma conexão a Internet e um navegador (no lado do cliente), ele possibilita o acesso do usuário a imagens de exames médicos, em tempo real, sem a necessidade de grandes tempos de download @FiALTIII/TE IMAGE, 2003).
A técnica de streaming utilizada pelo iPACS é denominada Pixels-on-
~ e m a n d . Ela permite a transmissão da imagem em tempo real, sem perda de qualidade e sem necessidade de duplicação dos arquivos de imagem. Ela foi desenvolvida pensando na forma como o olho humano processa a informagão. As partes mais importantes e relevantes da imagem são enviadas primeiro, permitindo a visualizagão de uma parte significativa da imagem em pouco tempo (REALTIME IMAGE, 2003).
Alkm da possibilidade de o usuário observar a imagem enquanto o download está sendo realizado, é possível utilizar o modo "Oncall". Esta outra opção de visualização disponibiliza as imagens para visualização e manipulação somente quando o download foi completamente realizado (REALTIME IMAGE, 2003).
A integração do iPACS com o sistema hospitalar já existente é fácil, já que ele
pode ser integrado facilmente a rede DICOM, ou mesmo diretamente a uma rede LAN
A técnica de streaming implementada, de acordo com a classificagão das técnicas apresentada anteriormente, é sem servidor, pois utiliza o próprio protocolo
HTTP para transmitir a informação, e é True Streaming, já que a imagem é exibida a
pariir do primeiro "pacote99 de informagão que chega no cliente.
Para o streaming das imagens, utilizou-se a técnica de histograma, combinada com técnicas de endereço, subtração e redução.
O histograma representa, para a imagem, quantos pixels cada nível de
intensidade (tons de cinza) a imagem possui (STREAILIINGMEDIA, 2002). Servindo como instrumento que determina as cores mais relevantes da imagem, o histograma fornece subsídios para a ordenação do envio das cores, da mais incidente para a menos, permitindo uma percepgão visual mais rápida da imagem.
A técnica de endereço é uma compressão sem perda. Se houver uma seqüência
de pixels com a mesma intensidade, apenas o primeiro e o último pixels (seus endereços) serão enviados, reduzindo a quantidade de informação a ser iransmitida.
Essa técnica é uma variação da técnica de compressão RLE (Run Length Encoding).
A técnica de subtração consiste em uma comparação entre duas imagens consecutivas de uma série, para que sejam enviados apenas os pixels diferentes. Esse processo ocorre da seguinte forma: a partir da segunda imagem da série a ser transmitida, verifica-se o que esta imagem tem de diferente da anterior, e transmite-se apenas as diferengas, evitando o reenvio das partes iguais.
A técnica de redução consiste em diminuir o tamanho da imagem (tanio em largura quanto em altura) por um determinado fator, e enviar apenas parte dos pixels, de forma que a imagem não fique deformada, e não aparente perda de qualidade. Essa
técnica é utilizada apenas na lista de imagens que serve para o usuário escolher com
qual efetivamente irá irabalhar. Após essa escolha, a imagem é completada, não
havendo nenhuma perda de informagão.
Ao passar pelas técnicas apresentadas anteriormente, a imagem é discretizada
em seu espaço de cor (tons de cinza), para que as partes mais significativas sejam enviadas primeiro. Assim, as cores que estão em maior ntimero (pixels) são rimeiramente envi as. Ao chegar no cliente, a imagem é facilmente "remontada" e
O processo de streaming desenvolvido será detalhado no capítulo 4, onde serão apresentadas a arquitetura do software, e toda a parte técnica envolvida.
Para compreender melhor o processo de streaming das imagens médicas, e as
dificuldades envolvidas, é necessário conhecer o ambiente onde isso ocorre. O próximo
A área médica vem enfrentando um grande desafio: tomar o atendimento ao paciente cada vez melhor e mais eficiente, sem aumentar demais seus custos ATTISTI, 2002a). Com isso, aumentou-se o foco no controle de custos, tornando cada vez mais importante o controle das informações hospitalares.
A informação de um hospital envolve as especialidades médicas, histórico dos pacientes, dados laboratoriais, dados financeiros, etc, tomando a quantidade de documentos e informações grande demais para se trabalhar e gerenciar. Por isso, um
diferencial para clínicas e hospitais é a capacidade de trabalhar de forma mais rápida e
eficiente com estas informações (BATTISTI, 2002a).
Diante de todos estes desafios, os hospitais e clínicas passaram a utilizar a tecnologia para armazenar seus dados, no computador em formato digital, sejam eles administrativos ou prontuários de pacientes. Sendo assim, surgiram vários sistemas para controlar todo este conjunto de informações. Estes sistemas auxiliam muito a tarefa na
área em que atuam, mas não se comunicam (BATTISTI, 2002a), e o ideal é que as
informqões estejam integradas, compondo um sistema único, regido por um padrão internacional que regulamente esta integração.
Para suprir esta necessidade, começaram a surgir sistemas capazes de integrar
as informações hospitalares, Hospital Information System (HIS - Sistema de
Informação Hospitalar), exigindo o surgimento de um padrão internacional para
integração da informação médica, o Health Level Seven (HL7).
Neste capítulo, a sessão 3.2 apresenta o padrão Health Level Seven (NL7) que
regulamenta toda a troca de informação entre os sistemas médicos. A sessão 3.3
apresenta os sistemas S, que são responsáveis pela inkgração das informações
hospitalares. A sessão seguinte apresenta o sistema Picture Archival Communication
ACS), que é responsável pela aquisição, visualização e armazenamento das
imagens médicas digitais. Em seguida, na sessão 3.5, é apresentado o padrgo
responsável pela comunicação das imagens propriamente dita. É este padrão que dá suporte ao PACS.
O Nealth Leve1 Seven (HL7) é uma organizagão voluntária e sem fins
lucrativos da American National Standards Institute (ANSI) que desenvolve normas e
padrões para a área de saúde. Sua missão é fornecer padrões para a troca, gerenciamento
e integração de dados clínicos e administrativos do sistema hospitalar (WL7 ORG, 2003) (GUALBERTO et al., 2003).
A organização HL7 é composta por provedores, vendedores, grupos
governamentais, e pessoas que t2m interesse no desenvolvimento de padrões para a área médica. Os membros formam os chamados Grupos de Trabalho, e estão organizados em comitês técnicos, e grupos de interesses especiais. Os comitês técnicos são responsáveis pelo padrão em si. Os grupos de interesses especiais, são responsáveis por explorar novas áreas que devem ser abrangidas pelo WL7 (HL7 ORG, 2003) (GUALBERTO et al., 2003).
O "Nível Sete" do nome desta organizagão vêm da camada de mais alto nível do modelo ISO-OSI' de comunicação de uma rede: a camada de aplicação. O sétimo nível suporta fun&ões como segurança, identificação, mecanismos de negociação e estrutura de troca de dados (HL7 ORG, 2003).
Existem diversos padrões para a área de saúde, porém o mais utilizado e
difúndido é o HL4, pois, ao contrário de outros padrões, trata de todas as informações
presentes na área médica, e não de um departamento em particular (HL7 ORG, 2003). O padrão HL7 possui uma série de trabalhos e iniciativas, como, por exemplo, (HL7 ORG, 2003):
I [
: que é um ponto fundamental dopadrão. Este modelo é uma representação dos dados clínicos (domínios),
identificando os ciclos de vida dos eventos que as mensagens, ou os grupos de mensagens relacionadas, irão transportar.
Este modelo será melhor explicado na sessão 3.5.2, que trata da forma de Comunicação do padrão DICOM.
lates: que são uma estrutura de dados, baseada no RIM, que
detemina os dados necessários em uma área clínica específica, ou em um contexto administrativo.
k i o : que é um padrão que deternina o significado dos dados codificados. Muitas vezes, os dados transmitidos são codificados, o que os torna inúteis se não houver um padrão bem definido que permita que ambos os lados (transmissor e receptor) conheçam o significado exato, sem ambigüidade dos dados. O Vocabulário permite a troca de informações clínicas e administrativas entre sistemas diferentes.
L: a tecnologia XML (Extensible Markup Language) foi desenvolvida
para descrever dados. Esta linguagem é muito semelhante ao HTML, porém
suas tags não são pré-definidas. O XML é utilizado no HL7 para toda troca
de informação entre sistemas (HL7 ORG, 2003).
O sucesso das versões 2.x do HL7 é muito atribuído à sua flexibilidade. Essas
versões contêm muitos elementos e segmentos de dados opcionais, tornando-o muito adaptável. Porém, essa adaptabilidade traz um problema, pois torna quase impossível a criação de um grupo de testes único para todas as implementações, forçando os irnplementadores a gastar mais tempo analisando, planejando e testando as interfaces entre os sistemas, para garantir a comunicação (HL7 ORG, 2003).
A versão 3 deste padrão traz uma metodologia bem definida, baseada no
Reference Information Model (RIM), ou seja, em dados. Usando uma rigorosa análise e
técnicas de construção de mensagens, e incorporando mais eventos de trigger e formatos de mensagens com poucos pontos opcionais, esta versão traz a vantagem de fornecer um padrão mais fácil de testar, além de permitir a certificação a fornecedores. Esta versão utiliza a metodologia de desenvolvimento orientado a objeto @L7 ORG, 2003).
Em uma clínica ou hospital, é comum a existência de sistemas para tratar de
departamentos, como radiologia (RIS - Radiology Information System) e farmácia (PIS
-
Pharmacy Information System); sistemas clínicos (CIS - Qflinical Information System)que são centrados nos acientes e nos procedimentos icos; além de sistemas
Porém, seria muito mais útil se todos esses sistemas fossem integrados,
permitindo a troca de informação entre eles. Esse é um sistema HIS ideal, que integra
informações tanto financeiras como clínicas, auxiliando na administração das transações diárias do hospital (GANNOT, 2003).
O HIS compõe o núcleo central de toda informação hospitalar, abrangendo desde a área administrativa, como contabilidade e recursos humanos, por exemplo, até a área de prontuário de pacientes, o setor laboratorial, radiologia, e demais áreas do hospital. A figura 3.1 ilustra este sistema.
Uma das informações geridas por esse sistema são as informações digitais. Dentre elas, destacam-se as imagens digitais geradas em exames de Raio-X, Ressonância Magnética, etc.
A grande quantidade de imagens digitais produzidas para diagnóstico tornou
complicada a sua manipulação e seu armazenamento. Por isso, tornou-se necessária a criação de um mecanismo de manipulação e armazenamento dessas imagens em dispositivos conectados em rede, levando em conta a facilidade, rapidez, segurança e o acesso a imagens de qualidade.
Para atender a essa necessidade da área médica, foi criado o PACS, que possui
as funcionalidades de gerenciar: a aquisição de em; o urmazenamento de
informação; a distribuição e visualização de imagens (consulta, interpretação ou diagnóstico); o registro ale resultados (laudos); a interface com outros sistemas; a comunka&ão remota e a segurança do sistema (MARTÍNEZ, et all, 2003).
Algumas das vantagens do PACS estão relacionadas a uma percepção de centralizagão das imagens, pelo usuário, mesmo que elas estejam em bancos de dados
distribuídos (Mini PACS). Além disso, o sistema garante a segurança e preservagão da
informação médica, por possuir urna camada de software controlando o acesso de
múltiplos usuários às imagens.
Para pesmitir que o PACS tenha todas estas funcionalidades, é necessária uma
série de equipamentos trabalhando em conjunto, cada um com uma funcionalidade específica. A figura 3.2 ilustra os componentes de um sistema PACS (MARTÍNEZ, et all, 2003).
Estação de rabaiho para
: Componentes de um sistema PACS
Porém, há um outro problema a ser resolvido. Existem diversos fabricantes de dispositivos de aquisigão de imagens, de componentes de rede, além de diversos fosmatos de imagem. Desta forma, tomou-se necessária a criação de um padrão de comunicação e armazenamento destas imagens, para que os dispositivos dos diversos fabricantes pudessem trabalhar em conjunto, sem a necessidade de programas de
- Application Program Inkerface) entre eles (RICKARDS, 2003). Este
padrão, conhecido como DICOM, faz parte do PACS, e fornece todo o suposte de rede as suas atividades.
O primeiro padrão internacional criado para a comunicação de imagens foi o
American College of Radiology - National Electrical Manufacturers ' Association
(ACR-NEMA), para uma rede ponto-a-ponto. Porém, com a rápida evolução das redes de computadores, uma comunicação ponto-a-ponto tornou-se limitada. Por isso, o padrão ACR-NEMA foi redesenhado, de forma a abranger as novas tecnologias de rede.
O resultado deste trabalho foi o Digital Imaging and Communication in Medicine
(DICOM) (HORII, 2002).
O padrão DICOM contém uma especificação detalhada que descreve: o "formato" da imagem; suas informações agregadas; e como ela deve ser transmitida entre os equipamentos hospitalares (RICKARDS, 2003). Desta forma, o DICOM facilita a interoperabilidade dos equipamentos de imagens médicas ao especificar um conjunto de protocolos que devem ser seguidos, a sintaxe e a semântica dos comandos, e as informaqões que devem ser fornecidas nas implementações dos equipamentos que estão em conformidade com o padrão (LEAD TECHNOLOGIES, 2003b). Além disso,
ele é flexível na definição de novos serviços (MART~EZ, et all, 2003).
Por ser um padrão extremamente adaptável, o DICOM deixou de ser utilizado apenas em radiologia, passando a ser adotado em diversas áreas que geram imagens, como patologia, endoscopia, etc (HORII, 2002). A figura 3.3 abaixo exibe o escopo do DICOM (LEAD TECHNOLOGIES, 2003b):
: Escopo do padrão DICOM
Atualmente a maior parte dos equipamentos médicos é compatível com este
(Comitâ Europâen de Normalisation) o utiliza como base para o MEDICOM. No Japão, a "Japanese Industry Association of Radiation Apparatus" e o Centro de Desenvolvimento de Sistemas de Informação Médica estão adotando o DICOM nos
seus padrões de processamento de imagens médicas (IIORZT, 2002) (RICKARDS,
2003).
Para que a imagem seja transferida, é necessário que ela tenha um formato predeterminado, descrito pelo padrão. Com isso, todas as imagens que seguem esse padrão são denominadas como sendo do formato DICOM (RORD36N, 2002).
Uma imagem DICOM é composta por um cabeçalho, que contém informações
sobre o paciente e sobre o exame, pela imagem em si (que pode conter informaqões em três dimensões, ou seja imagens tri-dimensionais) (RORDEN, 2002)(LEAD
TECIIONOLOiGIES, 2003a), e por um prefixo de 4 bytes "DICM" (LEAD
TECHONOLOGIES, 2003a).
A figura 3.4 ilustra como seria um arquivo de imagem DICOM:
-
: Ilustrando um arquivo DICOM
Como ilustrado acima, o cabeqalho armazena informações sobre a imagem, como as dimensões, por exemplo. Além disso, pode armazenar informações sobre o exame, como a data da realização, o dispositivo utilizado, o médico que solicitou, etc. O cabeçalho armazena também, informações sobre o paciente, como nome, data de nascimento, sexo, etc.
A figura 3.5 abaixo exibe um exemplo de um cabeçalho e sua imagem DICOM:
: Detalhando um arquivo DICOM
Não é obrigatório que o cabeçalho, que possui o tamanho de 128 bytes, esteja
preenchido por informações. Ele pode estar "vazio", preenchido apenas pelo valor "OOH", que indica que ele não possui informação (LEAD TECHONOLOGES, 2003a).
A definição do formato das imagens é apenas um dos pontos do padrão
DICOM. Ele descreve também como deve ocorrer a transmissão destas imagens.
Como já foi dito, o objetivo do padrão DICOM é descrever um conjunto de
regras uniformes e bem compreendidas para a comunicação de imagens médicas (HORII, 2002).
Em geral, quando se fala de troca de informação em computação, logo se imagina um modelo em camadas, cada uma desenvolvendo uma tarefa específica. Na
verdade, este modelo é parte de um padrão internacional de comunicação denominado
International Standards Organization Open System Interconnection (ISO-OSI) Reference Model. A figura 3.6 ilustra esse modelo. Como se observa, a camada mais
inferior (Física) é a que realiza a conexão com o meio físico, enquanto a superior
(Aplicação) é a que realiza a intentàce com o usuário. As camadas intermediárias são
responsáveis, por ex 10, pelos-protocolos de comunicação, pela correção de erros,
onexáo Física
I I L-' I
: Modelo de comunicação
Cada camada recebe uma entrada da camada superior, executa uma determinada tarefa, e fornece o resultado para a camada inferior. O fluxo pode ocorrer
também no sentido oposto, já que a comunicação é bidirecional.
Os protocolos das camadas superiores, definidos pelo DICOM, são os próprios protocolos do modelo ISO-OSI, o que garante a comunicação entre aplicações DICOM de forma eficiente e coordenada (LEAD TECHNOLOGIES, 2003b).
A vantagem do modelo de camadas é que uma camada pode ser substituída
sem afetar as demais (HORII, 2002), desde que as informações de entradas e saídas sejam respeitadas.
O padrão DICOM utiliza este modelo em camadas para a comunicação e
transmissão das imagens, ao invés de criar um modelo próprio. O modelo OS1 é
amplamente utilizado no mundo da computação, o que traz vantagens significativas no uso do DICOM, pois se torna desnecessária a criação ou adaptagão de equipamentos de rede já existentes, bem como a alteração da infra-estrutura de rede hospitalar para transmissão destas imagens.
Além do modelo OSI, o padrão DICOM suporta a comunicação através do protocolo TCPDP, facilitando mais ainda sua utilização (LEBD TECHNOLOGIES, 2003b). Essa possibilidade de se ter comunicação via ISO-OS1 e TCPIIP, permite a migração de um tipo de comunicação para outro, sem impacto na aplicação. A figura 3.4 ilustra a comunicação do DICOM através do protocolo TCP/IIP, pelo modelo ISO- OSI, e pela comunicação ponto-a-ponto, a primeira implementada pelo DICO
f
.
DIC OM Sessionf Tí-anspori/ Nehivork @TN) DIC OM Data Link DICOM Pkysical (5 O-p in) ,OS1 Association Contr-o
I
OS1 Presentation Kwiel1
OS1 Session KernelOS1 Transpost. OS1 Network
I
LLCStandafd network physical layer
I
(Ethwiet, FDDI, ISDN, etc) Point-to-Point Network EnvironmentEnvironment
-7: Arquitetura de Comunicação do DICOM
A forma como o padrão DICOM especifica os protocolos e a interface do meio físico, permite que um componente que possui uma interface de rede ponto-a-ponto se comunique com uma rede que utiliza o modelo OSI, sendo necessário apenas uma
unidade de interface de rede (Network Interface Unit - NIU). A figura 3.8 ilustra como
: Comunicação Ponto-a-Ponto com OS1
Porém, o DICOM não determina somente o formato da imagem, e como enviá- la em uma rede de computadores. Este padrão especifica também os objetos que estão envolvidos em todo o processo, bem como a relação entre eles.
0 modelo de dados fornecido pelo DICOM não é composto apenas de tabelas.
Ele explicita todo o relacionamento, a interação e a hierarquia entre os objetos. A figura
3.9 apresenta o modelo de dados completo. É importante observar que este modelo
: Modelo de dados do DIGOM
Na figura acima, os retângulos representam as entidades, os losangos os
relacionamentos. A sigla IOD significa Informatio Object DeJinition, VOI Value of
Interest, e a LUT significa Lookup Table Modality.
Neste trabalho foi utilizado um modelo simplificado, que trata da relaqão entre
: Modelo DICOM simplificado
Como mostrado neste capítulo, o DICOM, o PACS e o HIS trabalham em
conjunto, formando todo o ambiente de informações digitais da área médica. O PACS é
um dos sistemas que compõem o HIS, e o DICOM é o suporte para toda a rede PACS.
A figura 3.1 1 ilustra esta situação, apresentando a interligação entre eles.
.I 1 : Integração HISPACSíDICOM
No próximo capítulo, serão apresentados a arquitetura do so@are, a
No desenvolvimento de software, várias questões estão envolvidas, como: as funcionalidades desejadas; a arquitetura a ser utilizada; tanto do ponto de vista lógico como físico; a linguagem de programação mais adequada; e o ambiente onde o software estará inserido.
O sofiare desenvolvido nesta dissertação, denominado WebMedViewer, visa disponibilizar, em tempo real, imagens médicas através de uma rede Intranet/Internet, possibilitando que o usuário mkdico realize a análise de exames das diversas modalidades.
Para que isso seja possível, vários pontos devem ser considerados, além da interface com o usuário a ser criada, e a técnica de streaming para a transmissão da
imagem.
6 necessário, também, conhecer e escolher a arquitetura, assim como os
softwares de "'in6.a-estrutura" que darão suporte ao sistema, e a linguagem de programação utilizada.
Neste capítulo são apresentadas, na sessão 4.2, as diversas arquiteturas físicas existentes, e aquela escolhida para irnplementação desta dissertação. A sessão 4.3 descreve a linguagem de programação utilizada, sua estrutura e suas vantagens. Em
seguida, na sessão 4.4, é detalhada a interface com o usuário. Por último, é apresentada
a técnica de streaming implementada.
Em uma empresa, os sistemas de informação se apoiam na arquitetura de informação (INEI, 2002). Inicialmente, a arquitetura dos sistemas de informação eram centralizadas. Os mainzames eram responsáveis por tudo, gerenciamento dos dados, consulta, interface com o usuário, etc. Com o passar do tempo, este tipo de arquitetura passou a ser ine ciente, não satisfazendo mais as necessidades das empresas, gerando a uma nova arquitetura. Assim, iniciou-se a descentralizagão de dados e
recursos de processamento. Foi neste ambiente que surgiu a arquitetura clientelservidor
(BATTISTI, 2002a), que foi tão utilizada, e ainda é, por diversas empresas em todo o
mundo.
A arquitetura clientelservidor em duas camadas consiste em uma ou mais máquinas que atuam como servidores, disponibilizando recursos para os demais computadores, que atuam como clientes. Com isso, tem-se servidor de arquivos, de banco de dados, de impressão, etc (BATTISTI, 2002a). A figura 4.1 ilustra esta arquitetura.
Clienie Cliente Cliente
: Arquitetura Cliente-Servidor.
É importante observar, que não 6 obrigatório haver uma máquina para cada
serviço. Pode-se ter o servidor de banco de dados e de arquivos em um mesmo computador.
No modelo em duas camadas, tem-se um programa instalado em cada máquina
cliente, que é responsável pelo acesso aos dados armazenados no servidor. Neste tipo de
arquitetura, o servidor de banco de dados, por exemplo, é responsável apenas por
armazenar e gerenciar as informações. Já o software cliente é responsável pela interface
com o usuário (porção gráfica do sofiare), e pela lógica do negócio (regras que definem o processamento da informação) (BATTISTI, 2002a). A lógica do negócio engloba desde a consulta e inserção de dados no banco de dados, até, por exemplo, o cálculo de tarifas e escontos em so4;twares de comércio.
A primeira versZo desenvolvida nesta dissertação foi em duas camadas. Sendo assim, o sojtware, um aplicativo Java, era responsável pela interface com o usuário e pela consulta ao banco de dados, localizado em um servidor. A figura 4.2 ilustra a arquitetura desta primeira versão.
Cliente Cliente Cliente cliente
I
: Arquitetura em duas camadas
Esta implementação não contém nenhuma parte de streaming de imagem, pois, por ser em duas camadas, o servidor de banco de dados não processa a imagem antes de
enviá-la, e o aplicativo (no cliente), não tem como fazê-lo, pois a imagem não é local.
O modelo de duas camadas 6 muito utilizado, porém, possui urna série de desvantagens. Por exemplo, se for realizada uma alteragão na interface ou nas regras de negócio, o so4i;ware terá que ser reinstalado em todas as máquinas clientes, mesmo que a alteração tenha sido mínima. Isso gera um grande problema de controle de versão, já
que é extremamente complicado gerenciar qual versão está instalada em cada cliente
ATTISTI, 2002a).
Há também o conhecido "iderno das DLL's9', onde os aplicativos instalam diferentes versões de uma mesma DLL, prejudicando o funcionamento de outros programas (BATTISTI, 2002a). Como o software desenvolvido nesta dissertação não implementa nenhuma DLL, não há o risco de ocorrer este tipo de problema.
A evolução do modelo de duas camadas veio com o crescimento da Internet, surgindo assim, o modelo em três camadas. Este modelo consiste em retirar a lógica do negócio do cliente, e colocá-lo em um servidor de aplicações. Desta forma, a atualização da lógica do negócio não requer a reinstalação do soJÉware em todos os clientes (BATTISTI, 2002a). A figura 4.3 ilustra esta arquitetura.
Sewidou d e BD Sewidor do, Atrilica~ões
I
lie ente Cliente Cliente Cl i e )?te: Arquitetura em três camadas
Como se pode observar na figura acima, o cliente acessa o banco de dados de acordo com as regras de negócio presentes no servidor de aplicações. Desta forma, tem- se as três camadas, que são PATTISTI, 2002a):
$ação: que é a interface com o usuário. Esta camada continua no
software instalado no cliente, ou seja, qualquer alteração na interface com o
usuário gera a necessidade de reinstalação do software.
6cio: que são as regras do negócio, que determinam como os
dados serão acessados, utilizados, etc. Ao separar a lógica do negócio em um servidor, qualquer alteração realizada nas regras será automaticamente enxergada pelos clientes, sem a necessidade de uma reinstalação do programa.
os: que são os dados armazenados no servidor de banco de dados,
necessários para o funcionamento da aplicação. Como já foi dito anteriormente, os dados são acessados apenas pelo servidor de aplicação, e não mais pelo cliente.
Esta arquitetura resolveu um problema da arquitetura em duas camadas: a instalação de uma nova versão da aplicação cliente toda vez que uma regra de negócio fosse alterada. Porém, o problema da alteração na interface continua. Se algo for mudado, por menor e mais insignificante que seja, será necessário reinstalar o s o f i a r e
em todos os clientes.
Para resolver este problema, surgiu o modelo de quatro camadas. Esta arquitetura retira a camada de apresentação do cliente, centralizando-a em um servidor
web. Desta forma, o cliente passa a 66buscar" a inteirface, através
atualizada. Ao se alterar a interface, basta atualizá-la no servidor web, que todos os clientes terão acesso (BATTISTI, 2002b). A figura 4.4 exibe esta arquitetura:
Servidor Servidor de
d e
BD
Servidor bYeb Aplica@es--- Fluxc
I
1
-
Rede: Arquitetura em quatro camadas
Da mesma forma que na arquitetura de três camadas, todo acesso ao banco de
dados é regulamentado pelo servidor de aplicação. As camadas do modelo são
(BATTISTI, 2002b):
te: que é o navegador. Para acessar a aplicação, o cliente precisa apenas
digitar um endereço web em seu navegador.
resentaçãio: que é o servidor web. A interface pode ser feita utilizando-se qualquer tecnologia capaz de gerar páginas no navegador. Vale reforçar, que qualquer atualização da interface necessita ser feita apenas no servidor web. Desta forma, todos os clientes possuem acesso a versão mais atualizada do software.
ica: são as regras que determinam como os dados serão utilizados. Assim
como no modelo em três camadas, por estar em um servidor próprio (o servidor de aplicações) toda atualização necessita ser realizada apenas no servidor de aplicações, garantindo que todos os clientes tenham automaticamente acesso, de forma indireta, através do servidor web.
os: é o servidor de banco de dados, com todas as informações necessárias
para a aplicação.
A aplicação desenvolvida, que antes estava em duas camadas, foi alterada passando para o modelo em quatro camadas. Como se pode observar na figura 4.5, tem- se o cliente com um navegador, o servi or web com a interface com o usuário, o servidor de aplicação com toda a lógica do negócio, e o servidor de banco de dados.
: Arquitetura com os componentes utilizados
É importante observar que não há a necessidade de os servidores estarem
fisicamente em máquinas separadas. Pode-se ter o servidor de banco de dados, o
servidor de aplicações e o servidor web em apenas um computador.
O cliente, como dito anteriormente, precisa ter instalado apenas um navegador que suporte programas escritos na linguagem de programação escolhida para o desenvolvimento, o Java.
O servidor web utilizado foi Internet Information Service (11s) da Microsoft.
O servidor de aplicações, foi o JRun, da MacroMedia. Ele é responsável por
fornecer ao servidor web todas as requisições feitas pelo cliente. O JRun contém o
programa que realiza a consulta ao banco de dados, e busca as imagens para serem
exibidas, sendo o responsável pelo stveaming da imagem.
O servidor de banco de dados utilizado foi o SQL Server 2000 da Microsoft.
Porém, como dito anteriormente, a imagem está no formato DICOM, ou seja, ela é um
metadado contendo todas as informações que devem ser armazenadas no banco de
dados. O SQL Sewer não é capaz de extrair da imagem as informações necessárias para
criar e povoar o banco de dados. Por isso, tem-se o Coquest trabalhando em conjunto
com o SQL Server.
O Conquest é um servidor DICOM que extrai as informações do cabeçalho da
imagem, e insere essas informações nas tabelas corretas do SQL Server. Para a
aplicação, o Conquest é transparente, ou seja, ela trabalha diretamente com o servidor
de banco de Dados Server. Porém, sem o Conquest as informações teriam que ser
: Conquest e SQL Server
Como se pode observar, novas imagens geradas nos aparelhos de exame (ressonância magnética, Raio-X, Ultra-Som, etc) são enviadas para o Conquest, que extrai as informações e as envia para as tabelas do SQL Server.
É importante observar que tanto o servidor web, quanto o de aplicação e o de
banco de dados podem ser alterados. O software não utiliza nenhuma particularidade de nenhum deles.
Tão importante quanto a arquitetura e a infra-estrutura para o sofiare, é a
linguagem de programação. É ela que possibilita a implementagão de todas as camadas
do so@are, incluindo-se a interface com o usuário.
A linguagem de programação utilizada para desenvolver este trabalho foi a linguagem Java.
Esta é uma linguagem de programação orientada a objetos desenvolvida pela
Sun Microsystems, em 1991, como parte de um projeto de pesquisa destinado à criação
de software para dispositivos eletr6nicos (equipamentos para televisão, videocassetes,
torradeiras, etc) (C
,
1999) (CURSO IBM DE PROGRAMAÇÃO, 1999)(MOIRRISON, 1999).
Ela foi concebida a partir do C++ para ser compacta, simples, rápida e eficiente, sendo capaz de realizar as mesmas tarefas e resolver o mesmo tipo de problema que outras linguagens de programação. Além disso, a linguagem Java foi feita
essa uma de suas vantagens mais características sobre outras linguagens ( C W , 1999) (CURSO B M DE PROGRAMAÇÃO, 1999).
A portabilidade do Java só é possível por dois motivos principais: Java é uma
linguagem interpretada e suas bibliotecas são construídas de forma a não haver necessidade de se alterar o código inter-plataforma (CURSO TFIM DE
PROGWÇÃO, 1999).
No primeiro caso, o código fonte é passado para o formato denominado
bytecode que é interpretado pela Máquina Virtual Java (Java Virtual Machine, também
conhecida pelas siglas JVM e MVJ). A JVM garante que um mesmo código em bytecode será executado em qualquer plataforma, pois funciona como um processador
Java, sendo uma camada entre o arquivo bytecode e a CPU. Na figura 4.7, pode-se
observar que existe apenas um arquivo bytecode e várias JVMs, uma para cada plataforma, não existindo um arquivo executável.
JVM
Sun
.7: Máquina Virtual Java para diversas platafomas
No segundo caso, a portabilidade se dá no nível de código fonte. Suas bibliotecas são escritas de forma que o código não necessita ser reescrito ao se mudar de
plataforma. As chamadas dos mktodos são sempre as mesmas. Um exemplo claro é o
pacote Abstract Window Toolkit (AWT), que fornece um conjunto de classes independentes de plataforma que cuidam das operações gráficas. Com isso, ao se criar
um botão, ou qualquer outro componente de interface, seu aspecto é diferente em cada
plataforma, pois é uti izado o botão padrão d ela plataforma. orém, o código fonte
Java é o mesmo.
Tem-se também a biblioteca Swing, incorporada posteriormente, que é uma
o AWT. Esta agregou novos componentes e funcionalidades, como por exemplo, a não necessidade de se utilizar componentes do sistema operacional no qual o
em qualquer plataforma. Esta é a grande diferença entre AWT e Swing: o primeiro se baseia no sistema em que o aplicativo está rodando, enquanto o segundo não utiliza nenhum código nativo. No software WebMedViewer implementado, foram utilizadas as duas classes de interface com o usuário.
A portabilidade do Java o torna ideal para a distribuição de programas
executáveis através da Internet, onde há grande variedade de plataformas. Esse foi um
ponto determinante na escolha desta linguagem, já que o objetivo do trabalho é permitir
a visualização de imagens pela Internet.
Com o Java, pode-se criar dois tipos de programa: applets e aplicativos. Uma
applet é um programa dinâmico e interativo que pode ser executado em um navegador
web ou em um visualizador de applets (AppletMewer). Isso lhe traz a vantagem de já ter uma janela de programa e a capacidade de responder aos eventos da interface com o
usuário por meio do browser. A applet é mais segura que o aplicativo, já que possui
acesso restrito ao sistema de arquivos, tanto na máquina local, onde está sendo executada, quanto nas máquinas em rede, fato este de responsabilidade da própria linguagem Java, por encarar os programas de forma diferente (CHAN, 1999).
Um aplicativo, por sua vez, é um programa que roda independente do browser,
podendo funcionar isoladamente. O aplicativo pode ser executado através de linhas de comando, ou pode conter interface gráfica, com janelas, botões, etc.
No so&are implementado, tem-se uma applet de pesquisa chamando
aplicativos de visualização. Porém, como o aplicativo está sendo executado a partir da applet, ele possui as mesmas restrições de acesso, aumentando a segurança do sofmare.
ste esquema de seguraqa nativo da linguagem Java, foi outro ponto importante na sua escolha.
Como dito anteriormente, uma applet não pode acessar arquivos da máquina local, nem arquivos ou banco de dados, que não estejam em seu diretório na máquina de
origem. Isso gera um problema, já que é necessário realizar consultas a banco de dados,
e leihirdprocessamento dos arquivos de imagem. Para resolver este problema, foram utilizados os servlets.
Os servlets Java são programas Java utilizados para expandir, ou aperfeiçoar as funcionalidades do servidor. Eles emitem que o desenvolvedor estenda e personalize o servidor com portabilidade, flexibilidade e facilidade (OLIVEIRA, 2003). O servlet está para o servidor, assim como a applet está para o navegador.
