Padrão Dicom

PADRÃO DE COMUNICAÇÃO DE IMAGENS MÉDICAS DICOM V3.0 1 Ronaldo Gomes da Silva 2 Orientador: Prof. Milton Sampaio3 RESUMO O padrão DICOM ( Digital Imaging Communication in Medicine ) especifica um protocolo de transferência de dados, formato de imagem digital, e uma estrutura de arquivo para imagens médicas e informações co-relatas. O objetivo deste trabalho é estudar o padrão DICOM v3.0, seus protocolos, suas aplicações e limitações. Palavras-Chave: DICOM, Telemedicina, Teleradiologia.

O tema deste artigo é o padrão DICOM versão 3.0 ou simplesmente DICOM ( Digital Imaging and Communication in Medicine ). O DICOM é um padrão desenvolvido pelo American College of Radiology ( ACR ) em associação com National Electronics Manufacturer’s Association ( NEMA ), ele permite que dispositivos que criam ou trabalham com imagens médicas troquem estas imagens assim como informações relacionadas a elas. O artigo se justifica pois O DICOM é largamente usado hoje em dia pela maioria dos fabricantes de equipamentos médicos. O Objetivo do trabalho é estudar o padrão DICOM, estabelecer uma visão geral do seu funcionamento, apresentar informações relevantes para o seu entendimento e implementação. Embora o padrão não tenha sido alterado, 23 suplementos foram adicionados para tratar de mudanças e necessidades que surgiram desde a criação do padrão original. Atualmente o padrão DICOM consiste em 18 volumes contendo informações sobre protocolos de transferência de dados , formato de imagem digital e estrutura de arquivo para imagens médicas e informações co-relatas. O objetivo específico do artigo é colher as informações relevantes do padrão, descrevendo suas funções e mostrando exemplos.

VISÃO GERAL O DICOM estabelece informações detalhadas de como devem ser projetadas as interfaces que possibilitarão a intercomunicação de equipamentos de aquisição de 1 2

Artigo final da especialização em Redes de Computadores 2002 da Universidade Salvador – UNIFACS

Graduado em engenharia Elétrica pela UFBA, pós-graduando em Redes de Computadores pela Universidade Salvador – UNIFACS. E-mail [email protected] 3 Mestre em Informação Estratégica pela UFBA - Universidade Federal da Bahia, Especialista em Administração pela UNIFACS - Universidade Salvador, Graduado em engenharia Mecânica pela UFRJ - Universidade Federal do Rio de Janeiro, Professor de cursos de Extensão e Graduação e Pós-graduação na UNIFACS _ Universidade Salvador, FTE - Faculdade de Tecnologia Empresarial e de Graduação nas Faculdades Jorge Amado, Consultor nas áreas de Gestão Estratégica, Gestão do Conhecimento e Inteligência Competitiva, Membro Consultivo da EngenAr - Empresa Júnior de Engenharias e Arquitetura da UNIFACS - Universidade Salvador. E-mail [email protected]

2

imagem médica, estações de trabalho de visualização e processamento de imagem, unidades de arquivo e impressoras de filme ou papel, de diversos fabricantes e modalidades. O padrão descreve como formatar e transferir os arquivos de imagens médicas, dentro do mesmo hospital ou para fora do mesmo. O padrão DICOM é baseado no modelo de referência para Interconexão de Sistemas Abertos (Open System Interconnection - OSI ) desenvolvido pela ISO International Organization for Standardization, com o propósito de padronizar a comunicação entre sistemas de processamento heterogêneos. O modelo OSI é composto de 7 camadas, embora as 4 primeiras camadas ( física, enlace, rede e transporte ) não sejam tratadas pelo o padrão DICOM, este apresenta total compatibilidade com o protocolo TCP/IP. Através de uma camada de interface, as entidades de aplicação estabelecem associações, transferem mensagens e terminam associações, isolando a camada de aplicação DICOM da pilha de protocolos de comunicação das camadas inferiores. A troca de mensagens utilizando o DICOM começa com o estabelecimento de uma associação, para isso é utilizado o protocolo ACSE (Association Control Service Element ) que é baseado no modelo OSI, após a associação o padrão DICOM utiliza o protocolo DIMSE para a troca de informação. O DICOM utiliza os conceitos de classe de serviço e definição de objeto para implantar as funcionalidades necessárias para a troca de imagens médicas. Através da definição de objeto as entidades de aplicação partilham uma visão comum das informações que serão trocadas, e da classe de serviço, os tipos de tarefas que devem ser implementas pelos dispositivos. Para entendermos as funcionalidade do modelo DICOM tomemos como exemplo uma aplicação básica do protocolo DICOM, a transferência de imagens de uma equipamento médico para outro equipamento ou para uma estação de trabalho. O DICOM oferece funcionalidades importantes que não estão presentes em um protocolo de transferência de arquivos genérico. Tendo um conhecimento comum entre cliente e servidor da estrutura de informação dos objetos, ou seja das propriedades de cada tipo de imagem incluindo informações a respeito de como estas imagens foram adquirida ( data, equipamento, técnicas utilizadas, etc.. ) e dados pessoais dos pacientes ( Nome, idade, sexo ). O receptor, ciente da estrutura da informação que irá receber, pode realizar diversas funções como permitir ao software receptor alocar recursos de acordo com o tipo de imagem que irá ser transferida, arquivar e armazenar estas imagens utilizando uma indexação baseada nos atributos das imagens como nome do paciente, data do exame, tipo de imagem, entre outros, ao invés de utilizar simplesmente o nome do arquivo transferido, e fazer a busca de imagens tanto remotamente como localmente, utilizando também atributos do objeto como o nome do paciente, nome do médico, idade, etc.. MENSAGEM DICOM Informação é comunicada através da interface de rede em uma mensagem DICOM. Esta mensagem é composta de um conjunto de comandos seguido de um conjunto de dados. O conjunto de comando é usado para indicar operação e notificação que serão executados no conjunto de dados. A estrutura geral de uma mensagem DICOM é mostrada na figura 3.1

3

Figura 3.1

CONJUNTO DE COMANDO Um conjunto de comando é composto de elementos de comando. Esses elementos contêm os valores codificados de cada campo de acordo com a semântica especificada pelo protocolo DIMSE que veremos a seguir. Os elementos de comando no conjunto de comando devem vir em ordem crescente de acordo com o número da etiqueta ( Comand Element Tag ). A etiqueta identifica o elemento de comando unicamente e deve aparecer no máximo uma vez no conjunto de comando, a codificação do elemento de comando deve ser na ordem de byte Little Endian. CONJUNTO DE DADOS

Figura 3.2

O conjunto de dados ( Data Set ) é composto de diversos elemento de dados fig. 3.2, cada elemento de dado é composto de três ou quatro campos, etiqueta ( tag ), representação de valor ( VR ), tamanho do valor, e campo de dados. Os elementos de dados são definidos unicamente por uma etiqueta (Tag). Os elementos de dados devem ser ordenados de acordo com a etiqueta em ordem crescente.

4

Etiqueta

VR

Tamanho

Número do Grupo

Número do Elemento

Caractere de 2 bytes estabelecendo a representação do valor ( tipo do dado)

Reservado

Tamanho em bytes do campo valor

2 bytes

2 bytes

2 bytes

2 bytes

4 bytes

Valor

Variável

ETIQUETA A etiqueta é composta de 32 bits ( 4 bytes ), 2 bytes para o grupo e 2 bytes para o elemento, os grupos pares são os que são definidos pelo padrão DICOM e podem ser encontrados na parte 6 do padrão, os grupos impares são para uso privado. Exemplo de Grupos

Grupo

Descrição

0002

Grupo de meta-elementos

0008

Grupo de identificação

0018

Grupo de Aquisição

0028

Grupo de apresentação das imagens

Exemplo de Etiquetas Grupo

Elemento

Titulo

Descrição

0002

0010

Transfer Index UID

Define a sintaxe de transferência

0002

0016

AE Fonte

Título da entidade de aplicação.

0008

0016

SOP Class UID

Define a classe par serviço-objeto (SOP)

0008

0060

Modalidade

Modalidade da imagem ( MR, CT, XR)

0008

0070

Fabricante

GE, Siemens, Toshiba

0018

0050

Espessura do Corte

Parâmetro de aquisição da imagem

7FE0

0010

Pixel Data

Imagem

REPRESENTAÇÃO DE VALOR ( VR) O campo VR ( Value Representation ) do elemento de dados deve conter 2 bytes que especificam o tipo de dados e a sintaxe de transferência que estará no campo

5

de dados, o VR pode ser explícito ou implícito, no implícito os dados são utilizados na sintaxe de transferência padrão DICOM ( implicit VR Little Indian ). Quando o VR for explícito, a representação dos dados será data pelas definições contidas na parte 5 do padrão DICOM de acordo com o valor do VR, na tabela abaixo podemos ver alguns exemplos de VRs. VR

Definição

Tipo de Caracteres

Tamanho

AE Application Entity

Caracteres que definem a entidade de aplicação

Alfanumérico

16 bytes máximo

DT

Data e hora

“0”-“9”,”.”

26 bytes máximo

OW

Texto cuja a codificação é especificada na sintaxe de transferência

N/A

Depende da Sintaxe de transferência

UID

Identificador único

“0” – “9”

64 Bytes máximo

IDENTIFICADORES ÚNICOS ( UID ) UID ( unique Identifiers ) é um número de identificação único utilizado nas mensagens DICOM, associado a uma organização e a uma função específica e é utilizado para definir a comunicação numericamente. Este número é composto por duas partes UID = <prefixo (org root) >. <sufixo> O prefixo identifica uma organização ( ex: fabricante, organização de pesquisa, NEMA ). A parte <sufixo> do UID representa a aplicação ( ex: transferência de imagens de tomografia na função de Usuário ) e deve ser único dentro do prefixo . Isto implica que a organização identificada como raiz (org root) é responsável pela garantia da unicidade do sufixo. O sufixo (org root) “1.2.840.10008” é reservado para itens do padrão DICOM, e não deve ser utilizado para definir itens privados. A organização responsável pela definição e registro deste UIDs é a NEMA. Outros prefixos privados podem ser utilizados com o DICOM, porém estes UIDs não serão registrados pela NEMA. As organizações que definem seus UIDs privados são responsáveis por registrar seus UIDs e garantir sua unicidade. UIDs privados só devem ser utilizados quando não houver UIDs DICOM referentes aquela função desejada. UID deve ter um Limite máximo de 64 Caracteres incluindo os separadores . Existem diversos tipos de UIDs mas os principais são aqueles que definem a classe SOP ( service-object pair ) que será vista mais a frente e aqueles que definem a sintaxe de transferência. SINTAXE DE TRANSFERÊNCIA A sintaxe de transferência que é estabelecida na etiqueta chamada transfer index (0002,0010) define um conjunto de regras que permite às entidades negociar as técnicas de codificação dos dados, este parâmetro tem influencia direta em como os dados de imagem ( 7FE0,0010) serão codificados, as imagens podem ser enviadas

6

tanto de forma nativa ( sem compressão ) como comprimidas por algum formato que não esteja no padrão DICOM . A sintaxe de transferência é definida pelo UID visto no item anterior, para forma nativa temos: Tipo

UID

Implicit VR,

1.2.840.10008.1.2

Explicit VR – LE

1.2.840.10008.1.2.1

Explicit VR – Big Endian

1.2.840.10008.1.2.2

Para as formas que utilizam compressão podemos ter: Tipo

UID

RLE

1.2.840.10008.1.2.5

JPEG

1.2.840.10008.1.2.4.50

JPEG-LS

1.2.840.10008.1.2.4.80

JPEG 2000

1.2.840.10008.1.2.4.90

PROTOCOLOS DIMSE ( DICOM MESSAGE SERVICE ELEMENT ) DICOM estabelece um protocolo para a troca de mensagens chamado DIMSE, este protocolo vai oferecer as condições de operação dos serviços DICOM chamados DIMSE-C e DIMSE-N. O funcionamento destes serviços esta descrito na parte 7 do padrão DICOM. O DIMSE oferecem dois tipos de serviço de transferência de usados pelas entidades DICOM, Notificação e Operação. O operações associadas a classes SOP composta e o DIMSE-N associadas a classes SOP normalizada. O conceito de SOP ( será visto mais a frente neste artigo.

informação que são DIMSE-C atende a atende a operações Service-Object Pair)

Nome

Grupo

Tipo

C-STORE

DIMSE-C

Operação

C-GET

DIMSE-C

Operação

C-MOVE

DIMSE-C

Operação

7

C-FIND

DIMSE-C

Operação

C-ECHO

DIMSE-C

Operação

N-EVENT REPORT

DIMSE-N

Notificação

N-GET

DIMSE-N

Operação

N-SET

DIMSE-N

Operação

N-ACTION

DIMSE-N

Operação

N-CREATE

DIMSE-N

Operação

N-DELETE

DIMSE-N

Operação

ACSE ( ASSOCIATION CONTROL SERVICE ELEMENT ) O ACSE é o elemento básico da camada de aplicação. Ele é o responsável pelo estabelecimento e pela liberação da associação entre duas entidades de aplicação que queiram ou estejam trocando informações. O usuário iniciador da associação requisita ao ACSE os serviços oferecidos por uma entidade de aplicação através de seu nome. Este nome independe de informações sobre endereçamento e sobre roteamento. Os serviços ACSE NOME

TIPO

A-ASSOCIATE

Confirmado

A-REALEASE

Confirmado

A-ABORT

Não confirmado

A-P-ABORT

Iniciado pelo provedor

P-DATA

Não confirmado

DEFINIÇÃO DE OBJETO DE INFORMAÇÃO - IOD O DICOM trabalha com a definição de objeto de informação IOD ( Information Object Definition ). Um IOD é um modelo de dado orientado a objeto utilizado para especificar objetos reais. Com base nos IODs, as entidades de aplicação partilham uma visão comum das informações que serão trocadas. Os IODs estão especificados na parte 3 do padrão DICOM. Um IOD não representa especificamente um objeto real mas sim, uma classe de objetos reais que partilham a mesmas propriedades ou atributos. Um IOD utilizado para representar uma única classe de objetos reais é chamado de IOD normalizado. Um IOD que inclui informações sobre objetos reais relacionados é chamado de IOD composto.

8

IOD NORMALIZADO OS IODs normalizados representam uma única entidade no modelo DICOM, estes IODs estão descritos no apêndice B da parte 3 do padrão DICOM. Como exemplo de IOD normalizado temos: Patient ( Paciente ), Study ( estudo ), VOI LUT, Storage Commitment ( compromisso de armazenamento ), Print Queue ( fila de impressão). Como exemplo, veremos o IOD Patient com mais detalhes Patient IOD A definição de objeto de informação Paciente é uma abstração da informação que descreve um paciente no qual os exames médicos foram realizados. O IOD Paciente, ou “Patient”, é útil as definições de classe de serviço que utilizam serviços que facilitam a troca de informações relacionadas ao paciente entre entidades de aplicação DICOM. Módulo

Referência

Descrição

SOP Common

C.12.1

Contem as informação SOP

Patient Relationship

C.2.1

Referencia a SOPs relacionados

Patient Identification

C.2.2

Identifica o paciente

Patient Demographic

C.2.3

Descreve o paciente

Patient Medical

C.2.4

Informações médicas sobre o paciente

A tabela acima identifica e define os módulos que compõem o IOD Patient, cada módulo faz referência a outra tabela que possui os atributos de cada modulo, todos estes dados podem ser encontrados detalhados no padrão DICOM parte 3 apêndice B e C. Destacamos abaixo os atributos mais importantes deste IOD, assim como a etiqueta relativa aos mesmos e o módulo a que o atributo pertence.

Módulo

Nome do Atributo

Etiqueta

Descrição do Atributo

Patient Identification

Patient’s Name

(0010,0010)

Nome completo do paciente

Patient Identification

Patient´s ID

(0010,0020)

Código do paciente emitido pelo hospital

Patient Identification

Patient’s Birth Name

(0010,1005)

Nome de nascimento do paciente

Patient Demografic

Patient’s Birth Date

(0010,0030)

Data de Nascimento do paciente

Patient Demografic

Patient’s Sex

(0010,0040)

Sexo do paciente

Patient Medical

Medical Alerts

(0010,2000)

Condições que a equipe médica deve estar alerta

9

IOD Composto Um IOD composto representa partes de várias entidades incluídas no modelo DICOM do mundo real. Os IOD estão descritos na parte 3 do padrão DICOM, alguns exemplos são IOD

Descrição

CR

Radiografia Digital

CT

Tomografia Computadorizada

MR

Ressonância Magnética

NM

Medicina Nuclear

SC

Filmes Escaneados

US

Ultrassom

XA

Angiografia

XA

Angiografia Bi-Plana

XR

Fluoroscopia

O IOD composto chamado MR especifica uma imagem que foi criada por um equipamento de ressonância magnética. O IOD MR deve conter todas as informações relevantes para este tipo de imagem, a tabela abaixo mostra alguns dos atributos que fazem parte deste IOD. A lista completa dos atributos para qualquer IOD composto pode ser encontrada nos apêndices A, B e C da parte 3 do padrão DICOM.

Entidade

Módulo

Atributo

Etiqueta

Descrição

Patient

General Patient

Patient’s Name

(0010,0010)

Nome do paciente

Patient’s ID

(0010,0020)

Identidade do paciente

Patient’s Birth

(0010,0030)

Data de nascimento paciente

Study UID

(0020,000D)

Identificador único do estudo

Study Date

(0008,0020)

Data do estudo

Study Desc.

(0008,1030)

Descrição do estudo

Modality

(0008,0006)

Modalidade (CT, MR, XR)

Protocol name

(0018,1030)

Nome do protocolo utilizado

Body Part

(0018,0015)

Descrição da parte do corpo examinada

Study

Series

General Study

General Series

10

Image

General Image

MR Image

SOP Common

P. Orientation

(0020,0020)

Orientação do paciente

Images Acqui.

(0010,1002)

Numero de imagens na aquisição

Image Type

(0008,0008)

Tipo da imagem

Echo Time

(0018,0081)

Parâmetro de aquisição de imagem

SOP Class UID

(0008,0016)

Identificador único da classe SOP ( 6.1)

Como podemos ver um IOD composto possui atributos de diversas entidades, ao contrário do IOD normalizado que possui atributos de apenas uma entidade. CLASSES SERVIÇOS O DICOM especifica tipos de comunicação chamadas classes de serviço DICOM. A funcionalidade do DICOM é expandida quando classes de serviços são adicionadas. As entidades podem exercer tanto a função de usuário como de provedor de um determinado serviço, a esta função chamamos respectivamente SCU ( service Class User ) e SCP ( Service Class Provider ). A interação entre as entidades de aplicação ocorre em um modelo cliente-servidor, o SCU atua como cliente e o SCP como servidor. As funções SCU/SCP são determinadas durante o estabelecimento da associação. Como o protocolo DICOM cobre quase todos os aspectos da transmissão de informação relevantes para as aplicações de radiologia, nenhum fabricante implementa todas as classes de serviço que o protocolo oferece. Cada fabricante escolhe implementar uma parte dos serviços DICOM que aumentarão a funcionalidade de um sistema em particular. Por exemplo um CT ( tomografia computadorizada ) não necessita ser uma impressora de imagens também, portanto os CTs somente implementam aquelas classes de serviço que estão alinhadas com a sua finalidade. As classes de serviço são: Verificação Protocolo de comunicação para assegurar que os dispositivo de rede estão conectados corretamente antes do inicio da comunicação. •

Gerenciamento de listagens das modalidades ( Modality Worklist Management )

Gerencia o fluxo de dados da rede interna do hospital ( utilizando um servidor RIS – Radiology Informaton System) para o equipamento de imagem. O servidor RIS funciona como um SCU que envia a informação de agendamento para o equipamento que funciona como SCP. •

PPS - Performed Procedure Step

Uma vez que o exame já foi realizado o equipamento comunica com o servidor RIS através do serviço DICOM PPS, para avisar que o exame foi concluído. Desta vez o

11

equipamento médico funciona como cliente (SCU) e o servidor RIS como provedor ( SCP) •

Store

Serviço utilizado para armazenamento de imagem, o equipamento como cliente (SCP) utiliza este serviço para enviar uma imagem para uma estação de trabalho ou para uma arquivo de imagem (SCP) •

Storage Commit

É importante que o equipamento gerador da imagem saiba que as imagem foram guardadas com sucesso no arquivo de imagem, para que as mesmas possam ser apagadas do equipamento de origem liberando espaço em disco. Através do serviço Store Commit o arquivo de imagem informa ao equipamento médico que agora é responsável pela as imagens transmitidas •

Print

Serviço que possibilita as funcionalidades necessárias para a transferências de imagem de um equipamento ou estação de trabalho para uma impressora de papel ou de filme fotográfico. •

Query/Retrieve

Serviço que permite ao usuário (SCU) visualizar a lista de exames do provedor (SCP) e transferir as imagens desejadas. Ao utilizar este serviço, um usuário em uma estação de trabalho pode visualizar a lista de exame de um equipamento médico remoto, escolher os exames desejados e visualiza-los em sua estação. CLASSE DE PARES DE SERVIÇO-OBJETO ( SOP ) Uma classe SOP ( Service-Object Pair ) é definida pela união de um IOD com um grupo de serviço. A definição de determinada classe SOP contem as regras e a semântica que podem restringir o uso de serviços no grupo de serviço e/ou nos atributos do IOD. A seleção da classe SOP é utilizada pela entidade de aplicação para estabelecer um conjunto de capacidades que atendam a sua interação. Um exemplo de classe SOP seria a classe chamada “CT image store”, proveniente da união do serviço de armazenamento ( store ) com o IOD CT Image, nesta classe estariam as regras e serviços utilizados para o armazenamento de imagens geradas por um tomógrafo. As classes SOP são determinadas de acordo com o identificador único UID, visto anteriormente Exemplos UID Classe SOP Tipo

UID

MR Store

1.2.840.10008.5.1.4.1.1.4

CT Store

1.2.840.10008.5.1.4.1.1.2

GE Private DICOM 3D Object

1.2.840.113619.4.26

12

CONSIDERAÇÕES FINAIS Desde a descoberta do raio-x em 1895 até bem pouco tempo atrás, a única forma de visualizar uma imagem médica era através de um filme radiográfico colocado em um negatoscópio. Com o aparecimento dos equipamentos digitais, essas imagens passaram ser transmitidas e armezadas digitalmente. A questão central passou a ser o compartilhamento da informação. O compartilhamento das informações, através das tecnologias de redes, permite que médicos possam obter segundas opiniões de especialistas em qualquer parte do mundo, possibilita que mais de um médico possa acessar exames simultaneamente. O armazenamento digital permite manter o histórico de um paciente de modo que qualquer médico possa acessa-lo quando for necessário. Novas possibilidades, ainda pouco exploradas, como a teleradiologia, permitem que médicos possam ver seus exames e fazer seus laudos mesmo que seus pacientes estejam a milhares de quilômetros de distância. Os novos monitores de alta definição possibilitam que os médicos vizualizem seus exames sem a necessidade de impressão em pelicula, reduzindo os custos e aumentando a eficiencia e rapidez dos sistemas de saúde. Tudo isso torna-se possível através das operações com imagens médicas digitais, tais como armazenamento, transferência e impressão. Como vimos neste artigo, essas operações seriam muita mais trabalhosas, e muitas vezes inviáveis se utilizassemos protocolos de comunicação genéricos ao invés dos procolos descritos no padrão DICOM, estes oferecem funcionalidades que resultam em uma total integração dos diversos dispositivos em uma rede de imagens médicas. Através do padrão DICOM, que hoje é aceito por toda indústria médica, a informação pode ser compartilha facilmente independente do tipo de equipamento que a gerou, do fabricante ou da sua localização.

REFERÊNCIAS National Electronics Manufacturer’s Association - NEMA, ”The DICOM standards”, disponível em http://medical.nema.org/. Acesso em Novembro de 2004 Bidgood, W. Dean Jr., Horii, Steven C., Prior, Fred W., and Syckle, Donald E. Van, “Understanding and Using DICOM, the Data Interchange Standard for Biomedical Imaging”, Journal of the American Medical Informatics Association Volume 4 Number 3 May / Jun 1997 ACR American College of Radiology, “Technical Standard for Teleradiology” , disponível em http://www.acr.org. Acesso em Novembro de 2004 Clunie, David A. “Lossless Compression of Grayscale Medical Images - Effectiveness of Traditional and State of the Art Approaches”, 2000 disponível em http://www.dclunie.com/ . Acesso em Novembro de 2004 Clunie, David A., “DICOM Compression 2002”, 2002

13

Rorden, Chris, “An introduction to the DICOM single-file format”, disponível em http://www.psychology.nottingham.ac.uk/staff/cr1/dicom.html#intro. Acesso em Novembro de 2004 Barré, Sébastien, “Medical Image Samples”, disponível em http://www.barre.nom.fr/medical/samples/#transfer-syntax. Acesso Novembro de 2004