UNIVERSIDADE FEDERAL DO PARANÁ MABI ADRIANE FRANCISCA PRUX VON STEINKIRCH SOUZA SISTEMA DE INFORMAÇÃO EM SAÚDE TRABALHO 4

Transcrição

1 UNIVERSIDADE FEDERAL DO PARANÁ MABI ADRIANE FRANCISCA PRUX VON STEINKIRCH SOUZA SISTEMA DE INFORMAÇÃO EM SAÚDE TRABALHO 4 CURITIBA 2017

2 Sumário 1. Introdução sobre interoperabilidade e o padrão DICOM 3 2. A estrutura e as partes da especificação DICOM Part 1: Introduction and Overview (Introdução e Visão Geral) Part 2: Conformance (Conformidade) Part 3: Information Object Definitions (Definições de Objetos de Informação) Part 4: Service Class Specifications (Especificação de Classes de Serviços) Part 5: Data Structures and Encoding (Estrutura de Dados e Semântica) Part 6: Data Dictionary (Dicionários de Dados) Part 7: Message Exchange (Troca de Mensagens) Part 8: Network Communication Support for Message Exchange (Suporte à comunicação em rede para a troca de mensagens) Part 9: Retired (Não existe mais) Part 10: Media Storage and File Format for Media Interchange (Armazenamento em mídia e formato de arquivo) Part 11: Media Storage Application Profiles (Perfis de aplicação de armazenamento em mídia) Part 12: Formats and Physical Media (Formato e mídia física) Part 13: Retired (Não existe mais) Part 14: Grayscale Standard Display Function (Função de exibição de escala de cinza) Part 15: Security and System Management Profiles (Perfis de Segurança e Sistema de Gerenciamento) Part 16: Content Mapping Resource (Recurso de Mapeamento de Conteúdo) Part 17: Explanatory Information (Informação Redundante) Part 18: Web Services Part 19: Application Hosting (Hospedagem da Aplicação) Part 20: Imaging Reports using HL7 Clinical Document Architecture (Transformação do Padrão DICOM para HL7 e vice-versa) 9 3. O Modelo de Comunicação DICOM 9 4. Modelagem de Informação e Objetos de Serviço Formato de Dados DICOM Como Sistemas de Informação usam DICOM Conclusão sobre o tema Referências Bibliográficas 16

3 1. Introdução sobre interoperabilidade e o padrão DICOM Em Sistemas de Informação em Saúde há o intercâmbio de dados entre diferentes sistemas dentro do hospital ou até mesmo entre diferentes hospitais ou organizações. Cada país, ou empresa de software cria sua própria linguagem de intercomunicação, um dialeto próprio. Contudo, para que todas as entidades envolvidas sejam beneficiadas dos dados gerados é necessário que estas sejam capazes de se comunicar entre si. Dessas necessidades surge a existência de interoperabilidade entre os sistemas. Esta tem como objetivo criar um padrão único de comunicação entre os diferentes sistemas e bases de dado. Para tanto existem organizações compostas por diferentes setores da sociedade e da indústria, como a National Electrical Manufacturers Association (NEMA) que busca criar e definir um padrão único para a interoperabilidade de transmissões de imagens médicas e as informações associadas nos sistemas de informação em saúde. A Interoperabilidade é a capacidade de troca de informação entre organizações e entre seus diferentes sistemas. Esta é composta por três atributos, a semântica trata-se do uso de um vocabulário padronizado dentro das informações eletrônicas de forma a permitir a mesma compreensão dos vocabulários e estrutura de dados nos diferentes sistemas envolvidos. Já a comparabilidade é a capacidade de verificar a equivalência de dados oriundos de fontes diferentes e a qualidade dos dados é a medição da acessibilidade, integralidade, acurácia e precisão da comunicação de dados eletrônicos entre sistemas ( SBPC/ML, 2014). A Portaria Nº 2.073, de 31 de agosto de 2011, do Ministério da saúde, regulamenta o uso de padrões de interoperabilidade e informação em saúde para sistemas de informação em saúde no âmbito do Sistema Único de Saúde, nos níveis Municipal, Distrital, Estadual e Federal, e para os sistemas privados e do setor de saúde suplementar (BRASIL, 2011). Os padrões de interoperabilidade constam do Catálogo de Padrões de Interoperabilidade de Informações de Sistemas de Saúde (CPIISS), publicado pelo Serviço do Departamento de Informática do SUS (DATASUS) (BRASIL, 2013). De acordo com a regulamentação para a representação da informação relativa a exames de imagem, por exemplo, será utilizado o padrão DICOM. O DICOM (Digital Imaging and Communications in Medicine), publicado pela primeira vez em 1993, é o padrão internacional mais utilizado no mundo que aborda a troca de informações digitais entre equipamentos de imagem médica e outros sistemas (DICOM, 2017). Além disso, este padrão foi desenvolvido focando na imagem para diagnóstico médico, como praticado em radiologia, cardiologia, patologia, odontologia, oftalmologia e disciplinas relacionadas, e terapias baseadas em imagem, como radiologia intervencionista, radioterapia e cirurgia. Dessa forma, revolucionando a prática em saúde ao permitir a substituição do filme de raios-x por

4 um fluxo de trabalho totalmente digital. No entanto, também é aplicável a uma ampla gama de imagens e informações não relacionadas à imagem trocadas em ambientes clínicos, de pesquisa, veterinários e outros médicos. O padrão DICOM é catalogado pelo padrão ISO ( International Organization for Standardization ) de número A publicação mais recente deste padrão da ISO é o 12052:2017 que aborda a troca de imagens digitais e informações relacionadas à produção e gerenciamento dessas imagens no campo da informática em saúde, tanto entre equipamentos e sistemas de imagem médica relacionados com a gestão e comunicação dessa informação. Este padrão facilita a interoperabilidade do equipamento de imagem médica especificando protocolos a serem seguidos por dispositivos que reivindicam a conformidade com este documento: 1) a comunicação de rede; 2) a sintaxe e semântica de comandos e informações associadas; 3) comunicação de mídia, isto é, conjunto de serviços de armazenamento de mídia, bem como um formato de arquivo e uma estrutura de diretório médico para facilitar o acesso às imagens e informações relacionadas armazenadas em mídias de intercâmbio; 4) informação que deve ser fornecida para a implementação (ISO, 2017). Entretanto, não especifica: 1) os detalhes de implementação de quaisquer recursos do padrão DICOM; 2) o conjunto geral de recursos e funções a serem esperados a partir de um sistema implementado integrando um grupo de dispositivos e; 3) um procedimento de teste / validação para avaliar a conformidade de uma implementação (ISO, 2017). Portanto, apesar de facilita a interoperabilidade dos sistemas que reivindicam a conformidade em um ambiente, não garante, por si só, a interoperabilidade. 2. A estrutura e as partes da especificação DICOM 2.1 Part 1: Introduction and Overview (Introdução e Visão Geral) Essa primeira parte fornece uma visão geral do padrão DICOM, apresentando uma breve descrição do conteúdo de cada parte do padrão. Inicialmente evidencia o que faz parte do escopo e não escopo do projeto, como já apresentado anteriormente no ítem 1 deste documento. Em seguida descreve a história, metas e estrutura do padrão e apresenta as referências normativas utilizadas, símbolos e abreviações, assim como as definições para os atributos, comandos utilizados e o Modelo de Comunicação do DICOM. 2.2 Part 2: Conformance (Conformidade) Essa parte define regras de implementação: 1) Requisitos de conformidade: especificação dos requisitos gerais; 2) Declaração de Conformidade: define a estrutura de uma Declaração de Conformidade, isto é, especifica as informações que devem estar presentes e os requisitos opcionais. Entretanto, esta parte não

5 especifica um procedimento de teste/validação para avaliar a conformidade de uma implementação com o padrão. 2.3 Part 3: Information Object Definitions (Definições de Objetos de Informação) A parte 3 especifica uma série de Classes de Objetos de Informação que fornecem uma definição abstrata de entidades do mundo real aplicáveis à comunicação de imagens médicas digitais e informações relacionadas (por exemplo, relatórios estruturados). Cada definição de Classe de Objeto de Informação consiste em uma descrição de seu propósito e os atributos que o definem. Caso seja necessário acrescentar novas funcionalidades é possível estender esse conjunto de Objetos de Informação. 2.4 Part 4: Service Class Specifications (Especificação de Classes de Serviços) A quarta parte do documento define uma série de Classes de Serviços. Uma Classe de Serviço associa um ou mais Objetos de Informação com um ou mais Comandos a serem executados sobre esses objetos. Além disso, contém uma série de anexos normativos que descrevem as Classes de Serviços individuais em detalhes. Exemplos: armazenamento, consulta e recuperação, gerenciamento de tarefas e gerenciamento de impressão. 2.5 Part 5: Data Structures and Encoding (Estrutura de Dados e Semântica) A quinta parte específica como os aplicativos DICOM constroem e codificam as informações do Conjunto de Dados resultantes do uso das Classes de Serviços de Informação e Serviços definidos nas partes 3 e 4. Neste momento é abordado uma série de regras de codificação necessárias para construir um fluxo de dados para ser transmitido em uma Mensagem conforme será especificado na parte 7. A parte 5 também define a semântica de uma série de funções genéricas que são comuns a muitos objetos de informação e também é descrito as técnicas padrão de compressão de imagem, por exemplo, JPEG. Além disso, também define as regras de codificação para conjuntos de caracteres internacionais usados no DICOM. 2.6 Part 6: Data Dictionary (Dicionários de Dados) O registro centralizado que define a coleção de todos os elementos de dados DICOM disponíveis para representar informações, juntamente com elementos utilizados para codificação de mídia intercambiável e uma lista de itens identificados de forma exclusiva que são atribuídos pelo DICOM. Para cada elemento, a parte 6 especifica: tag exclusiva, que consiste em um grupo e número de elemento; nome; representação de valores (seqüência de caracteres, inteiro, etc.); multiplicidade de valores (quantos valores por atributo). E para cada item identificado de forma exclusiva, essa parte também especifica: valor

6 exclusivo, nome, tipo, Classe de Objeto de Informação, definição de codificação para transferência de dados ou certas instâncias de objeto de informação e, qual parte do padrão DICOM está definido. 2.7 Part 7: Message Exchange (Troca de Mensagens) A parte 7 especifica tanto o serviço como o protocolo utilizados por um aplicativo em um ambiente de imagem médica para trocar Mensagens pelos serviços de suporte de comunicação definidos na parte 8. Uma mensagem é composta por um fluxo de comando definido na parte 7 seguido de um fluxo de dados opcional conforme definido na parte 5. Além disso, nessa parte é especificado: as operações e notificações (DIMSE Services) disponibilizadas para Classes de Serviços definidas na parte 4; regras para estabelecer e encerrar as associações fornecidas pelo suporte de comunicação especificado na parte 8, e o impacto nas transações pendentes; regras que regem a troca de pedidos e respostas do Comando; regras de codificação necessárias para construir fluxos e mensagens de comando. 2.8 Part 8: Network Communication Support for Message Exchange (Suporte à comunicação em rede para a troca de mensagens) A parte 8 especifica a comunicação entre os serviços e os protocolos de camada superior necessários para o suporte, em ambientes de rede, à comunicação entre aplicações DICOM conforme especificado nas partes 3 até a 7. Esses serviços e protocolos de comunicação garantem que a comunicação entre aplicativos DICOM seja realizada de forma eficiente e coordenada. Trata-se de um serviço de camada superior, pois permite que pares de aplicativos estabeleçam associações, transfiram mensagens e terminem associações utilizando o protocolo DICOM Upper Layer em conjunto com o protocolo de transporte TCP/IP. 2.9 Part 9: Retired (Não existe mais) Esta parte especificava previamente os serviços e protocolos utilizados para comunicações ponto-a-ponto de uma maneira compatível com ACR-NEMA 2.0. Entretanto, nesta nova versão não é mais utilizada Part 10: Media Storage and File Format for Media Interchange (Armazenamento em mídia e formato de arquivo) A parte 10 especifica um modelo geral para o armazenamento de informações médicas em mídias removíveis. O objetivo desta Parte é fornecer uma estrutura que permita o intercâmbio de vários tipos de imagens médicas e informações relacionadas em uma ampla gama de mídia de armazenamento físico.

7 Além disso, a parte 10 define vários conceitos de armazenamento de mídia, tais como o método para identificar um conjunto de arquivos em um único meio e o método para nomear um arquivo DICOM dentro de um sistema de arquivos específico Part 11: Media Storage Application Profiles (Perfis de aplicação de armazenamento em mídia) A parte 11 especifica subconjuntos específicos do aplicativo do Padrão DICOM ao qual uma implementação pode declarar 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. Isto é, adequa 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. A estrutura do DICOM e o design do mecanismo do Perfil de Aplicação são tais que a extensão para Classes de Objetos de Informação adicionais e a nova mídia de intercâmbio é direta Part 12: Formats and Physical Media (Formato e mídia física) Esta parte facilita o intercâmbio de informações entre aplicativos em ambientes médicos, especificando uma estrutura para descrever a relação entre o modelo de armazenamento em mídia e em uma mídia física específica e formato de mídia e, também, as características da mídia Part 13: Retired (Não existe mais) A parte 13 especificava previamente os serviços e protocolos utilizados para a comunicação ponto-a-ponto dos serviços de gerenciamento de impressão. Entretanto, nesta nova versão não é mais utilizada Part 14: Grayscale Standard Display Function (Função de exibição de escala de cinza) A parte 14 especifica uma função de exibição padronizada para exibição consistente de imagens em escala de cinza. Esta função fornece métodos para calibrar um determinado sistema de exibição com a finalidade de apresentar imagens consistentemente em diferentes meios de exibição (por exemplo, monitores e impressoras). A função de exibição escolhida é baseada na percepção visual humana. A sensibilidade ao contraste do olho humano é distintamente não linear dentro da faixa de luminância de dispositivos de exibição. Este padrão usa o modelo Barten do sistema visual humano.

8 2.15 Part 15: Security and System Management Profiles (Perfis de Segurança e Sistema de Gerenciamento) A parte 15 especifica os perfis de segurança e gerenciamento de sistema aos quais devem estar em conformidade com as implementações. Os perfis de gerenciamento de segurança e sistema são definidos fazendo referência a protocolos padrão desenvolvidos externamente, como DHCP, LDAP, TLS e ISCL. Os protocolos de segurança devem usar técnicas de segurança como criptografias de dados, chaves públicas e "cartões inteligentes". Porém, esta parte não aborda questões de políticas de segurança, pois apenas fornece mecanismos que podem ser usados para implementar as políticas de segurança relativas ao intercâmbio de objetos DICOM. É responsabilidade do administrador local estabelecer a segurança política apropriada Part 16: Content Mapping Resource (Recurso de Mapeamento de Conteúdo) Esta parte especifica modelos para estruturar documentos do DICOM; conjuntos de termos codificados para uso em objetos de informação; um dicionário de termos definidos e mantidos pelo DICOM e traduções específicas por país de termos codificados Part 17: Explanatory Information (Informação Redundante) A parte 17 especifica anexos informativos e normativos contendo informações explicativas Part 18: Web Services A parte 18 do Padrão DICOM especifica os meios pelos quais os Serviços da Web podem ser usados para recuperar ou armazenar um objeto DICOM. Os pedidos de recuperação de dados especificam o tipo de mídia (formato) do corpo da resposta. As requisições HTTP conforme definido neste padrão são suficientes para que o servidor HTTP atue como um DICOM SCU (Usuário de Classe de Serviço) para recuperar ou armazenar os objetos solicitados de um DICOM SCP (Service Class Provider) apropriado usando a função DICOM de linha de base - como definido na parte 4 e na parte 7. Isto significa que o servidor HTTP pode atuar como um proxy para o DICOM SCP Part 19: Application Hosting (Hospedagem da Aplicação) A parte 19 especifica uma Interface de Programação de Aplicação (API) para um sistema de computação médica baseado em DICOM em que os programas escritos naquela interface padronizada podem trocar informações. Somente um implementador do sistema de hospedagem precisa criar a API padronizada uma vez

9 para suportar uma grande variedade de aplicativos hospedados de complemento. Além disso, esta parte também define os modelos de dados que são usados pela API Part 20: Imaging Reports using HL7 Clinical Document Architecture (Transformação do Padrão DICOM para HL7 e vice-versa) A parte 20 especifica modelos para a codificação de relatórios de imagem usando a Arquitetura de Documentos Clínicos do padrão HL7 Versão 2 (CDA R2, ou simplesmente CDA). Dentro deste escopo estão os relatórios de procedimentos clínicos para especialidades que usam imagens para triagem, diagnóstico ou terapêutica. Dessa forma, é focado o uso e referência dos dados coletados em imagens de procedimentos como evidências explícitas nos relatórios. Esses dados incluem imagens, formas de onda, medições, anotações e outros resultados de análises gerenciados como instâncias do DICOM SOP. Além disso, esta parte também oferece um guia de implementação para CDA desenvolvido pelo HL7. 3. O Modelo de Comunicação DICOM O padrão DICOM facilita a interoperabilidade dos dispositivos que assumem a conformidade, ou seja, facilita: 1) o endereçamento dos comandos de semânticas e dados associados; 2) abordagem da semântica de serviços de arquivos, formatos de arquivos e diretórios de informações necessárias para a comunicação off-line ; 3) explicitamente define os requisitos de conformidade para a implementação do padrão. Além disso, os documentos de conformidade devem especificar informação suficiente para determinar as funções cuja interoperabilidade podem ser esperadas por outros dispositivos que podem pedir conformidade, isto é: 4) operação em um ambiente em rede; 5) estar estruturado para acomodar a introdução de novos serviços, facilitando o suporte para futuras aplicações de imagens médicas; 6) faz uso dos padrões internacionais existentes, sempre que aplicável, e está em conformidade com as diretrizes de documentação estabelecidas para os padrões internacionais. A Figura 1 apresenta o modelo de comunicação geral do padrão, que abrange tanto a comunicação de rede ( on-line ) quanto off-line. A seguir os mecanismos de transporte que podem ser utilizados pelos aplicativos: a) O Serviço de Mensagem DICOM e Serviço de Camadas Superiores provém independência para suportes físicos específicos e protocolos como TCP/IP. b) DICOM Web Service API e HTTP Service : permite o uso de hipertexto comum e protocolos associados para o transporte de serviços DICOM. c) Basic DICOM File Service : fornece acesso a mídia de armazenamento independentemente de formatos de armazenamento de mídia específicos e estruturas de arquivos.

10 Figura 1. Modelo Geral de Comunicação. Fonte: DICOM, Modelagem de Informação e Objetos de Serviço A modelagem de informação do DICOM (parte 3) define a estrutura de informação relacionada a comunicação de imagens médicas e pode ser observada na Figura 2. Uma Information Object Definition (IOD) é um modelo de dado abstrato usado para especificar a classe do objeto do mundo real que compartilha a mesma característica, no entanto, uma IOD não representa uma instância específica do objeto do mundo real. Além disso, é estabelecido dois tipos de Classe de Objetos de Informação: normalizado e composto. O tipo normalizado é uma definição de um objeto de informação que geralmente representa um única entidade no modelo de mundo real DICOM. Quando a instância de um IOD é comunicada, o contexto para aquela instância não é realmente trocado. No entanto, o contexto é providenciado pelo uso de ponteiros relacionados as instâncias das IOD normalizadas. Já o tipo composto é uma definição de um objeto de informação que representa parte de diversas entidades incluídas no modelo de mundo real DICOM. Esta IOD inclui atributos que não advém do objeto do mundo real que ela representa, mas de objetos do mundo real relacionados. Estes objetos do mundo real relacionados providenciam um contexto completo para a troca de informação. Quando uma instância de uma IOD composta é comunicada, este contexto inteiro é trocado entre

11 as entidades da aplicação. O relacionamento entre instâncias de IOD compostas devem ser transmitidas neste contexto de informação. O atributo de uma IOD descreve propriedades de uma instância de um objeto do mundo real. Atributos relacionados são agrupados em módulos que representam um nível alto de semântica documentada no módulo de especificações. Além disso, os atributos são codificados como elementos de dados utilizando regras. A PS3.5 contém um dicionário de dados que especifica o valor da representação e o valor da multiplicidade. Quando múltiplos módulos contendo o mesmo atributo são incluídos em um IOD, os atributos devem ser codificados somente uma vez no elemento de dados. Para comunicação online o Serviço DIMSE permite uma entidade de aplicação DICOM chamar uma operação ou notificação através da rede. Já para a troca de mídias de armazenamento, o Serviço de Armazenamento em Mídia permite a entidade de aplicação DICOM chamar operações relacionadas as mídias de armazenamento. Há dois tipos de Serviços DIMSE mencionados na documentação oficial do DICOM: DIMSE-C e DIMSE-N. O primeiro são serviços de operação aplicáveis somente em um IOD composto, com exceção para C-FIND que pode ser aplicado para instâncias compostas e normalizadas. O segundo são serviços tanto de operação quanto de notificação aplicáveis somente em IOD normalizadas. Já um Grupo de Serviços DIMSE especifica uma ou mais operações/notificações que são aplicados em uma IOD. Uma classe Par Objetos e Serviço ( SOP ) é definida pela união de uma IOD e um Grupo de Serviço DIMSE. Uma classe de definição SOP contém regras semânticas que podem restringir o uso de serviços no Grupo de Serviços DIMSE e/ou atributos da IOD. A seleção de classes SOP é usada por entidades de aplicação em acordo para estabelecer um conjunto de capacidades para suas interações. Essa negociação é feita no tempo estabelecido de associação. Uma negociação estendida permite entidades de aplicação para próximos acordos em opções específicas de uma classe SOP. As classes SOP como estão definidas no modelo de informação DICOM são equivalente na terminologia ISO/OSI para a Classe de Objetos Gerenciada. O padrão DICOM também define dois tipos de classes SOP: normalizada e composta. Classes SOP Normalizadas são definidas como a união de IOD normalizados e um conjunto de Serviços DIMSE-N. Já as Classes SOP Compostas são definidas como a união de IOD compostas e um conjunto de Serviços DIMSE-C. Além disso, especificação de Classes SOP tem um papel central para definir os requerimentos de conformidade DICOM. Isto permite Entidades de Aplicação DICOM a selecionar subconjuntos de nível de subclasses de aplicação bem definidos do padrão DICOM v3.0 para o qual eles podem requerer conformidade. O estabelecimento de associação é a primeira fase de comunicação entre pares de Entidades de Aplicação de acordo com o DICOM. A Entidade de Aplicação devem usar associações estabelecidas para negociar quais Classes SOP podem ser trocadas e como esses dados serão codificados.

12 Uma Especificação de Classe de Serviço define um grupo ou mais de classes SOP relacionados a uma função específica que será feita através das comunicações entre Entidades de Aplicação. Uma Especificação de Classe de Serviço também define regras que permitem a implementação de definições de níveis de conformidade para uma ou mais classes SOP. Aplicações podem ser conformes a classes SOP como Usuário de Classe de Serviço (SCU) ou Provedor de Classe de Serviço (SCP). Essas interações entre pares entidades de aplicação funcionam como modelo cliente/servidor. O SCU age como o cliente, enquanto o SCP age como servidor. Os papéis SCU/SCP são determinados durante o estabelecimento da associação. Figura 2. Principais Estruturas do Modelo DICOM de informação. Fonte: DICOM, Formato de Dados DICOM A estrutura básica de um arquivo DICOM é composta pelo Cabeçalho e pelo Conjunto de Dados e pode ser observada na figura 3. O cabeçalho é constituído pelo preâmbulo com 128 bytes e um prefixo DICOM com 4 bytes. A importância do preâmbulo é facilitar o acesso do arquivo utilizados no DICOM por outros software. Caso o preâmbulo do arquivo não seja utilizado todos os 128 bytes devem conter 00H para ajudar no reconhecimento do preâmbulo. Já os quatro bytes de prefixo precisam receber a string DIMC codificado como as letras maiúsculas da ISO 8859 G0 Character Peoetoire. Ambos os itens do cabeçalho não estão estruturados como um elemento de dados DICOM com uma tag e um tamanho ( Lenght ).

13 Figura 3. Estrutura Básica de um arquivo DICOM. Fonte: Autor (2017). O conjunto de dados DICOM é somente um para o arquivo atuando como uma única instância SOP relacionada a uma única classe SOP e seu respectivo IOD. Casos que contenham mais que um único frame de uma imagem bidimensional, podem ser utilizados IODs próprios para incluir diversos frames. A sintaxe de transferência usada para codificar o conjunto de dados deve ser única e identificada pela Transfer Syntax UID meta-física do arquivo DICOM. Além disso, no conjuntos de dados DICOM não está o seu tamanho. O fim da identificação do arquivo fornecido pelo DICOM File Sevice é a única identificação do final do conjunto de dados. Um conjunto de dados representa uma instância do mundo real, ou seja, um Objeto de Informação. Os elementos dos conjuntos contém os atributos codificados do objeto seguindo o IOD. Os elementos de dados, Pixel Data, Overlays e Curves, e suas interpretações se relacionam a outros elementos. Os conjunto de dados são compostos por elemento de dados que são constituídos por uma Tag, um Value Length, e um Value. A Tag é o identificador dos elementos de um conjunto. Os elementos do conjunto são ordenados de maneira que o valor de suas Tags sejam crescentes. São compostas de um par de inteiros positivos de 16 bits que representam o grupo e o valor do elemento dentro do grupo. Uma Tag somente pode se repetir dentro do Nested Data Sets. Já o Value Length é o campo que representa o tamanho do campo Value. Esse tamanho pode ser indefinido e será escrito com 16 ou 32 bits. O Value é o valor do elemento em si, ou seja, o valor contido no elemento. A constituição desse dado é dado pelo VR, ou seja, o VR defini o que se espera no value. Já o VR ( Value Representation ) para um elemento específico pode ser estabelecido utilizando o Data Dictionary ou ser outro valor do conjunto de dados. O VR está presente em estruturas com Sintaxe de Transferência de tipo Explicit VR Data Element. O elemento, sem VR explícito, pode ser descrito como apresentado na Tabela 1. No entanto, quando o VR é explícito pode assumir duas configurações dependendo do VR expostos na Tabela 2 e na Tabela 3.

14 Tag Número do Grupo Número do Elemento Value Length Value 2 bytes 2 bytes 4 bytes (Value Length) bytes Tabela 1. Elemento de dado com VR implícito. Fonte: Autor (2017). Tag Número do Grupo Número do Elemento VR Value Length Value 2 bytes 2 bytes 2bytes 4 bytes (Value Length) bytes Tabela 2: Elemento de dado com VR explícito com VR diferente de OB,OW,SQ ou UM. Fonte: Autor (2017). Número do Grupo Tag Número do Elemento VR Reservado Value Length Value 2 bytes 2 bytes 2bytes 2bytes = 0x00, 0x00 4 bytes Tabela 3: Elemento de dado com VR explícito com VR igual a OB,OW,SQ ou UM. Fonte: Autor (2017). (Value Length) bytes 6. Como Sistemas de Informação usam DICOM Os PACS ( Picture Archiving and Communication System - Sistema de comunicação e arquivamento de imagens) são sistemas que gerenciam as imagens médicas eletrônicas em conjunto com os Sistemas de Informação em Radiologia (RIS - Radiology Information System ) e de Informação Hospitalar (HIS Hospital Information System ) (MAZZONCINI et. al, 2005). A arquitetura desse sistema está exemplificado na Figura 4. O sistema PAC podem utilizar o padrão DICOM ao dar o prosseguimento do atendimento de um exame que gera imagens, como por exemplo ressonância magnética, ultra-sonografia e tomografia computadorizada. No momento seguinte a aquisição da imagem o profissional de saúde responsável deve digitar as informações relevantes em um ambiente específico, como a identificação do paciente e do exame. Dessa maneira, a imagem e suas informações serão

15 agrupados em um único arquivo junto com uma tag. Este arquivo deve ser do tipo DICOM e deve ser transmitido pela ethernet para o servidor DICOM da instituição de saúde (clínica ou hospital). O CNT ( Central Test Node ), por exemplo, é um servidor DICOM que, ao receber os arquivos do tipo DICOM, armazena em seu banco de dados as informações das tags e os arquivos originais em uma determinada pasta, criada no servidor de armazenamento (MAZZONCINI et. al, 2005). Permitindo assim que quando os arquivos sejam acessados exista a possibilidade de se fazer a comparação entre os dados das diferentes fontes, ganhando, assim, confiabilidade na informação. Estes arquivos são efetivamente integrados ao PAC utilizando a linguagem web e seus protocolos. Portanto, esses dados online, mesmo que na ethernet do HIS (Hospital Information System), podem ser acessados por meio de um applet como o Dicom viewer que é feito em java e visualiza imagens DICOM a partir de um navegador. De acordo com ACR-NEMA (2005) a implementação do servidor de imagens médicas considera a adoção do padrão DICOM, que não apenas define o formato de armazenamento, mas também o protocolo de comunicação entre o servidor e estações clientes. Toda comunicação com o mundo exterior é realizada através da interface DICOM, que faz seu fluxo de dados sobre o protocolo TCP/IP conforme a especificação. Figura 4. Exemplo de arquitetura PACS. Fonte: Savaris ( 2014).

16 7. Conclusão sobre o tema O padrão DICOM, assim como qualquer outro padrão de interoperabilidade, é algo fundamental para que haja comunicação eficiente dos dispositivos envolvidos. Ainda assim, este padrão não é completamente adotado por entidades, principalmente no Brasil. Esse cenário apenas reflete a dificuldade de desenvolvedores em adotar esse padrão devido a sua documentação volumosa e rigorosa, fazendo-os optar por uma estratégia mais simples, não necessariamente mais eficiente. Dessa forma, torna-se necessário o incentivo às pesquisas sobre o assunto com o objetivo de facilitar o momento da implementação. Além disso, também é necessário evidenciar a importância da utilização dos padrões de interoperabilidade. O uso do padrão DICOM na integração RIS/PACS, por exemplo, minimiza o risco de inconsistências, através da redução do número de interfaces entre bases de dados com grande redundância de informação, proporcionando um ambiente de trabalho rápido e seguro para consulta de laudos radiológicos e visualizações de imagens associadas. 8. Referências Bibliográficas SBPC/ML. Tecnologia da Informação em Medicina Laboratorial Posicionamento da SBPC/ML 2014 Interoperabilidade de Sistemas. Sociedade Brasileira de Patologia Clínica/Medicina Laboratorial (SBPC/ML) BRASIL. Ministério da Saúde Disponível em: < Acesso 02/10/2017. BRASIL. UAB 2013 Informática em Saúde Padrões em IS Disponível em: < adroes-em-is.pdf>. Acesso em 16/10/2017. DICOM. Disponível em: < Acesso em: 02/10/2017. ISO. Disponível em: < Acesso em: 02/10/2017. MAZZONCINI, Paulo; CARITÁ, E. C; BENETICTO, A. A; SANCHES, P. R. Integração RIS/PACS no Hospital das Clínicas de Ribeirão Preto: uma solução baseada em web. Radiol Bras. pg SAVARIS, A. Uma proposta de arquitetura de alto desempenho para sistemas PACS baseada em extensões de banco de dados f. Tese de doutorado de Ciências da Computação - Universidade Federal do Paraná, Curitiba, 2014.