Interoperabilidade numa perspectiva Hospitalar

Transcrição

1 Interoperabilidade numa perspectiva Hospitalar Mariana Isabel Ferreira and Nuno Felix Departamento de Informática Universidade do Minho Braga, Portugal Resumo Pretende-se com este artigo descrever a necessidade, conceber e implementar um mecanismo que viabilize a interoperabilidade de dados entre o sistema de informação cliníco-administrativo ICARE-EHR e o universo de sistemas e aplicações que coexistem num ambiente hospitalar. Esta implementação reveste-se de particular importância em virtude de o ICARE-EHR ser um sistema central, devendo como tal permitir interoperabilidade disponibilizando e recebendo informação dos sistemas departamentais de acordo com protocolos standardizados. 1 Introdução Com a disseminação de Tecnologias de Informação e Comunicação (TIC), muitos departamentos hospitalares ou profissionais de saúde individualmente adquiriram software médico ou criaram as suas bases de dados informáticas, de forma a armazenar e gerir registos contendo dados relevantes dos seus doentes. Infelizmente, muitos destes sistemas não foram desenhados de forma a permitir a comunicação entre si, tornando ineficiente a utilização e partilha de informação clínica. Para além deste facto, a multiplicação de sistemas não articulados gera a existência de dados replicados ou contraditórios, e a não utilização de normas de terminologia ou até de identificadores únicos de doentes pode dificultar a sua integração, impossibilitando o acesso a toda a informação existente de um doente. Nesta situação, o custo dos recursos humanos e técnicos necessários para a recolha, integração e armazenamento não automático de informação clínica é elevado. A ideia de um sistema que assente em sistemas de informação previamente existentes, pode ajudar no processo de integração e facilitar a comunicação entre sistemas, sem pôr em risco os dados já existentes ou interferir com as suas actualizações. A interoperabilidade não é simples num ambiente hospitalar e num ambiente de Service Provider, que pretende oferecer uma solução integrada de gestão clínico/administrativa a várias instituições, torna-se ainda mais complexa. Os problemas são semelhantes ao ambiente hospitalar, com contornos muito mais complexos: este sistema, além de conter uma estrutura multi-institucional, terá de interagir com n soluções diferentes para comunicação de informação semelhante. Cada cliente deste sistema será uma realidade única à qual tem de ser dada uma resposta. Por exemplo, uma simples ligação a um sistema de laboratório para comunicação de análises clínicas, implica o envio dos pedidos de

2 2 Interoperabilidade numa perspectiva Hospitalar análises e recepção dos resultados, neste sistema central vai implicar várias interfaces para comunicação de dados, de acordo com o cliente e com a solução específica de cada um: uns têm soluções próprias de laboratório, por aquisição ou desenvolvimento de software e outros têm fornecedores com os quais teremos de interagir. As soluções com as quais se pretende comunicar são, em última instância, uma por cliente. A diversidade de soluções e o estado tecnológico de cada uma delas vai ser muito vasto e diversificado. A comunicação de dados vai, por isso mesmo, ser complexa e obrigar a um sistema simples e robusto que permita a comunicação via vários canais e uma monitorização online. A solução que virá a ser adoptada para o ICARE-EHR será suficientemente genérica para que possa servir e resolver questões semelhantes num sistema hospitalar e portanto acrescida de maior valor e mérito. O projecto consiste em encontrar uma solução ideal de interoperabilidade entre um sistema central, ICARE-EHR, e os diversos sistemas existentes num ambiente hospitalar de modo a permitir a pesquisa e troca de informação através de um processo simples, independente da tecnologia e de baixo custo. Neste artigo identificamos as necessidades de comunicação entre os sistemas envolvidos, quais os standards existentes na área da saúde de troca de informação, como solucionar o problema de interoperabilizar o sistema central ICARE-EHR e descrevemos um teste efectuado com o intuito de mostar a viabilidade da solução encontrada. O artigo começa por apresentar, na Secção 2, o problema e objectivos a atingir com a concretização do projecto descrito. De seguida, na Secção 3, são apresentados os conceitos base de métodos existentes na saúde para troca de informação de modo a fazermos um levantamento das necessidades básicas para a comunicação entre os sistemas num ambiente hospitalar. Após identificarmos as necessidades apresentamos, na Secção 4, as tecnologias investigadas e usadas, qual a arquitectura adoptada na Secção 5 e uma descrição do desenvolvimento efectuado na Secção 6. Finalizamos este artigo, na secção 7, com as conclusões resultantes da concretização do projecto apresentando as dificuldades encontradas e uma síntese do trabalho realizado. 2 Apresentação do Problema, Objectivos Um sistema de informação clínico/hospitalar pode ser descrito como sendo um sistema desenhado para auxiliar na gestão de toda a informação clínica e administrativa da instituição, e melhorar a qualidade da prestação de cuidados de saúde. Tem por objectivo integrar com outros sistemas departamentais já existentes. A CimpleCare, fundada em julho de 2007, é um parceiro clínico com larga experiência na conceptualização de sistemas informáticos clínicos. Surgiu pela necessidade da constante actualização tecnológica e funcional das soluções que as organizações hospitalares adquirem para suporte às suas áreas de negócio. A CimpleCare disponibiliza uma solução, totalmente em ambiente WEB com toda a logística associada à manutenção de sistemas locais e custos associados

3 Interoperabilidade numa perspectiva Hospitalar 3 Figura1. Arquitectura funcional do ICARE-EHR - ICARE-EHR. O ICARE-EHR é uma plataforma central que acompanha todo o processo clínico dos utentes, promove a comunicação e organiza a informação entre os diferentes profissionais. Os benefícios esperados são possuir um sistema moderno e orientado ao novo conceito de utilização de serviços, disponibilizados via internet (SaaS), com a garantia da sua actualidade funcional e tecnológica, associada à alta disponibilidade e escalabilidade, garantindo e salvaguardando a segurança dos dados (armazenamento/comunicação) [12]. A metodologia adoptada de protocolos clínicos melhoram o desempenho e ajustam a prática clínica às melhores práticas. O ICARE-EHR contém ferramentas activas para apoio à decisão clínica, disponibilizando a melhor e mais adequada informação, promovendo uma melhor prática clínica com menores custos. Cumpre normas de segurança tais como: autenticação segura, passwords encriptadas, perfis de acesso na horizontal e na vertical, auditoria e log de acessos. O SI ICARE-EHR define um processo clínico electrónico composto pelas seguintes áreas [12] esquematizadas na figura 1: Área clínica: área de interacção com os médicos, técnicos de saúde, enfermeiros e directores clínicos; permite efectuar procedimentos no âmbito da consulta: registo clínico das consultas, manutenção dos programas de saúde, prescrições e manutenção da informação do utente; Área administrativa: contém toda a informação para gestão administrativa: agendas, marcações, facturação e gestão dos relatos médicos; BackOffice: permite fazer a gestão do sistema e dos perfis de acesso.

4 4 Interoperabilidade numa perspectiva Hospitalar A necessidade de interoperabilidade do ICARE-EHR com outros sistemas de informação clínicos exige a capacidade de interpretação de diversos padrões de mensagens standard, ou não, no âmbito clínico bem como despoletar acções no sistema consequentes de acções realizadas nos sistemas externos e viceversa. Pretende-se que a comunicação seja assente em protocolos conhecidos de forma a facilitar o mecanismo de integração com os sistemas existentes. Por outro lado deve ter a capacidade de receber mensagens não protocoladas, típicas dos legacy application existentes nos hospitais, operando as filtragens e transformações necessárias ao seu processamento. É objectivo que sejam desenvolvidos alguns interfaces já identificados: Comunicação de dados de facturação com a seguradoras e subsistemas de saúde; Pedidos de meios complementares de diagnósticos e a recepção dos resultados, onde estão incluídos diferentes serviços e diferentes tipologias de resultados: Análises Clínicas, Anatomia Patologia e Exames de Imagiologia. É fundamental que logo que um resultado de um exame esteja disponível, ele seja integrado na plataforma ICARE-EHR. Comunicação referente às prescrições electrónicas efectuadas pelos clínicos à Administração Central dos Serviços de Saúde. 3 Conceitos Base O objectivo central é providenciar um meio de comunicação de uma forma standard de modo a que qualquer equipamento e/ou sistema de informação consiga trocar dados, fazer pedidos ou executar operações no sistema ICARE-EHR. A possibilidade de manipular a informação electronicamente, trouxe como consequência a necessidade de estabelecer um protocolo standard de mensagens nos sistemas informáticos da área da saúde. Assim, diversas organizações e grupos de pesquisa têm-se reunido nos últimos anos para propôr regras que viabilizem a interoperabilidade de sistemas informáticos. A standardização das mensagens é necessária devido a diversos factores, dos quais se pode destacar: Diversificação de conceitos e termos; Multiplicidade de plataformas de hardware e software distintas; Necessidade de pesquisa e comunicação de informação; Utilização viável de sistemas de apoio à decisão. 3.1 Interoperabilidade A interoperabilidade é a Habilidade de 2 ou mais sistemas ou componentes de trocar informação e usar a informação que foi trocada [14]. Interabilidade é a capacidade de comunicar e executar programas através de várias unidades funcionais utilizando-se linguagens e protocolos comuns. [9] São identificados dois níveis principais de interoperabilidade de informações que se pretende obter com a concretização deste projecto:

5 Interoperabilidade numa perspectiva Hospitalar 5 Interoperabilidade funcional: interacção de dois ou mais sistemas (equipamentos, sistemas de informação, bases de dados) para trocar informações de acordo com um conjunto de regras definidas (por exemplo o correio electrónico - ). A interoperabilidade funcional é essencial para o projecto uma vez que o objectivo principal é a interacção e transmissão de informação entre o sistema ICARE-EHR e outros sistemas informáticos e equipamentos existentes num ambiente hospitalar; Interoperabilidade semântica: capacidade de sistemas de compartilharem informações compreendidas através da definição de conceitos de domínio. É o significado ou semântica das informações de diferentes origens, é solucionada através de ferramentas comuns de representação da informação, como classificação e ontologias. (por exemplo protocolos de comunicação de programas de conversação online). Pretende-se obter interoperabilidade semântica através do uso de protocolos standard existentes nos sistemas informáticos num ambiente hospitalar de modo a conseguir interpretar as mensagens recepcionadas no ICARE-EHR e enviar mensagens de modo a que os outros sistemas e equipamentos as interpretem. 3.2 Protocolos Standard A comunicação entre os sistemas de informação em saúde deve seguir os protocolos standard de modo a conseguir interoperabilidade entre os diversos sistemas informáticos e equipamentos médicos existentes num ambiente hospitalar. [9] Foram identificados os seguintes protocolos standard utilizados pelos sistemas informáticos/equipamentos médicos num ambiente hospitalar: DICOM (Digital Imaging and Communications in Medicine): protocolo vocacionado para imagens médicas de mensagens provenientes do PACS (Sistema de Comunicação e Arquivo de Imagens); X12: protocolo adoptado por sistemas informáticos de seguradoras de saúde; TISS (Troca de Informação em Saúde Suplementar): protocolo usado em sistemas informáticos de assistência à saúde de carácter clínico e administrativo; HL7 (Health Level Seven): protocolo de transmissão de mensagens de equipamentos médicos, sistemas administrativos e bases de dados médicas. Sendo este protocolo de elevada importância, devido à amplitude de sistemas que o adoptam e constante evolução, é dado um maior foco com uma descrição mais detalhada do mesmo. A comunicação entre o ICARE-EHR e os sistemas informáticos e equipamentos existentes num ambiente hospitalar deve suportar o envio e recepção de mensagens para/dos protocolos enumerados como podemos ver esquematizado na figura 2. DICOM - Digital Imaging and Communications in Medicine O padrão DICOM foi desenvolvido sob orientação da NEMA (National Electric Manufacturers Association), associação americana de produtores de equipamentos

6 6 Interoperabilidade numa perspectiva Hospitalar Figura2. Comunicação entre sistemas de informação em saúde eléctricos. Foi baseado num antigo padrão chamado ACR-NEMA, desenvolvido pela organização American College of Radiology em conjunto com a NEMA. [1] É um protocolo para gestão, armazenamento, impressão e transmissão de imagens médicas. A sua especificação define um formato de ficheiros para comunicação na rede. É desenvolvido para operação em redes tipo TCP/IP. Tem como público alvo os médicos que trabalham directamente com diagnósticos por imagens: radiologia, tomografia, ultra-som, ressonância magnética e oftalmologia. Este padrão proporciona interoperabilidade entre equipamentos de diagnóstico, servidores, estações de trabalho e impressoras, através da unificação da forma de comunicação e armazenamento das imagens recolhidas. Todos estes dispositivos formam o Sistema de Comunicação e Arquivo de Imagens (PACS). X12 A organização Accredited Standards Comittee desenvolveu o protocolo de comunicação ASC X12 para a comunicação entre fornecedores de serviços de saúde (por exemplo, hospitais) e o estado ou os planos de saúde. É utilizado no seguinte âmbito: quando um paciente faz o requerimento de um serviço (exame, por exemplo) num hospital, esta instituição envia um pedido de autorização à seguradora do paciente através de mensagens ASC X12. [10] TISS - Troca de Informação em Saúde Suplementar O padrão TISS é um padrão definido no Brasil pelo Ministério da Saúde, através da ANS (Agência Nacional de Saúde Suplementar), para a troca de informação sobre o atendimento prestado aos beneficiários, entre hospitais ou clínicas e as operadoras de plano privado. O objectivo do padrão TISS é atingir a compatibilidade e interoperabilidade funcional e semântica entre os diversos sistemas independentes para fins de avaliação da assistência à saúde (carácter clínico, epidemiológico ou administrativo). [13] Este padrão é categorizado, da seguinte forma: conteúdo e estrutura, representação de conceitos em saúde, comunicação, segurança e privacidade.

7 Interoperabilidade numa perspectiva Hospitalar 7 Este padrão está a ser actualizado de modo a ser adequado ao padrão HL7 v3.0 como base para troca de mensagens. [13] HL7 - Health Level Seven O HL7 é um padrão proprietário, desenvolvido através de uma organização sem fins lucrativos denominada Health Level Seven fundada em 1987 e certificada pelo ANSI(American National Standards Institute) para desenvolver padrões para a área da saúde desde [2] O nível sete refere-se ao nível mais alto - nível aplicacional - do modelo de comunicações para interconexão entre sistemas da organização internacional de standards (ISO - International Organization for Standardization) [6]. HL7 é um protocolo internacional para intercâmbio de dados electrónicos em todos os ambientes da área da saúde, integrando informações de natureza clínica e administrativa. Os membros que constituem o HL7 são programadores, vendedores, consultores, instituições governamentais, investigadores e utilizadores. Tem como preocupação identificar os diferentes anseios de cada grupo, assegurando os requisitos necessários de uniformidade e equidade, com qualidade e consistência. O HL7 tem como missão: Prover sistemas e padrões relacionados para a troca, integração, partilha e recuperação de informação electrónica na saúde, para apoio da prática médica e administrativa, permitindo um maior controlo dos serviços de saúde; Criar metodologias, padrões e directrizes que sejam flexíveis, viáveis economicamente e que permitam a interoperabilidade e partilha de informações clínicas armazenadas electrónicamente. O HL7 tem como finalidade: Desenvolver e publicar padrões aprovados pela ANSI; Promover o uso de standards dentro dos domínios da área da saúde e os controladores e reguladores a nível internacional; Promover a formação da utilização de standards; Prover serviços de certificação; Prover metodologias para a criação de extensões a partir das bases dos standards; Encorajar a aceitação e uso do HL7 internacional com a criação de afiliações internacionais. A versão corrente do HL7 é a versão 3 baseada em metodologias formais de desenvolvimento e orientado a objectos (OO). Foca-se na interoperabilidade semântica. [2] HL7 v2.x As limitações principais reconhecidas nas versões 2.x são: Morosidade (meses) da sua implementação; Não existe um processo rigoroso para a sua execução; Demasiadas opções e situações ambíguas;

8 8 Interoperabilidade numa perspectiva Hospitalar Não é um padrão de interoperabilidade, mas apenas de intercâmbio. Nestas versões, as mensagens são compostas por campos de comprimento variável e separados por um caracter de separação (usualmente ). Cada tipo de dados tem sua forma de codificação específica e as suas condições para repetição. Os campos são agrupados segundo lógica pré-estabelecida, numa estrutura denominada de segmento. Cada segmento começa com um código de três caracteres que define sua função. Vários segmentos, divididos pelos respectivos separadores (usualmente <cr>, caracter de mudança de linha), compõem uma mensagem. [2] HL7 v3.0 Mais do que uma nova versão, o padrão HL7 v3.0 representa uma mudança de paradigma. A versão 3 é baseada em metodologia formal de desenvolvimento: É orientado a objectos (OO); Usa os princípios da Universal Modelling Language (UML). Uma das vantagens que se aponta a versão 3 é a redução do esforço de implementação e viabilização de implementação de processos de qualidade. O modelo fundamental para a normalização do fluxo da troca de mensagens entre dispositivos é o RIM (Reference Information Model). A versão 3 suporta o CDA (Clinical Document Architecture), que deriva o seu conteúdo semântico do partilhado HL7 RIM implementado em XML. [11] O RIM abrange todos os processos de atendimento ao paciente, além de aspectos administrativos e financeiros. Apresenta processos bem definidos para especificação de mensagens e oferece uma definição robusta para os tipos de dados. Define procedimentos para associar conceitos presentes nas informações tratadas aos atributos definidos no modelo. O HL7-CDA é a primeira especificação derivada do modelo de informação do HL7 sendo é um padrão que especifica a estrutura e a semântica de um documento clínico. Trata-se de um padrão para representação de informações contidas originalmente em documentos médicos, utilizando estruturas baseadas em linguagem XML, voltadas ao armazenamento em sistemas de informação hospitalares. [11] Um documento estruturado através do CDA é habilitado a conter textos, imagens, sons e outros conteúdos multimídia. Tem as especificações básicas definidas pelo RIM. Terminologias e interpretações padrão das tags XML definidas na estruturação de um documento são esclarecidas no modelo para evitar ambiguidades. [11] 4 Tecnologia Usada O desafio proposto exige que o ICARE-EHR consiga comunicar e interagir com outros sistemas e equipamentos existentes num ambiente hospitalar através de protocolos standardizados tais como HL7, DICOM, X12, etc. A interpretação de cada um destes protocolos exige um desenvolvimento complexo e moroso o que

9 Interoperabilidade numa perspectiva Hospitalar 9 torna o seu custo elevado. Foram ponderadas várias soluções de modo a determinar qual seria a mais simples, mais configurável e com menos custos associados. Para além do desenvolvimento e implementação de código no ICARE-EHR uma outra solução consiste na integração de uma ferramenta open-source, com o sistema ICARE-EHR e outros sistemas clínicos de modo a viabilizar a comunicação padronizada e permitir a partilha de informação e o despoletar de acções por parte do ICARE-EHR no seu próprio sistema bem como nos outros sistemas clínicos. A pesquisa efectuada sobre tecnologias e ferramentas existentes, teve como principais critérios: independência da plataforma; conformidade com os protocolos existentes; conectividade aos RDBMS conhecidos; ser open-source. As ferramentas de envio e recepção de mensagens para os sistemas de informação em saúde encontradas de modo a tentar satisfazer os requisitos foram: Mirth; Cloverleaf; Iguana; HL7Connect; NeoIntegrate. A solução que melhor satisfaz os requisitos é a integração da ferramenta Mirth por ser a única ferramenta open-source extensível, com fácil configuração e suporte de diferentes protocolos de mensagens para estabelecer a comunicação entre os sistemas e equipamentos hospitalares e o ICARE-EHR. 4.1 Mirth O Mirth é uma ferramenta independente da plataforma, open-source, que permite o envio bi-direccional de mensagens em diferentes protocolos standard entre sistemas e aplicações sob múltiplos modos de transporte. Com a utilização de uma ferramenta de serviços bus o Mirth permite a filtragem, transformação e encaminhamento de mensagens de acordo com regras configuradas pelo utilizador. A criação de meios de comunicação para sistemas existentes tona-se fácil através de uma interface gráfica e com a configuração de canais com a ajuda de wizards que permitem associar aplicações com os componentes do motor do Mirth [7]. A arquitectura do Mirth é baseada em canais para conectar os sistemas fazendo uso do protocolo standard de mensagens. Os canais consistem em pontos de recepção ou envio, filtros e transformadores. Pode-se associar múltiplos filtros e transformadores a um canal. A interface gráfica do Mirth permite a reutilização da configuração dos filtros e dos transformadores em múltiplos canais. Os pontos dos canais são usados para configurar conecções e detalhes dos protocolos. Os pontos de recepção são usados para designar o tipo de listener das

10 10 Interoperabilidade numa perspectiva Hospitalar mensagens, tal como TCP/IP ou web services. Os pontos de envio são usados para designar os destinos das mensagens outgoing tal como uma base de dados. O Mirth permite registar todas as transações efectuadas de modo a verificar o seu correcto funcionamento. É extensível ao ponto de permitir criar e/ou usar filtros e perfis de validação e transformar as mensagens standardizadas mapeando segmentos das mesmas para fazer queries a bases de dados enviar mensagens por ou transformá-las em xml num formato desejado de modo a ser interpretado pelas funcionalidades do sistema. O Mirth pode ser configurado para receber e enviar mensagens standardizadas e conectar-se através de uma variedade de protocolos tais como TCP (transmission control protocol), bases de dados, ficheiros, s, FTP(file transfer protocol), SOAP (simple object access protocol) e JMS(java message service). Os benefícios de usar uma ferramenta como o Mirth são: Open-Source: O Mirth é um projecto open-source (Certificado pela OSI) que ajuda a alavancar outros projectos open-source tais como Mule, HAPI e Apache Rhino; Segurança: O facto de o mirth ser uma ferramenta open-source faz com que tenha sido testado e revisto por múltiplos programadores da comunidade open-source; Valor: O Mirth é livre para ser usado sem qualquer licença ou taxas. Providência um conjunto de sistemas para a saúde que podem ser descarregados e instalados no Mirth; Extensível: A arquitectura core do Mirth pode ser fácilmente extendida para se ajustar às funcionalidades dos sistemas no qual se pretende integrar. É assegurado, por ser uma ferramenta open-source, que vai estar sempre actualizado com os últimos avanços dos serviços na área da saúde; Incorporável: O Mirth pode ser fácilmente incorporado numa variedade de aplicações; Comprovado: O Mirth já processou milhares de mensagens e está em uso em centenas de ambientes em produção. 4.2 Cloverleaf O motor de integração cloverleaf forma uma tecnologia core, apropriada para muitas indústrias, que estão a substituir o desenvolvimento de interfaces pontoa-ponto com uma arquitectura configurável. O motor gera uma plataforma com alta performance de troca de mensagens que suporta conexões tanto síncronas e assíncronas a uma série de programas, bases de dados, objectos e protocolos [3]. A configuração é efectuada gráficamente o que permite um rápido desenvolvimento da lógica de fluxos para direccionar, modificar e dar suporte a regras de integração de negócio. O Cloverleaf gere eficientemente a comunicação de dados entre múltiplos sistemas com suporte para protolocos standard, comunicação com segurança, transformação das mensagens, connectividade a bases de dados e a web services. Não é uma ferramenta open-source nem permite a extensibilidade de configuração de transformadores de mensagens standardizadas.

11 Interoperabilidade numa perspectiva Hospitalar Iguana O motor de integração Iguana HL7 foi concebido de forma a tornar excepcionalmente fácil de configurar e manter interfaces HL7. É uma solução simples e efectiva que permite aos sistemas de informação em saúde, bem como bases de dados, trocar informação fácilmente fazendo uso do protocolo standard HL7. [5] É uma solução especialmente concebida para direccionar, transformar e mapear mensagens HL7. A solução tem a habilidade de enviar mensagens provenientes de uma única origem para múltiplos destinos de uma forma viável, coordenada e selectiva através de critérios definidos pelo utilizador. A transformação de mensagens HL7 é fácilmente configurada de modo a transformar o output de um sistema para ser entregue como input a um outro sistema tal como este espera receber a mensagem HL7. A solução Iguana fácilmente lê mensagens provenientes de bases de dados assim como escreve mensagens provenientes de outros sistemas em bases de dados. As vantagens da utilização da solução Iguana são: Fácilmente configurável: permite a configuração de canais de comunicação através de uma interface gráfica; Versátil: é uma solução independente da plataforma, com suporte de ligação a múltiplas bases de dados; Comprovado: Iguana ganhou um prémio de interface engine pela American Telemedicine Association. Não é uma ferramenta open-source e suporta apenas o protocolo HL HL7Connect HL7Connect é um motor de interfaces de transmissão de mensagens HL7 entre aplicações eliminando a necessidade de comunicação directa entre as aplicações. Facilita a gestão de múltiplos sistemas que transmitem mensagens HL7 em múltiplos formatos tal como TCP/IP e ficheiros. As mensagens podem ser recebidas ou enviadas, armazenadas ou redireccionadas, validadas ou manipuladas. As mensagens armazenadas podem ser visualizadas, interpretadas, tabuladas, reenviadas, copiadas ou apagadas com o uso do editor de mensagens do HL7Connector [4]. Providência todas funcionalidades necessárias pelas grandes organizações de saúde. Suporta comunicação via múltiplos protocolos de transporte e suporta a transformação de mensagens. Corre como um serviço do sistema operativo windows. Os dados são armazenados numa base de dados. A administração e monitorização do HL7Connect é efectuada via um interface web. As vantagens da utilização do HL7Connect são: Armazena e redirecciona mensagens; Suporta múltiplas camadas de transporte de mensagens; Permite a manipulação de mensagens;

12 12 Interoperabilidade numa perspectiva Hospitalar Efectua notificação de eventos; É fácilmente configurável via uma interface web; Suporta mensagens HL7. Não é uma ferramenta open-source e suporta apenas o protocolo HL NeoIntegrate A solução NeoIntegrate permite configurar interfaces de uma forma simples, construir uma lógica de dados rápidamente e assegurar qualidade com a construção de testes na solução. Trabalha produtivamente com vários formatos de dados: HL7, XML, CSV, etc. O NeoIntegrate permite uma gestão das interfaces, orientada a perfis de utilizadores, com acessos restritos à transmissão dos dados. Permite efectuar uma monitorização das ligações das interfaces configuradas [8]. As vantagens da utilização do NeoIntegrate são: Aumenta a produtividade com a construção e gestão de interfaces de um modo fácil e rápido; Permite validar e testar as interfaces e mensagens HL7; Efectua notificação de eventos; Assegura a transação de dados críticos de pacientes sem a necessidade de configuração complexa ou manutenção intensiva ou um ambiente clustering; Permite a exportação das configurações das interfaces para ambientes em produção. Suporta mensagens HL7 e a ligação a bases dados; Permite os protocolos de connecção sobre TCP/IP, LLP, ficheiro e HTTP. Não é uma ferramenta open-source e suporta apenas o protocolo HL7. 5 Arquitectura A Arquitectura da solução consiste num sistema de comunicação por protocolos entre diferentes aplicações e sistemas de informação, que utilizam uma Gateway (Mirth) para troca de informação. Em cada sistema terminal é implementado um (ou vários) processo(s) de (des) codificação e entrega/recepção ao meio de transporte de rede, por forma a tratar a informação que é enviada/recebida do Mirth. O Mirth interpreta mensagens de acordo com os protocolos HL7, DICOM, X12, assim como documentos estruturados em XML, ficheiros de texto e PDF. No servidor Mirth são criados os canais apropriados para filtrar, validar, transformar e reencaminhar a informação recebida dos sistemas origem de acordo com a configuração dos canais. A implementação da arquitectura tal como a vemos na figura 3 permite-nos obter interoperabilidade semântica bem como funcional. Desta forma o sistema ICARE-EHR permite a interacção, pesquisa e transmissão de informação para com os sistemas e equipamentos existentes num ambiente hospitalar.

13 Interoperabilidade numa perspectiva Hospitalar 13 Figura3. Arquitectura Figura4. Interface Web 6 Descrição do desenvolvimento O desenvolvimento consistiu em criar um ambiente de teste no qual provamos a interoperabilidade funcional e semântica através do estabelecimento de comunicação entre uma interface e o sistema ICARE-EHR através da internet. Pretende-se implementar um exemplo de pesquisa de informação de utentes na base de dados do sistema ICARE-EHR com transmissão de mensagens no protocolo HL7. A interface com o utilizador consiste num GUI Web com um formulário de campos de preenchimento de informação do utente a pesquisar. O facto de o interface ser Web deve-se a questões de simplicidade de utilização. Quando o formulário é submetido a informação preenchida é transformada numa mensagem para enviar ao Mirth. Podemos ver a interface na figura 4. No Mirth são efectuadas as configurações do canal necessário para receber o pedido, transfomar os dados e efectuar a pesquisa e enviar uma resposta tal como podemos ver na figura 5: 1. Conectores do sistema origem - interface web - responsável por mapear a mensagem recebida em variáveis locais do mirth; 2. Transformador desenvolvido em Java responsável por efectuar a query à base de dados do ICARE-EHR e estruturar a informação, resultante da query efectuada, em XML e numa mensagem HL7; 3. Conectores das interfaces destino: (a) Base de dados ICARE-EHR para registo de mensagens numa tabela de base de dados do utilizador Mirth, que se destina ao controlo das

14 14 Interoperabilidade numa perspectiva Hospitalar Figura5. Configuração dos canais no Mirth Figura6. Resposta em HL7 registada na consola mensagens e armazenamento de metadados, de forma a guardar todos os pedidos efectuados; (b) Interface web via TCP responsável por enviar uma mensagem em HL7 para dar como resposta à pesquisa efectuada; (c) com mensagem estruturada em XML da resposta obtida. A mensagem HL7 enviada para a interface web pelo mirth é registada na linha de comandos como podemos ver na figura 6 com toda a informação correspondente aos utentes pesquisados. No GUI web a mensagem mostrada ao utilizador está estruturada em xml tal como é apresentado na figura 7. A sequência de um pedido de pesquisa de informação de utentes ao sistema ICARE-EHR passa por o utilizador submeter a pesquisa com a informação do utente a pesquisar na interface web, encarregando-se esta de enviar o pedido para um canal do mirth. O mirth por sua vez, através do transformador do canal, efectua uma query à base de dados do sistema ICARE-EHR para obter a informação dos utentes de acordo com os dados recebidos que funcionam como filtros da query. A resposta da query é estruturada em XML e em HL7 e enviada para os destinos configurados no canal: base de dados ICARE-EHR para registar

15 Interoperabilidade numa perspectiva Hospitalar 15 Figura7. Resposta à pesquisa de utentes na interface web Figura8. Diagrama de sequência numa tabela de auditoria; via TCP para o cliente web; via . Podemos constatar a sequência no diagrama 8. 7 Conclusão A interoperabilidade num sistema hospitalar exige a comunicação entre diversos interfaces com métodos de comunicaçãao distintos. É necessário identificar os sistemas envolventes e solucionar o problema da comunicação entre eles. O estudo dos protocolos existentes na área da saúde permitiu-nos identifcar as necessidades de como estabelecer comunicação e trocar informaçãao entre os diversos sistemas. Torna-se imprescindível compreender os protocolos para compreendermos como receber e enviar informação através do ICARE-EHR. A solução a encontrar tinha de compreender os protocolos standard existentes

16 16 Interoperabilidade numa perspectiva Hospitalar num ambiente hospitalar e conseguir estruturar a sua informação de modo a efectuar ao ICARE-EHR os pedidos dos outros sistemas com a informação fornecida de modo a que este os entendesse e de igual modo os outros sistemas recebessem a informação e pedidos do ICARE-EHR num formato que compreendessem. Num ambiente empresarial é essencial a pesquisa de uma solução viável que satisfaça requisitos como não ser moroso de desenvolver e implementar; simplicidade na sua configuração e ter custos associados baixos. Estes requisitos levaram a que a solução adoptada, de modo a solucionar o problema de tornar o sistema ICARE-EHR interoperável, fosse conseguir encontrar e tirar partido de uma ferramenta open-source, independente da plataforma e que conseguisse receber/enviar, interpretar e transformar mensagens nos protocolos standard dos sistemas informáticos e equipamentos médicos existentes num ambiente hospitalar. Efectuamos uma pesquisa de ferramentas que satisfizessem estes requisitos e a ferramenta encontrada que melhor se adequou ao nosso problema foi o Mirth. O Mirth é uma ferramenta open-source, independente da plataforma, com uma arquitectura baseada em canais que permite o envio bi-direccional de mensagens em diferentes protocolos standard entre sistemas e aplicações sob múltiplos modos de transporte. Com a integração de uma ferramenta com arquitectura baseada em canais, canais de comunicação de interfaces, é viável estabelecer a comunicação entre os sistemas e a interpretaçãao dos protocolos torna-se simples através da configuração desses mesmos canais. Desenvolvemos um teste em que estabelecemos a comunicação de uma interface web que efectua o pedido de informação de utentes à base de dados do ICARE- EHR usando a ferramenta Mirth como tradutor o que viabilizou a aplicabilidade da ferramenta Mirth como sendo a solução a implementar para tornar o sistema informático ICARE-EHR interoperável. A implementação desta solução num ambiente hospitalar implica uma configuração inicial de canais, bem como quando algum sistema entra nesse ambiente obriga a uma nova configuração de canais de modo a determinar quais as necessidades de comunicação dos sistemas: Determinar que pedidos irão ser efectuados ao/para o(s) sistema(s); Identificar a sintaxe e o modo de envio das mensagens pedido e resposta; Identificar quando temos de interagir com o(s) sistema(s). Estas tarefas mostram-nos que esta não é a solução ideal. A solução ideal de tornar o sistema ICARE-EHR interoperável implicaria que a integração num ambiente hospitalar de qualquer sistema informático fosse plug and play, ou seja, sem ser necessário efectuar o levantamento das necessidades de cada sistema, começando os sistemas a interagir de imediato. Referências 1. Dicom, página institucional Health level seven, hl7.

17 Interoperabilidade numa perspectiva Hospitalar Healthvision cloverleaf, cloverleaf integration services. com. 4. Hl7 connect Interfaceware, iguana - hl7 integration engine. iguana.html. 6. Iso, página oficial do grupo de discussão iso tc Mirth project, open source cross-plataform hl7 interface engine. mirthproject.org. 8. Neotool - heathcare integrated, neointegrate. neointegrate. 9. Wikipédia, a enciclopédia livre X12, página institucional do protocolo asc x Committee ballot 1 - hl7 version 3 standard: Transport specification - web services profile, release 2. transport/transport-ebxml.htm, Maio Icare-ehr, cimplecare presentation A. N. de Saúde Suplementar. Padrão tiss - troca de informações em saúde suplementar. Technical report, Ministério da Saúde, I. of Electrical and E. E. Staff. IEEE Standard Computer Dictionary: A Compilation of IEEE Standard Computer Glossaries. IEEE Computer Society Press, 1990.