Arquitetura Proposta

Transcrição

1 Componentização e Integração de Sistemas de Informação em Saúde de Grande Porte Bianca de Oliveira Spazziani 1, Fabiane Bizinella Nardon 1 1 Fundação Atech / Vidatis Sistemas de Informação em Saúde, São Paulo, SP, Brasil Resumo - Este artigo tem como objetivo discutir as dificuldades inerentes à componentização e integração de sistemas de informação em saúde de grande porte e propor uma arquitetura e um processo de desenvolvimento que facilite este processo. Os resultados obtidos na aplicação desta arquitetura em um sistema real também são apresentados. Palavras-chave: integração de sistemas, componentes de software, sistemas complexos Abstract - This paper aims to discuss the problems when building a component based large scale information system in healthcare. A software architecture and a development process aiming to make this process easier is presented. The results of applying this architecture in a real world scenario is presented. Key-words: systems integration, software components, complex systems Introdução A área da saúde é de grande complexidade para o desenvolvimento de sistemas. As aplicações encontram-se distribuídas em plataformas heterogêneas, cada uma utilizando seu vocabulário específico. A necessidade de integrar a informação em saúde tem sido alvo de uma série de estudos [ 1][ 2]. Para que os sistemas possam compartilhar informação é necessário definir mecanismos que permitam estabelecer a integração, física e conceitual. Uma vez integrados, os sistemas podem, além de compartilhar informações, compartilhar também funcionalidades. Tarefas que sejam semelhantes ou até mesmo idênticas, não precisariam ser reimplementadas em um ambiente de sistemas integrados. Idealmente, estas tarefas deveriam ser desenvolvidas de tal forma que possam se tornar componentes compartilhados. Adicionalmente, para garantir esta integração é necessária a existência de uma arquitetura de software robusta, flexível, e que permita a escalabilidade e a evolução de todos os sistemas envolvidos, sem a necessidade de refazer cada sistema sempre que surgir alguma nova funcionalidade. Outro fator relevante quando se trata de integrar sistemas é garantir um controle de acesso unificado que possa ser utilizado por todas as aplicações. Este controle idealmente deve possuir perfis flexíveis capazes de incorporarem a legislação e códigos de ética profissionais. Este artigo tem como objetivo propor uma solução para integração e componentização de sistemas complexos e de grande porte na área de saúde, tendo como foco a proposta de uma arquitetura atrelada a um processo de desenvolvimento de sistemas, mostrando os resultados obtidos na aplicação da solução proposta em um caso real. Estudo de Caso As técnicas apresentadas neste artigo foram aplicadas na construção do sistema de informação da Secretaria Municipal de Saúde de São Paulo (SMS-SP). Este projeto visa construir um sistema integrado de informações em saúde, integrando o sistema de captura do atendimento, originado do projeto piloto do Cartão Nacional de Saúde, com o CNES Cadastro Nacional de Estabelecimentos de Saúde, com um sistema de Autorização de Procedimentos de Alta Complexidade e com um sistema de agendamento universal, que seja capaz de controlar tanto recursos regulados, através de um sistema de regulação, quanto recursos locais gerenciados pelo próprio estabelecimento de saúde. A integração de todos os subsistemas permite que um paciente seja identificado como sendo o mesmo indivíduo tanto no módulo de Autorização de Procedimentos de Alta Complexidade quanto na captura do Atendimento ou em qualquer outro subsistema, o que possibilita que seu histórico clínico esteja unificado e compartilhado. As características deste projeto são comuns a muitos outros projetos na área de saúde: diversas funcionalidades estão presentes em mais de um subsistema e deveriam ser desenvolvidas como componentes reutilizáveis, a equipe de desenvolvimento é heterogênea, diversos níveis de conhecimento devem ser combinados e devem produzir código homogêneo e de boa

2 qualidade. Estes fatores aliados ao fato de que os sistemas de saúde são inerentemente complexos, tratando de uma grande quantidade de informação, exigem um grande esforço para que se possa definir corretamente o nível de componentização adequado e mecanismos que permitam compartilhar adequadamente estes componentes. Neste sentido, a documentação do conhecimento dos especialistas para transformar o processo de construção das aplicações o mais automatizado possível e a definição de processos que permitam a rápida integração entre os subsistemas é fundamental para que se possa atingir um alto grau de reusabilidade e, ao mesmo tempo, garantir a qualidade do sistema. Arquitetura Proposta Como resultado do estudo realizado sobre as necessidades de integração e componentização, foi concebida uma arquitetura que incorpora um conjunto de ferramentas que tornam o desenvolvimento consideravelmente mais simples, rápido e menos sujeito a erros. As principais características desta arquitetura são: Independência de base de dados: é importante que o sistema construído seja independente de esquema de base de dados e de sistema gerenciador de banco de dados, para que não seja necessário modificar os sistemas quando o esquema da base de dados é modificado e para que se possa fazer instalações do mesmo sistema com diferentes sistemas gerenciadores de banco de dados, o que dá maior flexibilidade do sistema. Para atingir esta independência, todas as alterações de dados são realizadas através de Entity Beans [5], um padrão para persistência de dados. As consultas aos dados são realizadas através de um componente de consulta capaz de inferir os comandos SQL necessários para recuperar qualquer objeto e seus relacionamentos. Tanto para Entity Beans quanto para o componente de pesquisa, o esquema do banco de dados é descrito sob a forma de descritores XML, que podem ser modificados sem que haja necessidade de modificar o código da aplicação; Regras de conduta: uma série de regras de conduta, que garantem a homogeneidade do código gerado, foram criadas para definir claramente os padrões que devem ser adotados no desenvolvimento de software, aumentando a capacidade de integração; Documentação do conhecimento do especialista e geração automática de código: faz parte da arquitetura um trabalho de identificação de melhores práticas de desenvolvimento e a documentação destas práticas de forma que elas possam ser utilizadas para geração automática de código. As melhores técnicas e padrões de projeto adotados por especialistas em sistemas complexos e distribuídos são convertidas em metadados que são acrescidos ao código e posteriormente processados por um gerador que irá gerar o código adequado. Entre estas técnicas estão: técnicas para validação de dados, técnicas para geração de chave primária, técnicas para melhoria de desempenho, entre outras; Criação de um Repositório de Componentes: O Repositório de Componentes controla todos os componentes utilizados tanto na infraestrutura quanto nos sistemas desenvolvidos. Com ele o controle torna-se mais rigoroso já que todos os desenvolvedores devem manter versões atualizadas e informações sobre os componentes. Tudo o que for modificado em um componente é cadastrado pelo desenvolvedor que o modificou e automaticamente repassado para os desenvolvedores que se utilizam deste componente para algum propósito. Essas informações são muito importantes já que num ambiente onde se utilizam componentes, qualquer modificação pode alterar o funcionamento de um sistema que esteja utilizando este componente; Testes unitários: existe uma ênfase muito forte na utilização de testes unitários e automatizados que garantem que modificações realizadas em um componente do sistema não gerem efeitos colaterais que causem erros em outras partes já testadas no sistema; Ferramenta de apoio à criação de metadados: os metadados que serão utilizados pelo gerador de código ainda precisam ser inseridos pelo desenvolvedor, o que pode ser uma fonte de erros. Para resolver este problema, foi desenvolvida uma ferramenta chamada M.I.T.O.S.E. que, através de uma série de perguntas, auxilia o desenvolvedor no processo de definição de quais metadados serão necessários para construir o seu sistema; Utilização de um sistema de controle de acesso unificado: um sistema de controle de acesso único para todos os subsistemas é fundamental para manter a consistência das informações e para permitir uma verdadeira integração entre os subsistemas. Quando uma pessoa está autenticada em uma aplicação, ela deveria ser capaz de executar outra aplicação para a qual tenha acesso sem precisar autenticar-se novamente, criando a sensação de um sistema único e integrado;

3 Definição de fachadas por caso de uso: cada caso de uso do sistema é considerado uma unidade lógica grande o suficiente para ser uma parte da aplicação completa em si mesmo. Assim, cada caso de uso possui uma fachada que expõe para os demais sistemas os métodos necessários para executar o caso de uso. Esta abordagem facilita a tarefa de componentização e também a integração entre os módulos do sistema, uma vez que cada caso de uso tem sua interface bem definida. Um cuidado que deve ser tomado quando adotando esta abordagem é em identificar a granularidade do caso de uso [ 3]. A Figura 1 apresenta a arquitetura proposta como base para atingir os objetivos de componentização e integração de sistemas de informação em saúde descritos neste artigo. Nesta arquitetura, a base de dados é acessada por uma camada de objetos do domínio representados por Entity Beans e por classes de serviço. Estas classes são expostas para a camada de apresentação através das fachadas, representadas pelo design pattern Session Façade [4], um Session Bean [5] que contém todos métodos necessários para executar um caso de uso. importante que o componente seja identificado antes de ser desenvolvido pois o trabalho para componentizá-lo depois de já se encontrar implementado dentro da aplicação é difícil e demorado. Infelizmente, nem sempre é possível identificar todos os pontos de intersecção entre os subsistemas antes do desenvolvimento, principalmente quando se usa um processo de desenvolvimento iterativo, como o Unified Process [6]. Para estas situações, é fundamental períodos de refactoring, onde os componentes tardiamente especificados são extraídos. A abordagem deste projeto para minimizar o problema foi criar documentações que devem ser seguidas antes de iniciar o desenvolvimento de um caso de uso e que já indicam os possíveis futuros componentes. Uma dessas documentações é a Matriz de Responsabilidades, que indica quais os subsistemas responsáveis por cada componente do projeto com a finalidade de organizá-los de uma melhor maneira. Para o projeto da Secretaria Municipal de Saúde de São Paulo, foi criada uma Matriz de Responsabilidades onde mais de noventa funcionalidades diferentes foram mapeadas, sendo que destas cerca de 80% se tornaram componentes reutilizáveis. A tabela 1 mostra uma parte desta matriz. CNS CNS APAC/CNS Recepção/Acolhimento Localizar Paciente Cadastrar Paciente Acompanhar Laudos Tabela 1 Matriz de Responsabilidades Figura 1: Arquitetura Proposta Processo de Identificação de Componentes Um dos grandes problemas encontrados na componentização é justamente identificar que pedaços de código poderão vir a ser componentizados. Devem existir padrões de componentização para que se possa obter uma uniformidade na construção dos componentes, facilitando assim a integração e a manutenção. A primeira questão é saber o que poderá ser um componente. Uma possibilidade é trabalhar-se com o conceito de Casos de Uso, onde cada um deles tem um potencial para se tornar um componente. Em algumas situações, no entanto,a granularidade do Caso de Uso é muito grande e é necessário que apenas uma parte dele se torne um componente. É muito Os componentes representados pelas funcionalidades da Matriz de Responsabilidades e pelos casos de uso são componentes verticais, de granularidade maior e que geralmente são mini-aplicações completas compostos por três camadas. Além destes é importante que sejam identificados também os componentes de domínio, que formam a camada de persistência. Exemplos destes componentes são Paciente, Médico, Hospital, Atendimnto, entre outros. Estes componentes são utilizados praticamente por todas as partes do sistema e representam unidades fortemente reutilizáveis. Compartilhar estes componentes nem sempre é uma tarefa simples, considerando que diferentes equipes trabalham em diferentes sistemas e nem sempre uma equipe tem a visão geral de todo o sistema. Em sistemas simples, esta dificuldade é minimizada, mas em sistemas complexos, onde existem centenas de objetos do domínio, garantir a sua unicidade e sua reutilização não é uma tarefa simples. Em função disto, foi estabelecido

4 um processo em que todos os objetos de domínio são acessados a partir de um único repositório, criando uma camada única de persistência. A cada novo objeto de domínio criado, um comitê gestor de componentes avalia se nenhuma inconsistência no modelo de objetos foi criada, garantindo a unicidade dos objetos de domínio. Além disso, cada objeto de domínio criado é cadastrado no Repositório de Componentes que, automaticamente envia para todos os envolvidos no processo um informando do novo objeto criado, permitindo assim que outros membros da equipe se manifestem caso exista alguma violação de unicidade. Integração Uma vez definidos os componentes é necessário integrá-los às diferentes aplicações Além dos subsistemas a serem considerados no projeto da SMS-SP é necessário considerar também os sistemas legados Dependendo do tipo de componente, foram utilizadas três formas de integração para atender a estes requisitos: a integração via Callback, a integração via fachadas e a integração via Web Services. A integração de componentes via uma técnica de Callback é utilizada quando o componente é grande o suficiente para representar uma mini-aplicação. Tipicamente, estes componentes representam um caso de uso completo e são implementados em três camadas (persistência, lógica de negócio e apresentação). Quando um destes componentes é integrado a uma aplicação maior, é necessário haver um desvio de fluxo da aplicação original para o fluxo do componente e depois um retorno ao fluxo original. Esta situação ocorre, por exemplo, com o componente de cadastro de pacientes. Este componente é utilizado em diversas partes do sistema, como, por exemplo, no agendamento de uma consulta. Se o paciente não está cadastrado no sistema, o sistema de agendamento deveria chamar o componente de cadastro de pacientes, que executaria o seu fluxo e depois chamaria de volta a aplicação de agendamento, passando os dados necessários. Esta técnica é chamada de Callback e é uma forma bastante adequada para integração de componentes de granularidade maior. A integração via fachadas é usada geralmente em casos onde um caso de uso deve ser acessado sem que se passe pela sua camada de apresentação. Neste caso, um subsistema aciona outro através de chamadas à sua fachada. A integração via Web Services é usada principalmente para sistemas legados. Neste modo de integração, a fachada de um caso de uso é exposta através de uma interface XML que pode ser acessada por sistemas legados feitos em diferentes linguagens de programação. Resultados e Conclusões Os métodos empregados para a resolução do problema proposto se mostraram realmente eficazes à medida que se documentou o conhecimento adquirido durante o processo de desenvolvimento do sistema de forma que este fosse reaproveitado ao longo desse período. Foram encontradas dificuldades ao encontrar os componentes do sistema e, principalmente separá-los após já estarem implementados, portanto a verificação antes do desenvolvimento dos possíveis componentes foi uma das tarefas mais importantes para que não fosse gasto tempo desnecessário. Foi preciso um refactoring a cada fase do projeto para que fossem observadas as falhas na padronização e na integração e para que estas fossem resolvidas da melhor maneira possível. Uma característica dos processos iterativos, é que só se tem uma visão completa do sistema ao final de todas as iterações, o que gera a necessidade de refactorings periódicos para resolver desvios involuntários. A utilização de um repositório de componentes e a disciplina da equipe de desenvolvimento minimiza este problema, mas não o resolve completamente. A arquitetura proposta e os métodos de componentização permitiram construir uma aplicação realmente integrada e com grande produtividade. Referências 1. Nardon, F. B. (2003) Compartilhamento de Conhecimento em Saúde Utilizando Ontologias e Bancos de Dados Dedutivos. Tese (Doutorado), Escola Politécnica da Universidade de São Paulo, São Paulo. 2. Grimson, J. "Delivering the Electronic Healthare Record for de 21 st Century". International Journal of Medical Informatics. 64 (2001). p Kurt Bittner. Why Use Cases are not Functions. The Rational Edge Magazine. Disponível em ibm.com/developerworks/rational/library/c ontent/rationaledge/dec00/whyusecasesar enotfunctionsdec00.pdf. 4. Alur, D., Crupi, J., Malks, D. (2001), Core J2EE Patterns: Best Pactices and Design Strategies, Prentice Hall PTR 5. Marinescu, F. (2002), EJB Layer Architectural Patterns, In: EJB Design Patterns, Eds: Wiley, Bk&Poster, p Ambler, S.W., Constantine, L. (2000), The Unified Process Construction Phase: Best Practices in Implementing the UP, CMP Books

5 Contato Bianca de Oliveira Spazziani Fundação Atech - Vidatis Sistemas de Informação em Saúde Rua do Rocio, 351 Cj. 51-São Paulo, SP, Brasil [email protected] Fabiane Bizinella Nardon Fundação Atech - Vidatis Sistemas de Informação em Saúde Rua do Rocio, 351 Cj. 51-São Paulo, SP, Brasil [email protected]