UMA IMPLEMENTAÇÃO DE UM FRONT END PARA O SERVIDOR DICOM OFFIS

Transcrição

1 UNIVERSIDADE DO PLANALTO CATARINENSE DEPARTAMENTO DE CIÊNCIAS EXATAS E TECNOLÓGICAS CURSO DE INFORMÁTICA (BACHARELADO) UMA IMPLEMENTAÇÃO DE UM FRONT END PARA O SERVIDOR DICOM OFFIS OLAVO ALDÉRICO BIFFI LAGES, NOVEMBRO DE 2004

2 UNIVERSIDADE DO PLANALTO CATARINENSE DEPARTAMENTO DE CIÊNCIAS EXATAS E TECNOLÓGICAS CURSO DE INFORMÁTICA (BACHARELADO) UMA IMPLEMENTAÇÃO DE UM FRONT END PARA O SERVIDOR DICOM OFFIS Relatório do Trabalho de Conclusão de Curso submetido à Universidade do Planalto Catarinense para obtenção dos créditos de disciplina com nome equivalente no curso de Informática - Bacharelado. OLAVO ALDÉRICO BIFFI Orientador: Prof. Gilson Anselmo de Araújo, M.Sc. Co-Orientador: Prof. Emerson André Fedechem, M.Sc. LAGES, NOVEMBRO DE 2004

3 iii UMA IMPLEMENTAÇÃO DE UM FRONT END PARA O SERVIDOR DICOM OFFIS OLAVO ALDÉRICO BIFFI ESTE RELATÓRIO, DO TRABALHO DE CONCLUSÃO DE CURSO, FOI JULGADO ADEQUADO PARA OBTENÇÃO DOS CRÉDITOS DA DISCIPLINA DE TRABALHO DE CONCLUSÃO DE CURSO DO VIII SEMESTRE, OBRIGATÓRIA PARA OBTENÇÃO DO TÍTULO DE: BACHAREL EM INFORMÁTICA Prof. Gilson Anselmo de Araújo, M.Sc. Orientador Prof. Emerson André Fedechem, M.Sc. Co-Orientador BANCA EXAMINADORA: Prof. Douglas Nazareno D. Vargas, M.Sc. Universidade do Planalto Catarinense Prof. Edson Roberto Souza Paes, M.Sc. Universidade do Planalto Catarinense Prof. Angelo Augusto Frozza, Esp. Supervisor de TCC Prof. Wilson Castello Branco Neto, M.Sc. Coordenador de Curso Lages, 9 de Dezembro de 2004.

4 iv Dedico... para minha namorada Kelly, pela sua compreensão e carinho.

5 Agradeço... A minha família e amigos que compreenderam minha ausência, mesmo estando por perto. Aos mestres que se portaram como verdadeiros amigos e contribuíram para a realização deste. E, agradeço a mim mesmo, por não desistir diante das dificuldades. v

6 vi Abençoados são os fortes, pois eles possuirão a terra. Malditos são os fracos, pois esses herdarão as ruínas. (Autor desconhecido)

7 SUMÁRIO LISTA DE ILUSTRAÇÕES... IX LISTA DE SIGLAS...X RESUMO... XI ABSTRACT...XII 1 INTRODUÇÃO Apresentação Descrição do problema Justificativa Objetivo geral Objetivos específicos Metodologia PADRÃO DICOM Histórico Estrutura organizacional Grupos de trabalho Documentação do padrão DICOM PS Introduction and Overview PS 3.2 Conformance PS 3.3 Information Object Definitions PS 3.4 Service Class Specifications PS 3.5 Data Structure and Encoding PS 3.6 Data Dictionary PS 3.7 Message Exchange PS Network Communication Support for Message Exchange PS 3.9 Point to Point Communication Support for Messagem Exchange PS 3.10 ao PS 3.12 Media Storage and File Format for Media Interchange, Media Storage Application Profiles, Media Formats and Physical Media for Media Interchange PS 3.14 Grayscale Standard Display Function PS 3.15 Security Profiles PS 3.16 Contents Mapping Resource Ambiente PACS (Picture Archiving and Communications System) Definição...Erro! Indicador não definido.

8 viii Vantagens da utilização de um PACS Exemplos de PACS no Brasil Conclusão SERVIDOR DICOM OFFIS Breve descrição Funcionalidades Funções implementadas pelo servidor Aplicação storescp Aplicação storescu Aplicação findscu Aplicação movescu Aplicação imagectn Conclusão DESENVOLVIMENTO DO PROTÓTIPO Introdução Descrição do protótipo Casos de uso Diagrama de classes Conclusão DOCUMENTAÇÃO DA APLICAÇÃO Pré-requisitos de hardware e software Procedimentos para instalação e configuração do OFFIS Instalação e configuração da aplicação desenvolvida Procedimentos de utilização Iniciar, parar e reiniciar o servidor Pesquisar imagens Buscar imagem Enviar imagem Conclusão CONSIDERAÇÕES FINAIS...50 REFERÊNCIAS BIBLIOGRÁFICAS...52 BIBLIOGRAFIA COMPLEMENTAR...54

9 LISTA DE ILUSTRAÇÕES FIGURA 1 - Exemplo da estrutura de um PACS...17 FIGURA 2 - Estrutura do PACS do Instituto do Coração de São Paulo...19 FIGURA 3 - Exemplo da execução da aplicação storescp FIGURA 4 - Exemplo da execução da aplicação storescu FIGURA 5 - Exemplo da utilização da aplicação dump2dcm...27 FIGURA 6 - Exemplo da utilização da aplicação findscu...28 FIGURA 7 - Conteúdo do arquivo resultado.txt...28 FIGURA 8 - Exemplo da utilização da aplicação movescu FIGURA 9 - Exemplo do arquivo de configuração da aplicação imagectn...33 FIGURA 10 - Diagrama de caso de uso...38 FIGURA 11 - Diagrama das classes preliminares...40 FIGURA 12 - Como acessar as funções iniciar, parar e reiniciar servidor...44 FIGURA 13 - Exemplo de como fazer uma pesquisa geral...46 FIGURA 14 - Exemplo de como buscar uma imagem...47 FIGURA 15 - Exemplo de como enviar uma imagem...48 FIGURA 16 - Utilizando o botão... para encontrar a imagem...49 QUADRO 2 - Descrição dos casos de uso...38

10 LISTA DE SIGLAS ARC - American College of Radiology CAD - Computer-Aided Detection / Diagnosis DCMTK - DICOM Toolkit DICOM - Digital Imaging and Communications in Medicine DIMSE - DICOM Message Service Element HIS - Hospital Information System HL7 - Health Level 7 InCor - Instituto do Coração IP - Internet Protocol ISO - Internationnal Standards Organization NEMA - National Electrical Manufacturers Association OSI - Open System Interconnection PACS - Pictures Archiving and Communication System RSNA - Radiology Society of North America SCP - Service Class Provider SCU - Service Class User TCP - Transmission Control Protocol WG - Working Group

11 RESUMO O objetivo deste trabalho é a implementação de um front end para o servidor DICOM OFFIS, visando facilitar a utilização de suas principais funcionalidades, como enviar, armazenar, pesquisar e buscar imagens DICOM. O OFFIS é um servidor de imagens médicas que funciona por linha de comando e, para utilizá-lo, demanda que se tenha conhecimento de vários comandos e sintaxes, podendo ser um problema para usuários com pouco conhecimento sobre o servidor e/ou informática. Para alcançar esse objetivo, foram realizados estudos sobre temas como: padrão DICOM; funcionamento do servidor OFFIS e como a tecnologia é utilizada nos dias atuais; ambientes PACS. Através desses estudos conseguiu-se compreender o que é o padrão DICOM e as vantagens que a utilização deste proporciona, bem como, identificar possíveis dificuldades em utilizar o OFFIS e como esse se relaciona com o padrão. Por fim, foi desenvolvido um front end em Java para o servidor OFFIS, a fim de facilitar a utilização de suas principais funções. O protótipo desenvolvido não tem fins comerciais, estando o interesse voltado para pesquisas e estudos sobre o padrão DICOM e o OFFIS. Palavras-chave: DICOM; Ambientes PACS; Imagens Médicas; OFFIS.

12 ABSTRACT The objective of this work is the implementation of one front end for server DICOM OFFIS, aiming at to facilitate the use of this main functionalities, how to send, to store, to search and to get images DICOM. The OFFIS is a server of medical images who functions for command line and to use it, demand that if has knowledge of some commands and syntaxes, being able to be a problem for users with little knowledge on the server and/or computer science. To reach this objective, studies on subjects had been carried through as: standard DICOM; functioning of server OFFIS and as the technology is used in the current days; environments PACS. Through these studies I was obtained to understand what it is the standard DICOM and the advantages that the use of this provides, as well as, to identify possible difficulties in using the OFFIS and as this if relates with the standard. Finally, front end was developed in Java for server OFFIS, in order to facilitate the use of its main functions. The developed archetype does not have commercial ends, being the interest directed toward research and studies on standard DICOM and the OFFIS. Keywords: DICOM; Environments PACS; Medical images; OFFIS.

13 1 INTRODUÇÃO 1.1 Apresentação Dentro de um ambiente clínico hospitalar, que possui um sistema de arquivamento em papel, são notáveis algumas dificuldades e falhas. Um exemplo é consulta do histórico hospitalar de um paciente dos últimos dez anos. Se esses arquivos não estiverem armazenados e organizados adequadamente, podem sofrer deteriorização e, também, corre o risco de serem perdidos, sem contar a demora para o levantamento dos dados. Contudo, com a informatização dos sistemas hospitalares, conseguiu-se suprir essa dificuldade, armazenando informações dos pacientes em formado e qualidade digital, melhorando a segurança e integridade dos dados. Com o surgimento de equipamentos geradores de imagens digitais (Tomógrafo Computadorizado, Raio- X, Ecógrafo etc.), encontrou-se outro problema. Cada equipamento possuía seu padrão proprietário para o armazenamento dos dados, o que impossibilitava a comunicação entre equipamentos de fabricantes diferentes, pois o padrão entre eles era incompatível. Portanto, surgiu a necessidade da criação de um padrão que possibilitasse a comunicação entre equipamentos de fabricantes diferentes. Então surgiu o padrão DICOM (Digital Imaging Communication in Medicine), que especifica o padrão para o armazenamento de imagens médicas digitais em meios magnéticos (SAMPAIO, 1999). Segundo TACHINARDI e FURUIE (2003, p. 100), com a criação do padrão

14 2 DICOM conseguiu-se alcançar a interoperabilidade entre os equipamentos de imagens diferentes com sistemas de informação em ambientes clínicos hospitalares, pois o padrão independe do fabricante dos equipamentos, sistema operacional e arquitetura de hardware. Com isso, pode-se conectar equipamentos de tipos diferentes em uma rede, criando o que se denomina ambiente PACS (Picture Archiving and Communication Systems), mas isso só foi possível após o lançamento do DICOM 3.0. Atualmente, a utilização de recursos, como o servidor DICOM em ambientes PACS, para o armazenamento e transmissão de imagens médicas, está crescendo no mundo. Porém, no Brasil, o padrão DICOM ainda não é largamente difundido (SAMPAIO, 1999), mas já começa a fazer parte dos grandes hospitais e universidades. Dois exemplos são os PACS do Hospital Israelita Albert Einstein e do Instituto do Coração (InCor) em São Paulo, além de outras instituições no país. Atualmente, um dos servidores DICOM free e com o código fonte disponível é o OFFIS (2004). Para se utilizar um servidor DICOM como esse, é necessário que o usuário tenha conhecimento de comandos e sintaxes complexos, pois este software apresenta a sua interface com o usuário através de linhas de comando, podendo ser um problema para usuários que não sejam da área de informática. Por esta razão, este trabalho propõe a implementação de um front end para o servidor DICOM OFFIS, visando facilitar a utilização do mesmo. Esta proposta é pioneira nessa área na UNIPLAC, portanto servirá como apoio para trabalhos futuros que tenham como tema a mesma linha de pesquisa. Inicialmente, o capítulo 1 contém a introdução, com os objetivos e justificativa deste trabalho. Já no capítulo 2 é apresentado um histórico sobre o padrão DICOM 3.0 e toda sua estrutura organizacional que é essencial para o entendimento do trabalho. Ainda, no mesmo capítulo, é feita uma introdução a ambientes PACS. No capítulo 3 descreve-se o que é um servidor DICOM, como funciona, qual o modelo de comunicação utilizado. É apresentado o Servidor DICOM OFFIS, por ele ser um servidor free e de código aberto, destacando suas principais funcionalidades. Após o embasamento teórico, a implementação é proposta no capítulo 4, incluindo a análise dos requisitos e modelagem do sistema, passando para a codificação e os testes. No

15 3 capítulo 5 é apresentada toda a documentação do servidor DICOM. E, por último, são feitas as considerações finais, com base nos resultados dos testes. 1.2 Descrição do problema Para um usuário utilizar um servidor DICOM, como por exemplo, o servidor OFFIS, demanda que se tenha conhecimento de vários comandos e sintaxes, visto que a interação com este tipo de servidor é por linha de comando. Sendo assim, existem dificuldades para usuários leigos ou com pouco conhecimento sobre o servidor ou informática. Outro problema é a pouca divulgação e esclarecimento sobre o padrão DICOM e a sua forma de comunicação, o que dificulta até na utilização do próprio software. 1.3 Justificativa Desde a publicação da primeira versão do padrão DICOM até a atual versão 3.0, poucas pessoas têm conhecimento da sua existência, utilização e benefícios. Uma das vantagens apresentadas pelo padrão DICOM é proporcionar o armazenamento, em mídia magnética (discos e fitas), de imagens digitais (exames) provenientes de equipamentos de aquisição de imagens, juntamente com seus dados relacionados (dados do paciente). Desta forma, oferece muito mais economia e segurança dos dados do que o sistema tradicional, baseado no arquivamento por meio de filme ou papel, bem como agilidade em casos de consulta a esses dados. O armazenamento e distribuição de imagens médicas digitais deixou de ser protótipo para se tornar uma necessidade dentro dos hospitais modernos. (BERTOZZO JUNIOR e FURUIE, 2002, p. 1). Visto que, com a evolução da tecnologia dos equipamentos geradores de imagens, da velocidade da comunicação através de uma rede e dos computadores com poder de processamento cada vez maiores, a padronização DICOM é apresentada como uma solução para a implantação de um sistema como esse, denominado PACS (BERTOZZO JUNIOR e FURUIE,

16 4 2002). Deste modo, para que exista o armazenamento e comunicação dessas imagens, pode-se utilizar um servidor DICOM, como o OFFIS, conectado a rede, com a finalidade de prover tais serviços. Mas, para que isso aconteça, demanda que o usuário conheça comandos operacionais de um servidor DICOM, o que pode vir a dificultar a sua utilização, já que esta operação baseia-se em linha de código. Este problema tende a agravar-se ainda mais, porque na maioria das vezes os usuários que operam o servidor são médicos e não têm muito conhecimento na área de Informática. Assim, se o servidor dispusesse de uma interface gráfica mais intuitiva e de fácil manuseio, proporcionará um maior proveito sobre as funcionalidades disponíveis e uma interatividade maior do usuário com o servidor. 1.4 Objetivo geral O objetivo geral do presente trabalho é a implementação de um front end para o servidor DICOM OFFIS e apresentar para a comunidade interessada e região uma introdução ao padrão DICOM 3.0 e ao ambiente PACS, bem como apresentar como a tecnologia está sendo utilizada pela medicina nos dias atuais, por exemplo, o caso da telemedicina. O material apresentado neste trabalho também servirá de apoio para futuros trabalhos que vierem a seguir esta linha de pesquisa. 1.5 Objetivos específicos a) Descrever o que é um servidor DICOM e as funções que o mesmo provê; b) Descrever as características e a funcionalidade do servidor DICOM OFFIS; c) Desenvolver um software que forneça uma interface gráfica mais amigável e intuitiva para trabalhar com o servidor DICOM OFFIS; d) Identificar os benefícios que a utilização do padrão DICOM pode trazer para hospitais e clínicas médicas.

17 5 e) Apresentar as vantagens da utilização de um ambiente PACS; 1.6 Metodologia Para elaboração deste trabalho foi fundamental um levantamento bibliográfico sobre o padrão DICOM, apresentando um histórico do padrão e como o mesmo foi concebido, também, a sua estrutura e organização. Após o esclarecimento e entendimento sobre o padrão DICOM, fez-se uma introdução ao ambiente PACS. Sendo assim, para uma melhor compreensão sobre este tipo de ambiente, foi realizada uma pesquisa, procurando entender o seu funcionamento e aplicação, salientando os aspectos positivos de sua utilização. Como o objetivo deste trabalho foi a implementação de uma interface para o servidor DICOM OFFIS, foi necessário um embasamento teórico sobre servidores deste tipo, exigindo que fosse feito um estudo sobre o seu comportamento e seu funcionamento em ambiente PACS. Foi essencial, descrever como ocorre o processo de comunicação DICOM, visto que está intimamente relacionado com a funcionalidade do servidor. Depois de concluídas estas etapas e obtido o entendimento destes conceitos, deu-se início à implementação proposta neste trabalho. Para começar a construção do protótipo, foi feita uma análise dos requisitos necessários e a modelagem do sistema, através de diagramas de caso de uso e classes, a fim de tornar mais fácil a compreensão e o entendimento do que está sendo proposto. Depois de todo o levantamento dos dados necessários e elaboração dos diagramas, iniciou a implementação do front end para o servidor DICOM OFFIS. Portanto, foi imprescindível a atenção e preocupação quanto ao desenvolvimento, não apenas com o design, mas também com a interatividade do sistema com o usuário. Foi importante salientar que durante esta fase do projeto, ocorreu o processo de documentação, contendo toda a explicação da funcionalidade do sistema, o qual auxiliará o usuário no entendimento e utilização do servidor. Partindo deste ponto de vista, após a finalização da implementação proposta,

18 6 iniciou-se os testes, verificando a integridade do funcionamento da interface com o servidor e, com base na análise dos resultados encontrados, foram feitas as considerações finais.

19 2 PADRÃO DICOM A fim de esclarecer o que é o padrão DICOM, órgãos responsáveis pela padronização e outras características, este capítulo apresenta uma introdução e um histórico do padrão, sua estrutura organizacional e documentação. Também há uma descrição sobre ambientes PACS, vantagens da utilização e casos de sucessos ocorridos no Brasil. 2.1 Histórico Com o surgimento e utilização de equipamentos de aquisição de imagens, constataram-se alguns problemas, dentre eles, a incompatibilidade do padrão de comunicação entre equipamentos de fabricantes diferentes e a incompatibilidade no formato das imagens geradas, pois, cada equipamento possuía um padrão específico para o formato das imagens, no qual não podiam ser abertas ou alteradas em equipamentos que não trabalhassem com o mesmo padrão. Em 1983, o Colégio Americano de Radiologia (ACR) e a Associação Nacional dos Fabricantes de Equipamentos Elétricos (NEMA) formaram um comitê, nomeado ACR-NEMA Digital Imaging and Communications Standards Comittee, com o objetivo de desenvolver um padrão para imagens médicas e seus dados relacionados, que possibilitasse a comunicação entre equipamentos de diferentes fabricantes. Esta organização ficou responsável pelo desenvolvimento, manutenção e atualização do padrão, onde neste participam diversos fabricantes da área médica e engenheiros dos principais fornecedores da área de equipamentos médicos ou geradores de imagens médicas. O padrão também continha um dicionário de elementos

20 8 que eram necessários para a codificação e interpretação de imagens (SAMPAIO, 1999). Após dois anos de estudos, foi publicada a primeira versão do padrão DICOM, mas essa versão continha muitos erros e fez-se necessária à publicação de uma segunda versão em Então, somente a partir desta segunda versão, o padrão DICOM começou a ser utilizado na codificação e intercâmbio de imagens médicas digitais. Mas, foram realizadas diversas modificações nesta versão, tornando-o instável, pois não proporcionava uma comunicação confiável (SAMPAIO, 1999). Visto que, em 1988, cada vez mais usuários pretendiam utilizar dispositivos de imagens conectados a suas redes, gerou-se um problema. A atual versão do padrão possuía suporte a comunicação em redes, mas necessitava de melhoramentos, pois o padrão não fora desenvolvido exatamente com essa finalidade. Então, o ACR-NEMA optou pela reengenharia do padrão, pois, para desenvolver uma interface que permitisse a comunicação em rede robusta, necessitaria muito mais que apenas atualizações à versão corrente do padrão. A partir daí, foi adotado a orientação a objetos como novo método de concepção, visando proporcionar uma maior modularidade ao padrão DICOM (ARAÚJO, 2002). Com isso, o desenvolvimento do padrão DICOM deu-se de forma contínua, demonstrando uma ascendente compatibilidade e confiabilidade na comunicação de imagens médicas digitais (SAMPAIO, 1999, p. 16). Com relação à comunicação em rede, SAMPAIO (1999, p. 16) diz que: Adicionalmente, um rápido exame dos tipos de serviços necessários à comunicação em rede, mostrou que a definição de uma classe de serviços básicos permitiria que um processo de alto nível (na camada de aplicação) fosse capaz de se comunicar com um grande número de diferentes protocolos de rede. Assim, deu-se o desenvolvimento de uma nova versão, quase um novo projeto. Estes protocolos são modelados como uma série de camadas superpostas, também conhecidas como pilha. Na versão 2.0 do DICOM já existia uma pilha que definia uma comunicação ponto-a-ponto. Mais tarde foram inseridas, baseadas em sua popularidade e possibilidade de expansão, as pilhas Transmission Control Protocol/Internet Protocol (TCP/IP) e a Internationnal Standards Organization/Open System Interconnection (ISO/OSI). Mais tarde, após três anos de estudos e trabalho, foi finalizada a versão DICOM 3.0, analisando sugestões, tanto da área acadêmica quanto da indústria, tornando-se muito mais abrangente e robusta que as anteriores.

21 9 2.2 Estrutura organizacional do ACR-NEMA O padrão DICOM 3.0 está em constante expansão e, para isso, o comitê ACR-NEMA é formado por vários grupos com a finalidade de desenvolver e incorporar novas características de diversas áreas médicas e, atualmente existem vinte e dois grupos de trabalho responsáveis pela manutenção e atualização do padrão. Também foram produzidos e publicados dezesseis documentos que descrevem o padrão DICOM Grupos de trabalho Atualmente existem vinte e dois grupos de trabalho (working groups) que são responsáveis pela manutenção e atualização do padrão. Estes grupos de pesquisa vêm aumentando, visto que o padrão está se especializando e estendendo as novas aplicações, abrangendo novas áreas. A seguir, uma breve descrição de cada grupo, sendo que informações mais completas sobre cada grupo podem ser encontradas na homepage oficial do DICOM (NATIONAL, 2004) Grupo de trabalho 1 Cardiac and Vascular Information Grupo responsável por desenvolver padrões para o intercâmbio de imagens cardiovasculares digitais, waveforms (exames no formato de ondas como, por exemplo, áudio e eletrocardiograma) e informações clínicas características de um paciente que se submete a um procedimento de cateterização. Uma vez que a medicina cardiovascular requer a interação e consulta entre muitas disciplinas médicas, a padronização para intercâmbio dessas informações é fundamental Grupo de trabalho 2 Projection Radiography and Angiography Responsável por desenvolver e manter especificações de objetos para o padrão DICOM como: angiografia geral, neuroradiologia, fluoroscopia e a clínica, que acompanham um paciente que se submete a procedimentos gerais de raio-x.

22 Grupo de trabalho 3 Nuclear Medicine Responsável por desenvolver padrões para o intercâmbio de imagens digitais da medicina nuclear Grupo de trabalho 4 Compression Grupo responsável por desenvolver métodos de compressão de dados para o padrão DICOM e também para tipos de dados criados por outros grupos de trabalho Grupo de trabalho 5 Exchange Media Designado para desenvolver padrões DICOM para intercâmbio de mídias Grupo de trabalho 6 Base Standard Este grupo é responsável pela integridade e consistência do padrão DICOM e algumas de suas responsabilidades incluem: executar pequenos reparos (propostas e correções) à versão atual do padrão; coordenação e orientação técnicas para todos os outros working groups (WG); coordenação junto com o NEMA para a publicação do DICOM; desenvolvimento de suplementos relacionados ao padrão para impressão, gerência de imagem etc Grupo de trabalho 7 Radiotherapy Desenvolver e manter os objetos de informação da Radioterapia para o padrão e, também, promover a implantação e aceitação dentro da indústria Grupo de trabalho 8 Structured Reporting Desenvolver e manter a especificação do DICOM, relatando sua estrutura e colaborando com os grupos de trabalho do DICOM, como também, com outros comitês desenvolvedores de padrões no desenvolvimento de relatórios especializados e outros documentos baseado na especificação genérica do Structured Reporting.

23 Grupo de trabalho 9 Ophthalmology Endereçado a todas as questões referentes a imagens e relatórios de imagens baseados em aplicações da oftamologia Grupo de trabalho 10 Strategic Advisory Para considerar todas as questões e oportunidades relacionadas à evolução do padrão DICOM, como também, prover a ligação com outras organizações desenvolvedoras de padrões. Revisar padrões e tecnologias em assistência médica, imagens dentro da biomedicina, comércio, telecomunicações e informática. É, também, responsabilidade deste grupo desenvolver e manter, a longo prazo, o plano estratégico para o padrão DICOM Grupo de trabalho 11 Display Function Standard Desenvolver uma função padrão para demonstração e serviços DICOM relacionados a apresentação de objetos de imagens Grupo de trabalho 12 Ultrasound Seu papel é manter e estender o padrão DICOM encontrando necessidades da ultra-som e especialidades ecocardiográficas. Este inclui aspectos de aquisição de imagens 3D/4D, medição e outras evidências encontradas Grupo de trabalho 13 Visible Light Estender o padrão DICOM ainda mais longe, com visualização de imagens expostas à luz e, imagens coloridas em movimento produzidas por endoscópios, microscópios ou câmeras fotográficas Grupo de trabalho 14 Security Responsável por desenvolver extensões para o padrão DICOM de pequenos detalhes técnicos, proporcionando o intercâmbio de informações mais seguro.

24 Grupo de trabalho 15 Digital Mammography and CAD Desenvolver extensões ao DICOM para suportar imagens de mamas, incluindo resultados estruturados de equipamentos de auxílio à detecção de problemas (CAD Computer-Aided Detection / Diagnosis) Grupo de trabalho 16 Magnetic Resonance Um novo objeto da ressonância magnética foi desenvolvido que contém uma extensão da descrição dos atributos e emprega o uso de um novo mecanismo multiframe, não apenas para a ressonância magnética, mas também para outras modalidades. Também, é adotado atualmente pela tomografia computadorizada Grupo de trabalho 17 3D Têm a finalidade de estender o padrão com relação a imagens multidimensionais relacionadas ao espaço do mundo real, tempo, propriedades físicas, medidas ou derivações Grupo de trabalho 18 e 19 Clinical Trials and Education / Dermatology Estes grupos ainda não estão ativos Grupo de trabalho 20 Integration of Imaging and Information System Responsável por desenvolver padrões DICOM e HL7 (Health Level 7) para informações relacionadas a imagens de áreas onde o uso desses dois padrões é o interesse principal Grupo de trabalho 21 Computed Tomography Uma nova extensão do objeto de imagem foi desenvolvida para que tivesse um conjunto maior de atributos descritores e empregasse um novo mecanismo multiframe apropriado. Suporta muitos avanços tecnológicos e clínicos dentro da tomografia computadorizada. Particularmente, o aumento de seções em exames, a tecnologia de tempo-real serão resolvidas pelo novo objeto DICOM com capacidade

25 13 multi-frame Grupo de trabalho 22 Dentistry Dirigido a todas as edições relacionadas a imagens e relatos de imagens, baseados em estudos na área da odontologia. 2.3 Documentação do padrão DICOM 3.0 Como o padrão está em constante atualização e expansão, decidiu-se por dividir a especificação do padrão DICOM 3.0 em partes, para que essas partes pudessem ser expandidas sem que fosse necessário republicar todo o padrão. O padrão DICOM 3.0 está dividido em dezesseis partes publicadas em 2003, designadas pelos documentos PS 3.1 ao PS A seguir, uma breve descrição de cada documento, sendo que a descrição mais detalhada e completa de cada documento pode ser obtida na homepage do NEMA (NATIONAL, 2004) e também na homepage do doutor David Clunie (CLUNIE, 2000). O doutor David Clunie é membro responsável pelo working group 6 Base Standard PS Introduction and Overview Possui uma visão geral do que é o padrão DICOM. Descreve a história, extensão, objetivos e sua estrutura. Particularmente, possui uma breve descrição do de cada parte do padrão PS 3.2 Conformance Possui a definição geral para todas as implementações que pretendem estar em conformidade com o padrão DICOM PS 3.3 Information Object Definitions Descreve como os objetos de informação são descritos. Lista todos os grupos

26 14 de entidades de informação e definições de Objetos de Informações já definidos em cada objeto de informação. Estes grupos são coleções e seqüências de elementos de dados PS 3.4 Service Class Specifications Este documento contém a especificação das Classes de Serviço e também, como que essas classes de serviço são implementadas pelas entidades de aplicação. Esta parte é um bom referencial para programadores que desejam desenvolver aplicações DICOM PS 3.5 Data Structure and Encoding Especifica o método de codificação e decodificação dos dados, para a transmissão e recepção de dados, respectivamente PS 3.6 Data Dictionary Possui uma lista com todas as tags (palavras-chave) relacionadas com os atributos dos objetos de informação que fazem parte do padrão PS 3.7 Message Exchange Esta parte especifica o DIMSE (DICOM Message Service Element). O DIMSE proporciona serviços com base no protocolo DIMSE e este define as regras necessárias para construir mensagens PS Network Communication Support for Message Exchange O protocolo de comunicação especificado neste documento está intimamente relacionado ao modelo ISO (Open System Interconection). O protocolo de comunicação especificado neste documento está relacionado, em geral, com o protocolo de comunicação TCP/IP.

27 PS 3.9 Point to Point Communication Support for Messagem Exchange Este documento contém a especificação para a utilização do padrão DICOM sobre conexões ponto-a-ponto PS 3.10 ao PS 3.12 Media Storage and File Format for Media Interchange, Media Storage Application Profiles, Media Formats and Physical Media for Media Interchange Estes documentos especificam os formatos utilizados para armazenar dados em meios magnéticos removíveis, como discos magneto-óticos PS 3.14 Grayscale Standard Display Function (grayscale). Especifica a função padrão para visualização de imagens em escala cinza PS 3.15 Security Profiles Esta parte especifica perfis de segurança para aplicações DICOM. O padrão somente proporciona mecanismos que podem ser usados na implementação de segurança com respeito ao intercâmbio entre objetos DICOM PS 3.16 Contents Mapping Resource Define o conteúdo esquematizado dos recursos o qual define os modelos e o corpo dos grupos usados no padrão. 2.4 Ambiente PACS (Picture Archiving and Communications System) Segundo BUENO (2001), os grandes centros médicos e hospitais em todo o mundo têm se preocupado em integrar as informações de seus pacientes com os exames de imagens efetuados e a solução para isso seria a implantação de um sistema

28 16 PACS, o qual possibilita a integração de imagens junto às suas informações relacionadas. PACS são sistemas que possuem equipamentos de aquisição de imagens médicas digitais (tomógrafo, ressonância magnética, ultra-som etc.), conectados a uma rede local ou remota de dados, onde também podem estar conectados outros equipamentos, como estações de trabalho, servidores de arquivos, impressoras etc e, através da rede, compartilham informações de pacientes, exames e imagens digitais que podem estar armazenados em servidores de imagens médicas (figura 1). É nesse tipo de ambiente que se utiliza um servidor DICOM, para que seja possível gerenciar e organizar os arquivos que trafegam pela rede. Assim, podem-se interligar diversos, senão todos, departamentos de um ambiente clínico-hospitalar. Por exemplo, atualmente em um Departamento de Radiologia, já se tem a visão de que o usuário final do PACS não é apenas o radiologista e sim todos os profissionais envolvidos no processo diagnóstico e terapêutico do paciente, pois as imagens geradas poderão ser armazenadas em um servidor de imagens médicas e visualizadas em qualquer estação de trabalho dentro da instituição ou ainda serem consultadas por um especialista em um local remoto (telemedicina) (WHITE, 2004). Um dos principais objetivos de um PACS é coletar imagens radiológicas na forma digital para arquivamento e comunicação. (BUENO, 2001, p. 7). Como existem diferentes fabricantes e fornecedores de equipamentos de diagnóstico médico, com o padrão de comunicação e codificação de imagens proprietários, o padrão DICOM 3.0 pode ser definido como interface de rede, abstraindo as interfaces de rede de cada fornecedor, minimizando as dificuldades de interconexão entre os equipamentos e facilitando a criação de um ambiente PACS. Basicamente um PACS constitui de três elementos: Um computador para armazenar imagens digitais e dirigir a comunicação dentro do sistema (servidor); Uma workstation para visualizar imagens e informações; Um meio físico de comunicação interligando os equipamentos (rede).

29 17 Em um ambiente PACS não precisa necessariamente existir um equipamento médico conectado a rede, tento apenas o trafego de imagens pela rede já se caracteriza um PACS. Por exemplo: simulando um ambiente PACS em nossa região, o hospital geral poderia ser o centro principal de informações, onde existiria um servidor principal, equipamentos geradores de imagens e estações de trabalho (como o exemplo da figura 1). Então, nos hospitais dos municípios vizinhos conteriam apenas estações de trabalho e talvez algum servidor local para armazenamento temporário de informações. Desta forma existirão pequenos ambientes PACS em cada município e todos esses estão interligados com o hospital em Lages formando um único PACS. FIGURA 1 - Exemplo da estrutura de um PACS (Fonte: TACHINARDI e FURUIE, 2004) Vantagens da utilização de um PACS As vantagens que um sistema PACS pode proporcionar são várias e entre elas é importante citar: redução de custos com materiais operacionais, agilidade no processo de arquivamento e consulta de exames e dados relacionados, segurança e

30 18 integridade dos dados etc. Um PACS proporciona, por exemplo, que todos os exames e dados de um paciente sejam armazenados em formato digital, tal que, em conjunto com um sistema HIS (Hospital Information System), se possa ter um histórico de sua vida clínicohospitalar e, ser resgatado e consultado sempre que necessário, com rapidez e segurança. Estes dados também podem ficar disponíveis para o acesso remoto, uma vez que é possível interligar duas instituições distintas fisicamente, através de um único PACS, podendo assim, estabelecer uma troca de informações entre elas, auxiliando o diagnóstico médico (BUENO, 2001) Exemplos de PACS no Brasil No Brasil existem alguns PACS implantados, embora ainda esse tipo de sistema não seja muito conhecido (WHITE, 2004), pode-se citar, por exemplo, o PACS do Instituto do Coração de São Paulo (InCor), que possui o sistema voltado para o armazenamento de imagens médicas por longos períodos de tempo e em múltiplos volumes (figura 2).

31 19 FIGURA 2 - Estrutura do PACS do Instituto do Coração de São Paulo. (fonte: BERTOZZO JUNIOR e FURUIE, 2002, p. 1) O funcionamento do PACS do InCor de São Paulo decorre da seguinte forma: todos equipamentos, DICOM compatíveis, enviam as imagens diretamente para o servidor DICOM (desenvolvido pelo InCor em Java, utilizando o modelo do RSNA Radiology Society of North America). As imagens ARCNema são transferidas para um repositório temporário onde são convertidas para DICOM e depois armazenadas no repositório final. Para aqueles equipamentos que não possuíam interface digital, como o ultra-som, foi desenvolvido um sistema para captura de vídeo e conversão para DICOM (BERTOZZO JUNIOR e FURUIE, 2002). É importante salientar a grande quantidade de dados e informações pela rede de sistemas como esse, como por exemplo, a demanda de armazenamento gerada pelo PACS do InCor é, aproximadamente, de 6 GBytes por dia. (BERTOZZO JUNIOR e FURUIE, 2002).

32 Conclusão Atualmente, em hospitais modernos, o armazenamento e distribuição de imagens médicas digitais deixara de ser um protótipo e tornou necessidade. Com a evolução da tecnologia e o surgimento de equipamentos médicos mais modernos, de fabricantes diferentes, resultou na necessidade da criação de um padrão que abstraísse as interfaces, o formato e codificação de imagens proprietárias de cada fornecedor, implicando na redução de custos e total compatibilidade dos equipamentos. Com o padrão DICOM 3.0, proporciona-se subsídios para a redução de custos em ambientes clínico-hospitalar, bem como facilidades para manipular informações, como imagens e seus dados relacionados. A utilização de um sistema PACS em conjunto com um sistema HIS pode proporcionar muitas vantagens, principalmente em instituições públicas, onde algumas vezes, o sistema existente para o gerenciamento de dados dos pacientes é precário e ineficiente. Por exemplo, um sistema PACS eficiente pode proporcionar agilidade no processo do diagnóstico médico, de tal forma que um médico, de sua própria residência, possa ter acesso a informações e exames de pacientes (desde que o PACS esteja configurado com esse propósito) e pode prescrever o diagnóstico por para o paciente.

33 3 SERVIDOR DICOM OFFIS Como a proposta deste trabalho visa a implementação de um front end para o Servidor DICOM OFFIS, é imprescindível o conhecimento sobre o mesmo. Sendo assim, neste capítulo apresenta-se uma breve descrição sobre o servidor e uma descrição mais detalhada das principais funções que são implementadas pelo Servidor DICOM OFFIS, como storescu, storescp, findscu etc. Desta forma, este capítulo pode servir como um referencial para usuários que pretendam utilizar as principais funcionalidades deste software. 3.1 Breve descrição A empresa alemã Kuratorium OFFIS e.v. foi a responsável pelo desenvolvimento do Servidor DICOM OFFIS, tecnicamente chamado de DCMTK (DICOM Toolkit). Este pacote contém uma coleção das bibliotecas e aplicações que executam as principais funções do padrão DICOM. Isso inclui funções para examinar, construir e converter arquivos de imagens DICOM, como também transmitir, receber e armazená-las através de uma rede de comunicação. O DCMTK foi desenvolvido utilizando a linguagem ANSI C e C++ e pode ser encontrado para download na homepage oficial. O DCMTK vem com o código fonte completo e foi desenvolvido com a finalidade de ser open source. Também está disponível para várias plataformas como Windows e sistemas UNIX incluindo Linux, Solaris, FreeBSD e MacOS X (OFFIS, 2004).

34 Funcionalidades Funções implementadas pelo servidor Pode-se encontrar implementadas no servidor DICOM OFFIS várias funções DICOM, no qual, este capítulo contém a descrição e exemplos de utilização das funções mais comuns como armazenar, consultar e enviar imagens DICOM. São elas: storescp, storescu, imagectn, findscu, movescu e dump2dcm. Todas essas aplicações funcionam por linhas de comando. Para uma descrição mais detalhada sobre cada aplicação, deve-se consultar a documentação do servidor DICOM OFFIS, que encontra-se disponível para download juntamente com o pacote DCMTK Aplicação storescp A aplicação storescp implementa uma classe fornecedor de serviço (SCP) para a Classe do Serviço de Armazenamento. Uma vez executada esta aplicação, ela fica ouvindo uma porta TCP/IP especificada pelo usuário, para solicitações de um usuário do serviço (SCU) de armazenamento (storescu) e pode receber imagens de acordo com a Classe do Serviço de Armazenamento. As imagens recebidas são armazenadas no diretório raiz da aplicação servidora. A seguir, uma descrição do uso do storescp, principais parâmetros que podem ser utilizados e exemplos Usabilidade Storescp: DICOM storage (C-STORE) SCP. Sintaxe: storescp [opções] porta Parâmetros: Porta: porta TCP/IP que a função irá ficar ouvindo. Opções gerais: -h help mostra um texto de ajuda e a versão

35 23 -v verbose mostra os detalhes do processo -d debug mostra as informações para eliminação de erros -od output-directory [p]ath: diretório grava os arquivos de saída no diretório p. Opções de rede: -aet aetitle define um apelido para este ponto de rede aetitle: nome. Para executar essa aplicação, pode-se seguir o exemplo mostrado na figura 3. No computador servidor, digita-se a seguinte linha de comando: storescp v 140 Desta forma a aplicação estará iniciada e ouvindo na porta TCP/IP 140 a espera de uma solicitação de serviço de cliente, como storescu Aplicação storescu FIGURA 3 - Exemplo da execução da aplicação storescp. A aplicação storescu executa um SCU (serviço de usuário) para a Classe do Serviço de Armazenamento. Para cada arquivo de imagem o comando envia uma mensagem C-STORE para uma função SCP (fornecedor do serviço) e aguarda uma

36 24 resposta. Esta aplicação pode ser utilizada para transmitir imagens DICOM. A seguir, uma descrição do uso da aplicação storescu, principais parâmetros que podem ser utilizados e exemplos Usabilidade storescu: DICOM storage (C-STORE) SCU. Sintaxe: storescu [opções] nome_host porta arquivo.dcm Parâmetros: nome_host: nome da máquina do servidor DICOM. porta: porta TCP/IP de comunicação que uma função SCP monitorando. arquivo.dcm: arquivo DICOM que será transmitido. Opções gerais: -h help mostra um texto de ajuda e a versão -v verbose mostra os detalhes do processo -d debug mostra as informações para eliminação de erros Opções de rede: -aet aetitle define um apelido para este ponto de rede (padrão: storescu) aetitle: nome. -aec call o apelido do nome_host (padrão: algum-scp) A figura 4 demonstra um exemplo da utilização desta função com base do exemplo mostrado na figura 3. Na máquina, referente à aplicação cliente, digita-se a seguinte linha de comando: storescu -v localhost 140 c:\images\mr-brain.dcm Neste caso específico, as duas aplicações (servidor e cliente) estão sendo executadas na mesma máquina, por isso o parâmetro referente ao nome da máquina onde está executando a aplicação storescp está sendo informado como localhost. Após a execução, são mostradas informações sobre a execução processo, como mostra a figura 4.

37 25 FIGURA 4 - Exemplo da execução da aplicação storescu. Neste exemplo, a aplicação cliente (storescu) fez uma requisição à aplicação servidor (storescp) para o armazenamento da imagem DICOM, denominada mrbrain.dcm, que foi executada com sucesso Aplicação findscu Esta aplicação implementa um SCU para a Classe de Serviço de Pergunta/Resposta e a Classe de Serviço de Gerenciamento da Lista de Trabalho Básica. Findscu suporta somente as funcionalidades de requisições (query) utilizando mensagens C-FIND. Emite perguntas chaves a uma aplicação SCP (ex.: imagectn) e fica esperando uma resposta. Um exemplo da utilização da aplicação será apresentado a seguir, bem como uma descrição dos principais parâmetros que pode ser utilizados Usabilidade findscu: DICOM query (C-FIND) SCU Sintaxe: findscu [opções] nome_host porta arquivo.dcm Parâmetros: nome_host: nome da máquina do servidor DICOM.

38 26 porta: porta TCP/IP de comunicação que uma função SCP está monitorando. arquivo.dcm: arquivo DICOM. Opções gerais: -h help mostra um texto de ajuda e a versão -v verbose mostra os detalhes do processo -d debug mostra as informações para eliminação de erros Opções de rede: Combinações das chaves: -k key gggg,eeee= valor Modelo de informação de pergunta: -W worklist utiliza o modelo de informação da modalidade worklist. -P patient utiliza o modelo de informação do paciente -S study utiliza o modelo de informação do estudo -O psonly utiliza o modelo de informação do paciente / estudo. Títulos das entidades de aplicação -aet aetitle define um apelido para este ponto de rede (padrão: storescu) aetitle: nome. -aec call o apelido de destino(padrão: algum-scp) Ao utilizar a aplicação findscu é emitido uma requisição C-FIND ao SCP para os dados informados na linha de comando. As informações a serem buscadas devem estar em um arquivo DICOM válido contendo uma lista de informações (atributos) desejadas para cada resultado da consulta. Se encontrada as imagens, será obtido como resposta somente as informações que foram solicitadas sobre a imagem, como o nome do paciente, tipo do estudo, ID do paciente etc. Este é um exemplo do conteúdo de um arquivo DICOM que contém as informações desejadas de cada

39 27 imagem: # query patient names and IDs (0008,0052) CS [PATIENT] # QueryRetrieveLevel (0010,0010) PN [] # PatientsName (0010,0020) LO [] # PatientID Isso significa que para cada imagens só está sendo pedido o nome do paciente e o ID referente ao mesmo. Então pode-se criar um arquivo com a extensão.txt (padrão ASCII) contendo os atributos desejados (como o exemplo acima) e utilizar o aplicativo dump2dcm para convertê-lo para um arquivo DICOM (.dcm), como está sendo mostrado na figura 5. FIGURA 5 - Exemplo da utilização da aplicação dump2dcm. Assim, com base neste arquivo, pode-se fazer uma solicitação à aplicação servidor para que envie alguma imagem através da aplicação movescu, já que a aplicação findscu apenas retorna informações com a finalidade de descobrir se existem determinados exames ou imagens armazenadas no servidor. A figura 6 traz um exemplo de uma consulta ao servidor de imagens e a resposta é armazenado no arquivo resultado.txt.

40 28 FIGURA 6 - Exemplo da utilização da aplicação findscu. No exemplo da figura 6 pode-se ver a utilização de duas keys, que passam uma referência para que seja feita uma busca por pacientes (0008,0052=PATIENT) cujos nomes comecem por MR/A (0010,0010=MR/A*) e, posteriormente, é informado quem está solicitando a informação (cliente), para quem (servidor) e o ponto de rede onde se localiza o servidor. Os valores utilizados nos parâmetros aet e aec foram previamente configurados, através do arquivo de configuração do servidor configrc. FIGURA 7 - Conteúdo do arquivo resultado.txt.

41 29 A figura 7 mostra o conteúdo do arquivo resultado.txt, onde pode-se ver que apenas uma imagem foi encontrada (response) e as informações foram armazenadas de acordo com a sintaxe contida no arquivo query.dcm Aplicação movescu Esta aplicação implementa um SCU para a Classes de Serviço Pergunta/Resposta e um SCP para a Classe de Serviço de Armazenamento. Isso é feito através de mensagens DICOM C-MOVE. Quando iniciada, a aplicação envia perguntas chaves a uma aplicação SCP e espera resposta, de tal modo que se a aplicação servidor tiver a imagem requisitada, envia uma cópia da mesma para a aplicação que a solicitou. A aplicação movescu permite que seja iniciada a transferência de imagens para terceiros ou para si mesma Usabilidade movescu: DICOM retrive (C-MOVE) SCU Sintaxe: movescu [opções] nome_host porta arquivo.dcm Parâmetros: nome_host: nome da máquina do servidor DICOM. porta: porta TCP/IP de comunicação que a função storescp está ouvindo. arquivo.dcm: arquivo DICOM que será transmitido Opções gerais: -h help mostra um texto de ajuda e a versão -v verbose mostra os detalhes do processo -d debug mostra as informações para eliminação de erros Opções de rede: Combinações chaves: -k key gggg,eeee= palavra

42 30 Modelo de informação de pergunta: -P patient utiliza o modelo de informação do paciente (padrão) -S study utiliza o modelo de informação do estudo -O psonly utiliza o modelo de informação do paciente/ estudo Títulos das entidades de aplicação -aet aetitle define o apelido de quem está requisitando a operação (padrão: movescu) -aec call o apelido do destino (padrão: algum-scp) -aem move define o apelido do destinatário (padrão: movescu) Para cada arquivo informado para ser requisitado, é enviado uma mensagem C-MOVE para um SCP. O arquivo de requisição deve ser um arquivo DICOM válido contendo uma série de informações de uma mensagem C-MOVE-RQ. O arquivo pode ser criado utilizando o aplicativo dump2dcm, que converte um arquivo no padrão ASCII para um arquivo DICOM válido (.dcm). Desta forma, a aplicação movescu solicita ao servidor que lhe envie o arquivo contendo as informações que estão no arquivo criado através do dump2dcm. Este arquivo pode conter informações, como por exemplo: (0008,0052) CS [PATIENT] # QueryRetrieveLevel (0010,0020) LO [PAT001] # PatientID Isto significa que está sendo requisitado ao servidor, todas as imagens do paciente com o ID igual a PAT001. A figura 8 demonstra a utilização da aplicação movescu utilizando o arquivo DICOM (QueryTeste.dcm), que é a conversão do arquivo resultado.txt (figura 7), resultante da utilização da aplicação findscu (figura 6). No exemplo da figura 8, a aplicação movescu faz uma solicitação para o servidor, para que este lhe envie imagens referentes às informações contidas no

43 31 arquivo QueryTeste.dcm. Nota-se que o parâmetro referente ao nome do ponto de rede que está rodando a aplicação servidor, está como olavo, diferente dos outros exemplos que estavam como localhost, porque este exemplo foi executado em máquinas distintas, conectadas em uma rede Ethernet, onde a aplicação servidor (imagectn) estava sendo executada na máquina denominada olavo e a aplicação cliente (movescu) em outra denominada dionisio. Se a aplicação obtiver sucesso, então a imagem será armazenada no diretório raiz do servidor DICOM OFFIS, caso contrário, é apresentado uma mensagem de erro. FIGURA 8 - Exemplo da utilização da aplicação movescu Aplicação imagectn A aplicação imagectn implementa um SCP e suporta requisições feitas por aplicações SCU (movescu, findscu, storescu etc). Ela gerencia diversas áreas (diretórios, departamentos) para armazenamento, permitindo, por exemplo, que determinadas imagens de um departamento não se misturem com outras que não estejam relacionadas com ele. Também permite um controle de acesso de determinadas entidades a serviços implementados por esta aplicação. Esta aplicação foi utilizada para fazer as demonstrações DICOM deste trabalho (findscu, movescu, storescu), já que ela implementa um SCP.

44 Usabilidade imagectn: DICOM image archive (central test node) sintaxe: imagectn [opções] porta Parâmetros: porta: porta TCP/IP de comunicação que ficará ouvindo. Opções gerais: -h help mostra um texto de ajuda e a versão -v verbose mostra os detalhes do processamento -vv very verbose mostra mais detalhes do processamento -d debug mostra as informações para eliminação de erros -c config nome do arquivo de configuração (padrão: configrc) Esta aplicação tem um funcionamento bem simples, quando iniciada, fica ouvindo em uma determinada porta TCP/IP a espera de requisições de serviços oriundas de outras aplicações. Configurações, como os AETitle (application entity titles) dados aos hosts do sistema, podem ser feitas através do arquivo configrc (padrão), que permite criar grupos de trabalho, envolvendo vários hosts e desta forma, determinar restrições de acesso (figura 9). Grupos de trabalho podem ser utilizados para separar departamentos e restringir acesso de usuários não autorizados. No exemplo da figura 9, pode-se ver um modelo do arquivo de configuração da aplicação imagectn. As informações contidas no início do arquivo são referentes as configurações gerais da aplicação. Logo abaixo, contém as configurações dos hosts envolvidos no sistema. Também, pode-se criar grupos ou domínios, contendo o nome de todos os hosts envolvidos, que pode ser utilizado para definir quais destes têm permissões de acesso a determinados arquivos de um departamento. A figura 9 contém um exemplo de como configurar um domínio ou grupo, onde este se chama TCCteste e contém o agrupamento de dois hosts: maquina1 e maquina2. Assas informações sobre os hosts devem estar entre duas tags (palavras-

45 33 chave) delimitadoras, HostTable BEGIN e HostTable END. FIGURA 9 - Exemplo do arquivo de configuração da aplicação imagectn. As próximas configurações que devem ficar entre as tags VendorTable BEGIN e VendorTable END. Essas informações são utilizadas para administração remota, onde cria-se um usuário para que esse tenha acesso as áreas de armazenamento e possam ter controle sobre as imagens contidas nesses diretórios. Assim, o usuário pode acessar os diretórios o qual ele tem permissão através de uma aplicação do OFFIS chamada TI (telnet initiator) que se comporta como um cliente Telnet. Essa aplicação permite o usuário possa executar algumas ações, como listar e enviar o

46 34 conteúdo do(s) diretório(s). Por último ficam as configurações referentes as área de armazenamento de dados (AETable), onde é especificado o endereço destino da base de dados, permissões do tipo de acesso (leitura/escrita) e cotas (capacidade de armazenamento e quantidade de arquivos) para cada diretório. É necessário criar um AETitle para facilitar a referência a esses repositórios. Essas informações são fundamentais para o funcionamento do OFFIS como servidor de imagens, pois as aplicações storescu, findscu e movescu utilizam essas informações para seu funcionamento. 3.3 Conclusão Visou-se neste capítulo apresentar as principais funcionalidades do servidor DICOM OFFIS, descrevendo o funcionamento e exemplificando algumas aplicações implementadas por ele. Desta forma, pôde-se aprofundar o conhecimento sobre transferência de imagens médicas e a utilização do padrão DICOM neste processo. Identificou-se, também, situações reais sobre as dificuldades que usuários leigos enfrentam na utilização das aplicações DICOM, pois, muitas vezes, suas sintaxes apresentam-se confusas ou complexas, exigindo um conhecimento mínimo na área de informática, mais especificamente na área de redes. Assim, se conclui que a construção de uma interface mais amigável e intuitiva facilitará a utilização de aplicações DICOM implementadas pelo OFFIS, como as apresentadas neste capítulo, de tal forma que seja possível utilizar o servidor sem que seja necessário grande conhecimento específicos sobre as sintaxes de seus comandos.

47 4 DESENVOLVIMENTO DO PROTÓTIPO O objetivo deste capítulo é auxiliar o entendimento do desenvolvimento da aplicação de uma maneira simples usando casos de uso e diagrama de classes para modelar a proposta da aplicação. 4.1 Introdução É importante salientar que a aplicação não implementa nenhuma função DICOM, mas utiliza funções já implementadas no pacote DCMTK que compõem o servidor DICOM OFFIS. Então, a visão geral do projeto pode ser definida como uma interface para o servidor DICOM OFFIS, que permita o usuário utilizar de forma facilitada, suas principais funções, que são características de um servidor arquivos, como: armazenar, buscar e pesquisar arquivos. 4.2 Descrição do protótipo Com o intuito de facilitar a utilização do servidor DICOM OFFIS, optou-se por desenvolver a aplicação de forma simples e direta, proporcionando maneiras facilitadas para realizar operações comuns de um servidor de arquivos. O OFFIS é um servidor multiplataforma então, pretende-se seguir o mesmo padrão, tornando a aplicação desenvolvida funcional em várias plataformas. Para isso, a escolha de uma linguagem de programação que proporcione esta flexibilidade ao software é fundamental. Analisando esse requisito, a linguagem Java foi a que melhor atendeu as necessidades para o desenvolvimento da aplicação. Mas, para esta primeira

48 36 versão da aplicação, esta sendo visada apenas para o funcionamento na plataforma Windows, em vista do tempo para o desenvolvimento de uma aplicação mais robusta não ser adequado, ficando esta opção para ser implementada em verões futuras. O sistema se comunica com o OFFIS passando informações (parâmetros) necessárias para a execução de suas aplicações e gerenciando as informações retornadas (resposta a execução da aplicação em questão). As aplicações abordadas do servidor DICOM OFFIS são: storescu, findscu, movescu e imagectn. Essas aplicações estão associadas às funções de armazenamento, pesquisa, busca e servidor respectivamente. Também oferece condições facilitadas para a configuração do OFFIS, mais especificamente a aplicação imagectn, uma vez que isso seria feito através da edição do arquivo texto de configuração, procedimento comum para configurar aplicações em sistemas UNIX. Então, o usuário irá dispor de formulários com campos para que sejam informados dados necessários para o funcionamento do servidor e indiretamente, através deste, editar o arquivo de configuração. Não há a necessidade de que o servidor (local) esteja funcionando (executando) para que se possam realizar as operações de pesquisar, armazenar e buscar imagens, desde que essas sejam disparadas para outro ponto na rede onde esteja rodando o servidor OFFIS (a aplicação imagectn). A pesquisa de arquivos é feita utilizando um modelo padrão, onde através de um formulário, informam-se dados do paciente, como: nome do paciente, ID do paciente e AETitle. Esse último atributo refere-se a área (diretório) de armazenamento da imagem, previamente configurado (ver o item do capítulo anterior). A aplicação findscu do OFFIS permite que se utilizem outros modelos para que sejam feitas as pesquisas, mas inicialmente, só será permitida a utilização do modelo citado acima. Os resultados das pesquisas são apresentados em tabelas ou listas com as informações de cada figura, podendo-se selecionar uma imagem desejada e realizar a busca (get) desta através de um botão ou opção de menu. Não é permitido fazer a busca de várias imagens simultaneamente, essas devem ser realizadas individualmente.

49 37 Embora a aplicação do OFFIS permita esta ação, nesta primeira versão não será implementado essa possibilidade. O envio de imagens para um servidor consiste em fornecer algumas informações da origem, destino e o arquivo desejado. As informações de origem e destino estão relacionadas com as configurações da aplicação imagectn, uma vez que as aplicações do OFFIS utilizam os AETitles para fazer referência as entidades envolvidas, por exemplo: a configuração de um determinado host da rede seria assim: cliente = (CLIENT, olavo, 5678) Onde, para o host olavo define-se o AETitle CLIENT. Então, por exemplo, se fosse enviar uma imagem da máquina olavo para algum servidor, utilizaria-se o nome CLIENT para se referenciar a origem da imagem. 4.3 Casos de uso Para melhor entendimento do quê a aplicação irá oferecer em termos de funcionalidade, a seguir serão apresentados alguns casos de uso envolvendo as principais atividades realizadas por um usuário da aplicação. Os atores envolvidos são humanos (usuário comum ou administrador) e máquinas (computadores que contém o OFFIS instalado). O usuário irá utilizar algumas funcionalidades do OFFIS através da aplicação desenvolvida, que servirá como a interface de comunicação entre os atores. Os casos de uso previstos para a aplicação são: a) Reiniciar servidor; b) Enviar imagem; c) Pesquisar imagem; d) Buscar (get) imagem. A figura 10 apresenta o diagrama dos casos de uso citados acima e desta maneira pretende-se ajudar a compreender melhor as exigências e funcionalidades do sistema em questão, representando uma visão externa do sistema e suas interações com

50 38 o mundo exterior. FIGURA 10 - Diagrama de caso de uso Nº do caso de uso Quem inicia o caso QUADRO 1 - Descrição dos casos de uso Nome do caso de uso 1 Usuário Reiniciar servidor 2 Usuário Enviar imagem 3 Usuário Pesquisar imagem 4 Usuário Buscar imagem Descrição do caso de uso O usuário seleciona a opção reiniciar servidor através do menu. O sistema irá verificar com o OFFIS se o servidor já está iniciado. Caso não esteja iniciado, o usuário apenas receberá esta informação e nada será feito, senão, o sistema envia um comando para o OFFIS para que este pare o serviço de servidor (imagectn) e inicie novamente. O sistema mostra para o usuário uma mensagem informando o sucesso da operação. O usuário acessa a opção de enviar imagem através do menu. O sistema apresenta um formulário para que sejam informados os dados do host de origem e a área de armazenamento (AETable), além de outras informações necessárias. O usuário informa os dados necessários. O sistema valida as informações e as envia para o OFFIS para que execute a aplicação storescu. O sistema mostra uma mensagem ao usuário informando o sucesso na operação. O usuário acessa a opção de pesquisa através do menu. O sistema mostrará um formulário para que sejam informados os dados de origem, destino e dados sobre a imagem. Caso não seja informado nenhum dado sobre a imagem desejada, o sistema fará uma busca de todas as imagens contidas no diretório especificado. O sistema envia os dados para o OFFIS, para que esse execute a aplicação findscu. O sistema recebe os dados do resultado da pesquisa e mostra para o usuário uma lista com os dados de cada imagem encontrada. O usuário seleciona uma imagem na lista do resultado da pesquisa (caso de uso nº 3) e confirma a busca desta. O sistema envia as informações da imagem, junto com uma solicitação para o OFFIS para que sejam executado a aplicação movescu. A imagem retornada é armazenada no diretório raiz da aplicação. O sistema informa ao usuário o sucesso da operação.

51 39 O quadro 1 contém uma descrição mais detalhada das funcionalidades do sistema proposto e como esse se relaciona com o mundo externo. 4.4 Diagrama de classes Inicialmente, determinou-se as principais classes que compõem o sistema e seus atributos através de uma análise preliminar dos casos de uso e da descrição do projeto. Nesta fase, as classes identificadas estão em uma posição provisória (figura 11), sendo que podem essas sofrer modificações e ocorrer a inclusão de novas classes com o decorrer do desenvolvimento do projeto. As principais classes obtidas são: a) AeTable; b) HostTable; c) DadosImagem; d) Domínio; e) CabeçalhoGeral; f) ConfiguraçãoServidor. Basicamente, as classes estão relacionadas com o funcionamento e configuração da aplicação servidor (imagectn), onde foi definido que: todo host que for incluído na configuração do servidor poderá fazer parte de um domínio, facilitando assim a configuração do servidor, pois para cada área de armazenamento (AETable) é necessário definir quem tem permissão de acesso á aqueles dados. Então agrupando os hosts por domínios ficará mais fácil identificar quem faz parte e tem permissões de acesso a determinada área de armazenamento. Existe também a classe DadosImagem no qual está relacionada as imagens armazenadas no servidor, contendo as informações do modelo da consulta feita a aquela imagem, nome do paciente e um código identificador deste.

52 40 FIGURA 11 - Diagrama das classes preliminares 4.5 Conclusão A partir deste capítulo partiu-se para a implementação do software, visando criar uma interface simples e intuitiva, abordando as principais funcionalidades do OFFIS: armazenar, pesquisar, enviar e buscar imagens DICOM.

53 5 DOCUMENTAÇÃO DA APLICAÇÃO Este capítulo contém informações sobre a aplicação desenvolvida, prérequisitos de software e hardware, procedimentos de instalação e utilização das funcionalidades do DICOM OFFIS através da interface. Também é objetivo deste capítulo demonstrar como utilizar as funções do OFFIS do modo convencional e com a interface, procurando identificar e demonstrar as vantagens que a aplicação desenvolvida pode proporcionar. 5.1 Pré-requisitos de hardware e software Não existem pré-requisitos significativos de hardware para o funcionamento do software, então estipula-se para um bom desempenho a utilização da seguinte configuração de hardware: a) Processador Pentium III ou Athlon 500 Mhz ou superior; b) 64 Mb de memória RAM; c) Placa de rede; Como requisito de software, é imprescindível que esteja instalado o pacote DCMTK (pacote de bibliotecas que formam o OFFIS) na máquina em que se deseja utilizar o software. A aplicação foi desenvolvida para operar com a versão para a plataforma Windows (Win32). Utilizar uma versão inferior a essa, implicará no mal ou não funcionamento do software. A aplicação foi desenvolvida utilizando a linguagem Java, então é necessário ter instalado o Kit de Desenvolvimento Java (J2SDK.1.4.2) que pode ser encontrado no site oficial do Java (JAVA, 2004).

54 Procedimentos para instalação e configuração do OFFIS Inicialmente, deve-se ter o pacote dcmtk win32-i386.zip, que pode ser encontrado para download no site oficial do OFFIS (OFFIS, 2004). Descompacta-se o arquivo no diretório raiz do computador (normalmente C) e renomeando a pasta dcmtk win32-i386 que foi criada para dicom. Agora, dentro da pasta dicom criase uma nova pasta chama db que será o diretório para o armazenamento das imagens. Posteriormente precisarão ser feitas mais algumas alterações neste diretório. Para finalizar, deve-se configurar a variável de ambiente path para que facilite a utilização das funcionalidades do OFFIS. Dependendo da versão do sistema operacional, os passos para essa configuração poderão ser diferentes, mas o valor a ser configurado na variável path será o mesmo. Então, tomando como exemplo, a versão do Windows 2000 Professional, os passos são os seguintes: clica-se com o botão direito do mouse sobre o ícone na área de trabalho Meu Computador e seleciona a opção propriedades. Na guia Avançado, clicase no botão Variáveis de Ambiente. Agora, encontra-se a variável path e clica-se no botão editar. É provável que existam alguns valores para essa variável, sendo que esses não devem ser removidos. Então, ao final da linha, adiciona-se ; e em seguida o valor C:\dicom\bin (sem aspas), confirmando a inclusão no botão ok. Feitas essas configurações, o OFFIS está pronto para ser utilizado Instalação e configuração da aplicação desenvolvida Esta primeira versão do software não contém instalador, sendo que esse constitui-se de apenas um arquivo executável. Este arquivo deve ser colocado no diretório raiz do OFFIS, no caso a pasta dicom. Para executar o programa, basta que o usuário dê dois clique sobre o kamelotoffis.jar. Para facilitar o acesso pode-se criar um atalho para área de trabalho.

55 Procedimentos de utilização Com o intuito de esclarecer como utilizar as funções do OFFIS através desta aplicação, optou-se por desenvolver um guia para o usuário, mostrando também como que as mesmas funções são acessadas utilizando o método convencional (através do prompt de comando ou shell). Desta forma, pode-se ter uma visão real das dificuldades que o usuário pode encontrar utilizando o método convencional e as vantagens de se utilizar a interface para realizar a mesma operação Iniciar, parar e reiniciar o servidor A aplicação imagectn é responsável por realizar as funções de servidor, uma vez que essa está executando, permite que sejam feitas requisições a ela para o recebimento e envio de imagens. Então, a execução da aplicação através da shell pode ser feita através da seguinte linha de comando: imagectn c C:\dicom\etc\imagectn.cfg Desta forma, a shell ficará com o aspecto congelado, representando que a aplicação está em execução. As informações sobre a porta de comunicação, tipo de protocolo da rede etc, estão especificadas no arquivo de configuração (neste exemplo, imagectn.cfg). Para parar o serviço, deve ser pressionado as teclas Crtl+C, onde é gerado um sinal de interrupção que irá parar a execução da aplicação. Sempre que forem feitas alterações no arquivo de configuração da aplicação imagectn deve-se parar o serviço que está rodando e depois iniciá-lo novamente para que as novas configurações sejam validadas. Os procedimentos para realizar a mesma operação através da interface desenvolvida são os seguintes: na tela principal da aplicação, existe um indicador que informa o estado do servidor (aplicação imagectn). Assim, sabe-se qual ação deve ser tomada (iniciar, parar ou reiniciar o serviço). Essas ações são executadas sem que seja necessário escrever alguma informação, basta acessá-las através do menu (figura 12).

56 44 FIGURA 12 - Como acessar as funções iniciar, parar e reiniciar servidor Pesquisar imagens Este procedimento é um pouco complicado e requer a execução de alguns passos. A aplicação do OFFIS utilizada para realizar operações de pesquisa é a findscu. No item do trabalho, pode-se encontrar um exemplo de como fazer uma pesquisa usando o findscu através do prompt de comando. Há várias maneiras de se fazer uma consulta. Uma delas é fazer uma solicitação de todas as imagens armazenadas em um determinado repositório de imagens. Outra maneira é utilizando palavras chave para filtrar a consulta. A seguir, um exemplo de como realizar uma pesquisa de todas as imagens armazenadas em um determinado repositório. Primeiramente, deve criar um arquivo DICOM contendo os dados que serão pesquisados. Por exemplo: (0008,0052) CS [PATIENT] # QueryRetrieveLevel (0010,0010) PN [] # PatientsName (0010,0020) LO [] # PatientID Isto significa que será feito a pesquisa das imagens, verificando esses

57 45 atributos. Esse arquivo deve seguir um padrão, que é especificado no primeiro atributo, onde no exemplo, o padrão utilizado está definido como PATIENT (paciente). Assim, a pesquisa será feita verificando os atributos referentes ao paciente, como nome e código identificador do paciente. Nota-se que no exemplo os campos PN e LO estão vazios e desta forma o retorno da pesquisa será todas as imagens contidas no diretório de armazenamento. Para criar um arquivo DICOM válido, utiliza-se a aplicação dump2dcm do OFFIS, que converte um arquivo texto para um arquivo DICOM (ver figura 5). Então, tendo o arquivo DICOM, realiza-se a pesquisa da seguinte forma: findscu P aet MAQ1 aec TCC_STORE olavo 5678 arquivopesquisa.dcm > resultado.txt Interpretando o comando acima, vê-se que o primeiro atributo informado (- P) é referente ao tipo de pesquisa que está sendo feito (modelo PATIENT). Em seguida, os atributos aet e aec referem-se a origem e destino respectivamente. Por fim, é informado o nome do host onde está executando a aplicação imagectn, a porta TCP/IP que este está funcionando e o arquivo DICOM contendo os parâmetros da pesquisa. Ao executar esse comando na shell, o resultado é apresentado na tela, portanto, para facilitar o manuseio das informações resultantes, direcionou-se essas informações para um arquivo texto ( > resultado.txt). Caso seja necessário pesquisar imagens de um paciente pelo seu nome, devese informá-lo no atributo PN do arquivo de requisição. Por exemplo: (0008,0052) CS [PATIENT] # QueryRetrieveLevel (0010,0010) PN [FULANO] # PatientsName (0010,0020) LO [] # PatientID As informações resultantes poderão ser usadas para fazer a busca de imagens, mas isso será demonstrado posteriormente. Para fazer a mesma consulta através da interface, é mais simples. No formulário de pesquisa, acessado através do menu Ferramentas > Pesquisar arquivos, basta informar os dados de origem, destino, nome do host e porta lógica que o servidor está funcionando e clicar no botão pesquisar. Se nenhum outro dado referente a nome

58 46 do paciente e código forem informados, será interpretado como uma pesquisa geral, buscando por todas as imagens contidas no repositório desejado (figura 13). O resultado é mostrado em uma tabela, contendo as seguintes informações para cada imagem encontrada: nome do repositório (AETitle) onde a imagem se encontra, o nome do paciente e seu código (figura 14). FIGURA 13 - Exemplo de como fazer uma pesquisa geral Buscar imagem A forma de fazer a busca de imagens por meio da interface é simples. Após fazer uma pesquisa, o resultado é mostrado em uma tabela, podendo-se selecionar a imagem desejada e realizar a busca clicando no botão buscar, como na figura 14. A imagem recebida é armazenada no diretório raiz, onde a aplicação Kamelot Offis está executando. Uma desvantagem do OFFIS é que toda imagem que é enviada para ele, tem o seu nome transformado para o formato hexadecimal e quando é feito a busca de alguma imagem, o arquivo é enviado com o nome neste formato, gerando dificuldades para identificá-la.

59 47 FIGURA 14 - Exemplo de como buscar uma imagem Para realizar essa ação, utiliza-se a aplicação movescu. Esta tem a sintaxe similar a aplicação findscu. Então, se for realizar a mesma busca feita anteriormente pelo prompt de comando, os passos são os seguintes: Deve-se criar um arquivo DICOM com os dados da imagem no qual se deseja buscar. Para o exemplo da figura 14, o conteúdo do arquivo deve ficar assim: (0008,0052) CS [PATIENT] (0008,0054) AE [TCC_STORE] (0010,0010) PN [MR/ABDO/UTSE/256] (0010,0020) LO [4] Posteriormente, digita-se a seguinte linha de comando: movescu P aet MAQ1 aec TCC_STORE olavo 5678 arquivodicom.dcm Se a imagem for encontrada no diretório TCC_STORE, ela será enviada a MAQ1, caso contrário será enviado uma mensagem de insucesso na busca. É aconselhável sempre fazer uma pesquisa antes de realizar a busca de imagens, a fim de garantir que a imagem desejada exista no diretório de armazenamento. Nota-se que utilizando o método convencional está mais suscetível a insucessos, visto que qualquer informação errada sobre a imagem desejada pode resultar em erros na realização da busca, pois o arquivo pode não ser encontrado.

60 Enviar imagem O envio de imagens para a aplicação servidora, utilizando o prompt de comando, é realizado através da seguinte linha: storescu aet MAQ1 aec TCC_STORE olavo 5678 imagem.dcm Isso significa que o arquivo imagem.dcm está sendo enviado de MAQ1 para TCC_STORE, que está localizado no host olavo e recebendo requisições na porta Se a imagem que será enviada não estiver no mesmo diretório em que se está executando a aplicação storescu, é necessário incluir todo o caminho de onde a imagem se encontra, por exemplo: C:\imagens\imagem.dcm. Utilizando a interface, o envio de imagens se procede da seguinte forma. Acessando a opção no menu Ferramentas > Enviar arquivo, irá abrir um formulário para que sejam fornecidas algumas informações, como AETitle de origem e destino, nome do host e porta em que o servidor está executando e a imagem desejada (15). Para informar a imagem que se deseja enviar, pode-se optar por explorar o conteúdo do computador e selecioná-la ao invés de informar todo o caminho de onde essa se encontra (figura 16). FIGURA 15 - Exemplo de como enviar uma imagem

61 49 FIGURA 16 - Utilizando o botão... para encontrar a imagem 5.3 Conclusão Procurou-se através deste capítulo criar um guia para os usuários do software desenvolvido, demonstrando como que as funções de enviar, pesquisar e buscar, arquivos são executadas do modo tradicional (shell) e através da interface, proporcionando resultados visíveis das facilidades que o software proporciona para a utilização dessas funções.