Data Warehouse a experiência da ANVISA Camilo Mussi, Denis Murahovschi, Giliana Bettni, Luiz Gustavo Kratz Assessoria da Presidência, Agência Nacional de Vigilância Sanitária (ANVISA), Brasil Resumo - O contexto em que se vive atualmente demanda das organizações uma capacidade de analisar, planejar e reagir rapidamente para poder acompanhar ou superar as exigências dos clientes. A todo o momento, uma grande quantidade de informações, sobre os mais variados aspectos dos negócios da empresa, é gerada, armazenada, passando a fazer parte da base de conhecimento. Entretanto, esses dados estão espalhados por vários sistemas de difícil integração, sem qualidade e indisponíveis para os gerentes e altos executivos que são os tomadores de decisões estratégicas das organizações. Para suprir essa deficiência surgiu o Data Warehouse (DW), que se constitui de um conjunto de arquiteturas e/ou sistemas de informação orientados a assunto que existem em plataformas segregadas do ambiente transacional, manipulando grande volume de dados, principalmente históricos, e dão origem a consultas invariavelmente não previsíveis, que tem por objetivo dar suporte a esses processos. O objetivo desse trabalho é apresentar como foi implementada esta tecnologia na Agência Nacional de Vigilância Sanitária (ANVISA), os principais conceitos e questões envolvidas, procurando enfatizar a importância de sua utilização para garantir agilidade e segurança na tomada de decisão na área da Saúde, definindo o caminho a ser desenvolvido desde a modelagem até a implantação de um DW. Palavras-chave: Data Warehouse, Sistemas de Apoio à Decisão, Sistemas de Informações Executivas. Abstract - O contexto em que se vive atualmente demanda das organizações uma capacidade de analisar, planejar e reagir rapidamente para poder acompanhar ou superar as exigências dos clientes. A todo o momento, uma grande quantidade de informações, sobre os mais variados aspectos dos negócios da empresa, é gerada, armazenada, passando a fazer parte da base de conhecimento. Entretanto, esses dados estão espalhados por vários sistemas de difícil integração, sem qualidade e indisponíveis para os gerentes e altos executivos que são os tomadores de decisões estratégicas das organizações. Para suprir essa deficiência surgiu o Data Warehouse (DW), que se constitui de um conjunto de arquiteturas e/ou sistemas de informação orientados a assunto que existem em plataformas segregadas do ambiente transacional, manipulando grande volume de dados, principalmente históricos, e dão origem a consultas invariavelmente não previsíveis, que tem por objetivo dar suporte a esses processos. O objetivo desse trabalho é apresentar como foi implementada esta tecnologia na Agência Nacional de Vigilância Sanitária (ANVISA), os principais conceitos e questões envolvidas, procurando enfatizar a importância de sua utilização para garantir agilidade e segurança na tomada de decisão na área da Saúde, definindo o caminho a ser desenvolvido desde a modelagem até a implantação de um DW. Key-words: Data Warehouse, Decision Support Systems, Executive Information Systems. Introdução O contexto em que se vive atualmente demanda das organizações uma capacidade de analisar, planejar e reagir rapidamente para poder acompanhar ou superar as exigências dos clientes e à ameaça da concorrência. Para que isto aconteça, é necessário que a organização tenha disponível, quando necessário, as informações que constituem a base para obtenção de vantagens competitivas e maior fidelidade dos clientes. As inovações tecnológicas que estão chegando ao mercado permitem que as informações que irão garantir a supremacia da organização nesse novo mercado sejam manipuladas a nível global e num grande volume. A todo o momento uma grande quantidade de informações, sobre os mais variados aspectos dos negócios da empresa, é gerada e armazenada, passando a fazer parte da base de conhecimento. Entretanto, esses dados estão, geralmente, espalhados por vários sistemas, de difícil integração, sem qualidade e indisponíveis para os gerentes e altos executivos que são os tomadores de decisões estratégicas das organizações. Para suprir essa deficiência surgiu o Data Warehouse (DW), que se constitui de um conjunto de arquiteturas e/ou sistemas de informação
orientados a assunto que existem em plataformas segregadas do ambiente transacional, manipulando grande volume de dados, principalmente históricos, e dão origem a consultas (read-only) invariavelmente não previsíveis, que tem por objetivo dar suporte a esses processos, segundo W. H. Inmon [1]. Nesse sentido, considerando a importância da informação em subsidiar à tomada de decisão, está sendo implantado um Data Warehouse para avaliação das áreas de atuação da Agência Nacional de Vigilância Sanitária (ANVISA). A ANVISA é uma autarquia sob regime especial, ou seja, uma agência reguladora caracterizada pela independência administrativa, autonomia financeira e estabilidade de seus dirigentes durante o período de mandato, vinculada ao Ministério da Saúde. A finalidade institucional da Agência é promover a proteção da saúde da população por intermédio do controle sanitário da produção e da comercialização de produtos e serviços submetidos à vigilância sanitária, inclusive dos ambientes, dos processos, dos insumos e das tecnologias a eles relacionados. Além disso, exerce o controle de portos, aeroportos e fronteiras e a interlocução junto ao Ministério das Relações Exteriores e instituições estrangeiras para tratar de assuntos internacionais na área de vigilância sanitária. Os sistemas operacionais existentes estão atendendo a ANVISA de forma satisfatória, porém, esse atendimento é direcionado aos usuários operacionais. Os módulos gerenciais dos sistemas existentes não atendem as demandas de informações não estruturadas para a tomada de decisão. Essas demandas são constantes e, na maioria das vezes, não é possível atender dentro da expectativa em relação ao prazo. Em muitos casos, quando a demanda é atendida, a decisão já tem sido tomada com a informação que o usuário dispunha. Em outros, após analisar o resultado, o usuário solicita modificações no mesmo, gerando nova demanda a qual passa a concorrer com outras que já estão na fila, enfim, não se consegue atender bem os clientes tomadores de decisão. Metodologia Em meados de 2002, para resolver este problema, a ANVISA tomou a decisão de adotar a tecnologia de Data Warehouse (DW). Começou então o desenvolvimento de um protótipo em uma área escolhida, levando-se em conta a complexidade e a importância da mesma para a missão da ANVISA, que foi a Avaliação de Serviços de Saúde. Novos temas foram desenvolvidos, posteriormente, no DW, como Recursos Humanos, Arrecadação e outros. A ANVISA tem desenvolvido o DW de forma corporativa e incremental. O fato é que o DW se tornou a solução proposta para apoiar o processo decisório na instituição. As principais fontes de dados do DW são os sistemas transacionais ou On-Line Transaction Processing (OLTP) que atendem aos usuários da ANVISA e do Ministério da Saúde. Esses sistemas possuem bases de dados relacionadas com o assunto de interesse e que estão disponíveis para os processos de extração, transformação e carga (ETC). A integração de várias fontes é feita por meio do compartilhamento do significado dos dados. É uma característica que permite que informações de fontes distintas possam ser vinculadas entre si e apresentadas com significado correto, lado a lado, no mesmo relatório. No caso do Tema Avaliação de Serviços de Saúde, a principal fonte de dados externos é o DATASUS, por meio dos diversos sistemas existentes. A metodologia de desenvolvimento do DW é baseada na proposta por Kimball [2] do ciclo de desenvolvimento do DW. Para a infra-estrutura de DW, foram adquiridos equipamentos com grande área de disco para armazenar o volume de dados e com processadores paralelos para proporcionar melhores tempos de resposta. Os processos de extração e de transformação são executados utilizando soluções próprias da ANVISA, por meio de ferramenta de programação, portanto, a Staging Área, para transformar e integrar os dados operacionais antes de serem carregadas para o DW, começa no próprio ambiente operacional. Os arquivos resultantes desses processos de extração e transformação, no ambiente operacional, são transportados para a plataforma onde se encontra o DW. Após o processo de transporte, ocorrem ainda processos de transformação onde os dados sofrem as últimas alterações e são carregados no DW, por meio das ferramentas do Sistema Gerenciador de Banco de Dados Oracle. Os dados do DW estão armazenados ao nível de granularidade mais atômico possível e de forma corporativa incremental. A modelagem dos dados é multidimensional, na visão estrela (star schema), documentada com o Software Power Designer. As principais questões observadas na modelagem, para que as consultas não produzissem resultados incorretos, foram:
Atributos semi-aditivos e não aditivos: Uma operação não aditiva, como o cálculo da margem bruta, pode ser computada em qualquer plano da tabela de fatos, lembrando-se de calcular o quociente das somas, não a soma dos quocientes. Em outras palavras, o resultado deve ser a divisão das somas e não o inverso. Uma operação semi-aditiva não pode ser adicionada ao longo de todas as dimensões da tabela de fatos, deve-se limitar com isso a operação às dimensões válidas. Dimensões descaracterizadas: Números de controle de documentos, como números de autorizações ou números de controle, normalmente são representados como dimensões descaracterizadas (isto é, chaves de dimensão sem uma tabela correspondente) em tabelas de fatos em que o grão da tabela é o documento propriamente dito ou uma linha de item do documento. Dimensões derivadas que suportam agregados: Ë extremamente importante construir tabelas de fatos derivadas (resumidas) em vários níveis superiores de detalhe para melhorar o desempenho das consultas, que de outra forma apresentariam um grande número de registros. Existem muitas formas de agregados no DW, sendo as mais comuns: a. Cumulativa simples: as transações diárias são transportadas do ambiente operacional e resumidas em forma de registros no DW. O resumo pode ser feito por qualquer área de interesse, segundo a qual o DW esteja organizado. b. Resumo rotativo: os dados passam do ambiente operacional para o DW como mencionado anteriormente. A diferença está na forma como é agregado. Por exemplo, nesta estrutura, nos primeiros sete dias da semana a atividade é resumida em sete posições diárias. No oitavo dia, as sete posições diárias são acumuladas e colocadas na primeira posição semanal. No final do mês, as posições semanais são acumuladas e colocadas na primeira posição mensal. No final do ano, as posições mensais são acumuladas, e a primeira posição anual é carregada. Existem vantagens e desvantagens nesta abordagem com relação a anterior: Os dados podem ser processados para encontrar o ponto mais alto, mais baixo, a média, e assim por diante. A primeira e a última ocorrência de dados podem ser dispostas em um bloco. Dados de determinados tipos, inseridos nos limites de diversos parâmetros, podem ser mensurados. Dados válidos em relação a um determinado momento podem ser dispostos em um bloco. Os dados mais antigos e os mais recentes podem ser dispostos em um bloco. c. Dimensões grandes: não se devem desmembrar as dimensões, mesmo que elas sejam extensas, pois poderá causar um desempenho limitado. A melhor abordagem para rastrear modificações nessas tabelas é subdividi-las em minidimensões compostas por pequenos conjuntos de atributos estruturados para conter um número limitado de valores. d. Dimensões de modificação lenta: o DW deve representar de forma concreta o histórico passado, por isso não se pode considerar que as entidades não se modificam ao longo do tempo. Entretanto, a solução não será incluir tudo na tabela de fatos ou tornar cada dimensão dependente no tempo. Em vez disso, deve-se explorar o fato de que a maioria das dimensões é constante ao longo do tempo e que se pode preservar uma estrutura dimensional independente, incluindo relativamente poucas adições para capturar o aspecto temporal das modificações. Essas dimensões praticamente constantes são chamadas de dimensões de modificação lenta. Existem três opções de modificação destas dimensões, cada uma delas resultando em um diferente nível de rastreamento de modificações ao longo do tempo: Substituir os valores antigos dos registros da dimensão e, portanto, perder a capacidade de rastrear o histórico passado. Adicionar um registro à dimensão, contendo os novos valores do atributo no momento da mudança, para segmentar o histórico entre a descrição antiga e a nova descrição com muita precisão. Criar novos campos atuais no registro original da dimensão para incluir os novos valores do atributo, mantendo também seus valores originais, permitindo dessa forma descrever o histórico anterior e o posterior à mudança tanto em relação aos valores originais do atributo quanto aos valores atuais. e. Tabela de fatos sem fatos: alguns processos que são representados no DW produzem tabelas de fatos semelhantes às tabelas que foram construídas, mas que não contém fatos mensuráveis. São chamadas de tabelas de fatos sem fatos. As duas principais variações dessas tabelas são tabelas de rastreamento de eventos e tabelas de cobertura. Os eventos são geralmente modelados por uma tabela de fatos contendo algumas chaves, cada qual representando uma dimensão do evento, freqüentemente não estão associadas a fatos numéricos óbvios. As tabelas de
cobertura são, freqüentemente, tabelas de eventos que não ocorreram e, de modo geral, não contém fatos assim como as tabelas de rastreamento de eventos. Para acessar os dados do DW e realizar suas análises, os usuários finais utilizam a ferramenta On-Line Analytical Processing (OLAP) da Microstrategy. Os resumos e agregações são disponibilizados para acesso pelos usuários finais no mesmo ambiente do DW corporativo, podendo o usuário acessar, até mesmo, os dados mais atômicos, obedecendo à abrangência do Tema. Durante a implementação do DW foram identificadas as seguintes dificuldades: Falta de envolvimento/comprometimento de profissionais, com os perfis necessários. Para o desenvolvimento de um projeto de DW, é imprescindível que a equipe designada para o trabalho, além de estar envolvida e comprometida com o resultado deste trabalho, reúna, também, o domínio completo dos seguintes pontos: Conhecimento de modelagem multidimensional; Conhecimento do negócio do cliente; Conhecimento das necessidades do cliente; Conhecimento das bases e sistemas de origem (sistemas legados) esta dificuldade fez com que houvesse uma troca completa da equipe que iniciou o projeto, trazendo um atraso na implantação do DW; Falta de delimitação de um escopo para a primeira versão do projeto. O cliente tende a querer todas os dados existentes nos sistemas legados (fontes), desde a primeira versão. Isso, geralmente aumenta a complexidade do modelo, gerando dificuldade na utilização pelos usuários, o que leva ao desânimo e abandono, deixando a impressão de que DW é muito complicado e difícil de ser usado não se terminava o primeiro projeto porque não se sabia onde este era finalizado; Falta de uma previsão orçamentária compatível com o projeto a aquisição de equipamentos e software dependia de verba a ser alocada. Conforme a metodologia adotada, foram executados 11 (onze) processos para que fosse possível extrair os dados do banco de dados de produção e enviá-los para o DW. O conjunto desses processos é chamado, por Ralph Kimball [2], de Sistemas de Extração de Dados de Produção (SEDP) e são: 1. Extração primária; 2. Identificação dos registros modificados; 3. Generalização de chaves para dimensões em modificações; 4. Transformação em imagens de registros de carga; 5. Migração do sistema legado para o sistema DW; 6. Classificação e construção de agregados; 7. Generalização de chaves para agregados; 8. Carregamento; 9. Processamento de exceções; 10. Garantia de qualidade e 11. Publicação. Foi necessária a criação de rotinas de carga para atender determinadas situações que ocorreram. A catalogação dos sistemas de produção que alimentam o DW é de suma importância para identificação precisa da extração primária dos dados. Pode-se dizer que o processo de limpeza e transformação dos dados que foram carregados no DW serviu para corrigir algumas imperfeições contidas nas bases de dados transacionais, a fim de fornecer ao usuário do sistema analítico dados concisos e com uma qualidade que permitisse uma tomada de decisão baseada em valores mais próximos dos reais. Idealmente, pode-se imaginar que o dado deveria apenas ser convertido para padronização de medidas, porém existem valores incorretos nas bases de dados transacionais, os quais não podem ser propagados, principalmente no momento em que serão analisados, muitas vezes comparativamente. Como exemplo, existem campos de preenchimento obrigatório, com valores que não existem na tabela relacionada, como Município. Existem campos preenchidos, como o de Nascidos Vivos, que é previsto ser preenchido quando existe o nascimento de crianças, mas estão preenchidos para indivíduos do sexo masculino. Além disso, a limpeza é necessária porque os dados normalmente advêm de uma fonte muitas vezes desconhecida, concebida há muito tempo, contendo muito lixo e inconsistência, porque o interesse de cada usuário ao preencher os dados relativos a qualquer assunto é específico a este. Por isso, nessa fase do DW, fez-se a limpeza dos dados, para haver compatibilidade entre os mesmos. O processo de limpeza não estará completo sem que se possam livrar os dados de problemas que, por algum motivo, passaram despercebidos nos sistemas de origem, tais como: códigos inválidos e preenchimento de vários campos com valores incompatíveis entre si. A própria modelagem do sistema transacional pode conter pontos fracos que permitam, por assim dizer, a existência de dados inconsistentes, os quais podem e devem ser filtrados antes da carga no DW.
Pode-se e encontraram-se dados com os seguintes problemas: Diferenças de unidades: campos de idade dos pacientes em anos ou em meses, sendo necessário converter todas as medidas para qualquer uma das duas (ou todas em anos, ou todas em meses) ou, mantendo-as, entender como devem ser trabalhadas; Diferenças de precisão: alguns valores representados, por exemplo, com duas casas decimais em uma tabela e com quatro casas decimais em outra tabela, cabendo ao administrador do DW definir qual a precisão desejada; Diferenças de códigos ou expressões: em campos que são codificados nos sistemas transacionais a fim de reduzir o espaço de armazenamento, agilizar e padronizar a entrada de dados, para que não existam valores iguais com significados diferentes; Diferenças de granularidade: é o caso de um campo que totalize as horas despendidas para realizar uma determinada tarefa, como reuniões realizadas num mês que pode ser confundido com outro campo que totalize as horas gastas com reuniões numa semana, não sendo possível utilizar estes campos para realizar comparações ou totalizações sem as devidas conversões; Diferenças de abstração: no caso do campo de telefone ser armazenado com o DDD separado dos números normais em uma fonte enquanto que em outra fonte estes números estão combinados em um só campo. Normalmente as ações de correção das anomalias encontradas não se deram automaticamente com uma rotina específica, até porque isto poderia ter sido feito já na própria base transacional. O que se procurou é solucionar as pendências caso a caso, tentando corrigir inclusive a base original. O processo de transformação de dados no DW ocorreu porque as origens dos dados são de sistemas diferentes, sendo necessário padronizar os diferentes formatos. Por exemplo: em alguns sistemas a informação sobre o sexo do cliente pode estar armazenada no seguinte formato: M para Masculino e F para Feminino. Porém, em algum outro sistema pode estar armazenado como H para Masculino e M para Feminino e assim sucessivamente. Quando esses dados forem carregados para o DW, deve-se ter uma padronização deles, ou seja, quando o usuário for consultar o DW, ele não pode ver informações iguais em formatos diferentes [1]. A carga dos dados foi feita a partir de um sistema de banco de dados temporário, no qual os dados já passaram pelo processo de limpeza e integração (transformação). As tabelas que são atualizadas no sistema de DW foram montadas utilizando-se agregações, sumarizações e ordenações dos dados. A velocidade de carga influencia de forma drástica na performance do sistema. Muitas vezes são excluídos os índices de ordenação das tabelas com a finalidade de reduzir a quantidade de controles a serem monitorados pelo Sistema Gerenciador de Banco de Dados (SGBD), reconstruindo-as posteriormente, após a conclusão da carga. A todo o momento são realizadas alterações nas bases de dados transacionais. Estas modificações, inclusões de novos registros ou cadastro de novos dados, devem ser atualizadas para o DW a fim de que este esteja condizente com a atualidade das fontes de origem. Esta periodicidade deve ser determinada levando-se em conta o volume de dados e a necessidade dos usuários, podendo ser diária, semanal, mensal ou qualquer outro período determinado. Resultados Os estudos realizados até o presente momento mostram que é possível, a partir do DW implantado, no Tema Avaliação em Serviços de Saúde, executarem-se diversos relatórios gerenciais, com a especificidade de cada usuário, para que este possa tomar a melhor decisão. Existem dados relativos a Internações Hospitalares (AIH) desde janeiro de 2000 até dois meses anteriores ao atual. Em relação a Autorizações de Procedimentos de Alta Complexidade (APAC) existem dados desde janeiro de 1998 até um mês anterior ao atual e, em relação ao Cadastro Nacional de Estabelecimentos de Saúde (CNES), os dados são atualizados semanalmente. Todos estes dados podem ser cruzados em inúmeros relatórios. Podem-se executar relatórios gerenciais sobre qualquer uma das seguintes dimensões (pontos de vista do usuário), combinadas de qualquer modo, em relação, por exemplo, a AIH: Hospital; Município do Hospital; Unidade da Federação do Hospital; Natureza do Hospital; Tipo de AH; Especialidade; Caráter da Internação; Procedimento Solicitado; Procedimento Realizado; Diagnóstico Principal;
Diagnóstico Secundário; Motivo de Cobrança; Tipo de UTI; Sexo; Nacionalidade; Município do Paciente; Unidade da Federação do Paciente; Idade de Internação do Paciente; Idade de Saída do Paciente; Data de Internação; Data de Saída; Data de Emissão e outras. Pode-se também cruzar com dados do CNES, como: Fluxo de clientela; Equipamentos; Níveis de Hierarquia; Município do Paciente; Tipo de Unidade; Atendimento Prestado; Leitos; Serviços Especializados; Habilitações e outras. Também dados da APAC podem ser utilizados. Os valores, a partir das dimensões anteriores, que podem ser visualizados são: Quantidade de AIH s; Idade média, máxima ou mínima (de internação e saída); Total de óbitos; Total de nascidos vivos; Total de saídas; Total por qualquer uma das dimensões; e diversos outros. Discussão e Conclusões A implantação da tecnologia de Data Warehouse, em uma instituição de saúde, de qualquer porte, possibilita a busca e interpretação de informações armazenadas, garantindo maior acuricidade nas tomadas de decisão; permite estabelecer uma aproximação integrada e colaborativa para capturar, criar, organizar e usar todos os ativos de informação de uma empresa; consegue antecipar as mudanças bruscas no mercado; conhecer o negócio; ter uma visão clara sobre novos negócios; auxilia na implementação de novas ferramentas gerenciais; ter conhecimento sobre novas tecnologias, produtos ou serviços que possam afetar direta e indiretamente o seu negócio. Deve-se atentar para os possíveis erros na implantação de um DW que, segundo o Data Warehousing Institute [3] são: 1. Começar o projeto com o tipo errado de patrocínio; 2. Gerar expectativas que não podem ser satisfeitas, frustrando os executivos quando da utilização do DW; 3. Dizer: Isto vai ajudar os gerentes a tomar decisões melhores e outras informações politicamente ingênuas; 4. Carregar o DW com informações só porque estavam disponíveis ; 5. Falhar no objetivo de acrescentar valor ao dada por meio de mecanismos de desnormalização, categorização e navegação assistida; 6. Escolher um gerente que seja voltado para a tecnologia e não para o usuário; 7. Focalizar em dados tradicionais internos orientados a registro e ignorar o valor potencial de dados textuais, imagem, som, vídeo e dados externos; 8. Fornecer dados com definições confusas e sobrepostas; 9. Acreditar nas promessas de desempenho, capacidade e escalabilidade dos vendedores de produtos e 10. Usar o DW como justificativa para modelagem de dados e uso de ferramentas case. A ANVISA pode e propõe-se a disponibilizar, a todos os órgãos interessados, o modelo de dados que implantou e que possibilitará, aos usuários, neste primeiro momento, da AIH, APAC e CNES partir de um ponto mais avançado visando implantar um sistema de suporte à decisão, utilizando a tecnologia de um DW. Este trabalho serve também para despertar o interesse para a área de suporte à decisão, uma área que pode e deve disponibilizar as informações necessárias, consolidadas e, principalmente, em tempo hábil aos tomadores de decisão. Referências [1] Inmon, W.H. (1997), Como Construir o Data Warehouse, Rio de Janeiro: Campus. [2] Kimbal, Ralph (1998), Data Warehouse Toolkit, Rio de Janeiro: Makron Books. [3] Singh, H. S. (2001), Data Warehouse: conceitos, tecnologias, implantação e gerenciamento, Rio de Janeiro: Makron Books. Contato Camilo Mussi (61) 448-1129 - camilo.mussi@anvisa.gov.br