A aplicação do Business Intelligence no segmento de Saúde Pública Ambulatorial Gilberto Capatina Valente 1, Newton Naoki Ahagon 1 1 Atech Tecnologias Críticas, São Paulo, SP Resumo Este artigo descreve o processo de desenvolvimento do sistema de Business Intelligence, como ferramenta de apoio à tomada de decisões estratégicas, desenvolvido a partir das informações ambulatoriais geradas no SIGA Saúde, que é um sistema integrado de gestão e assistência à saúde pública. O artigo apresenta a metodologia utilizada para construir o sistema a partir da identificação das áreas de interesse e dos principais relatórios gerenciais almejados pelos gestores, para ter mais conhecimento sobre o Sistema Único de Saúde (SUS) nos municípios e nos estados do Brasil que utilizem o SIGA Saúde. Palavras-chave: Business Intelligence, Data Warehouse, Sistema de Apoio a Decisão, Data Marts. Abstract This paper describes the Business Intelligence development process as strategical decision support system, developed from information stored in SIGA Saúde relational database, a public heath care integrated system. The paper describes the methodology used to develop the system from subject areas and the management reports desired from managers for getting more knowledge about SUS in the cities and states in Brazil wich uses SIGA Saúde. Key-words: Business Intelligence, Data Warehouse, Decision Support System, Data Marts Introdução Com a globalização, o mundo impulsionou forças competitivas, as organizações se tornaram mais ágeis e competitivas e os clientes mais exigentes. As organizações são pressionadas pelo mercado a melhorar os serviços prestados aos clientes, melhorar constantemente os processos de negócio, qualidade, resolver os pontos de deficiência, ter colaboradores capacitados e ter conhecimento sobre o negócio, dentre outros. Assim, entende-se que elas têm a obrigação de buscar o conhecimento para obter vantagem competitiva sustentável. Um sistema de Business Intelligence (BI) permite ter uma visão objetiva da organização e da qualidade de atendimento aos clientes por indicadores alinhados aos objetivos estratégicos do negócio e à missão do negócio, obtidos de informações dispersas nas bases de dados existentes, como suporte ao processo de tomada de decisões estratégicas. Assim como outra organização, o segmento de Saúde Pública também visa cada vez mais prestar serviços de qualidade e eficiência à população e, por esse motivo, precisa seguir as tendências tecnológicas de extração de conhecimento gerado pelos sistemas de informação transacionais Estes sistemas normalmente possuem bases de dados em diferentes tecnologias, plataformas e totalmente desintegradas. Para que haja uma consolidação destes dados de forma que um ser humano possa ter informações para a tomada de uma decisão, entra em cena uma arquitetura que oferece total apoio aos sistemas de Business Intelligence, denominada Data Warehouse (DW), que possibilita a transformação de grandes quantidades de dados existentes na organização. Esta transformação consiste em oferecer informações úteis e confiáveis, de fácil e rápido acesso, que formem o conhecimento e apóiem o processo de tomada de decisão para a oferta de serviços de maior qualidade, adquirindo assim, maior satisfação e confiança dos usuários do Sistema Único de Saúde (SUS). O objetivo desse trabalho é descrever o processo de desenvolvimento, a arquitetura e tecnologias utilizadas no projeto de Business Intelligence para apoio a gestão ambulatorial, tendo como fonte de dados o SIGA Saúde, um sistema de informação integrado de Gestão e Assistência em Saúde Pública. Além disso, serão apresentadas as dificuldades encontradas neste processo de modelagem, desenvolvimento e homologação da criação de um ambiente de Data Warehouse na obtenção dos dados do sistema do SIGA utilizado como base de informações.
Metodologia Definição - O BI é um processo integrado que envolve conceitos, metodologias, arquiteturas e tecnologias e infra-estrutura, que permite a análise de informações armazenadas historicamente em uma organização, provenientes de diversas fontes de dados e sistemas de informação, a fim de extrair inteligência ou conhecimento sobre o negócio. Arquitetura - Para um adequado sistema de BI, foi adotada a arquitetura tradicional do Data Warehouse composta pela fonte de dados dos sistemas transacionais, uma área de transformação e carga de dados denominada Staging Area, a base de dados do Data Warehouse segmentado em Data Marts integrados, o que permitiu uma construção incremental de DW e a camada de apresentação, também conhecida como Online Analytical Processing (OLAP). Segundo Bill Inmon e Ralph Kimball, um Data Warehouse é uma coleção de dados corporativos, orientados a assuntos, integrados, históricos e não atualizáveis para suporte a tomada de decisões, análises gerenciais e descobrimento de tendências [2] e [4]. Os sistemas transacionais ou Online Transactions Processing (OLTP) são os sistemas de informação ou bases de dados que automatizam um processo de negócio e registram dados diários da organização, no caso, a fonte de dados é o SIGA Saúde. O Data Warehouse é carregado com dados provenientes do sistema transacional por um processo denominado Extraction, Transformation and Loading (ETL), que corresponde ao processo de extração da fonte de dados, transformações e padronizações de dados, caso seja necessário o carregamento dos dados para a base de dados do Data Warehouse, de forma programada e de acordo com a necessidade de execução destas cargas. Os dados são carregados em tabelas com estrutura de colunas relacionais parecidas com a da base de dados transacional, porém em uma instância intermediária do banco de dados do DW denominada Staging Area, sem relacionamentos, chaves estrangeiras e constraints de banco de dados. Abaixo segue um exemplo do modelo de dados criado no DW: Figura 1. Modelo de Entidade Relacionamento da área de interesse de Atendimento A Staging Area é o elo de ligação entre o sistema transacional e a base de dados do DW, onde os dados provenientes dos sistemas de informação, no caso o SIGA Saúde, são transformados por regras implementadas em procedures PL/SQL do Oracle para carga correta no DW, como por exemplo, a carga de vagas e agendamentos locais e regulados do SIGA Saúde de forma unificada no DW. Diariamente a Staging Área será carregada com as informações do dia anterior e apagadas no próximo processo de carga. E por isso, é considerada como um estágio de extração anterior e temporário ao processo de transformação e carga na base DW [2]. A necessidade de carga programada por ETL é diária, com processamento noturno, também por execução de procedures PL/SQL que deverão ser agendadas na configuração do SGBD. No atual estágio deste trabalho, o processo ainda não foi agendado por estar em fase de homologação e as execuções estarem sendo executadas seqüencialmente para a obtenção de um volume de dados relevante para a sua validação. Como exemplo, a carga para um mês de informações da base do DW leva em torno de dois dias para ser executado, após algumas alterações para melhoria e diminuição do tempo de execução deste processo. Nesse cenário, as áreas de interesse do negócio são denominadas de Data Marts, que corresponde a um subconjunto lógico e físico de segmentação e organização do DW e da camada de apresentação na arquitetura de DW [2]. A camada de apresentação de dados, também chamada de Front-end, é a interface que apresenta as informações ao usuário e é normalmente composta por ferramentas de criação de relatórios gerenciais padronizados, de consultas ad hoc (de domínio conhecido pelo usuário), denominadas como OLAP (Online Analytical Processing) e extensões como o SIG (Sistema de Informação Geográfica) e o Data Mining (Mineração de dados não intuitivos por
modelos estatísticos como agrupamentos e predições, de domínio parcial pelos usuários). Processo de Desenvolvimento As fases do projeto de BI seguidas foram: Levantamento Preliminar, Planejamento, Análise do Negócio, Projeto, Construção, Testes, Homologação e Implantação. Na fase de Levantamento Preliminar do projeto de BI foram feitas reuniões com os usuários para identificar os relatórios gerenciais e as áreas de interesse. A partir do protótipo de cada relatório gerencial especificado e validado foi possível identificar as áreas de interesse para o projeto de BI: Básicos: Estabelecimentos, Profissionais, Usuários SUS e Procedimentos. Complexos: Equipes de Saúde, Atividades Coletivas, Vacinação, Vagas, Agendamentos, Fila de Espera, Atendimentos e Regulação. Os objetivos das áreas de interesse que derivaram os Data Marts com o mesmo nome são os seguintes: Estabelecimentos permitirá um maior conhecimento da quantificação, distribuição administrativa e caracterização dos Estabelecimentos de Saúde da rede assistencial no município. Profissionais permitirá um maior alocação nos Estabelecimentos de Saúde e caracterização dos Profissionais de Saúde como especialidade e forma de contratação, que podem auxiliar na identificação de falta de profissionais e especialidades para possíveis ações de contratações. Usuários SUS permitirá um maior distribuição e caracterização dos Usuários SUS cadastrados no município como, por exemplo, faixa etária, sexo, nacionalidade, residentes em outros municípios, endereço, distrito administrativo e escolaridade. Permitirá também avaliar a qualidade dos dados no processo de cadastramento. Procedimentos - permitirá um maior distribuição e caracterização dos procedimentos solicitados e realizados, de acordo com a Tabela Unificada, nas regiões administrativas, estabelecimentos de saúde, nos seus grupos, subgrupos, forma de organização e nos níveis de complexidade de atenção básica, média e alta complexidade. Poderá auxiliar, por exemplo, nos processos de Faturamento, Atenção Básica e Regulação, incluindo a gestão do processo de autorização de procedimentos de alta complexidade (APAC) no que se refere a unidades solicitantes, unidades executantes, incluindo prestadores de serviço, autorizador/regulador, CID e tipo de APAC. Equipes de Saúde permitirá um maior distribuição e caracterização das Equipes de Saúde, Agentes Comunitários, Micro-Áreas e Famílias. Atividades Coletivas permitirá um maior conhecimento e administração da quantificação, distribuição e caracterização das atividades coletivas de acordo com as regiões administrativas, estabelecimentos de saúde, procedimentos, nº de sessões, nº de inscritos, nº de participantes, faixa etária, sexo e raça. Vacinação - permitirá um maior distribuição dos lotes de vacinas, caracterização, e administração dos lotes e vacinações nas regiões administrativas, estabelecimentos de saúde, tipo de vacinação, vacinas, dose válida e não válida, apoiando na atividade de mapas e produção vacinal. Vagas - permitirá um maior conhecimento e avaliação e administração da quantificação, distribuição e caracterização das ofertas de vagas para agendamentos de acordo com as regiões administrativas, estabelecimentos de saúde, especialidades, profissionais de saúde, tipo de atendimento e cancelamentos. Agendamentos - permitirá um maior distribuição e caracterização dos agendamentos de acordo com as regiões administrativas, estabelecimentos de saúde, especialidades, profissionais de saúde, tipo de atendimento e cancelamentos. Também permitirá avaliar a demanda reprimida e as regiões de maior movimentação por especialidade para possíveis ações de distribuição e contratações. Fila de Espera - permitirá um maior distribuição e caracterização das filas de espera para agendamentos, de acordo com as regiões administrativas, estabelecimentos de saúde, usuários SUS em espera, especialidades, tipo de atendimento e prioridades para uma melhor administração e atendimento dos pacientes em espera com mais agilidade.
Atendimentos - permitirá um maior distribuição e caracterização dos atendimentos, de acordo com as regiões administrativas, estabelecimentos de saúde, especialidades, tipo de atendimento, especialidade, profissional de saúde, CID e Procedimentos. Também permitirá conhecer melhor toda a produção, diagnósticos mais freqüentes, apoio à vigilância epidemiológica, condutas dos profissionais, que podem promover melhorias e programas de saúde para uma melhor assistência ao usuário SUS. Regulação - permitirá um maior distribuição, caracterização e administração das solicitações de agendamentos, autorização de agendamentos, devolução de solicitações de agendamentos, reguladores, nível de regulação (Regional ou Central), unidades solicitantes, unidades executantes e unidades reguladoras. Também permitirá o atendimento dos pacientes em espera com mais agilidade, avaliar as regiões de maior movimentação por especialidade para possíveis ações de distribuição e contratações. Definida as áreas de interesse acima foi possível fazer um Planejamento do Projeto: requisitos, cronograma, formação da equipe, custo, prazos, entregas, tecnologia de apoio, infra-estrutura e ambientes de desenvolvimento, homologação e produção [1]. Em seguida, iniciada a fase de Análise de Negócio, foi elaborado protótipo na ferramenta OLAP e de telas da funcionalidade de relatórios gerenciais no SIGA Saúde, que foram verificados e validados pelos usuários, o que permitiu uma melhor definição do escopo para a arquitetura de dados. A arquitetura de dados, já na fase de Projeto, foi desenvolvida em três tipos de modelos de dados, conforme a proposta de Ralph Kimball: o modelo de dados relacional do DW, o modelo de dados relacional da Staging Area e o modelo dimensional dos Data Marts [1] e [3]. Figura 2. Arquitetura do processo de ETL. A partir da revisão dos processos, regras e conceitos, foi feita uma modelagem de dados relacional do DW das áreas de interesse identificadas de forma padronizada e mais simplificada como, por exemplo, um modelo para área de interesse vagas e outro para Agendamentos, unificação dos modelos de agenda local e regulada e padronização do status para estas duas áreas de interesse. Por outro lado, foi feita também a modelagem de dados relacional da Staging Area, de acordo com cada área de Interesse, com as mesmas tabelas do modelo de dados relacional do SIGA Saúde. Finalmente, foi feita a modelagem de dados dimensional dos Data Marts, na representação Estrela (Star Schema), proposta por Ralph Kimball [2], composto de uma tabela central de totalizações, denominada tabela Fato, em um conjunto de tabelas periféricas ligadas à tabela fato, denominadas Dimensões e em alguns casos, foi necessária a representação Floco de Neve (Snow Flake), que normaliza dimensões. Segue abaixo um exemplo de modelo de representação Estrela da tabela fato de Atendimento. Segue abaixo a arquitetura do processo de ETL do projeto mencionado acima: Figura 4. Modelo de representação Estrela da tabela fato de Atendimento Em todos os modelos, os metadados e as regras necessárias para os procedimentos de ETL associadas às tabelas da Staging Area foram
documentados em uma ferramenta de mercado para modelagem de dados. Na fase de Construção, foram criados as tabelas e os índices, implementados os procedimentos de extração, transformação e carga (ETL) na linguagem PL/SQL, definidos os metadados de orientação, bem como as suas execuções no SGBD, tanto no ambiente de desenvolvimento para testes e ajustes, como no do ambiente de homologação, dentro de um período menor para efeito e facilidade de homologação pelo usuário [1]. Ainda nesta fase, os mapeamentos dos Data Marts, Cubos ou Universos das áreas de interesse foram construídos na ferramenta de OLAP denominada Infomax da Atech, uma customização com recursos adicionais de uma ferramenta de Business Intelligence, utilizando o DW como uma estrutura relacional de dados, compondo um tipo de implementação denominado de ROLAP (Relational Online Analytical Processing). A ferramenta Infomax customizada para atender o BI em Saúde Pública foi batizado como Infosaude, uma ferramenta amigável ao usuário que oferece recursos de drag and drop, gráficos, planilhas, drill up, drill down e publicação de relatórios, onde também foram registrados os metadados para orientação. Figura 3. Apresentação do relatório de agendamentos em planilha ou gráfico. Também está sendo implementado o SIG, de acordo com os Data Marts em mapa geográficos do município integrados à ferramenta OLAP Infosaude. Utilizando uma aplicação para visualização de informações geográficas, o sistema apresenta a distribuição de quantidades de agendamentos, por exemplo, pelas divisões operacional/administrativa do município Esta aplicação possui as funcionalidades mais comuns encontradas nas ferramentas SIG de mercado, como: aproximação (zoom in), afastamento (zoom out), deslocamento (pan), pesquisa e seleção. Além disso, é apresentada a legenda de cores temáticas para determinar em que faixa de valor cada região se encontra. A vantagem deste sistema é de ter a percepção visual na distribuição espacial dos indicadores relacionados às áreas de interesse definidos pelo cliente. Figura 4. Apresentação de indicador de quantidades de agendamentos através de mapa temático. Na fase de construção também foram realizados testes em termos de resultados e performance das procedures de ETL, dos resultados obtidos na ferramenta OLAP comparando com dados do próprio sistema transacional, em um ambiente de desenvolvimento [1]. A etapa de Homologação está em andamento, sendo realizada pelo cliente através da aplicação Infosaude, utilizando a ferramenta OLAP de extração de relatórios, onde receberam um rápido treinamento, em um ambiente dedicado à homologação. Foram realizadas diversas reuniões para dirimir as dúvidas e levantar os desvios nos resultados esperados no BI, a partir dos dados do sistema transacional. A cada avaliação foram executados os ajustes necessários nos procedimentos de carga ou na própria estrutura de dados do Data Warehouse e executado o ETL no ambiente de homologação para uma nova avaliação dos resultados obtidos [1]. A fase de Implantação, próxima etapa, contemplará a instalação do sistema de BI no ambiente de produção, seja como ferramenta OLAP e toda a carga de dados. Também será realizado o treinamento na ferramenta OLAP Infosaude aos usuários autorizados a utilizá-la [1]. Discussão e Conclusões Para este projeto de BI, estão sendo muito importante as ações de um patrocinador com visão em tendência tecnológica, que investiu e apresentou os benefícios e resultados, bem como usuários que conheçam o negócio e a tecnologia e que saibam como analisar os dados tradicionalmente gerados diariamente pelo sistema transacional, para gerar informações que o permitam conhecer melhor o negócio para ações que possam melhorar a qualidade de
atendimento e assistência aos usuários SUS e não apenas disponibilizar os dados. Um dos maiores desafios de um projeto de DW é a gestão de requisitos, que deve ser muito bem definido no início do projeto. Na fase de Levantamento de Requisitos e Análise de Dados deve ter o acompanhamento e validação do usuário, para que não haja ajustes, retrabalho ou complementos na fase de homologação. Naturalmente, em um projeto deste porte sempre há a necessidade da realização de ajustes a partir da análise dos resultados. Tomamos como aprendizado e melhoria no processo, a participação ativa do cliente não apenas na fase de validação dos requisitos, como na validação dos modelos obtidos na arquitetura de dados, para um processo de homologação mais rápido e alinhado. As solicitações de ajustes e complementos aumentaram o escopo previsto no início do projeto, o que resultou em um trabalho de revisão dos modelos e das procedures de ETL para atender os resultados esperados. Vale ressaltar a facilidade de utilização das ferramentas de consulta, relatórios e publicação pelas ferramentas utilizadas neste projeto. Porém, a arquitetura criada e o processo utilizado em seu desenvolvimento independe da ferramenta OLAP utilizada, possibilitando a portabilidade, caso seja necessária. O próximo passo é a extensão para a extração de informações qualitativas pelo processo, técnicas e ferramentas de Data Mining e a utilização da técnica de Dashboards (painel de indicadores) para acompanhamento dos indicadores de performance, obtidos pela técnica de Balanced Scorecard alinhada aos objetivos e metas da empresa. Agradecimentos Os autores agradecem ao Dr. Cláudio Giuliano da Costa pelo apoio no projeto, aos Srs. Pedro Scarpim, Marcelo Ribeiro de Almeida e Renato Barreto Rosolem por desenvolverem essa oportunidade de negócio, ao Sr. Robert Douglas Barbosa Funchal que participou na construção e a Sra. Lucia Beatriz de Area Leão Alves por gerenciar o projeto. Referências [1] MOSS, Larissa T. ; ATRE, Shaku. Business Intelligence Roadmap, The Complete Project Lifecycle for Decision Support Applications. Boston: Addison-Wesley, 2003. [2] KIMBALL, Ralph; ROOS, Margy The Data Warehouse Toolkit. Rio de Janeiro: Campus, 2002. [3] KIMBALL, Ralph. The Data Warehouse Lifecycle Toolkit Expert Methods for Designing, Developing and Deploying Data Warehouses. New York: John Willey & Sons, 1998. [4] INMON, W. H. Como Construir o Data Warehouse. Rio de Janeiro: Campus, 1997. [5] MACHADO, Felipe N. Rodrigues. Tecnologia e Projeto de Data Warehouse. São Paulo: Érica, 2006. [6] BARBIERI, Carlos. Business Intelligence Modelagem e Tecnologia. São Paulo: Axcel Books, 2001. [7] MONTEIRO, André Vinícius G.; PINTO, Marcos Paulo O.; COSTA, Rosa Maria E. M.Uma Aplicação de Data Warehouse para Apoiar Negócios. Rio de Janeiro, 2005. Contato Gilberto Capatina Valente possui MBA em Inteligência Competitiva com ênfase em BI/BPM pela FIAP e MBA em Gestão de Tecnologia da Informação pela Fundação Getúlio Vargas e é graduado em Ciência da Computação pela Pontifícia Universidade Católica de São Paulo, atuando na área de Tecnologia da Informação há 15 anos. É Consultor Sênior da Atech, onde atua nos projetos de implantação e evolução do SIGA Saúde e no projeto de BI para gestão ambulatorial. Newton Naoki Ahagon possui graduação em Engenharia Elétrica na Universidade de São Paulo com ênfase em Automação e Controle. É consultor especialista em sistemas de BI e SIG (Sistemas de Informações Geográficas) na Atech, e implantou soluções de BI e SIG para as Secretarias de Segurança Pública nos estados de Pernambuco, Mato Grosso, Ceará, Amazonas, Acre e Rondônia. Atualmente desenvolve solução de BI para gestão ambulatorial. Endereço: Rua do Rócio, 313 11 o. andar, 04552000 São Paulo, SP, telefone: 11 3040-7300 e-mails:gvalente@atech.br/gcvalente@uol.com.br e nahagon@atech.br/nahagon@hotmail.com.