Um Modelo para Comunicação de Dados DICOM em Redes ... - SBIS

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-

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

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.
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
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.
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.

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
UID
R -
Priority R -
Move Originator R -
Application Entity Title
Move
Message ID
Originator R -
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.

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 16.384Kbps
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 16.384 Kbps.
Modalida
S/ RESUMO C/ RESUMO
de N C N C
CT 3 1 4 1
US 3 1 4 1
XA 73 59 69 66
* N = Normal;
** C = Compactado.
As Tabelas 2 e 3 apresentam,
respectivamente, os tempos de envio dos
arquivos com taxa de 16.384 e 8.192 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 8.192 Kbps.
Modalida
S/ RESUMO C/ RESUMO
de N C N C
CT 10 5 10 5
US 9 3 10 3,5
XA 159 154 164 153
* 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%.

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.
[2] Digital Imaging and Communications in
Medicine (DICOM) - Part 1: Introduction and
Overview, National Electrical Manufacturers
Association – NEMA, Rosslyn, Virginia, USA.
2006.
[3] GNU Wget – GNU Project. Disponível em:
http://www.gnu.org/software/wget/, acessado em
13/07/2006.
[4] File Transfer Protocol – Wikipedia. Disponível
em: http://en.wikipedia.org/wiki/FTP_server,
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. 2006.
[6] Digital Imaging and Communications in
Medicine (DICOM) - Part 4: Message Exchange,
National Electrical Manufacturers Association –
NEMA, Rosslyn, Virginia, USA. 2006.
[7] Digital Imaging and Communications in
Medicine (DICOM) - Part 7: Service Class
Specifications, National Electrical Manufacturers
Association – NEMA, Rosslyn, Virginia, USA,
2006.
[8] Digital Imaging and Communications in
Medicine (DICOM) - Part 5: Service Class
Specifications, National Electrical Manufacturers
Association – NEMA, Rosslyn, Virginia, USA,
2006.
[9] Zlib Home Site. Disponível em:
http://www.zlib.net/, acessado em 12/07/2006.
Contatos
Antonio da Luz Jr.
Projeto Cyclops – UFSC
antoniol@inf.ufsc.br
Rodrigo Copetti
Projeto Cyclops – UFSC
copetti@inf.ufsc.br
Prof. Dr. rer. nat. Eros Comunello
Projeto Cyclops – UFSC
eros@telemedicina.ufsc.br
Prof. Dr. rer. nat. Aldo von Wangenheim
Projeto Cyclops – UFSC
awangenh@inf.ufsc.br