Consulta distribuída de Ordens de Serviço de
Equipamentos hospitalares usando Web Services
Marcelo Trindade Rebonatto1, Giovano Machado1, Luis Eduardo Spalding1,2, José Figueiredo2.
1
Curso de Ciência da Computação – ICEG - Universidade de Passo Fundo (UPF) Caixa Postal 611 – 99052-900 – Passo Fundo – RS – Brazil
2
Hospital São Vicente de Paulo
Rua Teixeira Soares, 808 CEP: 99010-080 – Passo Fundo – RS- Brazil
rebonatto@upf.br, giovano.m@terra.com.br, {spalding, jose}@elomed.com.br
Abstract. This paper describes the data integration among distributed
Biomedical Engineering Center using Web Services. It was proposed an model to distributed queries of maintence hospital equipment service order. The solution model was validated in CEBs using system of control service order with restrict access and storing data in database Microsoft Access. The integration was implemented in a service written in Java and Apache Axis with the consumer written in Delphi.
Resumo. O presente artigo descreve a integração de dados entre unidades
distantes fisicamente por meio da tecnologia de Web Service. Foi proposto um modelo para consultas distribuídas de ordens de serviço de manutenção em equipamentos médico hospitalares. O modelo de solução foi validado em Centros de Engenharia Biomédica que usam sistema para controle das ordens de serviço de acesso restrito, que utiliza banco de dados Microsoft Access. A integração foi a implementação do serviço foi realizada em Java e Apache Axis, com os consumidores do serviço implementados em Delphi.
1. Introdução
O número de equipamentos eletro-eletrônico presentes nos hospitais e demais instituições que prestam serviços na área de saúde é, a cada dia maior. Seu uso é intenso, seja em auxílio a diagnósticos ou em terapias, incluindo as intervenções cirúrgicas (Spalding, 2004). Esses equipamentos necessitam de manutenção, realizada por técnicos capacitados especificamente para esse fim. Diversos hospitais possuem setores responsáveis pela manutenção de seus equipamentos hospitalares. Estes setores são denominados Centros de Engenharia Clínica ou Biomédica (CEB).
Algumas empresas ligadas às áreas de Engenharia Clinica e Engenharia Biomédica possuem CEBs em diferentes hospitais. Cada CEB é independente na questão administrativa, porém parcialmente dependente na parte técnica dos demais CEBs da empresa, principalmente em relação aos CEBs mais antigos e mais experientes. A independência administrativa vai desde a adoção de uma base de dados
independente para a manutenção das ordens de serviço (OS) realizadas nos equipamentos de seu hospital até a infra-estrutura de serviços, como, por exemplo, acesso a internet.
A dependência técnica, mesmo que parcial, está relacionada à base de conhecimento acumulada pelos CEBs com maior tempo de funcionamento, uma vez que os defeitos apresentados pelos equipamentos médicos são, em muitos casos, os mesmos que aparelhos similares já apresentaram em outro momento. Dessa forma, o conhecimento dos procedimentos realizados na correção do problema, documentado nas OS, pode ser de extrema valia no conserto de um equipamento.
O procedimento normal de conserto de um equipamento num CEB é primeiro pesquisar na base de OS local se o mesmo problema já foi enfrentado e resolvido. Caso o técnico não encontre dados referentes ao equipamento e defeito em questão ele entra em contato, por meio de telefone ou e-mail, a fim de verificar em outro(s) CEB(s) se já foi realizado o conserto em equipamento semelhante. Desta forma, o técnico, além de aumentar o custo da manutenção com o uso de ferramentas de comunicação, ficará um maior tempo ocioso aguardando o retorno da informação. Um problema que pode ocorrer é a possibilidade da informação chegar de forma equivocada, por falhas de comunicação, na troca das palavras ditas ao telefone ou ainda por má interpretação das informações contidas na OS. Além disso, a solicitação da informação causa uma parada nas atividades desenvolvidas pelo técnico ao qual foi solicitado que procurasse e transmitisse a informação.
Uma solução para o problema seria a integração das bases de dados, porém essa alternativa é pouco viável em virtude da independência administrativa de cada CEB e também pela dependência dos hospitais em relação a, por exemplo, acesso a Internet. Um sistema integrado e distribuído com certeza incorreria em dificuldades em questões como política de acesso, firewall e portas livres para comunicação. Um sistema centralizado não é viável, uma vez que uma simples falha de conexão poderia deixar CEB(s) parado(s), sem possibilidade de pesquisa ou atualização de OS realizadas.
Nesse contexto, a tecnologia de Web Services (Weerawarana, 2005) surge como uma atrativa opção, uma vez que permite a integração de sistemas desenvolvidos em diferentes plataformas computacionais, por meio de protocolos considerados benignos, como o HTTP.
Este texto, descreve a integração de quatro CEBs, pertencentes a empresa com atuação no norte do Rio Grande do Sul e Paraná por meio de Web Services. Os CEBs, possuem software de controle de OS com base de dados Microsoft Access, gerenciado por aplicação na mesma linguagem. A integração é realizada por meio do desenvolvimento de um Web Service em linguagem Java com o framework Axis, tendo os consumidores dos serviços escritos em Object Pascal, por meio da ferramenta RAD Delphi.
O restante do texto está dividido em quatro seções. Na seção 2, uma breve descrição da tecnologia de Web Services. Na seção 3, uma explanação do modelo de funcionamento da solução de integração, sendo a validação, por meio de implementação, detalhada na seção 4. Na quinta seção as considerações sobre o trabalho e as áreas onde o mesmo continua avançando.
2. Web Services
Os Web Services (WS) são serviços disponibilizados através da web que possibilitam diferentes aplicações trocarem dados utilizando padrões difundidos e bem consolidados. Em outras palavras, fornecem uma infra-estrutura para prover a interoperabilidade entre consumidores e provedores (Coulouris et al., 2007).
Um WS é uma aplicação de software, identificada por uma por uma Universal
Resource Identifier (URI), cujas interfaces são capazes de serem definidas, descritas e
descobertas por artefatos Extensible Markup Language (XML). Eles devem suportar interações diretas com outras aplicações de software usando mensagens com conteúdo XML por meio de protocolos baseados na internet (W3C, 2004).
Os WS surgiram com o principal objetivo de facilitar as trocas de informações automatizadas, buscando ser um padrão na troca de informações entre empresas e aplicações em sistemas distribuídos. Para alcançar seus objetivos faz uso dos seguintes protocolos (Cerami, 2002):
• XML: precede os WS, usada como base para a criação dos componentes: SOAP, WSDL e UDDI;
• HTTP: também precede os WS, usado para transportar mensagens SOAP e documento WSDL. É largamente usado devido ao transito livre em firewalls, porém não é o único protocolo de transporte;
• SOAP: usado no formato das mensagens trocadas entre os WS com, entre outros objetivos, proporcionar a chamada do serviço. Serve a interoperabilidade, pois, não é relacionado a nenhuma arquitetura de hardware ou software;
• WSDL: documento que descreve as opções disponíveis, os tipos de mensagens, como e onde acessar um WS;
• UDDI: usado para o registro e descoberta de WS.
Esse conjunto de protocolos é centrado principalmente em tecnologias já consolidadas como o HTTP e a XML, sendo assim não é algo exatamente “novo”. Seu funcionamento é simular ao Remote Procedure Call, protocolo largamente difundido em aplicações distribuídas, funcionando sobre protocolos de requisição e resposta, que implementam um modelo de comunicação cliente-servidor com naturalidade (Gomes, 2005).
3. Modelo da solução
A fim de solucionar o problema da consulta de OS em diferentes CEBs, integrando sistemas legados (Stevens; Pooley, 1998), foi projetado uma arquitetura de funcionamento para a solução. A Figura 1 ilustra essa arquitetura, onde se pode observar que cada CEB deve possuir um WS aguardando requisições, e um consumidor de serviço para acessar o(s) WS dos demais CEB(s).
Figura 1 – Arquitetura da solução proposta
Na Figura 1 são mostrados dois (2) CEBs apenas para uma melhor visualização, porém o da parte inferior está identificado como “n” a fim de mostrar que o modelo de solução serve para vários. Em cada CEB pode-se observar três (3) componentes principais: serviço (WS), cliente (consumidor de WS) e sistema legado, que é o sistema que atualiza o banco de dados local de OS.
Conforme o modelo proposto, o WS recebe requisições dos demais clientes, acessa a base de dados Microsoft Access para fazer as consultas e retorna o resultado ao software consumidor que o solicitou. O aplicativo que irá requisitar as OS, poderá estar executando na rede interna do CEB onde está o serviço ou o nos demais CEBs.
Cada WS deve ser acessível aos consumidores por meio de uma URI, sendo disponível enquanto sua localização puder ser acessada. Em casos onde os CEBs, por motivos de redução de custos ou falta de interesse, não possuem um domínio cadastrado ou mesmo um endereço IP fixo é sugerido o uso de um software de Dynamic DNS (DDNS), realizando a resolução entre o IP atualmente ocupado pelo servidor do CEB e o domínio virtual cadastrado.
A solução proposta se assemelha a um modelo de interação de aplicações peer to
peer (p2p), onde os CEBs podem ser considerados servidores e também clientes
(Coulouris et. Al, 2007). Cada CEB é servidor quando disponibiliza um serviço para que os demais acessem suas OS. Ao mesmo tempo, pode ser um cliente quando realiza pesquisa nos demais CEBs. Ela traz consigo os benefícios de uma rede p2p como, por exemplo, independência de falhas uma vez que na apresenta um Single Point of Failure.
4. Implementação e validação
O modelo de solução, descrito na seção 3 foi implementado a fim de validar a solução e também proporcionar que os CEBs da empresa possam usufruir de seus benefícios, ou ____________________________________________________________________________________
seja, realizar pesquisas nos demais CEBs de forma direta. Na implementação da solução foram usados os seguintes componentes de software:
• Apache Tomcat (Apache TomCat, 2008) versão 6.0 com servidor web para disponibilizar acesso aos serviços;
• Apache Axis (Apache Axis, 2008) versão 1.4 como framework Java para dar suporte aos serviços;
• No-IP (No-Ip, 2008) como software para DNS dinâmico;
• Linguagem Java e JBDC para escrita do serviço e acesso a base de dados Microsoft Access;
• Delphi 7 para a criação de uma interface gráfica nos consumidores;
A opção por componentes de software de diversas linguagens foi uma necessidade, em virtude do sistema instalado e também uma forma de comprovar na prática a interoperabilidade proporcionada pelos WS.
A figura 2 ilustra a troca de informações entre as camadas de software usadas na implementação da arquitetura descrita na seção 3.
Figura 2 – Fluxo de informações da implementação
Na figura 2 são mostrados 3 elementos: o cliente (consumidor de serviço) escrito em Delphi, o servidor DDNS do No-IP e a estrutura instalada em cada CEB para o funcionamento do WS, compreendida por um retângulo.
O aplicativo cliente faz uma requisição ao serviço por meio do domínio registrado no aplicativo No-IP. Nessa operação ocorre a busca do endereço IP associado no momento ao domínio requisitado por meio do acesso a base de dados do No-IP. De posse do IP do WS, o cliente acessa o servidor web Apache Tomcat no endereço IP retornado pelo servidor de DDNS. Ressalta-se que essa operação de consultar o IP no servidor de DDNS e após conectar com o servidor web é transparente ao cliente.
Ao receber a requisição, o servidor web contata o provedor de serviços Apache Axis que repassa a requisição ao serviço implementado em Java. Todo o trabalho de
marshaling e unmarshing das informações solicitadas é realizado pela camada se
suporte a WS do cliente e pelo Apache Axis no servidor. O WS tem acesso à base de dados Microsoft Access para fazer consultas e realiza a consulta solicitada pelo cliente, preparando e devolvendo o resultado da requisição ao Apache Axis.
O Apache Axis realiza as conversões necessárias e entrega o(s) pacote(s) ao Apache TomCat. O servidor web por sua vez devolve o resultado ao cliente que fez a requisição, onde o resultado é novamente convertido para um formato de dados compatível com o Delphi e apresentado ao usuário.
O aplicativo cliente armazena a URI dos servidores nos CEBs em um arquivo texto na mesma pasta do arquivo executável do sistema. O arquivo contém a URI com a WSDL de cada serviço. Este arquivo é lido toda vez que o software cliente é executado, podendo ser modificado pelo usuário. A Figura 3 mostra o arquivo “ceb.ini” que armazena a configuração da URI dos CEBs.
Figura 3 - Arquivo de configuração da URI de cada CEB
No arquivo de configuração, mostrado na figura 3, o campo “[CEBn]” identifica a seqüência dos CEBs cadastrados, o campo “Nome” possui o nome do CEB e o campo “URI” armazena a URI completa do serviço. Pode-se adicionar quantos CEBs desejar, bastando seguir a lógica da seqüência. A ordem dos CEBs incluídos no arquivo é a mesma usada na pesquisa dos dados. A figura 4 mostra a interface para acesso as OS, juntamente com as possibilidades de filtro na pesquisa.
Figura 4 – Interface de consulta e visualização dos dados das OS
A interface descrita na figura 4 permite que sejam selecionadas as OS que desejam ser consultadas. Após selecionar os limites da consulta como data inicial e final, tipo, grupo e marca de equipamentos, o botão “Pesquisar” realiza a pesquisa em todos os CEBs cadastrados no arquivo de configuração, mostrando os resultados no grid identificado como “Lista de resultados”. Além de visualizar os resultados no grid, pode-se emitir e imprimir um relatório com as OS ou ainda visualizar uma OS individualmente, com os campos defeito e serviços realizados, que são campos de texto livre, totalmente visíveis na janela.
5. Considerações Finais e trabalhos em andamento
Este artigo apresentou e validou uma solução para realização de consulta de OS distribuídas em CEBs usando web services. Uma arquitetura para a solução foi proposta e implementada, mostrando que a tecnologia de WS pode ser usada na integração de sistemas de plataforma diferentes, incluindo sistema legados. A implementação comprovou ainda, a interoperabilidade entre diferentes linguagens de programação é obtida de forma direta com WS.
O serviço disponibilizado é inicialmente de uso exclusivo da empresa que durante anos vem alimentando o banco com informações sobre a manutenção dos equipamentos nos diversos CEBs que possui. Porém, ele poderá ser ampliado, servindo a outras empresas que também realizam a manutenção em equipamentos médicos e hospitalares, instaladas em qualquer região com acesso a Internet. Este acesso pode ser cobrado, ou não, ficando a critério da empresa, expandindo assim a possibilidade da
base de conhecimento da empresa gerar novas fontes de arrecadação. Uma expansão de uso em andamento é a disponibilização, por meio de convênio, com as principais fabricantes de equipamentos hospitalares, a fim de aprimorar os equipamentos construídos.
Ainda como futuros trabalhos, está o aprimoramento da aplicação cliente pode ser melhorada, produzindo consultas mais refinadas sobre os dados. Além disso, os serviços serão aperfeiçoados, incluindo controle de login e criptografia das mensagens, por meio do uso de HTTPS, oferecendo principalmente segurança em relação aos dados consultados. A arquitetura da solução proporciona também que uma base de dados com relatos de OS realizadas principalmente na década de 1990, armazenada em arquivos no formato “dbf” seja agregada ao sistema distribuído de consulta. Essa adição pode ocorrer pela simples adição de um WS com acesso aos arquivos em formato “dbf” que, mesmo na empresa, não estão disponíveis para acesso em virtude da interface textual onde o sistema foi desenvolvido.
6. Referências
APACHE AXIS. Disponível em <http://ws.apache.org/axis/>. Acesso em 05 de abril 2008.
APACHE TOMCAT. Disponível em <http://tomcat.apache.org>. Acesso em 10 de março de 2008.
Cerami, Ethan. Web Services Essential: Distributed Applications with XML-RPC, SOAP, UDDI & WSDL. O’ Reilly, 2002. 304p.
Coulouris, George; Dollimore, Jean; Kindberg, Tim. (2007) “Sistemas distribuídos: conceitos e projeto”. Tradução de João Tortello. 4.ed. Porto Alegre: Bookman. Gomes, Josir C. Utilização da Arquitetura de Web Services no Desenvolvimento de
Sistemas de Informação em Micro e Pequenas Empresas. Dissertação de Mestrado. IBMEC/RJ. Rio de Janeiro, 2005.
NO-IP. Disponível em <http://www.no-ip.com/>. Acesso em 15 de maio de 2008. Spalding, L.E.S. et al. (2004). “Análise da corrente elétrica para supervisão de segurança
em equipamentos eletromédicos durante procedimento cirúrgico”. In: Congresso Brasileiro de Informática em Saúde, 9, 2004, Ribeirão Preto. Anais … Ribeirão Preto: Sociedade Brasileira de Informática em Saúde, 2004, p.1-6.
Stevens, P.; Pooley, R. “Systems Reengineering Patterns”. In: Proceedings of the 6th ACM SIGSOFT international symposium on Foundations of software engineering, vol. 23 issue 6, 1998, pp. 17-23.
W3C. Web Services Architecture, 11 fev. 2004. Disponível em: http://www.w3.org/TR/ws-arch. Acesso em 27/09/2008.
Weerawarana, S. (2005). “Web services platform architecture: SOAP, WSDL, WS-Policy, WS-Addressing, WS-BPEL, WS-Reliable Messaging”. Upper Saddle River: Prentice Hall PTR, 2005. 413p.
