Construção de um Ambiente de BI (Business Intelligence) na ... - SBIS

Construção de um Ambiente de BI (Business Intelligence) na Secretaria
Municipal de Saúde da Cidade de São Paulo
Deborah Pimenta Ferreira 1 , Cláudia Miranda 2 , Cláudio Giulliano Alves da Costa 3
1,2,3 Assessoria Técnica de Tecnologia da Informação (ATTI), Secretaria Municipal da Saúde (SMS),
Prefeitura Municipal de São Paulo, Brasil
Introdução
O município de São Paulo caracteriza-se
pelos grandes números e não poderia ser
diferente na saúde: são 10.879.619 habitantes,
distribuídos em 5 coordenações de saúde e 24
supervisões; são 411 UBS, 106 AMA´s e 25
Ambulatórios . Em 2007, foram realizadas
7.852.498 consultas médicas especializadas;
9.288.633 consultas de Urgência; 13.666.087
consultas médicas básicas e 657.327
internações.
Em 2003 a SMS iniciou o desenvolvimento
de um sistema integrado para a gestão da saúde,
o SIGA, que está implantado desde 2005, em
toda a rede assistencial. Desde então, milhares
de dados têm sido coletados nas unidades,
porém, os relatórios são apenas operacionais e
não facilitam a análise pelos gestores. Além deste
sistema, muitos outros, não integrados, estão
implantados. Assim, vários relatórios gerenciais
são gerados através de planilhas e outros
recursos, com grande trabalho “manual” e sem
garantia do resultado final e da integridade dos
dados.
Este trabalho tem a finalidade de
apresentar a experiência da Secretaria Municipal
de Saúde da Cidade de São Paulo na
implantação de um ambiente analítico com a
construção de um Data Warehouse e ferramentas
que permitam a prática de BI (Business
Intelligence). Embora este termo já seja utilizado
há mais de vinte anos, tornou-se realmente
conhecido mais recentemente, sendo referido
muitas vezes como um sistema. Porém, BI não é
um produto em si, mas sim, uma prática ou um
constante processo de analisar os negócios para
a tomada de decisão.
Do ponto de vista da tecnologia, é a
reunião de diversos recursos usados para extrair,
transformar e analisar grandes volumes de dados,
produzindo conhecimento.
Metodologia
Optou-se, como primeiro projeto (“um piloto
em produção”), incluir apenas os dados do SIGA.
A metodologia adotada pela empresa
desenvolvedora para a construção do Data
Warehouse foi a tradicional, descrita por R.
Kimball [1], com a implantação de data marts
(subconjuntos) de forma incremental.
O sistema gerenciador de banco de dados
(SGBD) utilizado foi o Oracle 10g e os programas
de carga foram desenvolvidos em PL/SQL do
Oracle. A ferramenta de OLAP utilizada foi
customizada pela empresa desenvolvedora a
partir da ferramenta Business Object da SAP.
Resultados
Foram construídos 11 Cubos ou Universos,
relacionados ao sistema transacional SIGA:
Agendamentos, Atendimentos, Equipes de
Saúde, Estabelecimentos, Fila de Espera,
Pacientes (Usuários), Procedimentos,
Profissionais, Regulação, Vacinação e Vagas.
Vide exemplo de tela no final (fig. 1).
Discussão e Conclusões
O processo de construção deste DW,
considerando-se as premissas iniciais, exigiu um
trabalho e um esforço adicional uma vez que não
existiam parâmetros e referências da construção
de um BI para um ambiente e uma população tão
complexa e diversa. Embora os resultados ainda
sejam poucos, durante este processo teve-se
muitas lições aprendidas:
Modelagem dimensional: durante o
processo de modelagem é importante que a
equipe desenvolvedora trabalhe em conjunto e
muito próxima aos usuários chaves, validando
todos os processos antes do desenvolvimento
das tabelas e ETLs. Esta forma de trabalho
poderia ter evitado que erros de conceito fossem
percebidos somente no processo de
homologação, prolongando muito esta fase. Após
a correção dos erros mais visíveis optou-se por
colocar em produção, pois, pela complexidade e
tamanho do sistema, a homologação se
completará apenas com o uso efetivo do sistema.
Granularidade: sendo o SIGA um sistema
de gestão integrado que cobre todas as unidades
de saúde sob gestão municipal (incluindo
prestadores privados, que têm suas agendas no
sistema), o balanceamento entre a granularidade
necessária e o dimensionamento e desempenho
do DW, mostrou-se um grande desafio. As cargas
foram programadas para o período noturno,
diariamente, porém, ainda é muito cedo para
verificar-se o sucesso deste balanceamento.
Das dificuldades encontradas neste
desenvolvimento, optou-se por priorizar as

dimensões mais críticas em saúde e comuns a
vários fatos:
• Paciente (usuário): são mais de
13.000.000 de registros;
• Local de procedência (endereço do
paciente), hierarquizado de acordo com a
divisão administrativa do município - no
caso do município de São Paulo, foi
necessária a subdivisão por distrito
administrativo (DA), porém, este atributo
não é tratado nas tabelas do correio;
optou-se por utilizar uma tabela própria
da Coordenadoria de Epidemiologia e
Informação da SMS, relacionando CEP e
DA, para inclusão deste atributo;
• Local de ocorrência – também
hierarquizado, de acordo com a estrutura
organizacional do município – no caso de
SP, inclui o estabelecimento de saúde,
supervisão técnica de saúde (24),
coordenadoria regional de saúde (5) e a
própria SMS;
• Procedimento
• Diagnóstico
• Profissional
• Tempo
Uma das vantagens da construção de um
ambiente analítico, é a possibilidade de “passar a
limpo” o sistema transacional, tanto corrigindo
falhas do sistema quanto melhorando a coleta
dos dados.
Após este piloto, iniciou-se um segundo
projeto, integrando neste DW dados do sistema
transacional de dispensação de medicamentos
(GSS) e do Programa Remédio em Casa, que já
se encontra em processo de homologação. As
ferramentas de construção e apresentação
escolhidas foram outras.
Referência
[1] Kimball R, Ross M. The Data Warehouse
Toolkit: The complete guide to
dimensional modeling, 2nd ed., New
York: Wiley; 2002.
Contatos
deborahc@prefeitura.sp.gov.br
cgcosta@prefeitura.sp.gov.br
cfmiranda@prefeitura.sp.gov.br
Figura 1 – Distribuição dos usuários cadastrados por Supervisão Técnica de Saúde