iPOINTER: Um sistema multiagente para a integração de fontes de
dados clínicos em ambientes hospitalares
Ilídio Castro Oliveira
Instituto de Eng.ª Electrónica e Telemática de Aveiro (IEETA), 3810-193 Aveiro, Portugal
ioliv@ieeta.pt
Orlando Belo
Departamento de Informática, Universidade do Minho, 4700-320 Braga, Portugal
obelo@di.uminho.pt
João Paulo Cunha
Departamento de Electrónica e Telecomunicações, Universidade de Aveiro, 3810-193 Aveiro, Portugal Instituto de Eng.ª Electrónica e Telemática de Aveiro (IEETA), 3810-193 Aveiro, Portugal
jcunha@det.ua.pt
Resumo
O iPOINTER é um sistema de agentes cooperativos que trabalham pró-activamente na in-tegração de informação clínica, em cenários hospitalares. Os agentes do iPOINTER, espe-cializados num tipo de fonte de informação, classe de dados ou papel na comunidade, co-municam numa linguagem de alto nível para estabelecer sinergias e, colectivamente, cons-truir vistas unificadas que replicam a informação dos doentes, fragmentada por vários sis-temas médicos distribuídos. O utilizador estabelece então diálogos com um tipo particular de agentes de interface que satisfazem os inquéritos de forma imediata, mesmo quando a resposta é composta por dados provenientes de várias fontes. A implementação dos agentes segue uma aproximação incremental, em que cada novo agente especializa um conjunto de comportamentos comuns e implementa apenas os serviços específicos de aplicação associ-ados. Em termos gerais, este artigo apresenta as características e funcionalidade principais do sistema, dando particular ênfase aos diversos tipos de agentes utilizados nos processos de integração de fontes de dados clínicos e à forma como estes foram implementados e in-tegrados no sistema.
Palavras-chave: Sistemas multi-agente, Agentes de Software, Integração de informação distri-buída, Processo Clínico Electrónico, Sistemas de Informação Hospitalares.
1 Introdução
As infra-estruturas de informação hospitalar actuais comportam, tipicamente, uma grande diver-sidade de sistemas computorizados para suportar a riqueza de métodos e a própria estrutura descentralizada da prestação de cuidados de saúde [Bemmel e Musen 1997]. A proliferação de sistemas médicos deu origem à coexistência de repositórios de dados digitais nos hospitais, contendo elementos estruturados convencionais e classes de dados inovadoras (como o sinal biológico e a imagem médica). É fácil constatar que o “novo” processo clínico do doente tende a ser electrónico e se encontra fragmentado por vários sistemas, distribuídos ao longo das insta-lações da organização (Figura 1).
O acréscimo significativo da quantidade de informação clínica do doente armazenada em repo-sitórios digitais não significa um aumento igualmente importante da informação disponível nas estações de trabalho. Na verdade, o estado das implementações actuais caracteriza-se pela
for-mação de “ilhas de autofor-mação”: existe um elevado número de sistemas clínicos que operam de forma desconexa entre si, inviabilizando uma exploração comum e integrada da informação existente [OTA 1995; Reynolds e Wejerfeld 2000].
Infra-estrutura de informação da organização Hospitalar
Processo Clínico Electrónico do doente
Figura 1– Alguns componentes do Processo Clínico Electrónico na infra-estrutura computacional emergente.
Face à dispersão e heterogeneidade dos sistemas, o clínico necessita de meios e ferramentas eficazes que lhe permitam aceder, de forma transparente e holística, ao património fragmentado de dados do doente. Para o utilizador clínico, deveria ser simples aceder a estes recursos disper-sos, como se de uma única base de dados, mais completa, se tratasse.
O sistema iPOINTER visa precisamente ajudar os clínicos a “navegar” no universo de informa-ção clínica digital já disponível, através de uma plataforma de explorainforma-ção unificada, abstraíndo a heterogeneidade de sistemas e protocolos de operação subjacentes (de acordo com a arquitec-tura discutida em [Oliveira et al 2000]). Para isso, o iPOINTER expõe para os utilizadores um modelo de informação unificado e apresenta tempos de resposta curtos, isolando os profissio-nais clínicos do estado de disponibilidade, variações de desempenho, localização e protocolos de acesso das fontes subjacentes.
O restante corpo deste artigo está organizado da seguinte forma: na secção 2, descrevemos a aplicação do iPOINTER na integração de informação num serviço de Neurofisiologia clínica; na secção 3, caracterizamos a organização funcional do sistema e o papel de cada agente na comu-nidade; na secção 4, descrevemos os principais processos de integração de informação; a secção 5 aborda alguns aspectos específicos de implementação.
2 Cenário de aplicação: o Serviço de Neurofisiologia
A integração de toda a informação clínica disponível nos sistemas espalhados por um Hospital não é uma tarefa fácil, estando claramente bem para além dos objectivos do iPOINTER. O âmbito natural de aplicação do sistema corresponde às necessidades de um departamento ou serviço clínico. A este propósito, o Serviço de Neurofisiologia do Hospital Geral de Santo An-tónio (SN-HGSA) constitui um bom exemplo da utilização combinada de tipos de informação multidisciplinares na rotina diária, com origem em diferentes sistemas [Cunha et al 1993]. O SN-HGSA colabora com as outras especialidades médicas principalmente através da realiza-ção e interpretarealiza-ção de exames (e.g.: electroencefalogramas, electromiografias, potenciais evoca-dos) e auxilia no diagnóstico de patologias neuro-fisiológicas (e.g.: epilepsia, doenças cérebro-vasculares, traumatismos craneo-encefálicos, doenças de sono, patologias neuromusculares). Para suportar a prática clínica, a infra-estrutura de informação do serviço integra um numeroso conjunto de sistemas computorizados e equipamentos digitais orientados para a obtenção e armazenamento de informação relativa aos doentes (já notado em [Cunha 1995]). O leque das
classes de dados trabalhadas neste serviço engloba não só informação estruturada, mas também tipos de dados inovadores e multimédia, como o sinal biológico, a imagem médica e exames de medicina nuclear.
A Tabela 1 apresenta quatro fontes de informação distintas que, apesar de relacionadas ao nível dos conteúdos, têm sido utilizadas de forma independente. O facto de os sistemas associados serem autónomos e provenientes de diferentes fornecedores faz com que não partilhem dados e utilizem repositórios próprios. Com a utilização do iPOINTER, pretende-se reunir os objectos de dados identificados (segunda coluna) sob uma vista integrada, relacionando os fragmentos existentes nos quatro sistemas.
Sistema Objectos de dados extraídos Tecnologia de implementação
LINe Dados demográficos dos doentes Requisições de exames Relatório de interpretação Cabeçalhos dos relatórios de EEG
Microsoft SQL Server
SBI Onyx / EEG Information System
Cabeçalhos dos relatórios de EEG EEG digital
Corel Paradox; flat files de sinal biológico em formato proprietário
Sistema de Informação Hospi-talar
Dados demográficos dos doentes Oracle Server
Arquivo de Magnetic
Resonan-ce Image (MRI)
Imagens de exames de MRI Ficheiros de imagem. Uma série de tomogramas pode constar num único ficheiro ou dar origem a uma sequência de ficheiros individuais.
Tabela 1– Fontes de dados seleccionadas para integração.
3 Organização geral do sistema iPointer
3.1 Descrição geral
Uma possível configuração do iPOINTER é ilustrada na Figura 2, em que o âmbito dos proces-sos de integração e exploração de informação é representado pela elipse central. Nesta instala-ção, as quatro fontes de informação referidas na secção anterior contribuem com dados parciais para a formação de uma vista de integração materializada (denominada repositório unificado), que replica informação relativa aos doentes com o objectivo de a apresentar de uma forma unifi-cada. A redundância intencional confere ao sistema duas características essenciais:
- Elevado desempenho na execução de inquéritos. A existência de réplicas próximas do utilizador e de elevada disponibilidade tornam possível a satisfação imediata dos inqué-ritos, por oposição à execução em tempo real de inquéritos distribuídos.
- Qualidade dos dados. Os processos de integração semântica e carregamento dos repo-sitórios, podem garantir a verificação de restrições de coerência e originar registos mais completos. Para além disso, tarefas de segundo plano, como processos de agregação ou a extracção de indicadores clínicos relevantes, podem ser delegados na fase de carrega-mento.
A formação do Repositório Unificado (RU) e a sua consequente exploração dependem de pro-cessos sofisticados de extracção, limpeza, integração e apresentação dos dados normalmente provenientes de fontes de informação heterogéneas. Para isso, modelamos as acções de carre-gamento e exploração dos RU através da definição de processos de interacção entre agentes de
software [Wooldridge e Jennings 1995]. A integração e exploração da informação é realizada por um sistema multiagente (SMA) [Ferber 1999] e resultam de interacções “sociais” em que “indivíduos”, com objectivos e controlo locais, se relacionam e se comprometem a atingir objec-tivos globais. A utilização de um SMA na integração de informação modela com naturalidade os processos de computação cooperativos e distribuídos como aqueles que se torna necessário implementar na extracção e reunião de dados dispersos, e a diversidade de competências associ-adas [Sycara et al 1996; Belo 1999].
LINe -Ag.Extractor Sítios de integração Fontes de informação ONYX / EEG-IS -Ag.Extractor Ressonância Magnética (MRI) -Ag.Extractor SIH -Ag.Extractor
Repositório Unificado (RU)
-Facilitador Ponto de acesso - AgInterface - Ag.Integrador - Ag.Compiladores Agente Fluxos de dados no carregamento do RU Fluxos de dados em tempo de exploração
Figura 2– Os componentes principais do sistema iPOINTER. 3.2 A organização funcional do SMA
Os agentes do iPOINTER (Figura 2) podem ser organizados funcionalmente em três grandes classes: interface, integração e fontes de dados (Figura 3). Estas classes correspondem, de um modo geral, à estrutura adoptada por outros autores em trabalhos relacionados (e.g.: [Sycara et al 1996], [Nodine et al 2000]):
- Os agentes de interface assistem os utilizadores na preparação de inquéritos que con-vertem em especificações compatíveis com as representações internas do sistema. Com-pete a estes agentes activar a satisfação dos pedidos de informação, enviando-os ao agente Facilitador (que controla o RU), e apresentar os respectivos resultados.
- Os agentes de integração são especializados na reunião, limpeza e fusão de dados. Nesta categoria, incluímos três tipos de agentes: o Integrador, o Compilador e o Facili-tador. O Integrador observa a agenda do sistema, onde estão definidos os objectivos de integração, e activa planos de integração. O Compilador é responsável por recolher da-dos distribuída-dos relevantes para a satisfação de um plano concreto e consolidar os resul-tados parciais para obter versões unificadas, de acordo com o conhecimento do domínio embebido. O Facilitador é responsável por satisfazer inquéritos a partir dos dados no re-positório unificado e incorporar os dados recolhidos na vista de integração materializa-da.
- Os agentes do nível das fontes de dados controlam a interacção com os sistemas de software que gerem as fontes subjacentes. Cabe a estes agentes, os Extractores, aceder
às fontes, utilizando protocolos de acesso a dados específicos, e trazer os dados relevan-tes para a comunidade de agenrelevan-tes.
Para além dos agentes classificados nas categorias funcionais enunciadas, existe um conjunto adicional de outros agentes (de sistema) que prestam serviços aos agentes posicionados nos diversos níveis. O Intermediário fornece serviços de mediação para a localização dinâmica de agentes (semelhante ao paradigma das “páginas amarelas”), enquanto que o Administrador permite controlar a composição da comunidade, acompanhar a actividade dos agentes e configu-rar os processos de integração.
A organização descrita leva a que os agentes exibam âmbitos de responsabilidade diferenciados. Na verdade, cada agente tem uma função própria no sistema, isto é, uma capacidade de resolu-ção de problemas limitada e específica. O comportamento interessante do iPOINTER resulta do trabalho conjunto, em cenários de cooperação com que os agentes se comprometem com objec-tivos colecobjec-tivos. Para isso, os agentes comunicam de forma intencional, utilizando uma lingua-gem de alto nível.
Nível de interface Nível de integração Nível das fontes de dados Agente de Interface Plataforma de interface Agente Integrador Agente Compilador Agente Facilitador Agente Extractor Agente Intermediário Agente Administrador Agentes de sistema Agente Vigia
Figura 3– Organização funcional do iPOINTER.
4 Serviços de integração e exploração de informação
4.1 Modelo semântico
A integração de informação distribuída fica comprometida se existirem ambiguidades ou impre-cisões quanto à interpretação de cada elemento de dados. Uma forma de acautelar este problema consiste em descrever os conceitos do domínio em causa através de ontologias que estabelecem a interpretação dos conceitos do domínio [Wache et al 2001; Nodine et al 2000]. O iPOINTER define uma ontologia global que explícita o modelo de dados comum, em termos das entidades de dados e associações que o compõem. Desta forma, o vocabulário e interpretações dos concei-tos ficam claramente definidas para suportar as interacções entre agentes e, até, a extensão do sistema. A ontologia global é utilizada pelos agentes em várias etapas da execução dos proces-sos de integração:
- Extracção: os Extractores acedem às fontes locais e exportam os conteúdos subjacentes alinhados pelo modelo global. Este processo implica a resolução da heterogeneidade semântica entre as origens de dados e o modelo de referência.
- Transporte: os dados clínicos recebidos e operados pelo Compilador estão expressos no modelo global.
- Incorporação: o motor de fusão de dados e integração no repositório unificado trabalha sobre resultados parciais conformes com o modelo global.
- Inquérito: o utilizador formula inquéritos sobre o modelo global, e nunca é confrontado com as heterogeneidades entre fontes.
4.2 Extracção e alinhamento dos conteúdos locais
Cabe aos Extractores fazer corresponder os conteúdos locais no modelo de referência, recorren-do, para isso, a especificações de conversão. Uma especificação de conversão define:
1. O subconjunto do modelo global que o Extractor é capaz de cobrir com os dados da fonte que encapsula. Esta informação é utilizada no anúncio de capacidades por parte dos Extractores, e é mantida nos agentes Intermediários, para mais tarde responder a pe-didos de mediação na localização de agentes ou fontes de informação.
2. As correspondências e transformações necessárias para converter os dados locais nas representações globais e que são usadas para alimentar o motor de reestruturação. A especificação de conversão associa o modelo local ao modelo de referência da seguinte for-ma:
- Os conceitos globais são associados a vistas locais. A interpretação específica da desi-gnação da vista local depende do sistema de gestão de dados subjacente; no caso relaci-onal, corresponderá tipicamente ao nome de uma vista lógica definida sobre uma ou mais tabelas. Esta técnica de alinhamento de esquemas é conhecida por global-as-view [Busse et al 1999]. As vistas locais poderão ser identificadas através de nomes de objec-tos do sistema de gestão de bases de dados subjacente ou, se tal não for possível ou de-sejável, poderão ser definidas na própria especificação de conversão (em vez do nome da vista aparecerá embebida a sua definição, na linguagem própria do sistema encapsu-lado pelo Extractor).
- Os membros locais são convertidos nos membros globais através de transformações. A transformação mais simples é uma operação de cópia, que é também a mais frequente, visto que podemos construir vistas locais que preparam os dados para se ajustarem ao modelo de referência. É possível, no entanto, definir transformações mais complexas como, por exemplo, a invocação de módulos de código.
4.3 Planos de integração
A incorporação de (nova) informação no RU é guiada por planos específicos de integração, que estabelecem a gama de informação pretendida e parâmetros operacionais para a execução dos processos de recolha e fusão. O plano de integração indica o subconjunto de dados distribuídos que devem ser recolhidos, fundidos e integrados na vista materializada. Um exemplo informal da natureza desta especificação poderia ser:
“obter informação demográfica do paciente 012345 constante no sistema LINe, e os EEGs associados que se encontram no sistema SBI/Onyx, e os relatórios clínicos asso-ciados, também disponíveis no LINe, e os exames de ressonância magnética relaciona-dos a esses episódios”.
Quando um plano de integração é activado (Figura 4), o agente Integrador (A1) começa por obter a identidade de um Compilador disponível (A3), a quem solicita a realização de um plano de integração. Este agente elabora uma estratégia de execução, em função da qual vai tentar encontrar agentes extractores relevantes. Para isso, consulta o Intermediário, solicitando-lhe a identidade dos Extractores relacionados com as origens de dados pretendidas. A cada Extractor considerado (A4) é submetido um inquérito que corresponde, tipicamente, a uma parte dos dados pretendidos. O número de resultados pode ser elevado, ocorrendo um diálogo iterado entre A3 e A4. Tendo cumprido o transporte e conversões especificadas, A3 procura um Facilitador (A5) para enviar os dados já unificados. Finalmente, A5 inclui os resultados recebidos no RU.
A1 : Integrador A3 : Compilador A4 : Extractor A5 : Facilitador A2 : Intermediário request( plano ) query( AgComp? ) inform( A3 ) agree()
query( AgExt, Fonte=F1) inform( A4 ) query( Q1 ) inform( R1.1 ) query( Q1 ) inform( R1.2 ) query( AgFac? ) inform( A5 )
inform( dados disponíveis )
query( ) inform( R' ) inform( sucesso )
Figura 4– Interacções entre agentes na execução de planos de integração. As mensagens no diagrama de sequência correspondem a mensagens de alto nível entre agentes ([Odell et al 2000]).
4.4 Exploração
A informação dispersa, depois de reunida e unificada, é publicada no RU tornando-se, a partir daí, disponível para satisfazer os inquéritos do utilizador. Os profissionais clínicos colocam os pedidos de informação através dos agentes de Interface, especializados no domínio de aplicação. Os agentes de interface do iPOINTER são específicos para o domínio da saúde, desenhados para apoiar o inquérito dos profissionais clínicos sobre o modelo global. A aplicação do sistema noutros domínios requereria a adaptação dos agentes de Interface.
O processo de consulta da informação no RU é trivial, uma vez que os resultados aí disponíveis já se encontram expressos na ontologia de referência. Para isso, o agente de Interface começa por obter a referência do Facilitador, com quem inicia um diálogo iterado na forma pedi-do/resposta.
5 A implementação do sistema em Java
5.1 Organização geral
O sistema iPOINTER foi desenvolvido em linguagem Java [Eckel 2000] e demonstrado na integração de informação em no serviço de Neurofisiologia Clínica. A implementação assenta em várias camadas de serviços (Figura 5). Sobre o protocolo de transporte TCP/IP, existe em cada nodo uma JVM que proporciona o ambiente de execução para programas em Java (ou mais precisamente, em bytecode). O ambiente de programação distribuída fornecido pela biblioteca ObjectSpace Voyager [ObjectSpace 2000], também ela em Java. Recorrendo às facilidades proporcionadas pelo Voyager, desenvolvemos o Ambiente Distribuído dos Agentes (ADA). Esta camada cria a abstracção de um espaço contínuo de nomes (ao nível do sistema multi-agente) e fornece os serviços de subsistência da comunidade (e.g.: propagar mensagens, adicionar ou remover nodos da comunidade, instanciar agentes, etc.). Os agentes do iPOINTER interagem com o ADA e não apresentam dependências dos protocolos ou implementações abaixo dele.
TCP/IP JVM Voyager (ORB) TCP/IP JVM Voyager (ORB) Nodo a
Agente i Agente i+1 Agente i+2 Agente i+k
Nodo b Ambiente distribuído dos agentes
Figura 5– Organização geral da solução de software. 5.2 O agente base
Cada agente do iPOINTER pode ser organizado conceptualmente em camadas de serviços, em que os níveis superiores se baseiam nos serviços dos níveis inferiores (Figura 6). O primeiro nível diz respeito aos serviços de acesso ao ambiente e compreende os sensores e os actuadores do agente, isto é, os pontos de interface do agente com o ambiente.
Sobre este nível, é implementada a camada de gestão de mensagens, que envolve a criação, expedição e recepção de mensagens. As mensagens são enquadradas em diálogos, isto é, con-textos iniciados a partir de um determinado acto comunicativo e geridos por uma camada de conversação. Tanto as mensagens como outras percepções recebidas têm de ser analisadas e a respectiva reacção planeada por um módulo de controlo. Esta camada é responsável por decidir quais as tarefas a realizar e controlar a sua execução. O controlo pode ser dividido em duas sub-camadas:
- serviços genéricos que fazem parte de todos os agentes (e.g.: responder a um pedido de prova de vida);
- serviços de aplicação específicos cujo conhecimento e competências necessários à sua realização estão atribuídos a agentes especializados (e.g.: a extracção de informação dos sistemas operacionais compete exclusivamente aos Extractores).
Nível das mensagens Nível da conversação Nível de controlo genérico
Nível de aplicação
Nível de acesso ao ambiente
Nível das mensagens Nível da conversação Nível de controlo genérico
Nível de aplicação
Nível de acesso ao ambiente
Ambiente distribuído dos agentes
Ser
vi
ços Âmbito do agente base
Agente i Agente i+1
Figura 6– Camadas internas de serviços dos agentes.
Os mecanismos que integram os módulos internos dos agentes são, em boa parte, comuns. Por exemplo, a formatação de mensagens ou as acções desencadeadas para as emitir ou receber são as mesmas, independentemente do agente em questão. Por isso mesmo, o conjunto de mecanis-mos comuns aos vários agentes foi integrado num agente base, que funciona como ponto de partida para a construção dos agentes concretos, libertando assim o programador para se con-centrar nos serviços específicos de cada agente. Para além disso, garantimos assim a uniformi-zação dos processos comuns (e.g.: comunicação). O desenvolvimento de novos agentes parte, portanto, desta base, que especializa: ao nível do software, o agente específico é uma subclasse do agente base. O mesmo princípio se aplica à modelação e implementação dos agentes Extrac-tores, já que podemos identificar um conjunto de comportamentos de acesso e tratamento dos dados que é comum entre eles (e.g.: gestão de cursores, gestão de conexões, etc.). Deste modo, os Extractores concretos são subclasses de um Extractor base abstracto.
Acesso ao ambiente
Os agentes acedem ao ambiente do sistema, i.e., ao ADA, através de sensores e actuadores. O agente dispõe de métodos para registar ou remover sensores e actuadores, cujo cardinal pode variar de agente para agente, existindo sempre pelo menos um sensor que observa o ambiente, pesquisando mensagens que são dirigidas ao agente, e um actuador capaz de lá colocar as men-sagens para expedição (as menmen-sagens são modeladas no iPOINTER como percepções e acções). Outros sensores e actuadores específicos podem coexistir (por exemplo, para monitorização de eventos de dados relacionados com o sistema de gestão de dados subjacente).
Nível das mensagens
O nível das mensagens lida com a instanciação, empacotamento e desempacotamento de men-sagens. Esta camada assegura a formatação válida e consistente para todas as mensagens, em conformidade com a linguagem de comunicação do iPOINTER.
Gestão de conversações
Os modelos internos do agente incluem um gestor de conversações que assegura a aplicação dos protocolos de conversação definidos. O contexto de cada conversação activa (uma nova conver-sação é iniciada quando um agente toma a iniciativa de um acto comunicativo que não referen-cia nenhum anterior) é mantido pelo gestor num grafo que representa o diagrama de estados associado ao protocolo de interacção que está a ser observado.
O módulo gestor de conversações mantém uma memória das mensagens que foram expedidas e cujo protocolo declara que esperam repostas. Estas mensagens são normalmente respondidas. Neste caso, o gestor, depois de verificar a idoneidade através da informação de envelope, entre-ga o respectivo conteúdo aos objectos que devem ser notificados. Pode também suceder que a resposta não chegue ou tal se passe demasiado tarde, dando origem a um timeout. As mensagens que chegam para além do tempo limite definido, isto é, que referenciam uma conversação que já expirou, são simplesmente descartadas.
Nível de controlo genérico
A actividade do agente compreende três fases essenciais: a recepção de percepções, o planea-mento das tarefas a executar e a respectiva activação.
As percepções são captadas por sensores, executados num thread autónomo (de modo a garantir que nenhuma percepção é perdida) e inseridas na fila prioritária de percepções do agente. Quan-do uma nova percepção é detectada, a percepção no topo da fila é retirada e analisada pelo módulo de planeamento do agente. Os objectivos do agente são codificados na lógica dos plane-adores. O método principal de um planeador retorna para uma dada percepção, uma tarefa a ser activada. Mais uma vez, há um conjunto de reacções às percepções comuns a todos os agentes e outras que são específicas. Esta lógica reflecte-se na existência de um módulo comum, que incorpora os mecanismos de decisão base e módulos de planeamento especializados por agente. Nível de aplicação
Esta camada corresponde às perícias específicas em cada agente. No caso do agente de Interfa-ce, por exemplo, envolve a gestão de diálogos com o utilizador, as interacções com o Facilita-dor, e os processos de visualização de informação.
6 Conclusões
A arquitectura do sistema iPOINTER apresenta alguns pontos fortes para a integração de infor-mação clínica distribuída, entre os quais podemos destacar:
- Facilidade em integrar sistemas legados, naturalmente encapsulados em termos de capa-cidades de inquérito, protocolos de acesso e modelos da informação, sob a abstracção de agentes Extractores. No extremo, qualquer sistema dispondo de dados clínicos rele-vantes pode ser considerado nos processos de integração, desde que exista um agente Extractor idóneo que o adapte.
- Distribuição da carga computacional, consequência directa da divisão de competências por vários agentes, instanciados em múltiplos nodos computacionais. Esta distribuição de tarefas reflecte a dispersão da informação e introduz o paralelismo nos processos computacionais do sistema.
- A extensão do sistema, para incorporar novas origens ou classes de informação clínica, é facilitada por desenho, pois corresponde à introdução de novos agentes na comunida-de, sem necessidade de reprogramação dos processos e agentes já existentes. Do ponto de vista do desenvolvimento, novos agentes podem ser criados rapidamente por especia-lização dos agentes já existentes.
- A aplicação do sistema segue uma estratégia não intrusiva, permitindo a integração de fontes de dados sem necessidade de adaptar os sistemas já existentes. Este aspecto é
particularmente importante face ao custo e dificuldade inerentes à alteração dos siste-mas presentes nos hospitais e usados na rotina.
Para além das vantagens anteriores, decorrentes essencialmente da modularidade e descentrali-zação proporcionada pela aplicação da computação baseada em agentes, a nossa estratégia beneficia ainda da utilização de repositórios departamentais para armazenar vistas materializa-das dos dados unificados. Os processos de extracção, preparação e exploração de dados assim definidos permitem efectivamente apresentar respostas em tempo útil e elevar a confiança do clínico na informação reunida. Para isso contribui principalmente a visão mais completa dos objectos de dados dos doentes, disponíveis a partir de um único ponto de acesso.
7 Referências
Belo, O. (1999) "Gathering the Right Information at the Right Time: An Agent Based Approach to Data Warehouses Loading Processes" Em International Conference on Enterprise In-formation Systems (ICEIS), Setúbal, Portugal.
Bemmel, J. H. v. e M. A. Musen (Eds.) (1997) Handbook of Medical Informatics, Springer. Busse, S., R.-D. Kutsche, U. Leser, et al. (1999) Federated Information Systems: Concepts,
Terminology and Architectures, Technische Universität Berlin, Fachbereich 13 Infor-matik, Relatório Nr. 99-9, Berlin.
Cunha, J. P. (1995) Actividade de base no EEG de doentes epilépticos: Procura de relações entre diferentes derivações baseadas em medidas não lineares, Tese de Doutoramento, Universidade de Aveiro.
Cunha, J. P., P. G. d. Oliveira, M. B. Cunha, et al. (1993) "Integration of Multimedia Informati-on in a Clinical Neurophisiology Department" Em 15th Annual Int. CInformati-onf. of the IEEE Engineering in Medicine and Biology Society, pp 624-625.
Eckel, B. (2000) Thinking in Java, 2nd ed., Prentice Hall.
Ferber, J. (1999) Multi-Agent Systems: An Introduction to Distributed Artificial Intelligence, Addison-Wesley.
Nodine, M. H., J. Fowler, T. Ksiezyk, et al. (2000) "Active Information Gathering in InfoS-leuth", International Journal of Cooperative Information Systems, 9(1-2): pp. 3-27. ObjectSpace (2000) Voyager ORB 3.3 Developer Guide, ObjectSpace.
Odell, J., H. V. D. Parunak e B. Bauer (2000) "Representing Agent Interaction Protocols in UML" Em Ciancarini, P. e Wooldridge, M. ( Eds ) Agent-Oriented Software Enginee-ring (AOSE), First International Workshop, Limerick, Ireland, pp 121-140.
Oliveira, I. C., O. Belo e J. P. Cunha (2000) "Agents Working on the Integration of Heteroge-neous Information Sources in Distributed Healthcare Environments" Em Monard, M. C. e Sichman, J. S. ( Eds ) Advances in Artificial Intelligence, International Joint Confe-rence, 7th Ibero-American Conference on AI, 15th Brazilian Symposium on AI, IBERAMIA-SBIA 2000, Atibaia, SP, Brazil, pp 136-145.
OTA (1995) Bringing Health Care Online: The Role of Information Technologies [online], U.S. Congress, Office of Technology Assessment (OTA), disponível em: http://www.ota.nap.edu/pdf/data/1995/9507.PDF [Acedido em 2001-12-15].
Reynolds, M. e I. Wejerfeld (2000) Short Strategy Study - Health Information Infrastructure, CEN/TC 251, Relatório CEN/TC 251/SSS-HII FWD 2.0.
Sycara, K., A. Pannu, M. Williamson, et al. (1996) "Distributed Intelligent Agents", IEEE Ex-pert, 11(6): pp. 36-46.
Wache, H., T. Vögele, U. Visser, et al. (2001) "Ontology-Based Integration of Information: A Survey of Existing Approaches" Em Stuckenschmidt, H. ( Ed ) IJCAI Workshop on On-tologies and Information Sharing, Seattle, WA, USA, pp 108-117.
Wooldridge, M. e N. R. Jennings (1995) "Intelligent Agents: Theory and Practice", The Know-ledge Engineering Review, 10(2): pp. 115-152.
