Projeto de um Data Warehouse para a Saúde Pública Ricardo S. Santos1, Marco Antônio Gutierrez2, Sergio Furuie2, Umberto Tachinardi3 1
Departamento de Informática em Saúde (DIS) Universidade Federal de São Paulo (UNIFESP), Brasil 2 Serviço de Informática, Instituto do Coração (INCOR) Universidade de São Paulo (USP), Brasil 3 Secretaria de Estado da Saúde de São Paulo
Resumo – As técnicas de Data Warehouse para produzir informações estratégicas destinadas à tomada de decisão têm despertado o interesse de organizações desde os anos 90. A área da saúde, sobretudo o segmento da saúde pública, começa adotar esta tecnologia para obter uma maior eficiência no gerenciamento da saúde. O objetivo deste trabalho é apresentar um projeto de Data Warehouse para a gestão da saúde pública. O Data Warehouse proposto pretende suprir a Secretaria de Estado de Saúde de São Paulo com informação gerencial obtida através da integração dos dados provenientes de diversas fontes isoladas. Este artigo detalha a metodologia e a estratégia adotadas para o projeto, as ferramentas utilizadas, os desafios encontrados e as soluções estabelecidas. A conclusão do trabalho mostra que os resultados obtidos, até o estágio atual, superam as expectativas iniciais e encorajam a ampliação do projeto. A experiência obtida com a implementação do data warehouse apresentada neste trabalho, pode contribuir, significativamente, em projetos similares na área da saúde. Palavras-chave: Data Warehouse, Gestão da Saúde, OLAP, Banco de Dados, Informática Médica. Abstract – The Data Warehouse techniques for powered strategic decision-making information are dominating the companies attention since the 1990s. The healthcare organizations, including the public healthcare organizations, are adopting this technology to achieve the better efficiency in the health management. The objective of this work is to present a Data Warehouse project for the management of the public health. The Data Warehouse will supply the Health Secretary of São Paulo with strategic information through the integration from several isolated data sources. This Paper details the methodology and strategy adopted for the project, the used tools, the challenges and the solutions. The conclusion show the success in the implementation of the first part of project and stimulate the continuity of the project. The experience obtained with the implementation of the data warehouse showed by this work, can be used to similar projects in the health care organizations.
Key-words: Data Warehouse, Health Management, OLAP, Databases, Medical Informatics.
Muitas iniciativas de sucesso, como o DW desenvolvido pela Universidade do Sul da Flórida para gerenciamento da saúde comunitária [2] e ferramentas para gerenciamento de doenças que identificam e incluem cidadãos com potencial para determinadas doenças em programas preventivos [3], incentivam a adoção desta tecnologia como um facilitador para o aumento de qualidade da saúde pública. O objetivo deste trabalho é apresentar um projeto de implementação de um DW destinado à gestão da saúde pública. O DW pretende suprir a Secretaria de Estado de Saúde de São Paulo (SESSP) com informação gerencial obtida através da
1. Introdução
A produção de informações estratégicas para tomadas de decisão, através das técnicas de data warehouse (DW), tem despertado o interesse de organizações desde os anos 90 [1]. Os benefícios obtidos com a utilização desta tecnologia são muitos. Entre eles destacam-se: - agilidade na tomada de decisão, melhor gerenciamento dos recursos, descoberta de novas oportunidades de negócio, etc. A área da saúde, sobretudo a da saúde pública, também busca, através de soluções DW, maior eficácia dos programas de saúde pública. 1
integração de dados provenientes de diversas fontes isoladas. O projeto será apresentado detalhadamente, mostrando o contexto e o escopo, a metodologia e estratégia adotada, as ferramentas utilizadas, e as soluções adotadas para os principais desafios.
dados contidos no DW. O principal meio para obtêlos ocorre através de ferramentas OLAP (On Line Analytical Processing), que são apropriadas para trabalharem com o modelo dimensional. Estas ferramentas permitem ao usuário elaborar análises sofisticadas através de diferentes e complexas visões [5]. Para auxiliar os processos envolvidos em uma solução DW, existe um amplo dicionário de dados denominado metadados. Segundo Berson [5], metadados são dados utilizados para descreverem os dados contidos no DW, além de descreverem, também, informações técnicas necessárias à administração do DW. As descrições contidas no metadados facilitam a elaboração de consultas e relatórios pelo usuário final.
2. Definições Para melhor compreensão do projeto apresentado neste trabalho, é necessário conhecer a arquitetura de uma solução DW, que está representada pela figura 1. Shams [1] define DW como uma plataforma que contém todos os dados da organização, centralizados e organizados de forma que usuários, de maneira muito simples, possam extrair relatórios analíticos complexos, contendo informações gerenciais para apoio à decisão. Pode-se observar, pela arquitetura, que os dados contidos no DW são provenientes dos sistemas operacionais. São considerados sistemas operacionais ou OLTP (On line Transaction Processing), os sistemas que registram os detalhes das transações ocorridas na organização [4]. A extração dos dados operacionais e a sua inclusão no DW, são denominados processo de carga, e correspondem a uma das mais árduas tarefas do projeto. Neste processo, são realizados procedimentos de limpeza, integração e transformação dos dados. Isto é necessário para que eles sejam inseridos no DW em um formato adequado à produção de informação gerencial [5]. Os procedimentos do processo de carga podem ser implementados por programas desenvolvidos em alguma linguagem de programação, ou, podem ser utilizadas ferramentas disponíveis no mercado destinadas a esta finalidade. São denominadas ferramentas ETL (Extracting, Transforming and Loading). Após a carga, os dados contidos no DW estão num modelo propício para a produção de informação gerencial. Este modelo é denominado Modelo Dimensional. Segundo Kimball [6], este modelo corresponde a uma maneira intuitiva de organizar os dados permitindo um acesso rápido. O modelo consiste em uma tabela central, denominada tabela fato, e num conjunto de tabelas periféricas ligadas à tabela fato, denominadas tabela dimensão. Finalmente é necessário disponibilizar ao usuário, em forma de informação gerencial, os
D a d o s O p e r a c i o n a is BD1
BD2
BD3
P ro c e s s o d e C a rg a ( F e r r a m e n ta s E T L )
DW
M e ta d a d o s
Acesso aos Dados ( F e r r a m e n ta s O L A P )
C o n s u lt a s /R e la t ó r io s G e r e n c ia is
Figura 1 – Arquitetura de uma solução DW. 3. O contexto do projeto Além de uma visão geral sobre a arquitetura de um DW, também é necessária uma noção sobre as instituições relacionadas ao projeto: A Secretaria da Saúde do Estado de São Paulo, como cliente das informações e o DATASUS, como provedor dos dados. As informações aqui apresentadas foram extraídas dos sites institucionais das respectivas instituições [7],[8]. A Secretaria de Estado da Saúde de São Paulo (SES-SP), é o gestor estadual do SUS Sistema Único de Saúde. Está constituída por 6 coordenadorias e 24 diretorias regionais. Além destas, integram a estrutura organizacional da SES2
SP, Fundações, Autarquias, Conselhos e Assessorias. Uma das metas da SES-SP é a construção de uma rede estadual de informações, cujo objetivo é garantir acesso à informação a todos os gestores do SUS e a cidadãos comuns. O Departamento de Informática do SUS (DATASUS) é o órgão responsável por “coletar, processar e disseminar informações sobre saúde". O DATASUS possui vários sistemas, cujos dados serão utilizados como fonte para o DW, entre eles destacam-se: O sistema de Informações Ambulatoriais (SIA); Informações Hospitalares (SIH); Estatísticas Vitais (IEV); Informações Epdemiológicas (IEP); Prestadoras de Serviços (PS) e materiais médicos (MAT).
As fontes de dados, representadas na figura 2, correspondem às bases de dados provenientes dos sistemas do DATASUS, além de planilhas e documentos internos. Cada base de dados do DATASUS corresponde a um conjunto de sistemas que foram agrupados na fase do estudo inicial. As informações produzidas devem atender três tipos diferentes de usuários: Os gestores municipais, os diretores regionais e os coordenadores. 4.1.
Metodologia de Desenvolvimento
Existem várias abordagens metodológicas para o desenvolvimento de um DW. Inmon [9], estabelece uma metodologia que pode ser resumida de acordo com a tabela 1.
4. O projeto O objetivo primordial é suprir a SES-SP e os gestores municipais de informações estratégicas referentes à “saúde” no estado de São Paulo. O objetivo do projeto é a definição e implementação de um DW para centralizar, integrar e disponibilizar as informações provenientes dos sistemas do DATASUS. Após um estudo inicial foi possível limitar um escopo para o projeto (figura 2).
Etapa
Descrição
1- Análise do Modelo de Dados
Elaborar o modelo de dados para o DW. Estimar o volume de dados que o DW vai conter. Definição das configurações técnicas para o DW Identificar tecnicamente como a configuração definida será acomodada. Seleção da área de negócio para ser povoada. Elaborar o projeto físico de banco de dados para o DW. Identificar, nos sistemas existentes, a fonte de dados para o DW, e efetuar um mapeamento entre eles. Definir, em especificações de programas, as rotinas para carga dos dados. Codificação das especificações para as rotinas de carga Execução das rotinas de carga do DW
2- Dimensionamento 3- Avaliação Técnica 4- Preparação do Ambiente Técnico 5- Análise das áreas de Interesse 6- Projeto do Data Warehouse
DATASUS
7- Análise do Sistema Fonte SIA
SIH
IEV
IEP
PS
MAT
8- Especificações
XLS DOC
9- Programação
WEB
Carga
10-Povoamento
Tabela 1. Metodologia para desenvolvimento de um DW (Inmon).
DW SESSP
Considerando as particularidades do nosso projeto, definimos uma metodologia específica, baseada na proposta por Inmon, porém, com a alteração de algumas etapas. A principal diferença é que Inmon sugere definir inicialmente o modelo do DW e depois estudar os sistemas fontes. Em nosso projeto iniciamos pelo estudo dos sistemas fontes para posteriormente definir o modelo do DW. Esta decisão é fundamentada no fato dos sistemas fontes pertencerem a outra instituição (DATASUS), portanto, o nosso modelo deve ser projetado em função dos dados disponibilizados por estes sistemas. A tabela 2 mostra a metodologia adotada para o projeto.
Front-End
Coordena -dorias
Diretorias Regionais
Gestores Município
Figura 2. Escopo global do projeto.
3
Etapa da metodologia
Equivalente Inmon
1- Estudo dos sistemas existentes (sistemas fontes) 2- Modelagem dos Dados 3- Análise do volume de dados 3- Definição das regras para carga 4- Definição da arquitetura do DW 5- Análise do Ambiente Operacional 6- Implementação do Ambiente Operacional 7- Implementação das rotinas de carga 8- Execução da Carga 9- Desenvolvimento dos relatórios
Etapa 7
Conseqüentemente, na fase de modelagem de dados são criados dois modelos: O modelo relacional, representado pelo DER (Diagrama de Entidade e Relacionamento) e o modelo dimensional, representado pelo Esquema Estrela. A figura 4 mostra uma parte do modelo dimensional do projeto, referente aos atendimentos ambulatoriais. Ainda, nas definições estratégicas, deve-se escolher as ferramentas para o desenvolvimento do projeto. O processo de escolha abrange vários aspectos, entre eles: robustez para suportar o volume de dados; existência de casos de sucesso implementados na ferramenta e um custo acessível. Considerando estes aspectos, foi adotado um conjunto de ferramentas Oracle, conforme tabela 3. Além das ferramentas adotadas, também foi utilizada uma ferramenta específica para automatização do processo de carga.
Etapa 1 Etapa 2 Etapa 8 Etapa 6 Etapa 3 Etapa 4 Etapa 9 Etapa 10
Tabela 2. Metodologia adotada para o projeto. 4.2.
Estratégia de Desenvolvimento
Visando permitir ao usuário usufruir dos benefícios rapidamente e, ainda, possibilitar uma avaliação parcial dos resultados, foi adotada a estratégia de implementação modular, onde cada módulo corresponde a uma fonte de dados proveniente dos sistemas do DATASUS. Esta estratégia reforça o motivo de iniciar o desenvolvimento com o estudo dos sistemas fontes, pois, só após este estudo, foi possível a definição dos módulos. Outro aspecto estratégico significativo é a criação de um banco de dados relacional (operacional) além do dimensional. O motivo é manter os dados fontes em um meio mais seguro. Eles estão disponíveis para download na homepage do DATASUS, porém, não há garantias que sempre estarão lá. A figura 3 mostra o fluxo dos dados no projeto.
Tarefa
Ferramenta
Armazenamento do DW Modelagem ETL Metadados / Ferramenta OLAP
Oracle 9i Oracle Designer 1 Oracle WarehouseBuilder 1 Oracle Discoverer
Tabela 3. Ferramentas Utilizadas D_TEMPO
D_SEXO
D_UNIDADE
. . .
D_FAIXA_ETARIA .
D_MUNICIPIO .
.
.
.
. F_ATENDIMENTOS . . D_PROCEDIMENTO
.
D_SERVICO
. .
.
.
.
R e la t ó r io s / C o n s u lt a s . D_ESPECIALIDADE
. D_CID
. D_TIPO
B D D im e n s io n a l
Figura 4 – Esquema Estrela – Modelo Dimensional B D R e la c io n a l
4.3.
O processo de carga
Devido a estratégia adotada, o processo de carga dos dados é constitui-se de duas fases. Na primeira fase os dados dos sistemas fontes (DATASUS) são carregados em um banco relacional, e posteriormente, os dados são
A r q u iv o s S U S
Figura 3 – Fluxo de dados no projeto 4
carregados da base relacional para o banco dimensional (figura 3). Na primeira etapa da carga, há um grande número de arquivos recebidos por download numa grande variedade de formatos. Visando facilitar a carga para a base relacional, foi desenvolvida, em parceria com a Compumédica Informática Ltda, uma ferramenta para automatização do processo de download, descompactação, transformação e carga dos arquivos contidos na home-page do DATASUS para a Base Relacional. A ferramenta também efetua a validação do conteúdo e da estrutura do arquivo para garantir a integridade dos dados. Todo o processo de carga é armazenado em um arquivo log, permitindo auditorias ou a repetição da carga. A figura 5 mostra a interface da ferramenta. A segunda etapa da carga é efetuada por scripts simples gerados pelos mapeamentos implementados no Oracle Warehouse Builder. As rotinas são extremamente simples, pois, as tarefas de limpeza, padronização e consistência dos dados foram efetuadas na primeira etapa.
são desenvolvidos pela ferramenta Oracle Discoverer. A figura 9 mostra um exemplo de consulta analítica desenvolvida para o usuário. O exemplo analisa procedimentos realizados por cada município em um determinado período, de acordo com o tipo de gestão e tipo de serviço.
Figura 5 – Consulta Analítica Pré-Definida 5. Resultados e Discussão Embora o projeto ainda não esteja implementado em sua totalidade, resultados preliminares podem ser discutidos. Atualmente, o projeto encontra-se em fase final da implementação do primeiro módulo (SIA). O desenvolvimento do primeiro módulo permitiu a identificação de algumas dificuldades. Estas dificuldades confirmam os desafios de um projeto de DW para a área da saúde citadas por autores como Berndt et al.[2], DeJesus [10], Isken et al. [11]. Os desafios encontrados estão listados na tabela 4. Ação Adotada
- Dados provenientes de muitas fontes e em diversos formatos
A ferramenta de carga desenvolvida possui uma função de padronização que unifica os vários formatos dos arquivos. A ferramenta de carga analisa a estrutura do arquivo e efetua os ajustes necessários. Inclusão de um campo para controle no modelo de dados e tratamento desta particularidade, através de uma regra de negócio, no metadados. e consequentemente nos relatórios desenvolvidos. Para prover todos os usuários com a informação analítica, a estratégia é disponibilizar o acesso via Web.
- Constantes Alterações na estrutura dos arquivos - Dados lançados em um determinado período, correspondentes a períodos anteriores
Figura 4 – Ferramenta para carga (etapa 1). 4.4.
Desafio
A exibição dos Dados do DW
Nesta etapa, além do cadastramento das descrições dos dados e das regras de negócio no metadados, são desenvolvidos relatórios e consultas pré-definidos para atender os principais requisitos dos usuários. Os relatórios e consultas
- Relatórios (saídas) devem ser disseminados para usuários separados geograficamente
Tabela 4. Principais desafios do projeto 5
Os próximos passos, já em andamento, são a avaliação da satisfação dos usuários para o módulo desenvolvido e a implementação dos demais módulos. Após a implementação de todos o módulos, será iniciada a introdução de técnicas de Data Mining para realização de simulações e análises mais complexas.
Outros resultados preliminares que podem ser discutidos, são o volume de dados e o desempenho do processo de carga. Considerando apenas o módulo SIA, o volume mensal de dados para serem carregados no DW é de 1.800.000 registros, que corresponde a aproximadamente a 211 Mb. Acrescentando as tabelas auxiliares, este número aproxima-se de 250 Mb. Isto corresponde a 2,9 Gb por ano. Somando outras estruturas de banco de dados, como índices e log, o volume anual será de, aproximadamente, 3,5 Gb. Embora não seja um número assustador, é um volume razoável se comparado aos 23 Gb. do CDR (Clinical Data Repository) da Universidade de Virgínia [12] após 5 anos de existência. Os tempos para o processo de carga estão plenamente satisfatórios, mesmo sendo realizados os testes de performance em um ambiente muito inferior ao ambiente de produção. Os testes foram realizados em um servidor x-series 200 da IBM, com 128 Mb de RAM, uma rede de 10 Mbps, e acesso web speedy 256 mbps. A primeira fase da carga, que inclui as rotinas de limpeza e consistência demorou aproximadamente 2 horas. A segunda fase, bem mais simples, demora menos que 10 minutos. O tempo para download dos arquivos de um mês é de aproximadamente 30 minutos. No estágio atual, ainda não é possível mensurar a satisfação do usuário, nem quantificar os benefícios obtidos com a nova solução, embora eles sejam óbvios.
7. Agradecimentos Aos funcionários da Secretaria de Estado da Saúde de São Paulo. 8. Referências [1] Shams K., Farishta M. (2001), “Data Warehousing: Toward knowledge Management”, Topics in Health Information Management, v. 21, n. 3, p. 24-32. [2] Berndt D.J., Hevner A.R., Studnicki J. (2003) “The Catch Data Warehouse: Support for Community Health Care Decision-Making”, Decision Support Systems, v.35 n.3, p.367-384. [3]
Ramick
D.C.
Management
(2001),
“Data
Warehousing
Programs”,
Journal
in
of
Disease
Healthcare
Information Management, v. 15, n. 2, p. 99-105. [4] Moody, D. L., Kortink, M.A.R. (2000), “From Entreprise Models to
Dimensional
Models:
A
Methodology
for
Data
Warehouse and Data Mart Design”, Proceedings of the International Workshop on Desing and Management of Data Warehouse, Stockholm, Sweden, p. 5.1-5.12, 5-6 June. [5] Berson A., Smith S. J. (1997), Data Warehousing, Data Mining, & OLAP, New York: McGraw-Hill. [6] Kimball R. (1997), “A Dimensional Modeling Manifesto”, DBMS Online, (http:/www.dbmsmag.com/9708d15.html). [7] Secretaria de Estado da Saúde de SP. Disponível em http://www.saude.sp.gov.br. Acesso em 05 mai. 2003. [8] DataSUS – Ministério da Saúde. Disponível em http://www.datasus.gov.br. Acesso em 05 mai. 2003. [9] Inmon, W. H. (1997), Como Construir o Data Warehouse, Rio de Janeiro: Campus.
6. Conclusões O artigo mostrou um projeto de uma solução DW para fornecer informações estratégicas para a gestão da saúde pública. O estágio atual do projeto, mostra um resultado positivo que supera as expectativas iniciais e encoraja a implementação dos demais módulos. Uma das grandes contribuições do trabalho é a identificação de alguns aspectos peculiares da área da saúde e a implementação de mecanismos para a superação destes desafios. O projeto foi desenvolvido utilizando um conjunto de ferramentas robustas e adotando metodologia adequada para garantir o sucesso do empreendimento. Os fatores mensuráveis apresentaram números positivos. O volume de dados é razoável, comparado a outros projetos, e o desempenho dos procedimentos de carga está plenamente satisfatório.
[10] DeJesus E.X. (1999), “Disease Management in a Warehouse: Data Warehouse Technology Makes a Good Fit for Disease Management programs.”, Healthcare Informatics, v.16, n. 9, p. 33-36, 38-39 [11] Isken M.W., Littig S.J., West M. (2001), “A data Mart for Operations Analysis”, Journal of Healthcare Information Management, v. 15 , n. 2, p.143-153. [12] Einbinder J.S., Scully K.W., Pates R.D., Schubart J.R., Reynolds R.E. (2001), “Case Study: A Data Warehouse for an Academic Medical Center”, Journal of Healthcare Infornmation Management, v. 15, n. 2, p. 165-175.
Contato
[email protected] 6
