INTRODUÇÃO AO PROTOCOLO DICOM E IMPLEMENTAÇÃO DE UM VISUALIZADOR COMPATÍVEL

Transcrição

1 UNIVERSIDADE FEDERAL DO PARÁ ITEC FACULDADE DE ENGENHARIA DA COMPUTAÇÃO E TELECOMUNICAÇÕES BRENNO BERNARDES RIBEIRO INTRODUÇÃO AO PROTOCOLO DICOM E IMPLEMENTAÇÃO DE UM VISUALIZADOR COMPATÍVEL BELÉM, PARÁ 2013

2 BRENNO BERNARDES RIBEIRO INTRODUÇÃO AO PROTOCOLO DICOM E IMPLEMENTAÇÃO DE UM VISUALIZADOR COMPATÍVEL Trabalho de Conclusão de Curso apresentado no curso de Engenharia da Computação da Universidade Federal do Pará, como requisito parcial para obtenção do grau de Engenheiro da Computação. Orientador: Ronaldo de Freitas Zampolo BELÉM, PARÁ 2013

3 BRENNO BERNARDES RIBEIRO INTRODUÇÃO AO PROTOCOLO DICOM E IMPLEMENTAÇÃO DE UM VISUALIZADOR COMPATÍVEL Aprovada em: / / Trabalho de Conclusão de Curso apresentado no curso de Engenharia da Computação da Universidade Federal do Pará, como requisito parcial para obtenção do grau de Engenheiro da Computação. BANCA EXAMINADORA Prof. Ronaldo de Freitas Zampolo Universidade Federal do Pará - UFPA Orientador Eng. Almir de Morisson Faria Júnior Co-Orientador Prof. Agostinho Luiz da Silva Castro Universidade Federal do Pará - UFPA Prof. Ádamo Lima de Santana Universidade Federal do Pará - UFPA Diretor da Faculdade de Engenharia da Computação e Telecomunicações

4 AGRADECIMENTOS Em primeiro lugar a Deus por cada dia de vida, a oportunidade de fazer as coisas melhores e da descoberta de novos caminhos e conhecimentos. Aos meus amados pais, Cleonice Bernardes Ribeiro e Carlos Alberto Araujo Ribeiro, por me mostrarem o verdadeiro caminho a seguir e pelo apoio que sempre têm me dado. Ao meu irmão, Tácio Vinícius Bernardes Ribeiro e aos meus familiares, onde mesmo na distância se fizeram presentes no meu coração. À minha namorada, Heloisa Pamela Mendonça que sempre me apoiou, me incentivando e compreendendo os momentos que abdicamos juntos para que esse momento chegasse. Ao meu orientador Prof. Dr. Ronaldo de Freitas Zampolo, que pelo voto de confiança depositado, deu-me a oportunidade de realizar este trabalho. Agradeço pela oportunidade, pela disponibilização dos recursos necessários, o apoio e a ajuda que forneceu para o desenvolvimento e conclusão deste estudo. Aos amigos queridos, principalmente aqueles que estavam na mesma jornada que eu, aspirantes a Engenheiro, seja desde o início do curso ou no decorrer deste. Só eles realmente sabem e entendem o quanto é difícil chegar no final da jornada, principalmente olhando para trás e vendo que vários desistiram do curso porque não aguentaram a pressão ou acharam que o curso é muito difícil. Se fosse fácil não teria graça, pois tudo que vem fácil vai embora mais facil ainda. Um abraço muito especial para toda a galera de 2007, afinal o que seria do vadião se não fosse vocês. Aos professores que contribuíram com minha formação, não só com instrução técnica, mas com princípios que substancialmente se fizeram e fazem importantes para a minha formação. Ao LaPS (Laboratório de Processamento de Sinais), pela colaboração significativa com o meu amadurecimento acadêmico e onde tive a oportunidade do desenvolvimento deste trabalho.

5 E por fim, mas não menos importante, agradeço também à UFPA, pela graduação.

6 O que é raro tem valor, o abundante não. Biscoito da Sorte

7 SUMÁRIO 1 Introdução Objetivos Contribuições Estrutura do trabalho O padrão DICOM Histórico Conformidade Declaração de conformidade Visão geral da seção de redes para declaração de conformidade Visão geral da seção de armazenamento de mídias para declaração de conformidade Requisitos de conformidade Requisitos de conformidade em redes de computadores Requisitos de conformidade em intercâmbios de mídias DICOM Funcionalidades DICOM para transferência de imagem DICOM para gerenciamento de impressão em rede DICOM para gerenciamento de imagem DICOM para intercâmbio/arquivamento de mídias

8 2.4 Estrutura Formato de um arquivo DICOM Definições de Informação do Objeto - IODs Título de Aplicação da Entidade - AE Title Classe Usuária/Provedora de Serviços - SCU/SCP Identificadores Únicos - UIDs Sintaxe de Transferência Representação de Valor - VR Conclusões Trabalhos relacionados Serviço de Acesso a Observações Clínicas - COAS Linguagem de Marcação Extensível - XML Extensões Multifunção para Mensagens de Internet - MIME Nível Sete de Saúde - HL Conclusões Ferramenta Desenvolvida Ambiente de desenvolvimento Modelagem do sistema desenvolvido Metodologia de trabalho ITK VTK Qt Processamento ITK Processamento VTK Processamento Qt Descrição da ferramenta produzida Conclusões Conclusão Propostas Futuras

9 Referências Bibliográficas

10 LISTA DE FIGURAS Figura 2.1 Transformando dados em uma sequência de elementos Figura 2.2 Representação dos elementos de dados Figura 2.3 Exemplo de conexão entre SCUs e SCPs Figura 2.4 Representação de Identificadores Únicos Figura 2.5 Little Endian versus Big Endian [13] Figura 3.1 Representação de um documento XML Figura 3.2 Mensagem HL7 [34] Figura 3.3 Segmento de uma mensagem HL7 [34] Figura 4.1 Diagrama de casos de uso da ferramenta desenvolvida Figura 4.2 Esquema de integração entre as tecnologias Figura 4.3 Registro de uma imagem [41] Figura 4.4 Da esquerda para direita: Imagem original, tipo 1 de segmentação, tipo 2 de

11 segmentação e tipo 3 de segmentação [41] Figura 4.5 Representação do processamento de imagem realizado pela VTK Figura 4.6 Arquitetura do Qt formada por seus módulos [51] Figura 4.7 Imagem da interface do Visualizador de Imagens DICOM Figura 4.8 Janela para abertura de arquivo DICOM Figura 4.9 Imagem DICOM visualizada após todo o processamento das bibliotecas Figura 4.10 Imagem DICOM visualizada após o desenho de pontos Figura 4.11 Imagem DICOM visualizada após o desenho de círculos Figura 4.12 Imagem DICOM visualizada após o desenho de retas Figura 4.13 Imagem DICOM visualizada após o desenho de elipses Figura 4.14 Imagem DICOM visualizada após o desenho de retângulos Figura 4.15 Imagem DICOM visualizada após a aplicação de um zoom de 250% Figura 4.16 Imagem DICOM visualizada após desenhos com propriedades modificadas. 35 Figura 4.17 Imagem DICOM visualizada após a escrita de texto Figura 4.18 Imagem DICOM e funcionalidade para o Janelamento Figura 4.19 Imagem DICOM visualizada após um Janelamento Figura 4.20 Imagem DICOM visualizada após um Janelamento Figura 4.21 Imagem DICOM visualizada após um Janelamento

12 Figura 4.22 Exibição de um resumo das tags contidas em um arquivo DICOM Figura 4.23 Exibição das tags contidas em um arquivo DICOM Figura 4.24 Exibição da funcionalidade de salvar a imagem em um arquivo no formato DICOM Figura 4.25 Exibição da funcionalidade de salvar a imagem em outros formatos

13 LISTA DE TABELAS Tabela 2.1 Lista de tags DICOM Tabela 2.2 Representação do corpo de um arquivo DICOM Tabela 2.3 Exemplo de IODs Tabela 2.4 Exemplo de AE Title Tabela 2.5 Ordenação Little Endian Tabela 2.6 Ordenação Big Endian Tabela 2.7 Representação de algumas das 27 possíveis VRs Tabela 3.1 Decomposição dos campos de um segmento Tabela 4.1 Arquivos DICOM utilizados

14 LISTA DE SIGLAS 2D 3D AAPM ACR AE ANSI ASCII ATI COAS CT dcm DDR3 DICOM DVD DX FFT FSC FSR FSU GB GE GHz GIF GNU GUI HD Bidimensional Tridimensional American Association of Physicists in Medicine American College of Radiology Application Entity American National Standards Institute American Standard Code for Information Interchange Allied Telesyn International Clinical Observation Access Service Computed Tomography Extensão do arquivo DICOM Double Data Date type Three Digital Imaging and Communications in Medicine Digital Versatile Disc Digital Radiography Fast Fourier Transform File-set Creator File-set Reader File-set Updater Gigabyte General Electric Gigahertz Graphical Interchange Format GNU is Not Unix Graphical User Interface High Definition

15 HIS HL7 HTTP ID IOD IODs ISO ITK JPEG JPG MB MIME MPEG MR NEMA NM OMG OS OSI PACS PNG RAM RGB RIS RSNA RT SCP SCPs SCU SCUs SOP SOPs SR TCP/IP TI TM UID UIDs Hospital Information System Health Level Seven Hypertext Transfer Protocol Número Identificador Information Object Definition Information Object Definitions International Organization for Standardization Insight Segmentation and Registration Toolkit Joint Photographic Experts Group Abreviação de JPEG Megabyte Multipurpose Internet Mail Extensions Moving Picture Experts Group Magnetic Resonance National Electrical Manufaturers Association Nuclear Medicine Object Management Group Operating System Open Systems Interconnection Picture Archiving and Communication System Portable Network Graphic Random Access Memory Red Green Blue Radiology Information System Radiological Society of North America Radiation Therapy Service Class Provider Plural de SCP Service Class User Plural de SCU Service Object Pair Plural de SOP Structured Reporting Transmission Control Protocol/Internet Protocol Tecnologia da Informação Trade Mark Unique Identifiers Plural de UID

16 US Ultrasound v2 version 2 v3 version 3 VL Value Length VR Value Representation VTK Visualization Toolkit W3C World Wide Web Consortium XML Extensible Markup Language XP Extreaming Programming

17 RESUMO Imagens médicas são amplamente utilizadas e de fundamental importância para o auxílio de diagnósticos médicos, o padrão mais utilizado para armazenar estas imagens denomina-se DICOM (Comunicação de Imagens Digitais na Medicina), o que motivou a implementação de um visualizador de imagens que seja capaz de trabalhar com imagens DICOM. É apresentada uma revisão bibliográfica ampla, bem como histórico do desenvolvimento do padrão DICOM, algumas características de conformidade, as suas principais funcionalidades e a organização da sua estrutura. Ainda há a apresentação de alguns comentários sobre outros padrões estruturados que podem ser utilizados em sistemas de informação hospitalar, tais como COAS (Serviço de Acesso a Observações Clínicas), XML (Linguagem de Marcação Extensível), MIME (Extensões Multifunção para Mensagens de Internet) e HL7 (Nível Sete de Saúde). O visualizador foi codificado em C++ usando o framework Qt e as bibliotecas ITK e VTK, disponibilizando assim funcionalidades mínimas necessárias para abranger os principais usos em situações práticas, dentre as quais podem-se relacionar: exibição de imagem, anotação de texto, traçado de retas, retângulos, círculos, elipses e pontos, zoom, centralização, janelamento, exibição de tags e exportação de imagem. Palavras-Chave: DICOM, Processamento de imagens, C++, ITK, VTK, Qt.

18 ABSTRACT Medical images are widely used and have a fundamental importance in the medical diagnoses support, the most used standard for storing these images is called DICOM (Digital Imaging Communications in Medicine), this motived the implementation of a image viewer which is able to work with DICOM images. This work also presents a comprehensive literature review, as well as the historical development of the DICOM standard, some features of conformance, its main features and the organization of its structure. It also presents some comments of other structured standard that can be used in hospital information systems, such as COAS (Clinical Observation Access Service), XML (Extensible Markup Language), MIME (Multipurpose Internet Mail Extensions) and HL7 (Health Level Seven). The viewer was coded in C + + using the Qt framework and libraries ITK and VTK, providing the minimum required functionality to cover the main uses of a image visualizer in practical situations, among which may be related: image display, text annotation, tracing lines, rectangles, circles, ellipses and points, zoom, centralization, windowing, tags display and image export. Keywords: DICOM, Image processing, C++, ITK, VTK, Qt.

19 1 CAPÍTULO 1 INTRODUÇÃO O DICOM (Digital Imaging Communications in Medicine - Comunicação de Imagens Digitais na Medicina) é um padrão de TI (Tecnologia da Informação) que é usado em hospitais em uma escala mundial. Sua atual estrutura, que foi desenvolvida em 1993, foi projetada para assegurar a interoperabilidade de sistemas utilizados para produzir, armazenar, exibir, processar, enviar, consultar, recuperar e imprimir imagens médicas e documentos derivados, bem como gerir fluxo de trabalhos relacionados. O DICOM foi desenvolvido de acordo com os procedimentos do grupo formado por fabricantes e associações, em grande maioria da área médica, chamado de DICOM Standards Committee (Comitê DICOM de Padrões), e tem a sua estrutura baseada nas diretrizes de elaboração e apresentação de padrões internacionais [1]. As declarações de conformidade são regras do referido padrão e essenciais para interoperabilidade, pois fornecem informações importantes para os implementadores e integradores de sistemas com o intuito de determinar se há ou não a necessidade de fazer aplicações interoperarem (se comunicarem). Além disso, quando ocorrerem problemas, elas fornecem uma fonte de informação com o intuito de resolver potencialmente qualquer problema, proporcionando implementadores com um modelo consistente. Hospitais, clínicas, centros de imagem e especialistas necessitam de DICOM. Ao adquirir somente equipamentos e sistemas de informação que estejam em conformidade com o padrão DICOM, pode-se garantir que essas ferramentas vão trabalhar juntas para produzir, gerir e distribuir imagens independentemente de fornecedores. 1.1 Objetivos O principal objetivo deste trabalho é realizar um estudo sobre o padrão DICOM com o intuito de criar um visualizador de imagens armazenadas segundo o referido padrão que possua

20 2 as funcionalidades mínimas para abranger os principais usos em situações práticas, dentre as quais podem ser citadas: exibição de imagem, anotação de texto, traçado de retas, retângulos, círculos, elipses e pontos, zoom, centralização, janelamento, exibição de tags e exportação de imagem. Esta meta é alcançada com o uso de bibliotecas em C++ que permitem a segmentação, o manuseio e o processamento de imagens. Através de processamentos descritos no decorrer deste trabalho torna-se viável, ao ter como entrada um arquivo DICOM, a visualização de diversas informações que estavam codificadas neste arquivo, destacando a imagem contida no mesmo. 1.2 Contribuições Este trabalho fundamenta alguns dos diversos componentes que ajudam a formar o padrão DICOM, de modo que cada um possui a sua especificidade e a sua contribuição. E para chegar e um resultado final foi necessário passar por algumas etapas, cada uma com a sua respectiva contribuição. Seguindo as etapas realizadas neste trabalho pode-se definir como principais contribuições do mesmo: A introdução ao histórico do padrão DICOM. A introdução aos seus princípios de conformidade. A introdução às principais funcionalidades que o padrão DICOM possui. A introdução à estrutura do padrão DICOM, tornando possível o entendimento da organização do mesmo. A apresentação de comentários sobre outros padrões estruturados que podem ser utilizados em sistemas de informação hospitalar. A implementação de uma aplicação prática usando o padrão DICOM. 1.3 Estrutura do trabalho O restante do documento é dividido em capítulos de acordo com o que segue: Capítulo 2: apresenta uma revisão bibliográfica ampla, bem como um breve histórico do desenvolvimento do padrão DICOM e suas principais funcionalidades e recursos. Capítulo 3: comenta outros padrões que se relacionam de alguma forma com o padrão DICOM. Capítulo 4: detalha a implementação feita de uma aplicação prática do padrão DICOM. Capítulo 5: apresenta as considerações finais sobre os temas abordados neste trabalho, bem como propostas para trabalhos futuros relacionados.

21 3 CAPÍTULO 2 O PADRÃO DICOM Para compreender a necessidade de se criar um padrão que fosse capaz de entender a mesma mensagem recebida em diferentes máquinas (de fabricantes distintos) basta observar o seguinte exemplo: em uma viagem para o exterior, compra-se uma fita de vídeo com um filme antigo e raro porém ao retornar para o seu país de origem e colocar a fita no devido aparelho de reprodução, o que se vê é apenas uma imagem chuviscada. E ao examinar a fita percebese que nela está escrito que o vídeo funciona somente em um sistema de reprodução que só é vendido no país de origem da fita. Pois são problemas como este que tornam difíceis a troca de informações médicas entre os principais sistemas de produção de imagens. 2.1 Histórico Um dos padrões que antecederam o DICOM, e teve a sua devida importância foi o padrão que foi aprovado pela AAPM (American Association of Physicists in Medicine - Associação Americana de Físicos em Medicina) em 1978, um padrão no formato de fita magnética para troca de imagens digitais [2], que trouxe a ideia de gravar imagens em fitas magnéticas de forma que toda informação codificada seria uma sequência de elementos. Estes que já carregariam consigo, ainda que não totalmente amadurecida, a ideia do conceito de tag, uma chave correspondendo a um nome descritivo formando um par com um determinado valor, ou seja, representando dados como uma sequência de elementos. A Figura 2.1 representa este conceito. Figura 2.1: Transformando dados em uma sequência de elementos.

22 4 Em 1983 o ARC (American Association of Physicists in Medicine - Colegiado Americano de Radiologia) e o NEMA (National Electrical Manufaturers Association - Associação Nacional de Fabricantes Elétricos) formaram um comitê cujos objetivos eram desenvolver um padrão que fosse capaz de promover a comunicação de informações contidas em uma imagem digital, seja qual fosse o fabricante do equipamento, facilitar o desenvolvimento e expansão dos PACS (Picture Archiving and Communication System - Sistema de Comunicação e Arquivamento de Imagens) [3], se relacionar com outros sistemas de informação hospitalar e permitir a criação de diagnósticos baseados em dados que possam ser examinados por uma variedade de dispositivos. Porém, somente em 1985 a primeira versão do padrão DICOM foi criada, portando o nome de ACR-NEMA ou ACRNEMA 1.0, e disseminada pela RSNA (Radiological Society of North America - Sociedade Norte Americana de Radiologia). Esta versão especifica uma interface que suporta transmissão de imagem ponto-a-ponto, um dicionário de dados (um conjunto de regras para a codificação de informações) e um conjunto de comandos para iniciar transações. A segunda versão do padrão DICOM foi publicada em 1988 e recebeu o nome de ACR- NEMA 2.0 ou ACR-NEMA , esta versão também aborda a transmissão de imagem ponto-a-ponto e fornece regras semânticas para a organização de mensagens. Contudo, com a disseminação da tecnologia de redes tornou-se necessário realizar mais algumas adaptações no padrão, pois o mesmo ainda possuía capacidade limitada para operar neste tipo de contexto. Em 1992, a terceira versão do padrão foi apresentada para a RSNA e recebeu o nome de ACR-NEMA DICOM ou DICOM 3.0, como o padrão não recebeu em suas nomenclaturas anteriores os nomes DICOM 2.0 e DICOM 1.0 ele é comumente denominado apenas de DICOM. O DICOM recebe revisões anuais e sua versão mais recente pode ser encontrada e lida no site oficial do NEMA [4]. 2.2 Conformidade O padrão DICOM define 2 princípios de conformidade que as implementações precisam seguir para poder estarem de acordo com o padrão. São eles: requisitos de conformidade e declarações de conformidade. Os requisitos de conformidade especificam os requisitos gerais que devem ser cumpridos por qualquer implementação que alegue estar em conformidade. Enquanto isso, as declarações de conformidade definem a estrutura de uma implementação, especificando quais informações devem estar presentes em qualquer implementação com DICOM Declaração de conformidade Uma implementação não precisa usar todos os componentes do padrão DICOM. Depois de conhecidos os requisitos mínimos gerais, uma implementação DICOM que esteja em conformidade deve utilizar qualquer um dos SOP (Service Object Pair - Serviços de Objetos Pa-

23 5 reados) DICOM, onde estes representam um pareamento que fornece serviços como armazenar, resgatar, mover e pesquisar a partir de objetos como imagens oriundas, por exemplo, de uma MR (Magnetic Resonance - Ressonância Magnética) ou de uma CT (Computed Tomography - Tomografia Computadorizada). A declaração de conformidade permite que o usuário determine quais componentes opcionais do padrão DICOM são suportados por uma implementação em particular e quais extensões adicionais ou especializações estão incluídas na mesma. Partindo deste pressuposto, ao comparar as declarações de conformidade entre duas diferentes implementações um usuário bem informado deveria ser capaz de determinar se há ou não a possibilidade da comunicação entre as duas implementações ser suportada. Diferentes estruturas são usadas pelo conteúdo da declaração de conformidade, dependendo do caso a implementação pode suportar uma interface de redes DICOM, ou uma interface de armazenamento de mídias DICOM, ou ainda uma combinação de ambas. Em último caso, uma simples declaração de conformidade deve fornecer o que consiste na sua seção apropriada Visão geral da seção de redes para declaração de conformidade Para satisfazer os requisitos de redes, uma implementação deve conter alguns elementos que estão contidos na própria declaração de conformidade, tais como uma visão funcional contendo o diagrama de fluxo de dados da aplicação que mostra todas as entidades da aplicação, incluindo qualquer sequência de restrições entre elas, mostrando como as entidades se relacionam tanto localmente quanto remotamente com as atividades do mundo real. Também é importante que se tenha uma especificação mais detalhada de cada entidade da aplicação (listando as Classes SOP suportadas e delineando as políticas com as quais se iniciam ou aceitam associações entre estas), uma lista de cada opção suportada pelo SOP para cada Classe SOP relacionada à uma sintaxe abstrata e um conjunto de protocolos de comunicação que a referida implementação suporta. Outra necessidade como requisito é um conjunto de descrições, tais como: uma descrição da proposta (associação inicial) e dos contextos de apresentação aceitáveis (associações aceitáveis) para cada entidade da aplicação e para cada combinação de atividade do mundo real, uma descrição de qualquer extensão, especialização ou privatização publicamente divulgada nesta implementação, uma seção descrevendo os detalhes de configuração relacionados ao DICOM, uma descrição de qualquer detalhe da implementação que possa estar relacionado com a conformidade do DICOM ou a interoperabilidade, e por fim uma descrição de quais códigos e mecanismos de terminologia controlada são usados Visão geral da seção de armazenamento de mídias para declaração de conformidade Para satisfazer os requisitos de armazenamento de mídias uma implementação deve conter alguns elementos, tais como (semelhantemente à seção de redes) uma visão funcional

24 6 contendo o diagrama de fluxo de dados da aplicação que mostra todas as entidades de aplicação, incluindo qualquer sequência de restrições entre elas, e também mostrar como elas se relacionam localmente e remotamente nas atividades do mundo real. Pode-se destacar ainda entre os requisitos uma especificação mais detalhada de cada entidade da aplicação, listando os perfis da aplicação de armazenamento de mídias suportadas, definindo as Classes SOP suportadas e as mídias selecionadas, e delineando as políticas com as quais criam, lêem, ou atualizam um conjunto de arquivos nas mídias. Também há a necessidade de um conjunto de listas, tais como uma lista opcional de Classes SOP suportadas, uma lista de qualquer opção suportada para cada Classe SOP de armazenamento de mídias relacionadas com o perfil da aplicação de armazenamento de mídias e uma lista opcional de sintaxes de transferências suportadas para cada Classe SOP de armazenamento de mídias relacionadas com o perfil de aplicação de armazenamento de mídias. Por fim, ainda são necessárias algumas outras descrições, tais como uma seção descrevendo detalhes de configurações relacionadas ao DICOM e uma descrição de qualquer extensão, especialização ou privatização publicamente divulgada nesta implementação seja ela aumentada ou de acordo com o perfil de aplicação privada Requisitos de conformidade Como requisitos fundamentais para estar em conformidade com o padrão DICOM, pode-se destacar o suporte a redes de computadores e o suporte ao armazenamento de mídias. Para uma implementação estar de acordo com a conformidade do padrão é necessário que pelo menos um dos dois requisitos seja satisfeito, também havendo a possibilidade dos dois requisitos estarem presentes em uma implementação Requisitos de conformidade em redes de computadores Com relação ao suporte a redes de computadores existem alguns fatores que auxiliam a satisfazer este requisito, dentre eles podem-se destacar a aceitação de um contexto de apresentação por parte dos dispositivos envolvidos, definindo papéis específicos para cada um, onde haverá papéis de cliente (SCU, Service Class User - Usuário de Classe de Serviço) e servidor (SCP, Service Class Provider - Provedor de Classe de Serviço). Também há a necessidade de uma produção e/ou processamento de um Data Set (conjunto de dados) definidos na parte 5 do padrão [5], a obtenção do direito legítimo de um ID (Número Identificador) registrado por uma organização que seja condizente com a criação de UIDs (Unique Identifiers - Identificadores únicos) na parte 5 do padrão, e obviamente suportar o protocolo de comunicação TCP/IP Requisitos de conformidade em intercâmbios de mídias DICOM O padrão não avalia a conformidade somente de uma mídia de forma isolada mas sim o relacionamento do seu perfil de aplicação com o contexto específico para que haja a interopera-

25 7 bilidade. Por outro lado o padrão também especifica métodos para proporcionar segurança em diferentes níveis do modelo de rede ISO/OSI [6] através da utilização de mecanismos específicos para uma determinada camada. Os métodos de aplicação destes mecanismos são descritos nas várias partes do padrão DICOM. Alguns mecanismos e algoritmos são especificados como perfis de segurança na parte 15 do padrão [7], descrevendo os perfis de segurança que podem ser usados por determinada aplicação. De um modo geral, para satisfazer os requisitos de conformidade do padrão em questão uma implementação deve possuir algumas atribuições como estar em conformidade com pelo menos um perfil de aplicação do padrão definido na parte 11 do padrão [8], suportar umas das mídias físicas e formatos de mídias associadas que estão conforme a parte 12 do padrão [9], usar alguns dos termos utilizados pelo padrão para troca de dados tais como ler como FSR (File-set Reader - Leitor de Conjunto de arquivos) ou FSU (File-set Updater - Atualizador de Conjunto de arquivos) e escrever como FSC (File-set Creator - Criador de Conjunto de arquivos) ou FSU todas as Classes SOP definidas como obrigatórias por cada um dos perfis de aplicação suportados em uma das sintaxes de transferência obrigatórias, e por fim ser capaz de ignorar qualquer padrão ou Classe SOP privada que devem estar presentes no meio do armazenamento mas não estão definidos em qualquer um dos perfis de aplicação onde a conformidade é solicitada. 2.3 Funcionalidades Os tipos de serviços suportados pelo DICOM podem ser classificados em 4 grupos, são eles: transferência de imagens, servidores de impressão, gerenciamento de imagens e, por fim, intercâmbio e arquivamento de mídias. Antes de iniciar uma breve descrição dos grupos citados anteriormente, torna-se interessante conhecer como funciona o ciclo genérico de um fluxo de trabalho de um serviço DICOM. O funcionamento do ciclo referido se dá da seguinte forma: o ciclo se inicia quando ocorre uma estabilização entre a associação formada por um dispositivo que é a fonte de imagem (um usuário de serviços de armazenamento) e por outro dispositivo que é o servidor de imagens (um fornecedor de serviços de armazenamento). Após a associação se estabilizar, ocorre uma requisição de armazenamento, oriunda da fonte de imagem, enviando uma mensagem com cabeçalho e pixels de acordo com umas das sintaxes de transferências aceitas. O próximo passo será a resposta do provedor de serviços de armazenamento de imagens com a relação ao pedido de armazenamento. A resposta conterá o resultado da operação de armazenamento, se ocorreu com sucesso ou se houve falha. Após a resposta do sistema, como a associação está estabilizada, o ciclo repete as fases de pedido e resposta até que a associação se desestabeleça.

26 DICOM para transferência de imagem O padrão DICOM alcança a maioria das imagens médicas, podendo usar manuseio e recuperação de dados de uma determinada imagem para auxiliar em planos de terapia e relatórios estruturados. O padrão em questão, além de ser muito usado pela radiologia também visa outras especialidades da medicina como a cardiologia (Angiografia usando Raios-X, Medicina Nuclear - NM e Ultra-som - US), oncologia (Portal de Imagens de Terapia por Radiação - RT), odontologia (Raios-X Intra-oral), patologia, endoscopia, microscopia, oftalmologia, etc. Para construir uma rede de transferência de imagens DICOM deve-se seguir basicamente três passos. Esclarecer qual as necessidades clínicas para a transferência de imagens e para as aplicações de processamento de imagem, casar as necessidades com as Classes de Serviços DICOM usando as declarações de conformidade e validar a interoperabilidade da aplicação da imagem DICOM para gerenciamento de impressão em rede Este gerenciamento permite que dispositivos de aquisição de imagens e estações de trabalho compartilhem uma impressora que esteja em uma rede DICOM, semelhante à maneira com que computadores pessoais compartilham uma impressora comum a rede doméstica. O Anexo H na parte 4 do padrão DICOM [10] especifica a Classe de Serviço de Gerenciamento de impressão. Esta especificação define um conjunto básico de funções obrigatórias e algumas extensões opcionais. Quatro meta Classes SOP (conjuntos de objetos interdependentes destinados a serem utilizados de uma forma coordenada) são especificadas para dar suporte básico às aplicações de impressão. As meta Classes SOP que são obrigatórias dão suporte à impressão em tons básicos de cinza, impressão em cores básicas, impressão em tons de cinza com realces da tabela RGB (Red Green Blue - Vermelho, Verde e Azul) de cores e a impressão em tons com realce da tabela RGB de cores. Pelo menos uma das quatro meta Classes SOP obrigatórias deve ser implementada para estar de acordo com a conformidade do padrão em questão. Qualquer combinação de Classes SOP opcionais pode também ser usada. As Classes SOP opcionais permitem anotação em filme, sobreposição de imagem e relatórios avançados do status do serviço de execução de impressão DICOM para gerenciamento de imagem O DICOM fornece uma integração de suas modalidades com sistemas de informação de radiologia e com os PACS, transferindo dados demográficos do paciente automaticamente, identificando casos de estudo, realizando agendamentos e realizando procedimentos dentro das próprias modalidades do referido padrão.

27 9 Com este tipo de gerenciamento é possível ter outras visões a partir da imagem a ser trabalhada. Pode-se, por exemplo, adequar a imagem de acordo com os níveis desejados para um determinado tipo de análise, realizando alterações no centro e na largura de janela da imagem, melhorando assim a visualização por alteração de brilho e contraste DICOM para intercâmbio/arquivamento de mídias O intercâmbio de mídias se dá pelo armazenamento de imagens ou objetos DICOM no formato do padrão. Estas imagens e objetos DICOM podem ser intercambiadas e possivelmente serem lidas por outro dispositivo que seja capaz de ler o padrão DICOM. Estas aplicações são tipicamente para dispositivos portáveis que podem coletar imagens e armazená-las em um DVD (Digital Versatile Disc - Disco Digital Versátil). O próprio DVD é usado posteriormente para a obtenção das imagens em outra estação de trabalho. Outra aplicação seria colocar um Data Set contendo um estudo de cardiologia em um DVD para que o paciente possa levar o estudo até outro hospital. 2.4 Estrutura Para realizar uma breve descrição da estrutura do padrão DICOM, deve-se desmembrálo para melhor identificar os seus respectivos grupos e subgrupos de dados, fazendo assim com que seja mais simples entender a sua organização e o seu funcionamento Formato de um arquivo DICOM O padrão DICOM é um protocolo que foi construído e projetado para cobrir vários aspectos em diferentes contextos de uma imagem médica digital. Devido à esta alta complexidade e com o intuito de simplificar a descrição da estrutura do padrão, o mesmo será representado na forma de arquivo. O cabeçalho de um arquivo DICOM é formado por 3 subgrupos de informações: o arquivo é iniciado pela preamble (preâmbulo), que é a string (sequência de caracteres) de 128 bytes que por padrão é preenchida com 0 bytes (espaços em branco), porém a preamble pode ser usada para um fim específico e sendo assim usará os 128 bytes da melhor forma que precisar neste caso. Após a preamble virá o prefixo "DICM" que ocupará 4 bytes no arquivo e possuirá os caracteres sempre em sua forma maiúscula, oriundos de um repertório de caracteres da ISO 8859 [11]. Tanto o prefixo "DICM" quanto a preamble não estão estruturados como um elemento de dados DICOM, contendo uma tag e um comprimento definido. O padrão DICOM aplica a seguinte definição para o seu conceito de tag, trata-se de um identificador único para uma informação de um elemento composto por um par ordenado de

28 10 números (um número de Grupo seguido por um número de Elemento), dos quais são utilizados para identificar atributos e seus elementos de dados correspondentes. Seguindo a preamble e o prefixo "DICM", a partir do byte 133, pode-se encontrar a metainformação do arquivo DICOM, que por sua vez carregará consigo todos os atributos que pertencem ao Grupo 0002, incluindo assim informações sobre a identificação dos Data Sets encapsulados. O elemento mais importante do Grupo 0002 é representado pela tag (0002,0010), este atributo recebe o nome de "Transfer Syntax UID" (Sintaxe de transferência com identificador único) e tem como função identificar o próximo Data Set. A Tabela 2.1 representa uma lista de outras possíveis tags. Tabela 2.1: Lista de tags DICOM Informação Tag DICOM Paciente (número grupo, número elemento) ID Paciente 0010:0010 Nome Paciente 0010:0020 Data de nascimento Paciente 0010:0030 Sexo Paciente 0010:0040 Estudo de caso Tag DICOM ID Estudo 0020:0010 Nome do médico 0008:0090 Descrição Estudo 0008:1030 Data Estudo 0008:0020 Equipamento Tag DICOM Número de Série Equipamento 0020:0011 Modalidade Equipamento 0008:0060 Número de aquisição Equipamento 0020:0012 Imagem Tag DICOM Número de Instância 0020:0013 Altura Imagem 0028:0010 Largura Imagem 0028:0011 Após o cabeçalho se iniciam os elementos de dados, estes serão constituídos por quatro atributos, tais como a sua respectiva tag (que conterá 32 bits, sendo 16 bits para o Grupo da tag e 16 bits para o elemento de referido Grupo), a sua VR (Value Representation - Representação de Valor) (que poderá ocupar 0, 16 ou 32 bits, dependendo do seu tipo, podendo ser uma data, um horário, um valor binário, ou uma string, ou ainda um nome) definida pelo Dicionário de dados, o seu VL (Value Length - Valor de Comprimento) (que poderá ser de 16 ou 32 bits, dependendo da codificação usada na Representação de Valor), e por fim o valor real do campo referente à tag indicada anteriormente, podendo ter um tamanho variável que pode chegar até mesmo a 1 byte. Esta representação pode ser ilustrada na Figura 2.2, onde PN - Nome Pessoal e LO - Long String representam alguns dos diversos tipos de VRs.

29 11 Figura 2.2: Representação dos elementos de dados. O conjunto formado por todos os elementos de dados de um arquivo DICOM é denominado de Data Set, onde este é ordenado de forma crescente através da tag de cada elemento de dados. A estrutura completa da um arquivo DICOM pode ser representada pela Tabela 2.2. Tabela 2.2: Representação do corpo de um arquivo DICOM Preamble 128 bytes Prefixo "DICM" Cabeçalho 4 bytes (0002,eeee) Metainformação do arquivo X bytes Elemento de dados 1 Y1 bytes Arquivo DICOM Elemento de dados 2 Y2 bytes Elemento de dados 3 Y3 bytes Data Set Elemento de dados 4 Y4 bytes Elemento de dados n Yn bytes *eeee é qualquer elemento pertencente ao Grupo Definições de Informação do Objeto - IODs As IODs (Information Object Definitions) são coleções de atributos que trazem informações do mundo real para dentro do padrão DICOM, de modo que cada IOD contenha um

30 12 valor existente no mundo real. Existem vários tipos de IODs, tais como a IOD do paciente, IOD do equipamento, a IOD do caso de estudo, a IOD da imagem contida no arquivo, entre outras. Como exemplo de atributos contidos na IOD de um paciente pode-se citar o nome do paciente, ID do paciente, peso do paciente, altura do paciente e sexo do paciente. Um exemplo de IOD é apresentado na Tabela 2.3. Tabela 2.3: Exemplo de IODs IOD do paciente Nome Brenno Ribeiro ID Peso 86.5 Altura 1.85 Sexo M Título de Aplicação da Entidade - AE Title O padrão DICOM denomina dispositivos ou programas através do Valor de Representação AE (Application Entity) Title, com o intuito de identificar o referido dispositivo dentro de uma rede de computadores. O AE Title é um dos mais importantes Valores de Representação em redes DICOM, pois caso ele não esteja correto ela não conseguirá se comunicar com outros servidores. O AE Title ideal deve seguir algumas restrições, tais como usar somente letras e números, sem caracteres especiais e as letras preferencialmente maiúsculas. A Tabela 2.4 ilustra este conceito. Tabela 2.4: Exemplo de AE Title Lista de Acesso de Clientes Remotos AE TITLE IP PORTA COMENTÁRIO Servidor 1 MEUSERVIDORDICOM servidorlocal 4006 O próprio Servidor DICOM Servidor 2 OUTROSERVIDOR Outro Servidor Classe Usuária/Provedora de Serviços - SCU/SCP Para compreender os conceitos de Classe Usuária de Serviço (SCU - Service Class User) e Classe Provedora de Serviço (SCP - Service Class Provider) é necessário visualizar o

31 13 DICOM como um modelo de Cliente/Servidor, onde a SCU é vista como um cliente e a SCP é vista como um servidor. A SCU (cliente) faz uma requisição de um determinado serviço para a SCP (servidor), a SCP retorna uma resposta de aceitação ou negação do referido serviço e caso ocorra a aceitação, a conexão entre a SCU e a SCP é estabelecida (handshake), proporcionando assim o determinado serviço que foi solicitado. A Figura 2.3 ilustra o referido conceito. Figura 2.3: Exemplo de conexão entre SCUs e SCPs Identificadores Únicos - UIDs O DICOM comumente faz o uso de UIDs (Unique Identifiers), quase toda entidade no modelo de dados do DICOM possui um UID. No DICOM toda Classe SOP (Service-Object- Pair - Pareamento de Serviço de Objeto) possui o seu UID, todos os UIDs pré-definidos, incluindo os UIDs da Classe SOP estão documentados na parte 6 do padrão DICOM [12]. Um Objeto DICOM é uma instância da classe do mesmo, e é chamado de instância SOP, possuindo um UID chamado de SOP Instance UID (Identificador de Instância Única de Pareamento de Serviço de Objeto). Ainda podem-se destacar outros UIDs tais como o Study Instance UID (Identificador de Instância Única de Estudo) que identifica unicamente um caso de estudo e o Series Instance UID (Identificador de Instância Única de Equipamento) que identifica unicamente um equipamento (usado na obtenção do caso de estudo). O padrão DICOM define um mecanismo com o objetivo de garantir que os UIDs serão globalmente únicos. O mecanismo se dá da seguinte forma: toda aplicação DICOM deveria adquirir um UID raiz (chamado de root) que seria usado como um prefixo para os UIDs que a mesma cria. Toda entidade no modelo de dados DICOM possui um UID com exceção do paciente, pois um paciente é identificado usando a combinação de todo o seu nome e de seus IDs. A Figura 2.4 faz uma breve representação dos UIDs.

32 Sintaxe de Transferência Figura 2.4: Representação de Identificadores Únicos. A Sintaxe de Transferência define como os objetos DICOM são serializados. O processo denominado como serialização trata-se de um processo de salvar um objeto em um meio de armazenamento como um arquivo de computador ou buffer de memória, ou ainda pode ser tratado como uma transmissão via redes de computadores, de modo que o conteúdo da informação original no processo seja lido no seu destino usando o mesmo ou um diferente processo. No DICOM não há memória compartilhada mas isto pode ser feito usando o mesmo mecanismo que é utilizado para redes e arquivos, semelhantemente ao que ocorre ao serializar o objeto em memória de acordo com as regras gerenciadas pelo padrão, usando a Sintaxe de Transferência. Para que uma aplicação possa ser capaz de ler um objeto DICOM oriundo de uma rede, a mesma necessita conhecer as regras que foram utilizadas para produzir o objeto que foi enviado pela rede. Na requisição de associação denominada de calling AE (calling Application Entity - Chamada de Entidade de Aplicação) é enviada uma lista de Sintaxes Abstratas com SOP Class UIDs (Identificador de Classe Única de Pareamento de Serviço de Objeto). Para cada SOP Class, a calling AE envia uma lista de Transfer Syntax UIDs. Na resposta de associação denominada de called AE (called Application Entity - Entidade de Aplicação Chamada) é selecionado um dos Transfer Syntax UIDs para toda SOP Class aceita. Partindo dos princípios citados anteriormente o DICOM utiliza várias Sintaxes de Transferência, entre as principais destacam-se a Implicit VR Little Endian (Representação Implícita de Valor pela Extremidade Menor), sendo esta a Sintaxe de Transferência padrão usada pelo DICOM, ainda se destacam a Explicit VR Little Endian (Representação Explícita de Valor pela Extremidade Menor) e a Explicit VR Big Endian (Representação Explícita de Valor pela Extremidade Maior).

33 15 As características Implicit e Explicit podem ser entendidas da seguinte forma: enquanto a característica Implicit nunca envia o seu campo VR e o seu campo VL (Value Length - Comprimento do Valor) é sempre 32 bits (implicitando assim o tipo de Representação de Valor dos elementos de dados), a característica Explicit sempre envia o seu campo VR (geralmente contendo 16 bits), seguido pelo seu campo VL que geralmente possui 16 bits. Por outro lado, as características Little Endian e Big Endian definem o tipo de ordenação de bytes, pois um mesmo valor pode ser representado de várias formas. A ordenação Little Endian armazena o byte de menor ordem nos menores endereços de memória e os de maior ordem nos maiores endereços como pode-se observar na Tabela 2.5. Enquanto isso, a ordenação Big Endian armazena o byte de maior ordem nos menores endereços de memória e os de menor ordem nos maiores endereços como pode-se ver na Tabela 2.6. A Figura 2.5 ilustra um comparativo entre os dois tipos de ordenação. Figura 2.5: Little Endian versus Big Endian [13]. Tabela 2.5: Ordenação Little Endian Ordenação Little Endian Representação de 4 Bytes Byte 0 Byte 1 Byte 2 Byte 3 Endereço Base

34 16 Tabela 2.6: Ordenação Big Endian Ordenação Big Endian Representação de 4 Bytes Byte 3 Byte 2 Byte 1 Byte 0 Endereço Base Representação de Valor - VR Uma VR (Value Representation) representa algum dos variados formatos de dados clínicos que o padrão DICOM comporta. Entre essa diversidade de formatos tem-se datas, horários, medidas de espaço, caracteres alfabéticos, entre outros. E com o intuito de poder representar toda essa diversidade o padrão DICOM definiu dentro de um conjunto de todas as VRs 27 tipos básicos de dados. Cada VR possui a sua própria abreviação em duas letras, seguida de seu nome completo, possui também uma descrição do conteúdo da VR e de quais caracteres são permitidos nesses dados e por fim uma descrição do limite de caracteres para preencher a mesma. A Tabela 2.7 ilustra alguns dos 27 tipos básicos de dados. Tabela 2.7: Representação de algumas das 27 possíveis VRs Nome da VR com- Definição do conteúdo Caracteres Limite de tapleto e abreviado da VR permitidos manho em caracteres AE Uma string de caracteres Caracteres maiúsculos, Entidade de que identifica um nome caractere em branco 16 no máximo aplicação de um dispositivo (espaço) e o underline Uma string de caracteres UI que contém um UID que é Identificador usada para identificar 0-9 e ponto (.) 64 no máximo Único unicamente uma variedade de itens Uma string de caracteres no DA formato AAAAMMDD, Data onde AAAA contém o ano, 0-9 Exatamente 8 MM contém o mês e DD contém o dia

35 Conclusões Este capítulo apresentou um breve histórico do padrão DICOM, desde padrões que antecederam o referido padrão até a criação da versão mais recente do mesmo. Também foram apresentados as declarações de conformidade e os requisitos de conformidade, que compõe os dois princípios de conformidade que o padrão possui. As quatro funcionalidades básicas que o padrão DICOM possui foram descritas, cada uma com a sua respectiva característica. Adicionalmente foi apresentada a estrutura do padrão em questão o que permitiu a compreensão da organização do mesmo.

36 18 CAPÍTULO 3 TRABALHOS RELACIONADOS O DICOM não é o único padrão usado em sistemas de informação hospitalar; existem outros que também tem a sua devida importância e contribuíram para o desenvolvimento desta área de aplicação. Este capítulo visa apresentar alguns comentários sobre outros padrões que podem ser usados em sistemas de informação hospitalar, apresentando seus conceitos e criando um breve paralelo do DICOM com cada um. 3.1 Serviço de Acesso a Observações Clínicas - COAS O padrão COAS - Clinical Observation Access Service [14] é um conjunto de interfaces e estruturas de dados relacionados com a forma com que um servidor pode fornecer observações clínicas e foi definido pelo OMG (Object Management Group - Grupo de gerenciamento de objeto) [15]. Observações clínicas referem-se a informações que foram capturadas a respeito do estado médico e/ou físico de um paciente e estão em um contexto relevante para determinado caso de estudo. O COAS consiste em uma porção significante de informação que diz respeito a qualquer paciente (qualquer informação útil para determinado estudo de caso), tanto instrumentos médicos quanto profissionais de saúde podem inserir ou ler essas informações durante exames ou outros procedimentos clínicos. Este serviço funciona basicamente como um meio para que as informações médicas sejam transferidas como dados bem definidos a partir de padrões estruturados como o DICOM, por exemplo. Cada observação possui um "tipo", onde significa dentro do padrão o nome da própria observação, ou seja, seria equivalente no DICOM à ideia do nome de um DICOM SR (Structured Reporting - Relatórios estruturados). Outro ponto em comum do COAS com relação ao DICOM é a especificação de conformidade, na qual o COAS define 3 áreas que são

37 19 usadas para especificar os seus níveis de conformidade, que são descritos na especificação do COAS [16]. Quando se fala em relatórios estruturados no campo de dados da saúde, o COAS consegue realizar pesquisas e operações de consulta em diversos campos porém se comparado ao DICOM, deixa a desejar em relação ao manuseio dos dados correspondentes às imagens médicas. 3.2 Linguagem de Marcação Extensível - XML O padrão XML - extensible Markup Language [17] é um padrão, recomendado pela W3C (World Wide Web Consortium - Consórcio da Rede Ampla Mundial) [18] para gerar linguagens de marcação para necessidades especiais, baseado em texto simples para representar informações estruturadas tais como documentos, dados, configurações, transações, livros, faturas, entre outras informações. A partir do próprio nome do padrão pode-se entender algumas características fundamentais do mesmo. Linguagem de marcação refere-se a um conjunto de palavras e símbolos que descrevem uma identidade ou função de uma parte do componente de um documento (cabeçalho, parágrafo, lista, legenda de uma figura, entre outros). A extensibilidade corresponde à flexibilidade no padrão em questão, usando a sua própria linguagem para descrever outras linguagens, tornando possível o planejamento de uma única linguagem de marcação para uma variedade de tipos de documentos. O padrão XML aplica uma definição diferente do padrão DICOM para o conceito de tag, trata-se de palavras chaves delimitadas pelos operadores < e >, e servem para demarcar o começo e o fim de elementos que serão as unidades lógicas de informação em um documento XML. A Figura 3.1 representa um exemplo de documento XML, onde cada elemento é iniciado seguindo a sintaxe <nometag> e finalizado seguindo </nometag>. Figura 3.1: Representação de um documento XML. O XML assim como o DICOM estrutura, armazena e transporta informação usando as suas respectivas tags. Porém o XML possui um foco maior para armazenamento de dados enquanto o DICOM possui um leque de aplicações conforme foi descrito no item 2.3 deste trabalho. Outra desvantagem do XML com relação ao DICOM é que o primeiro possui um menor

38 20 poder para descrever estruturas de dados de complexidade mais elevada pelo fato de usar a codificação ASCII (American Standard Code for Information Interchange - Código Americano Padrão para Troca de Informação) [19], pois este tipo de codificação só consegue representar valores na forma de texto simples enquanto o DICOM utiliza a codificação em bytes, que permite a codificação de inúmeros tipos (datas, UIDs, entre outros). 3.3 Extensões Multifunção para Mensagens de Internet - MIME O padrão MIME - Multipurpose Internet Mail Extensions [20] é um padrão que foi proposto em 1991 pela companhia Bell Communications Research [21] e tem como propósito auxiliar a expandir o limite de capacidade de s permitindo o anexo de diferentes tipos de conteúdo tais como textos (incluindo texto rico com cores, efeitos e tipos de fonte), imagens JPEG (Joint Photographic Experts Group - Grupo Conjunto de Especialistas em Imagem) [22] e GIF (Graphical Interchange Format - Formato de Intercâmbio de Gráficos) [23], vídeos no formato MPEG (Moving Picture Experts Group - Grupo de Especialistas em Imagens em Movimento) [24], áudio, programas (aplicações) e mensagens. Uma mensagem de possui vários campos, entre os quais podem ser citados: "Remetente", "Destinatário", "Data", "Título do ", "Tipo de Conteúdo", entre outros. O MIME utiliza o campo "Tipo de Conteúdo" para identificar qual tipo de conteúdo o carrega consigo e definir a forma com que este conteúdo será exibido para o Cliente deste serviço de [25]. Objetos binários como imagens DICOM e relatórios estruturados podem ser codificados em mensagens MIME usando a codificação Base64 [26] e desse modo o DICOM através do NEMA requisitou um tipo de conteúdo denominado "application/dicom" para que o MIME pudesse suportar arquivos no formato DICOM. Isto resultou na Suplementação 54 no padrão DICOM [27]. O protocolo HTTP (Hypertext Transfer Protocol - Protocolo de Transferência de Hipertexto) [28] utiliza codificação MIME para o corpo de s assim como objetos DICOM podem facilmente ser transferidos usando o protocolo HTTP. Contudo, existe uma desvantagem significativa do MIME em relação ao DICOM: dado que o padrão MIME não é capaz de especificar qualquer requisito de conformidade em que as classes SOP e as Sintaxes de Transferência sejam suportadas através de , pois não há conformidade ao usar o HTTP como protocolo para transferência de mídias, colocando em risco a integridade da conformidade do padrão DICOM. 3.4 Nível Sete de Saúde - HL7 HL7 - Health Level Seven International [29] é uma organização fundada em 1987, certificada desde 1994 pelo ANSI (American National Standards Institute - Instituto Nacional Americano de Padrões) [30] e possui como principal objetivo o desenvolvimento de padrões

39 21 voltados para a interoperabilidade e compartilhamento em sistemas de informação hospitalar, integrando informações de natureza clínica e administrativa. Esta organização possui esta nomenclatura para fazer referência à sétima camada do modelo OSI (Organização Internacional de Padronização) de comunicação [31], esta que se trata da camada de aplicação, ou seja, a camada mais próxima do usuário final. A organização HL7 criou vários tipos de padrões, dentre eles os padrões de mensagens tais como o HL7 v2.x e o HL7 v3.x [32] (o X corresponde às atualizações realizadas nas referidas versões). Os padrões de mensagens tem como importância definir como a informação será empacotada e comunicada de um lugar para outro. Este trabalho terá um foco maior no HL7 v2.x, pois o HL7 v3.x atualmente está muito menos difundido do que o HL7 v2.x, dado que a grande maioria das implementações existentes está na versão 2.X e este é o padrão de mensagens mais utilizado no mundo atualmente em sistemas de informação hospitalar [33]. O HL7 v2.x é um protocolo que foi projetado para sinalizar mudanças em algum registro do paciente usando mensagens curtas. Quando qualquer informação de um registro de um paciente é alterado, esta mudança é enviada para outro sistema de informação hospitalar usando mensagens no formato do referido protocolo. Uma mensagem no HL7 v2.x pode ser representada pela Figura 3.2. Uma mensagem é composta por um conjunto de segmentos, onde cada segmento possui um símbolo (sequência de strings) delimitador que tem como função indicar o termino de um segmento, trata-se das letras cr inseridas entre os sinais de menor < e maior >, culminando no seguinte formato: <cr>. Figura 3.2: Mensagem HL7 [34]. O primeiro segmento no HL7 representa o cabeçalho da mensagem, possibilitando um apanhado geral sobre informações da mensagem inteira. Um segmento é composto por diversos campos, onde a cada (barra vertical) um campo é finalizado e outro é iniciado. O HL7 diz que a partir do primeiro campo de qualquer segmento é possível saber de qual tipo de segmento está se tratando. O nome de cada segmento se dá pelas 3 letras que formam o primeiro campo. De posse disso, deve-se consultar o padrão HL7 v2.x para verificar o tipo do referido segmento e observar os significados dos outros campos correspondentes ao

40 22 tipo de segmento. A Figura 3.3 representa o primeiro segmento retirado da Figura 3.2 enquanto a Tabela 3.1 representa os significados dos campos e os seus respectivos valores. Figura 3.3: Segmento de uma mensagem HL7 [34]. Tabela 3.1: Decomposição dos campos de um segmento Ordem Descrição Valor do do do Campo Campo Campo 1 Tipo de segmento MSH 2 Separador de campo ˆ \& 3 Aplicação que envia a mensagem GHH LAB 4 Centro de tratamento que envia a mensagem ELAB-3 5 Aplicação que está recebendo a mensagem GHH OE 6 Centro de tratamento que está recebendo a mensagem BLDG4 7 Data/Hora da mensagem Campo em branco Campo em branco 9 Tipo de mensagem ORUˆR01 10 ID de controle da mensagem CNTRL ID de processamento da mensagem P 12 Versão da mensagem 2.4 Fazendo um paralelo entre o HL7 e o DICOM é possível afirmar que as mensagens HL7 são análogas aos DICOM IODs e os segmentos são análogos aos módulos DICOM, estes que consistem em atributos que são codificados como elementos de dados com várias representações de valor. Por outro lado, ainda não há uma integração em escala mundial do HL7, pois há várias versões espalhadas por diversas nacionalidades e muitos fornecedores de saúde estão encontrando dificuldades para tornar as suas aplicações compatíveis com o HL7. A integração deste padrão ainda não atingiu o nível de maturidade de integração do DICOM. Entre outros fatores que contribuem para o nível mais elevado de maturidade do DICOM, pode-se destacar o fato deste trabalhar com várias camadas do modelo OSI e possuir uma documentação que pode ser acessada gratuitamente diferentemente da documentação do HL7, onde só há a possibilidade de usufruir da mesma se tornando um membro da organização HL7 ou pagando pela mesma.

41 Conclusões Este capítulo trouxe alguns comentários sobre outros padrões estruturados que podem ser usados em sistemas de informação hospitalar tais como o COAS, XML, MIME e HL7, além de realizar um breve comparativo entre cada um e o DICOM, trazendo os pontos fortes do DICOM. Todos os padrões apresentados neste capítulo podem carregar consigo as informações contidas em um arquivo DICOM. Isto é viável apenas para transportar estas informações e visualizá-las, pois ao realizar este procedimento de conversão não há garantias de que não sejam violados alguns dos termos de conformidade do padrão DICOM.

42 24 CAPÍTULO 4 FERRAMENTA DESENVOLVIDA Neste trabalho foi desenvolvido um protótipo de ferramenta cujo objetivo é visualizar imagens que usam o padrão DICOM, de modo que também fosse capaz de realizar algumas outras tarefas, tais como exibição de imagem, anotação de texto, traçado de retas, retângulos, círculos, elipses e pontos, zoom, centralização, janelamento, exibição de tags e exportação para outros formatos de imagem e para o próprio padrão DICOM. O protótipo, através do processamento de imagens digitais e de técnicas que implementavam a visualização de imagens baseadas em renderização, é capaz de oferecer auxílio a um médico para que o mesmo decida um diagnóstico para um paciente. Neste capítulo serão demonstrados aspectos da implementação e utilização do protótipo desenvolvido. 4.1 Ambiente de desenvolvimento O desenvolvimento do trabalho foi realizado utilizando-se um notebook equipado com processador Intel(R) Core(TM) i5 M450 (2.40GHz), 4GB de memória RAM DDR3 e placa de vídeo ATI Radeon HD4750 com 512MB de memória dedicada. O sistema operacional de desenvolvimento foi o GNU/Linux da distribuição Mint 12, de codinome Lisa, por ser software livre, compatível com a maior parte das ferramentas utilizadas e possuir um vasto suporte em sua comunidade. Para o desenvolvimento do sistema, foi utilizada a metodologia de desenvolvimento ágil de software denominada de XP (Extreaming Programming - Programação Extrema) com o intuito de criar uma ferramenta de alta qualidade, de maneira ágil, econômica e flexível [35].

43 Modelagem do sistema desenvolvido Nesta sessão, será apresentada a modelagem da ferramenta desenvolvida a partir de sua descrição. E para isso, será apresentado um diagrama que foi elaborado para o sistema. Para descrever as funcionalidades do sistema, seu ator, suas entidades e a forma como eles se relacionam com o sistema, foi utilizado o diagrama de casos de uso. Este diagrama é como um documento narrativo que descreve a sequência de eventos de um ator que usa um sistema para completar um processo [36]. O usuário final, como passo inicial, deve abrir uma imagem DICOM e caso a mesma realmente seja uma imagem DICOM, abre-se a possibilidade do usuário desempenhar algumas funções na imagem, tais como criar desenhos na imagem (círculos, elipses, retângulos, linhas e pontos), escrever na imagem, aplicar zoom e exportar a imagem (para os formatos.png, jpg ou jpeg ou para o próprio formato.dcm ). Caso o usuário final não queira desempenhar nenhuma das funções citadas anteriormente, ele ainda tem a opção de visualização da imagem DICOM, opção de realizar o janelamento na imagem e visualizar as tags referentes ao arquivo DICOM que encontra-se aberto. A Figura 4.1 representa o diagrama de casos de uso para a ferramenta apresentada. Figura 4.1: Diagrama de casos de uso da ferramenta desenvolvida. 4.3 Metodologia de trabalho Este capítulo apresenta uma visão geral acerca das tecnologias escolhidas para o desenvolvimento do trabalho, dentre elas as bibliotecas ITK (Insight Segmentation and Registration Toolkit - Kit de Ferramentas para Registro e Segmentação Introspectiva) e VTK (Visualization Toolkit - Kit de Ferramentas para Visualização), e o framework Qt. Cada tecnologia foi selecionada com o intuito de atender as necessidades específicas da ferramenta produzida. A ITK será usada para manipular dados médicos usados pelo padrão DICOM enquanto a VTK será usada para a aplicação de algoritmos de visualização e por fim o framework Qt será

44 26 usado para a criação de uma GUI (Graphical User Interface - Interface Gráfica para o Usuário). A Figura 4.2 representa a integração entre as tecnologias citadas. Figura 4.2: Esquema de integração entre as tecnologias ITK A ITK [37] é uma biblioteca de código aberto, escrita em C++ e que apesar de não possuir suporte para interface gráfica e nem para visualização, possui um alto potencial para realizar funções como processamento de imagem, registro de imagem e segmentação de imagem. Esta biblioteca pode ser implementada em várias plataformas tais como Unix [38], Windows [39] e Mac OS X [40]. Denomina-se registro de imagem o processo de mapear espacialmente uma imagem que passará por uma transformação, de modo que, de posse do resultado desta transformação, será possível identificar um ponto que conterá uma posição equivalente antes da transformação. A Figura 4.3 representa uma imagem antes e depois de uma transformação T qualquer mapeando a posição do ponto p para o ponto q, onde o ponto q representa o ponto p após a transformação T. Figura 4.3: Registro de uma imagem [41].

45 27 Pode-se chamar de segmentação [42] o processo de se atribuir um rótulo (marcação) para cada pixel que compõe uma imagem de tal forma que os pixels com os mesmos rótulos possuam as mesmas características visuais, baseando-se em vários tipos de medidas como escalas de cinza, escalas de coloração, textura, profundidade ou movimento. O objetivo da segmentação é simplificar e/ou modificar a representação de uma imagem para algo que seja mais simples de analisar, basicamente distinguindo objetos de um plano de fundo. A Figura 4.4 representa um processo de segmentação. Figura 4.4: Da esquerda para direita: Imagem original, tipo 1 de segmentação, tipo 2 de segmentação e tipo 3 de segmentação [41]. A ITK possui para o processamento de imagens uma variedade de filtros que são capazes de realizar das mais variadas operações em imagens, tais como rotação, translação, operadores lógicos (AND, OR e XOR) [43], reamostragem usando RGB [44], conversões 2D (Bidimensional) para 3D (Tridimensional), entre outras operações. Apesar do fato da ITK estar voltada para executar tarefas de processamento de imagem, ela tem como principal objetivo o processamento de dados de imagens médicas, de modo que neste caso as informações adicionais sobre as imagens são consideradas obrigatórias VTK A VTK [45] é uma biblioteca de código aberto, escrita em C++ e é voltada para a computação gráfica 3D, processamento de imagens e visualização, havendo a possibilidade de ser implantada em várias plataformas tais como Unix, Windows e Mac OS X. A biblioteca VTK não possui suporte para interface gráfica. Mas por outro lado possui suporte a uma variedade de algoritmos de visualização tais como o scalar, vector, tensor, texture, além de outros tipos de técnicas de modelagem e algoritmos de processamento de imagem [46]. Mesmo não possuindo suporte a interface gráfica a VTK possui mecanismos que facilitam a interação da mesma com sistemas que possuem suporte a interface gráfica, tal como o QVTKWidget serve de ponte para o framework Qt. A computação gráfica 3D corresponde basicamente nas diversas formas de realizar o processo de renderização, ou seja, obter um produto final de um processamento digital qualquer,

46 28 convertendo símbolos gráficos em efeitos visuais. O processo de visualização se dá com os mecanismos que tornam alguma informação visível. Esta informação é ajustada em coordenadas dentro de um espaço vetorial, sendo caracterizada como um ator dentro de um sistema, havendo a necessidade de criar um outro referencial (denominado câmera) que servirá como ponto de origem de onde este ator poderá ser visto (cada um em sua respectiva coordenada ou posição). O processamento de imagens ocorre com a utilização de filtros, onde tem-se como entrada a imagem a ser trabalhada, seguida pelo tipo de filtro do qual usa-se de acordo com a necessidade. Como exemplo de filtros podem ser citados os de convolução [47], gradiente, média, distância, FFT (Fast Fourier Transform - Transformada Rápida de Fourier) [48], entre outros, gerando assim uma saída com a transformação desejada na imagem. A Figura 4.5 representa o processamento. Figura 4.5: Representação do processamento de imagem realizado pela VTK Qt O Qt [49] é um framework de aplicações multiplataforma, está escrito em C++ e é amplamente utilizado para o desenvolvimento de aplicativos com interface gráfica mas também pode desenvolver ferramentas que usam linhas de comando ou console para servidores. O nome da ferramenta foi escolhido da seguinte forma: a letra Q foi escolhida como prefixo porque na visão dos seus criadores era a mais atraente quando se apresentava no tipo de fonte denominado Haavard s Emacs enquanto o t foi adicionado para representar o kit de ferramentas, inspirado no Xt, o kit ferramentas X [50]. A arquitetura do Qt pode ser dividida em módulos. Estes correspondem à biblioteca propriamente dita do Qt e podem ser ativados ou desativados em tempo de compilação, permitindo ajustes no conjunto de recursos, fazendo com que todos os módulos se encaixem. A Figura 4.6 representa a arquitetura do Qt formada pelos seus módulos. Figura 4.6: Arquitetura do Qt formada por seus módulos [51].

47 Processamento ITK O início da implementação da ferramenta produzida se constituiu por todo o processamento realizado pela biblioteca ITK. A biblioteca possuiu como entrada para o sistema um arquivo DICOM, este que ao ser introduzido no sistema recebe a leitura primeiramente como qualquer arquivo de forma sequencial, sendo posteriormente seguida por uma outra leitura de um filtro GDCMImageIO [52], este que verifica a autenticidade de um arquivo DICOM e tem como retorno uma matriz (em pixels) que contém a imagem contida no arquivo DICOM. Após a obtenção da matriz que contém a imagem DICOM, foram necessárias diversas operações na mesma para que ela resultasse em uma forma ideal para sua visualização. Destacaram-se entre essas operações, a operação de escala de cores, onde a imagem passa por uma reconfiguração para permitir o uso de 256 cores diferentes, e a operação de rotação, onde é criada uma rotação em torno do eixo y (eixo vertical) de 180 graus, dado que a orientação das matrizes no campo da ITK segue com rigor a orientação DICOM em matrizes enquanto que a biblioteca utilizada para visualização possui justamente essa diferença em graus no seu eixo vertical. Caso a imagem recebida pela biblioteca VTK não viesse com esta operação feita, o que seria visto seria a mesma imagem porém de cabeça para baixo. Por fim, foi necessário fazer uma ponte entre a biblioteca ITK e a biblioteca VTK, dado que a ITK não possui suporte para visualização, criando um filtro de transporte entre os dados lidos na ITK para a VTK Processamento VTK Após a VTK receber estes dados oriundos da ITK, foi necessário uma espécie de adequação do meio para tornar a imagem visível ao usuário final. Após o recebimento dos dados da ITK, fez-se necessária a criação de um ator da imagem DICOM, esta que já se encontrava no formato VTK de imagem para inserir esses dados em um filtro que transforma a imagem VTK em ator para que seja usado no processo de renderização da imagem. Para finalizar o processamento da VTK, foi criada uma janela que recebeu o resultado da renderização, onde foi necessário criar um interator que recebeu o ator criado e processou cada ponto da imagem tornando possível a renderização da imagem, implicando na visualização da mesma. O simples fato de criar a imagem não era suficiente para o sistema, havia a necessidade de colocar a imagem em uma interface que o usuário final pudesse manipulá-la e para isso foi utilizado o framework Qt. De modo que seria necessária outra ponte só que dessa vez uma ponte para interligar a biblioteca VTK para o framework Qt. Para a criação dessa ponte foi utilizado o objeto QVTKWidget [53], este que recebia a janela de renderização e retornava um widget (componente de uma interface gráfica do usuário, que pode incluir janelas, botões, menus, ícones, barras de rolagem, entre outros itens) juntamente com a imagem adquirida durante todo o processo.

48 Processamento Qt Para apresentar o resultado de todo o processamento anterior realizado em conjunto pela ITK e pela VTK, de modo que seja possível o usuário final manipular este resultado, o framework Qt recebeu o widget que portava a imagem contida no arquivo DICOM. E de posse deste widget, pôde-se obter as medidas de largura e altura mínimas para que a cena em que a imagem aparece fosse criada, através do objeto QGraphicsScene [54], onde o widget fosse dentro da aplicação quando fosse recebido um arquivo DICOM como entrada. Após a criação da cena, foi necessário criar uma nova ponte entre o widget e a cena usando o objeto QGraphicsProxyWidget [55], para o widget se tornar parte da nova cena. Feito isto, bastou-se atualizar a cena e o objeto QgraphicsView [56], que é responsável por aquilo que se vê na cena, e então pôde-se visualizar a imagem DICOM, junto ao seus métodos de manipulação que foram criados para que haja a interação do usuário final com a imagem. 4.4 Descrição da ferramenta produzida Após a integração dos processamentos anteriormente descritos foi obtido o Visualizador de Imagens DICOM. Na Figura 4.7 é possível ver uma amostra do Visualizador de Imagens DICOM, contendo a sua janela inicial e a posição de qualquer ponto da cena através das coordenadas em pixel. Figura 4.7: Imagem da interface do Visualizador de Imagens DICOM.

49 31 O usuário final deve seguir algumas orientações para usufluir dos recursos que a ferramenta desenvolvida apresenta. Para abrir um arquivo DICOM (extensão."dcm") basta clicar no botão indicado (marcado em vermelho) na Figura 4.8 ou clicar em Arquivo, depois em Abrir e procurar o arquivo em seu devido diretório. Figura 4.8: Janela para abertura de arquivo DICOM. Após selecionar o arquivo para ser aberto, todo o processamento feito pelas bibliotecas que o programa usa geram o seguinte resultado visual, incluindo a mudança no título do programa que agora já acompanha o nome do arquivo selecionado (na marcação em verde). Quando a imagem for aberta, ela automaticamente já estará centralizada na cena o que caracterizará a funcionalidade de centralização, sem precisar de ajustes como mostra a Figura 4.9. Figura 4.9: Imagem DICOM visualizada após todo o processamento das bibliotecas.

50 32 Para desenhar pontos, deve-se apertar no botão marcado (em vermelho) na Figura 4.10 e escolher o ponto a ser desenhado e ao clicar já pode-se ver o ponto desenhado. Figura 4.10: Imagem DICOM visualizada após o desenho de pontos. Para desenhar um círculo, deve-se clicar no botão marcado (em vermelho) na Figura 4.11 e desenhar clicando primeiramente onde deseja-se marcar o centro do círculo, segurando o mouse até a posição em que se deseja que fosse o raio do círculo (o círculo é desenhado como se fosse uma circunferência inscrita em um quadrado, portanto quando deseja-se escolher o raio, na verdade está se escolhendo umas das diagonais que compõe o quadrado em que o círculo está sendo desenhado). Figura 4.11: Imagem DICOM visualizada após o desenho de círculos.

51 33 Para desenhar uma reta, deve-se clicar no botão marcado (em vermelho) na Figura 4.12, clicar na cena no ponto de origem da reta e segurando o cursor do mouse até a extremidade onde seja o final da reta desejada e soltar o mouse. Figura 4.12: Imagem DICOM visualizada após o desenho de retas. Para desenhar elipses, deve-se apertar no botão marcado (em verde) na Figura 4.13 e tomar como base o mesmo procedimento tomado para desenhar círculos, porém mencionando que ao invés de círculos inscritos em quadrados, desta vez tem-se elipses inscritas em retângulos. Figura 4.13: Imagem DICOM visualizada após o desenho de elipses. Para desenhar um retângulo, deve-se clicar no botão marcado (em amarelo) na Figura

52 e desenhar clicando primeiramente na imagem para escolher o ponto de origem do retângulo e em seguida soltar o mouse no ponto onde terminará a diagonal do retângulo. Figura 4.14: Imagem DICOM visualizada após o desenho de retângulos. Para exibir a imagem em zoom, deve-se atentar para o menu marcado (em amarelo) na Figura Ao clicar no menu, pode-se ver uma lista de possíveis valores de zoom para a imagem, tanto para zoom maior quanto para zoom menor, e ao escolher e clicar em algum desses valores, pode-se ver a atualização do tamanho da imagem que é vista, juntamente com a adequação da barra de rolagem ao tamanho atualizado da imagem. Figura 4.15: Imagem DICOM visualizada após a aplicação de um zoom de 250%. As propriedades dos desenhos também podem ser modificadas. Para isto há um menu

53 35 marcado (em amarelo) na Figura 4.16 que permite ao usuário selecionar o preenchimento do desenho, a cor da linha do desenho e a espessura da linha do desenho. Figura 4.16: Imagem DICOM visualizada após desenhos com propriedades modificadas. Para escrever na imagem é necessário clicar no botão marcado (em amarelo). Ao clicar neste botão é possível escolher através do menu marcado (em verde) na Figura 4.17 a formatação do texto, incluindo características como o tipo de fonte, o tamanho da fonte, outras propriedades de exibição de texto (exibição em negrito, itálico ou sublinhado) e a cor da fonte. Figura 4.17: Imagem DICOM visualizada após a escrita de texto. Ao clicar no menu superior, em Ferramentas e em seguida na opção Janelamento surgirá uma janela que permitirá o manuseio de valores que usarão o Centro e Largura de janela

54 36 de uma imagem DICOM, de modo que a variação desses valores mudará as escalas de cores da imagem atual, onde o usuário poderá ajustar os valores de entrada para melhor visualizar determinada densidade de algum elemento contido na imagem. Os valores de entrada estão marcados (em amarelo) na Figura 4.18 e podem variar de 0 à 255. Esta variação caracteriza a aplicação do janelamento em DICOM. Figura 4.18: Imagem DICOM e funcionalidade para o Janelamento. A variação de entrada para o campo Centro da janela dá a sensação de variação no efeito visual chamado de brilho. A Figura 4.19 mostra uma imagem onde a entrada para o campo Centro possui um valor de 80 enquanto o campo Largura se manteve no valor inicial que possui o valor padrão de 255. Figura 4.19: Imagem DICOM visualizada após um Janelamento.

55 37 Por outro lado a variação do campo Largura da janela dá a sensação de variação no efeito visual denominado de contraste. A Figura 4.20 mostra uma imagem onde a entrada para o campo Largura possui um valor de 80 enquanto o campo Centro se manteve no valor inicial padrão. Figura 4.20: Imagem DICOM visualizada após um Janelamento. Para misturar os ambos os efeitos foram alterados os dois parâmetros, tanto o Centro da janela quanto o Largura da janela, para 80 de modo que proporcionassem uma mistura proporcional. A Figura 4.21 representa a imagem obtida após esta configuração. Figura 4.21: Imagem DICOM visualizada após um Janelamento. Para mostrar um breve resumo das tags carregadas pelo respectivo arquivo DICOM aberto foi criada uma tabela que exibe esta informação. A Figura 4.22 representa este resumo

56 38 de tags dentro de uma tabela. Figura 4.22: Exibição de um resumo das tags contidas em um arquivo DICOM. Para uma exibição mais completa das tags foi construída uma tabela capaz de representar a informação do grupo e elemento da tag, uma descrição de cada tag e o valor real portado por cada tag. A Figura 4.23 traz essa exibição. Figura 4.23: Exibição das tags contidas em um arquivo DICOM. Para salvar as alterações feitas em um arquivo DICOM para outro arquivo DICOM só serão salvas as alterações decorrente ao processo de janelamento anteriormente citado. Esta operação gera um novo arquivo DICOM que portará estas alterações realizadas, mantendo íntegro o arquivo original por se tratar de uma cópia deste. Para realizar esta operação o usuário

57 39 deverá ir em Arquivo (no menu superior) e em seguida clicar em Salvar em ".dcm", e após o usuário escolher o destino do arquivo este ainda deverá digitar o nome do arquivo seguido da extensão ".dcm". A Figura 4.24 ilustra esta funcionalidade. Figura 4.24: Exibição da funcionalidade de salvar a imagem em um arquivo no formato DICOM. Toda e qualquer alteração realizada na imagem poderá ser exportada para outros formatos de imagens como ".jpg", ".jpeg" e ".png". Para isso o usuário deverá ir no menu superior, em Arquivo e em seguida clicar em Salvar Imagem ou clicar no botão marcado (em amarelo), onde após o usuário escolher o destino do arquivo este ainda deverá digitar o nome do mesmo seguido da extensão ".jpg", ".jpeg" ou ".png". A Figura 4.25 ilustra esta funcionalidade. Figura 4.25: Exibição da funcionalidade de salvar a imagem em outros formatos. Os arquivos DICOM que foram utilizados para testes referentes à ferramenta produ-