Um Modelo para Comunicação de Dados DICOM em Redes de Telemedicina de Baixa Velocidade

Transcrição

1 Um Modelo para Comunicação de Dados DICOM em Redes de Telemedicina de Baixa Velocidade Antonio da Luz Jr., Rodrigo Copetti, Eros Comunello, Aldo v. Wangenheim Laboratório de Telemedicina Projeto Cyclops Departamento de Informática e Estatística (INE) Universidade Federal de Santa Catarina (UFSC) Resumo O DICOM define um conjunto de serviços e formas de comunicação de dados entre PACS. O modelo de comunicação definido é baseado no conceito de redes internas de alta disponibilidade. O desenvolvimento de redes de Telemedicina integrando aplicações baseadas no DICOM está se popularizando. Porém, a disponibilidade de redes de alta velocidade nem sempre são uma realidade quando se necessita transmitir dados entre pontos geograficamente distribuídos. A proposta deste trabalho é de otimização do processo de comunicação e transferência de dados em Redes de Telemedicina de Baixa Velocidade, utilizando técnica de compactação de dados e resumo de transferências. É apresentado um modelo de comunicação de dados, realizando uma extensão do padrão, atendendo as deficiências apresentadas pelo DICOM para se trabalhar com esse tipo de rede. Palavras-chave: Telemedicina, DICOM, PACS, Comunicação de Dados. Abstract DICOM defines a set of services and data communication manners among PACS. The defined communication model is based on the concept of high availability internal networks. Despite the development of Telemedicine networks which integrate DICOM based applications is growing in acceptance, high speed networks are not always available when it is necessary to exchange data between geographically distributed locations. The proposal of this paper is optimizing the communication process and data transferring in Low Speed Telemedicine Networks, using data compression and transference resume techniques. It is presented a data communication model, realizing an extension of the DICOM Standard, fulfilling DICOM weaknesses of working with this kind on network. Key-words: Telemedicine, DICOM, PACS, Data Communication. Introdução A utilização de PACS Picture Archiving and Communications System [1], integrado em redes de Telemedicina, é uma realidade no dia-adia de clínicas e hospitais. A implantação desse tipo de tecnologia, além de auxiliar na realização de tarefas rotineiras, possibilita a criação de novas formas de execução das atividades. Um exemplo claro é o compartilhamento de informações do exame, através de portais web, para auxílio na elaboração de diagnósticos. Com o objetivo de garantir a interoperabilidade entre PACS de diferentes fabricantes, foi definido o padrão DICOM Digital Imaging and Communications in Medicine [2]. Esse é o padrão internacionalmente aceito para o desenvolvimento desse tipo de aplicações. O DICOM define a estrutura dos arquivos que contém os exames, os serviços a serem executados e a forma como os dados devem ser comunicados entre as diferentes aplicações. Inicialmente desenvolvido na década de 80, o modelo de comunicação de dados definido no padrão DICOM ainda segue grande parte dos conceitos tecnológicos existentes na época de sua criação, não tendo acompanhado a evolução na área de comunicação de dados. Isso pressupõe que: para uma efetiva realização de troca de informações, entre aplicações que implementem esse padrão, é necessário se garantir a confiabilidade do meio físico responsável pela transmissão dos dados. Tal característica faz com que o modelo de comunicação estabelecido pelo DICOM seja eficiente em redes internas, intranets. Nesse tipo de rede têm-se controle total sobre a qualidade do meio físico que será utilizado, além da possibilidade de transmissão de grandes quantidades de dados em alta velocidade. Em redes internas de Telemedicina, a utilização de PACS em conformidade com o DICOM é uma abordagem eficiente para transmissão de dados médicos. Porém, quando se tem como cenário uma rede de Telemedicina geograficamente distribuída, a utilização do modelo de comunicação conforme descrito pelo padrão DICOM acarreta diversos problemas. Os problemas para comunicação em redes de larga escala são detectados principalmente na dificuldade encontrada em se garantir a qualidade do serviço de transmissão de dados. Esse problema surge nesse tipo de rede, devido à necessidade de se utilizar de diferentes infra-

2 estruturas. Em um cenário simplificado, existem pelo menos três infra-estruturas envolvidas: uma local, onde está o PACS que irá enviar os dados; uma que possibilitará o acesso a internet e a transmissão dos dados; e uma no destino, onde se encontra a aplicação que irá receber os dados transmitidos. Geralmente as infra-estruturas de rede que fornecem acesso a internet possuem uma capacidade de transmissão de dados inferior à encontrada em redes internas. Além disso, dependendo do nível de qualidade desse tipo de serviço, é esperada a perda de conectividade com o meio de comunicação durante a fase de transmissão. Uma possível alternativa é o uso de ferramentas externas ao PACS, como o Wget [3], para realizar a transmissão dos dados. Com esse tipo de ferramenta é possível realizar comunicação utilizando diferentes protocolos, entre eles o FTP [4]. Esse protocolo implementa a característica de armazenamento temporário dos dados recebidos. Com isso é possível aproveitar os dados já transmitidos quando do restabelecimento da comunicação após uma situação de perda de conectividade na rede. Contudo, é necessário que o modelo de comunicação de dados, a ser utilizado em redes de Telemedicina, atenda as características encontradas em ambos os tipos de rede e, ainda, tenha a capacidade de manter a conformidade com o DICOM para possibilitar a integração de qualquer aplicação acordante com esse padrão. Com o objetivo de oferecer solução às dificuldades encontradas em transmissões de redes de larga escala e, ainda, manter a conformidade com o padrão DICOM, o presente trabalho apresenta um modelo para comunicação de dados em redes de Telemedicina de larga escala e baixa velocidade. Metodologia O modelo proposto neste trabalho foi desenvolvido a partir das características definidas no modelo de comunicação do padrão DICOM. Devido a isso, para melhor compreensão da abordagem desenvolvida e da garantia de manutenção da compatibilidade entre as aplicações que implementarem essa proposta e as demais aplicações DICOM compatíveis, faz-se necessário o entendimento do modelo básico de comunicação e execução de serviços do padrão. O padrão DICOM define alguns passos para o estabelecimento da comunicação entre os PACS antes de executarem algum tipo de solicitação de serviço propriamente dito [5]. A Figura 1 apresenta o esquema de troca de mensagens entre as aplicações para o estabelecimento da comunicação. Figura 1 - Estabelecimento de Comunicação DICOM [5]. O processo de associação é realizado em quatro etapas. A aplicação requisitante envia uma solicitação de requisição de associação para a aplicação a qual deseja se conectar. Essa mensagem contém as informações dos tipos de serviços que a entidade requisitante pretende solicitar e as sintaxes de transferência suportadas. As sintaxes de transferência são as diferentes formas de codificação que podem ser utilizadas para a organização dos dados a serem enviados. Ao receber uma requisição de associação, um PACS deve verificar quais dos serviços presentes na mensagem de requisição são suportados pela aplicação e, ainda, definir para cada serviço a forma de codificação a ser utilizada. A sintaxe de transferência a ser utilizada deve ser uma das informadas pela aplicação requisitante. Caso não suporte algum serviço, ou nenhuma das formas de codificação solicitadas para um determinado serviço, esse serviço é marcado como rejeitado. Após essa verificação, a entidade responde a requisição, através de uma mensagem contendo uma lista de pares serviços/codificação aceitos ou rejeitados. Ao receber essa resposta a aplicação requisitante dá seqüência a solicitação de serviços. Dentre os diferentes serviços definidos no padrão DICOM [6], os mais críticos, quando se trata de envio de grande quantidade de dados em uma rede de Telemedicina de baixa velocidade, são o C-STORE e C-MOVE. Ambos os serviços são utilizados para a transferência de arquivos DICOM entre PACS. O C-STORE faz o envio de um arquivo localizado na entidade requisitante para a aplicação destino da solicitação. O C- MOVE realiza a operação inversa, ele transmite um arquivo localizado na entidade destino para uma aplicação identificada na mensagem de solicitação, para isso realiza uma nova associação requisitada pela entidade executante para a aplicação destino da transmissão do serviço e efetua a transmissão arquivo utilizando o serviço C-STORE. A Figura 2 ilustra o processo de atendimento a uma requisição do serviço C- MOVE [7]. O modelo de comunicação de dados e execução de serviços do DICOM, em seu formato nativo, apresenta dois principais complicadores para sua utilização em grandes redes de

3 Telemedicina que possuem restrições em relação a qualidade de serviço: não possui uma abordagem para reaproveitamento de dados transmitidos, quando da perda de conectividade durante o envio de um arquivo; e, a falta de uma sintaxe de transferência que consiga reduzir o volume de dados a ser transferido sem comprometer sua qualidade. O DICOM define algumas sintaxes com compactação, porém ou elas possuem uma baixa taxa de compressão ou, acarretam perda de qualidade na qualidade da imagem contida no arquivo. sintaxes básicas. Com isso, um PACS DICOM compatível pode ser facilmente estendido para suportar as novas sintaxes inserindo poucos passos adicionais antes de se realizar a leitura ou escrita de dados. Com a nova proposta cria-se um novo parâmetro na classificação das sintaxes de transferência: existência de compactação. As novas codificações definidas são: Compacted Little Endian Explicit, a Compacted Big Endian Explicit e Compacted Little Endian Implicit. A Figura 3 apresenta uma representação hierárquica das sintaxes de transferência com a definição do modelo proposto. Figura 3 - Hierarquia do Modelo das Sintaxes de Transferencia. Figura 2 - Envio de Comandos e Dados DICOM. O modelo de comunicação proposto neste trabalho integra ao padrão DICOM o suporte a sintaxes de transferência que possibilitam uma mais alta taxa de compactação dos dados a serem transmitidos sem comprometer o conteúdo da informação transmitida e, também, a característica de resume das operações de envio de dados, semelhante ao utilizado no protocolo FTP. Compactação de dados As sintaxes de transferência básicas, não compactadas, presentes no DICOM [8] estão organizadas seguindo dois critérios: forma de disposição dos bytes, em Big ou Little Endian; e, presença ou não do Valor de Representação de cada um dos dados que compõem um arquivo de exame, Explicit ou Implicit. Seguindo esses critérios, são definidos três tipos básicos de codificação: Big Endian Explicit, Little Endian Explicit e Little Endian Implicit. Para minimizar o impacto da implantação da abordagem proposta definiu-se uma sintaxe de transferência compactada para cada uma das Para os processos de compactação e descompactação dos dados foi definida a utilização da biblioteca Zlib [9], por possuir uma boa taxa de compactação sem perda, ser de distribuição gratuita e possibilitar a extensão de seu código-fonte. Um dos parâmetros esperados pelos métodos deflate, compactação, e inflate, descompactação, da biblioteca, utilizados no modelo proposto, é o tamanho total da stream que irá receber os dados após a execução do método. Ou seja, antes de se executar uma compactação deve-se saber qual o tamanho esperado para os dados ao final do processo, de igual forma, deve-se conhecer previamente qual o tamanho esperado para a stream ao final da descompactação. Para a primeira operação, compactação, a biblioteca fornece um método que efetua uma previsão para o tamanho final do conjunto de dados. A operação inversa, no entanto, não possui um método preparado para fornecer a informação necessária. Com o objetivo de atender a essa necessidade estendeu-se o método de compactação da biblioteca, inserindo 4 Bytes no início do conjunto de dados compactados, que tem por função armazenar o tamanho original da stream.

4 Restabelecimento de Operações após Interrupção No esquema de funcionamento do serviço C-STORE, após o envio de uma mensagem de requisição de serviço, a entidade requisitante envia, em mensagens consecutivas, todo o conjunto de dados. Com isso, quando ocorre uma situação de perda de conectividade durante a transmissão dos dados, seguindo o modelo de funcionamento desse serviço não existe uma maneira efetiva de se recuperar um conjunto de dados já recebido pela aplicação destino, sendo necessária a retransmissão de todo o conjunto. No modelo de comunicação proposto neste trabalho foram definidas novas estruturas para o serviço C-STORE. A Tabela 1 apresenta a estrutura definida para o novo serviço, C- STOREX. Tabela 1 Estrutura do serviço C-STOREX. Nome do Parâmetro RQ RSP Message ID R - Message ID Being - R Responded To Affected SOP Instance R - UID Priority R - Move Originator R - Application Entity Title Move Originator R - Message ID Bytes To Transfer R - Number Transfered - R Bytes Status - R R indica que o parâmetro é requerido. - indica que o parâmetro não é utilizado nesse tipo de mensagem. A estrutura do serviço C-STOREX compreende os seguintes parâmetros: Message ID - ID da Mensagem: Identificador da Mensagem de requisição; Message ID Being Responded To - ID Mensagem Respondida: Identifica qual mensagem de solicitação está sendo respondida; Affected SOP Instance UID ID da Instancia SOP Transmitida: Identifica unicamente qual o exame que está sendo enviado na execução do serviço; Priority - Prioridade: Identifica o nível de importância que deve ser atribuído a essa mensagem; Move Originator Application Entity Title Entidade de Aplicação que Requisitou a Transferência: Identificador da Aplicação que solicitou a transferência desse arquivo; Move Originator Message ID ID da Mensagem que Requisitou a Transferência: Identificador da mensagem que requisitou a transferência dos dados. Em caso de ter sido solicitado a partir de um C-MOVE, esse parâmetro recebe o ID da mensagem de requisição desse serviço; Bytes To Transfer Bytes a Transferir: Indica o número de Bytes do arquivo que será enviado pelo serviço; Number Transferd Bytes Número de Bytes Transferidos: Indica o número de Bytes que desse arquivo que já foram transferidos para a aplicação destino e estão armazenados na área temporária; Status Status: Indica a situação da execução do serviço: Pendente, Sucesso ou Falha. O novo serviço utiliza uma abordagem de armazenamento físico temporário dos dados recebidos. Essa técnica permite que os dados recebidos sejam recuperados, caso ocorra algum problema durante a transmissão dos dados ou execução do serviço. O armazenamento temporário é realizado em uma estrutura hierárquica a partir da identificação da entidade que está transmitindo os dados. Em seguida é definida qual a sintaxe de transferência está sendo utilizada e, então, os dados recebidos são armazenados em um arquivo identificado com o SOP Instance UID do exame que está sendo transmitido, esse atributo identifica unicamente um arquivo DICOM. Essa estrutura foi adotada para eliminar a problemas quando da transmissão de um mesmo exame vindo de aplicações diferentes, ou ainda, o envio de um mesmo exame de uma mesma entidade utilizando sintaxe de transferência diferente da codificação do arquivo temporário. O processo de sincronização dos dados já recebidos quando da retransmissão de um conjunto de dados ocorre com a verificação do parâmetro contendo o número de bytes já recebidos, existente na mensagem de resposta enviada imediatamente posterior ao recebimento da mensagem de solicitação de serviço C- STOREX. Na Figura 4 é apresentado o fluxo de execução do serviço. Após receber uma mensagem de solicitação de serviço, a entidade executante verifica no local definido para o armazenamento temporário dos dados, se possui algum conjunto de dados para o exame que será transferido, identificado pelo parâmetro Affected SOP Instance UID informado na mensagem de requisição do serviço. Caso encontre, deve informar a quantidade de bytes desse conjunto no parâmetro Bytes To Transfer da mensagem de resposta. Caso contrário, esse parâmetro deve receber valor zero.

5 As Tabelas 2 e 3 apresentam, respectivamente, os tempos de envio dos arquivos com taxa de e Kbps. O tempo foi medido para o envio de um arquivo de cada modalidade. Tabela 3 Tempo de Envio em segundos de Arquivos de CT, US e XA em uma taxa de transmissão de Kbps. Modalida S/ RESUMO C/ RESUMO de N C N C CT US ,5 XA * N = Normal; ** C = Compactado. Figura 4 Fluxo de Execução C-STOREX. No modelo proposto, ainda foi definido o serviço C-MOVEX. Esse serviço é uma variação do C-MOVE. A estrutura foi mantida conforme a definida no comando nativo do DICOM. A modificação do serviço se dá no fato de que ao invés de executar o serviço C-STORE, deverá executar o serviço C-STOREX definido no modelo proposto. Resultados Para validar o modelo proposto neste trabalho foram realizados testes de transmissão de dados de exames DICOM. Os PACS utilizados nos testes foram implementados seguindo a metodologia descrita. Nos testes foram utilizados arquivos de Tomografia Computadorizada CT, Ultrasonografia US e Angiografia XA. Foram elaborados dois ambientes, o primeiro utilizando taxa de transmissão de arquivos de Kbps e, o segundo, com taxa de 8.192Kbps. Essas taxas são as encontradas em serviços de acesso a internet comuns. Tabela 2 Tempo de Envio em segundos de Arquivos de CT, US e XA em uma taxa de transmissão de Kbps. Modalida S/ RESUMO C/ RESUMO de N C N C CT US XA * N = Normal; ** C = Compactado. Também foram testados os re-envios dos dados após uma perda simulada de conectividade com a rede. Com a utilização do serviço que implementa o resumo das operações o tempo efetivamente gasto com o envio dos dados e a quantidade de dados transmitidos, em ambas as taxas de transferência, são os mesmos dos obtidos quando não ocorreu a perda de conexão. Discussão e Conclusões Observando os resultados realizados com o modelo de comunicação de dados em redes de Telemedicina de baixa velocidade, proposto neste trabalho, verificou-se um ótimo desempenho dos novos serviços e sintaxes de transferências. Na questão relacionada ao tempo de transmissão de dados, observou-se uma diminuição significativa, principalmente para dados de exames como Tomografia Computadorizada e Ultra-Sonografia. A utilização de uma codificação compactada reduziu em média 70% o tamanho dos dados necessários para trafegar na rede. A utilização combinada de compactação e uso de resumo de operações pode melhorar o desempenho dos serviços de transferência de dados na maioria dos casos. Em algumas situações, o uso da compactação não apresenta muito benefício, como em exames de Angiografia. Isso ocorre pelo fato desse tipo de exame já ser gerado utilizando o método de compactação JPEG. A possibilidade de configuração dessas combinações nos PACS através dos AE-Titles pode ser uma grande prática para ganhar desempenho. Uma outra aplicação para o tipo de codificação compactada é sua utilização no armazenamento dos dados. Seja o modo de armazenamento em banco de dados ou até mesmo em arquivo, a redução de espaço em disco utilizado é bastante significativa. No caso de exames de ultra-sonografia, a redução média é de 82%.

6 Um ponto importante a ser ressaltado, é que mesmo com a utilização da abordagem proposta neste trabalho, uma aplicação desenvolvida em conformidade com o DICOM não perde essa característica. Ou seja, essa aplicação continua sendo capaz de se comunicar com qualquer outro PACS, mesmo que esta outra aplicação não tenha suporte a estas novas características. Referências [1] Duerinckx, A.J., Pisa, E.J., Filmless Picture Archiving and Communication System (PACS) in Diagnostic Radiology, Proc SPIE 1982;318;9-18. Republicado na IEEE Computer Society Proceedings of PACS'82, No 388. Contatos Antonio da Luz Jr. antoniol@inf.ufsc.br Rodrigo Copetti copetti@inf.ufsc.br Prof. Dr. rer. nat. Eros Comunello eros@telemedicina.ufsc.br Prof. Dr. rer. nat. Aldo von Wangenheim awangenh@inf.ufsc.br [2] Digital Imaging and Communications in Medicine (DICOM) - Part 1: Introduction and Overview, National Electrical Manufacturers Association NEMA, Rosslyn, Virginia, USA [3] GNU Wget GNU Project. Disponível em: acessado em 13/07/2006. [4] File Transfer Protocol Wikipedia. Disponível em: acessado em 12/07/2006. [5] Digital Imaging and Communications in Medicine (DICOM) - Part 8: Network Communication Support for Message Exchange, National Electrical Manufacturers Association NEMA, Rosslyn, Virginia, USA [6] Digital Imaging and Communications in Medicine (DICOM) - Part 4: Message Exchange, National Electrical Manufacturers Association NEMA, Rosslyn, Virginia, USA [7] Digital Imaging and Communications in Medicine (DICOM) - Part 7: Service Class Specifications, National Electrical Manufacturers Association NEMA, Rosslyn, Virginia, USA, [8] Digital Imaging and Communications in Medicine (DICOM) - Part 5: Service Class Specifications, National Electrical Manufacturers Association NEMA, Rosslyn, Virginia, USA, [9] Zlib Home Site. Disponível em: acessado em 12/07/2006.