UNIVERSIDADE FEDERAL DO PARANÁ Johanna E. Rogalsky. Padrão DICOM

Transcrição

1 UNIVERSIDADE FEDERAL DO PARANÁ Johanna E. Rogalsky Padrão DICOM Curitiba 2017

2 1. Introdução Com a evolução dos exames, surgiram os exames por imagem, como Tomografias Computadorizadas, Ressonâncias Magnéticas e Ultrassonografias (as mais comuns). Para que fossem utilizados no diagnóstico por imagem, surgiram vários formatos e tipos de equipamentos, de modo que cada equipamento era um sistema isolado e sendo conectado a apenas uma estação de trabalho e uma impressora. Mas, com o surgimento e desenvolvimento do uso das informações em formato digital, viu-se a necessidade da conexão desses equipamentos e também a padronização do formato das imagens, das informações que as mesmas carregam e de diretrizes para a implementação de sistemas que "conversassem a mesma língua". Assim, depois de algumas tentativas, o American College of Radiology (ACR) e a National Electrical Manufacturers Association (NEMA), reconheceram que existia uma urgência na criação de um padrão para transferir esses dados, imagens e informações associadas. Para tal, formaram em 1983 um comitê para definir um padrão que permitisse a comunicação da informação digital, independente do fabricante do equipamento, facilitasse o desenvolvimento de sistemas para comunicação e arquivamento das imagens e possibilitasse a criação de informação diagnóstica significante para ser distribuída a uma grande variedade de aparelhos. Então, em 1985, criou-se então um padrão através desse comitê, que mais tarde veio a se chamar DICOM (Digital Imaging and Communications in Medicine). Ele especifica uma série de protocolos para comunicação em rede, a sintaxe e a semântica para comandos e suas informações associadas que podem ser trocadas usando esses protocolos. Além de fornecer padrões para os serviços de armazenamento de mídia e formatos e estruturas de arquivos para tal. Desse modo, permitindo uma maior interoperabilidade entre diversos sistemas e equipamentos médicos. Além disso, permite que exames sejam transportados para vários lugares em mídias físicas sem a necessidade da impressão dos mesmos. A seguir, o padrão DICOM e suas estruturas e especificações são explicadas. 2. Estrutura e as partes da especificação DICOM As estruturas e especificações do padrão DICOM, são separadas em 20 partes. Dessas vinte, permanecem 18, já que a comunicação ponto a ponto referente as partes 9 e 13 não é mais necessária. E apesar de todas serem relacionadas, cada parte é um documento independente. Suas descrições são feitas a seguir e baseadas no arquivo da primeira parte [3]. Na Figura 1 é possível ver sua arquitetura Parte 1 - Introdução e visão geral O padrão DICOM não foi criado da forma como o temos hoje, apesar de não ter mudado muito desde sua criação, tendo apenas três versões. A primeira foi criada em 1985 e chamada de ACR-NEMA ou ACRNEMA 1.0. Ela possuía apenas a interface de hardware, um número mínimo de comandos de software e um conjunto consistente de formatos de dados.

3 Figura 1. Arquitetura das partes DICOM A segunda versão, ACR-NEMA ou ACRNEMA-2.0, veio apenas três anos depois incluindo um novo material para fornecer suporte a comandos de dispositivos de exibição. Dessa forma, foi possível introduzir um novo esquema hierárquico de identificação de imagens e também adicionar elementos de dados para aumentar a especificidade da descrição de imagens. Sua terceira versão foi criada em 1993 e permanece até hoje. Ela é chamada de ACR-NEMA DICOM ou DICOM-3.0 (mais comum) e pode ser aplicada a um ambiente em rede e à troca de mídia off-line, definindo o formato do arquivo e dando suporte a vários tipo de mídias físicas. Além disso, é um protocolo orientado para o serviço, que especifica a semântica de comandos e dados associados, e como os dispositivos reagem a comandos e transferência de dados. Sendo assim, inclui suporte para gerenciamento do fluxo de trabalho de um departamento de imagens e explicitamente descreve como um programador deve estruturar a Declaração de Conformidade para seleção de opções específicas Parte 2 - Conformidade A conformidade define princípios para a implementação que reivindica a conformidade com o Padrão. Requisitos de conformidade: especificação dos requisitos gerais. Declaração de Conformidade: especificação da informação que deve estar presente.

4 Sendo que a declaração de conformidade consiste no conjunto de objetos de informação que é reconhecido pela implementação. Além do conjunto de classes de serviço, de protocolos de comunicação, ou mídia física, e de medidas de segurança suportados Parte 3 - Definições de Objeto de Informação DICOM 3.0 especifica uma série de Classes de Objetos de Informação que fornecem uma visão abstrata das entidades do mundo real aplicáveis na comunicação de imagens médicas digitais e suas informações relacionadas. Elas são separadas em classes de objetos de informação normalizadas e compostas, sendo sua principal diferença entre os atributos incluídos. As normalizadas incluem apenas atributos inerentes à entidade do mundo real representada. Por exemplo, a classe de informação do estudo contém data e horário do estudo, porque elas são inerentes a um estudo real. Mas nome do paciente não é um atributo dessa classe, uma vez que é inerente no paciente sobre o qual o estudo foi conduzido e não o estudo em si. As compostas, incluem adicionalmente atributos relacionados à entidade do mundo real. Por exemplo, a classe de informação da tomografia computadorizada contém ambos os atributos que são inerentes à imagem (dados da imagens) e os que são relacionados mas não inerentes a imagem (nome do paciente). Dessa forma, fornece uma estrutura para expressar os requisitos de comunicação das imagens, onde dados da imagem e dados relacionados devem estar altamente associados Parte 4 - Especificação das Classes de Serviço As Classes de Serviço associam um ou mais objetos de informação através de um ou mais comandos realizados sobre os mesmos. Suas especificações ditam os requisitos tanto para provedores como para usuários dos serviços de comunicação, dos elementos de comandos e como eles são aplicados nos objetos. Além disso, DICOM 3.0 define as características compartilhadas por todas classes de serviço e como a declaração de conformidade para uma classe em específico deve ser estruturada. Alguns exemplos são Armazenamento, Consulta e recuperação, Gerenciamento de tarefas e Gerenciamento de serviços de impressão Parte 5 - Estruturas de dados e codificação Especifica como aplicações constroem e codificam a informação dos Conjuntos de Dados. Além de definir as regras necessárias para formar o Fluxo de Dados (coleção de Elementos de Dados que compõem o Conjunto) quando uma mensagem é transmitida. Além disso, define a semântica de outras funções genéricas que são comuns a muitos Objetos de Informação. E ainda, define as regras de codificação de conjuntos de caracteres internacionais que são usados Parte 6 - Dicionário de Dados Define a coleção dos Elementos de Dados disponíveis para representar informações. Para cada elemento, esta parte do padrão especifica: Tag única (grupo, número do elemento)

5 Nome Representação de valores - VR (string, inteiro, etc.) Multiplicidade (quantos valores por atributo) Se está presente ou não Além disso, para cada item unicamente identificado, especifica: Valor único Nome Tipo, Classe de Objetos de Informação, definição de codificação para transferência de dados, ou certas Instancias de Objetos de Informação Em que parte do padrão DICOM está definido 2.7. Parte 7 - Troca de mensagens Especifica tanto o serviço quanto o protocolo usado por uma aplicação para troca de Mensagens, que é composta de um Command Stream seguido por um Data Stream. Além disso, também especifica: operações e notificações para as classes de serviço normas para iniciar e encerrar associações dos suportes de comunicação e o impacto das transações regras que regem pedidos e respostas de comandos codificação necessária para construir fluxos de dados e mensagens 2.8. Parte 8 - Suporte à comunicação em rede para trocar mensagens Especifica os serviços de comunicação e protocolos de camada superior necessários ao suporte, em ambientes de rede, à comunicação eficiente e coordenada entre aplicações DICOM. Onde os serviços são especificados pelo modelo OSI conjuntamente com o protocolo de transporte TCP/IP, permitindo que aplicativos de pares estabeleçam associações, enviem mensagens e terminem a associação Parte 10 - Armazenamento em mídia e formato de arquivo Descreve como deve ser o armazenamento de informações de imagens médicas em mídia removível. E, além disso, provê um framework que permite o intercâmbio de vários tipos de imagens médicas e as informações associadas em um amplo domínio de mídias de armazenamento removível Parte 11 - Perfil da aplicação do armazenamento em mídia Perfis que especificam subconjuntos específicos (Perfil de Aplicação) de aplicativos do Padrão DICOM cuja implementação pode reivindicar a conformidade. Essa declaração de conformidade aplica-se ao intercâmbio interoperável de imagens médicas e informações relacionadas em meios de armazenamento para usos clínicos específicos Parte 12 - Formato de mídia e mídia física para transporte Especifica o intercâmbio de informações entre aplicações de sistemas médicos e determina a estrutura de descrição do relacionamento entre o modelo de armazenamento em mídia e uma mídia física específica e formato de mídia. Além das características específicas dessas mídias e formatos associados.

6 2.12. Parte 14 - Função de exibição da escala de cinza Padroniza as funções para uma exibição consistente de imagens em escala de cinza. Além de fornecer métodos para calibração de um dispositivo em particular para que a apresentação das imagens seja consistente em diferentes meios de exibição Parte 15 - Perfis de segurança e sistema de gerenciamento Define os perfis de segurança e sistema de gerenciamento para implementações que podem exigir conformidade, utilizando protocolos externos. Estes protocolos também devem usar técnicas de segurança, como chaves públicas e "smart cards". Além de fazer a criptografia dos dados Parte 16 - Recurso de mapeamento de conteúdo Especifica templates de estruturação de documentos como Objetos de Informação DI- COM, conjunto de termos codificados para uso nos mesmo objetos, dicionário de termos definidos e mantidos pelo DICOM e traduções pra várias línguas desses termos Parte 17 - Informação explicativa Define anexos normativos e informativos que contém informações explicativas Parte 18 - Acesso web a objetos persistentes Dita os meios pelos quais os Serviços Web podem ser utilizados para recuperar e armazenar objetos persistentes. Sendo que a requisição de recuperação especifica o formato de arquivo do corpo da resposta, e a de armazenamento especifica o formato de arquivo da solicitação Parte 19 - Hospedagem da aplicação Parte do DICOM que especifica uma Interface de Programação de Aplicação (API) para um sistema de computação médico. Nele, os programas escritos para essa interface padronizada podem ser conectados (modelo plug-in) como mostra a Figura 2. Além disso, especifica as interações e as APIs entre Sistemas de Hospedagem e Aplicativos Hospedados, e também o modelo dos dados. Figura 2. Interface entre a Aplicação Hospedada e o Sistema de Hospedagem Dessa forma, um implementador do Sistema de Hospedagem só precisa criar a API padronizada uma vez para suportar uma grande variedade de aplicativos hospedados. Sendo assim, uma Aplicação com esse formato plug-in escrita na API pode ser executada em qualquer ambiente que o Sistema de Hospedagem (que implemente a API em questão) forneca. Isso é demonstrado na Figura 3.

7 Figura 3. Ilustração da independência de plataforma através da Aplicação Hospedada Parte 20 - Relatórios de imagens usando a arquitetura de documentos clínicos HL7 Especifica templates para codificação de relatórios de imagens que usam o padrão HL7 Clinical Document Architecture Release (CDA). Nesse escopo, estão os procedimentos clínicos de especialidades que utilizam as imagens para triagem, diagnóstico ou fins terapêuticos. Além disso, contém um guia para implementação do CDA e está harmonizado com a abordagem de modelos padronizados de guias para o CDA desenvolvidos pelo HL7. 3. O Modelo de Comunicação DICOM A Figura 4, mostra o modelo de comunicação geral do DICOM que abrange comunicações de intercâmbio de mídia de rede e de armazenamento [3]. Nele, as entidades de aplicativo DICOM podem uitilizar um dos três mecanismos de transporte: Camada Superior de Serviço ou Serviço de Mensagens DICOM: fornece independência de suporte específico de comunicação em rede física API DICOM de Web Service e HTTP Service: permite o uso de hipertexto comum e protocolos associados para o transporte de serviços DICOM Serviço de Arquivos DICOM: fornece acesso a mídia de armazenamento independentemente de formato específico de armazenamento da mídia física e de estrutura de arquivos 4. Modelagem de Informação e Objetos de Serviço A modelagem da informação é baseada em um modelo Entidade-Relacionamento, onde uma entidade é usada para representar um Objeto do mundo real, uma Classe do mundo real ou uma representação de dados DICOM, e um relacionamento define como as entidades se relacionam. A partir disso, Objetos do mundo real tem suas informações especificadas pela Definição de Objeto de Informação (do inglês, IOD), que é um modelo de dados abstratos orientado a objetos. De modo que, as Definições de Objeto de Informação são separados em compostos e normalizados.

8 Figura 4. Modelo geral de comunicação DICOM Um IOD composto representa partes de várias entidades e inclui atributos inerentes aos Objetos do mundo real relacionados. Que por sua vez, fornecem um contexto completo das informações trocadas. Então quando uma instância é comunicada, todo esse contexto é trocado entre as Entidades de Aplicação. Já um normalizado, geralmente representa uma única entidade. E quando uma instância é comunicada, o contexto dessa mesma instância não é realmente trocado. Ao invés disso, o contexto é fornecido através da utilização de ponteiros para instâncias de IODs normalizados. Os Objetos de Serviço, por sua vez, são Classes do tipo Par Serviço-Objeto (do inglês, SOP) e são a união de um IOD e um Grupo de Serviço DIMSE (operações/notificações que podem ser aplicadas a IODs). Onde a definição dessas Classes contem regras e semânticas que podem restringir o uso dos serviços no Grupo de Serviço DIMSE e/ou atributos do IOD. Desse modo, a seleção de uma Classe SOP é usada por uma Entidade de Aplicação para estabelecer o conjunto de capacidades que suportarão sua interação. E assim como os Objetos de Informação, elas são separadas em classes SOP normalizadas e compostas.

9 Onde as normalizadas são a união de um IOD normalizado com um conjunto de Serviços DIMSE-N e as compostas, união de um IOD composto e um conjunto de Serviços DIMSE-C [4]. 5. Formato de Dados DICOM O Conjunto de Dados representa uma instância de Objeto de Informação do mundo real e é construído com Elementos de Dados. Que por sua vez, contem os Atributos e Valores desse objeto codificados. Eles são identificados unicamente por uma Tag em um Conjunto, onde devem ser ordenados de forma crescente seguindo o número dessa Tag e onde deveriam ocorrer apenas uma vez no Conjunto. Suas estruturas podem ser vistas na Figura 5. Figura 5. Estrutura do Conjunto de Dados e dos Elementos de Dados O Elementos podem ser Padrão ou Privados e devem ter uma de três estruturas. Duas delas possuem a Representação do Valor (VR) (explícito) do Elemento, diferindo apenas no modo como seus comprimentos são expressos, enquanto a terceira não possui (implícito). Além disso, as três estruturas contem os campos para a Tag, para o Comprimento do Valor e para o Valor do Elemento. E ainda, podem ser de três tipos. Os do Tipo 1 e Tipo 2 (Elementos Requeridos), são os que os IODs e as Classes SOP definem que devem ser incluídos e são obrigatórios. Já os do Tipo 1C e Tipo 2C (Elementos Condicionais), são os que os IODs e as Classes SOP definem que devem ser incluídos sob certas condições. Já o Tipo 3, são os Elementos opcionais, que em ausência não representam uma violação de protocolo [5]. Quando um Conjunto de Dados, que representa uma instância de SOP relacionada a um IOD, é encapsulado, ele forma um Arquivo DICOM. Esse Arquivo pode ser encapsulado em um Arquivo DICOM Seguro, com a Sintaxe da Mensagem Criptográfica, garantindo Confidencialidade (em termos de criptografia), Origem de Autenticação do dados (em termos de certificado e assinaturas digitais) e Integridade (em termos de assinaturas digitas) [6]. 6. Sistemas de Informação e DICOM Um Sistema de Informação (SI) tem como seu principal componente a informação e o objetivo é armazenar, tratar e fornecer as informações de modo que apoie as funções ou processos de uma organização. Sendo composto por um sub-sistema que inclui o

10 mundo real: pessoas, processos, informações e documentos. E um que inclui o mundo automatizado: máquinas, computadores e redes de comunicação que se interligam com o primeiro. Existem vários tipo de SI, dentre eles os Sistemas de Informação Hospitalar (HIS). Os quais devem, principalmente, conter a Base de dados do paciente, dar suporte a Aquisição de dados do paciente, permitir a Admissão, transferência e alta do paciente, além de permitir a Avaliação e o Gerenciamento do paciente. Além disso, os sistemas de informação podem ser utilizados para gerenciamento de imagens e informações clínicas. Isto é, para que equipamentos hospitalares não sejam apenas sistemas isolados, mas sim interligados de forma que a troca de dados de imagens fosse consistente e automática. Sendo assim, surgiu o PACS (do inglês, Picture Archiving and Communication System). O PACS é um sistema para arquivamento e comunicação voltado para o diagnóstico por imagem que permite o acesso de imagens médicas em formato digital a qualquer momento e em qualquer setor do hospital. A partir disso, pode-se obter um serviço de radiologia sem filme. Isto é, inter relacionar um PACS, um Sistema de Radiologia Digital (DRS): o DICOM, ou um de Informação Radiológica (RIS), e um HIS [1]. O que pode ser visto na Figura 6 Figura 6. Estrutura do Conjunto de Dados e dos Elementos de Dados 7. Conclusão Portanto, é possível perceber que o DICOM realmente melhorou a interoperabilidade, além de permitir que vários profissionais de saúde possam opinar sobre o laudo/diagnóstico de algum paciente através de seu exame, ao mesmo tempo e em tempo real, através do PACS. Dessa forma, evitando enormes gastos na impressão de exames por imagem e transtornos no transporta de exames dentro (e fora) de hospitais, clínicas, e etc.

11 Referências [1] DE AZEVEDO-MARQUES, Paulo Mazzoncini; SALOMÃO, Samuel Covas. PACS: sistemas de arquivamento e distribuição de imagens. Revista Brasileira de Física Médica, v. 3, n. 1, p , [2] DICOM - Digital Imaging and Communications in Medicine. Disponível em: < Acesso em: 9 de novembro de [3] DICOM Part 1: Introduction and Overview. Disponível em: < Acesso em: 9 de novembro de [4] DICOM Part 3: Information Object Definitions. Disponível em: Acesso em: 9 de novembro de [5] DICOM Part 5: Data Structures and Encoding. Disponível em: Acesso em: 9 de novembro de [6] DICOM Part 10: Media Storage and File Format for Media Interchange. Disponível em: Acesso em: 9 de novembro de 2017.