Como estruturar um data warehouse hospitalar

O dado hospitalar está espalhado e ninguém confia no número#

Se você trabalha com informação em um hospital, conhece a cena: o faturamento tem um número de atendimentos, a área assistencial tem outro, e o censo diário mostra um terceiro. Cada sistema conta a mesma realidade de um jeito, e a diretoria pede um painel que ninguém consegue fechar. Um data warehouse hospitalar existe justamente para resolver isso, criando uma camada única de verdade onde atendimento, conta e ocupação de leito conversam sem ambiguidade.

O problema raramente é falta de ferramenta. É falta de arquitetura. Hospitais operam com um ecossistema fragmentado: gestão hospitalar (HIS), prontuário eletrônico (PEP), faturamento, laboratório (LIS), imagem (RIS/PACS), farmácia e a integração com dezenas de convênios via TISS. Jogar tudo isso direto no Power BI, sem uma camada intermediária bem modelada, produz relatórios lentos, inconsistentes e impossíveis de auditar. Este artigo mostra como estruturar essa camada para que ela sustente decisão clínica e financeira ao mesmo tempo.

Modelagem dimensional é o que separa relatório de sistema de gestão#

A tentação de replicar o modelo relacional do HIS no warehouse é grande e quase sempre errada. Bancos transacionais são normalizados para escrever rápido, não para responder perguntas analíticas. Para BI, o padrão consolidado é a modelagem dimensional em esquema estrela, com tabelas fato ao centro e dimensões ao redor. Isso não é preferência estética. O motor VertiPaq, que roda por trás do Power BI e dos modelos semânticos do Fabric, comprime colunas por cardinalidade e trabalha muito melhor com chaves inteiras e tabelas largas de dimensão do que com dezenas de junções profundas.

No contexto hospitalar, a decisão central é definir quais são os fatos e qual o grão de cada um. Recomendo pelo menos três tabelas fato distintas, porque elas respondem a perguntas diferentes e têm granularidades incompatíveis.

Tabela fato	Grão (uma linha representa)	Métricas típicas	Perguntas que responde
Fato Atendimento	Um atendimento (consulta, internação, pronto-socorro)	Tempo de permanência, reinternação, desfecho	Volume assistencial, taxa de reinternação, giro
Fato Conta	Um item lançado na conta do paciente	Valor faturado, glosa, valor pago	Receita, glosa por convênio, ticket médio
Fato Censo	Um leito em um dia (snapshot diário)	Leitos ocupados, taxa de ocupação	Ocupação, disponibilidade, projeção de lotação

Reparou que o Fato Censo tem grão de "leito por dia"? Ele é um fato de snapshot periódico, diferente do Fato Atendimento, que é um fato transacional. Misturar os dois em uma tabela só é a origem clássica dos números que não batem. A ocupação não se soma ao longo do tempo do mesmo jeito que o faturamento se soma, e o modelo precisa refletir isso.

As dimensões são o vocabulário compartilhado. As mais importantes:

• Dimensão Paciente: identificação, faixa etária, sexo, procedência. Aqui mora boa parte do risco de LGPD, então trate os dados sensíveis com cuidado desde o início.
• Dimensão Procedimento: alinhada às tabelas de referência do setor, como a Terminologia Unificada da Saúde Suplementar (TUSS) e a tabela de procedimentos do SUS (SIGTAP), quando o hospital atende ambos.
• Dimensão Convênio: operadora, plano, tipo de contrato. Essencial para análise de glosa e rentabilidade por fonte pagadora.
• Dimensão Tempo: calendário completo, com competência de faturamento separada da data do atendimento, porque elas quase nunca coincidem.
• Dimensões de apoio: médico executor, unidade/setor, leito, CID.

Um cuidado que economiza retrabalho: use dimensões conformadas. Se "Convênio" significa a mesma coisa no Fato Conta e no Fato Atendimento, ela precisa ser a mesma tabela física, com a mesma chave. É isso que permite cruzar receita com volume assistencial sem gambiarra. Para aprofundar as técnicas de cálculo sobre esse modelo, vale ler nosso material sobre boas práticas de modelagem e DAX.

As camadas medalhão organizam o caos entre a origem e o painel#

Ter um bom modelo dimensional não basta se o caminho do dado bruto até ele for uma caixa-preta. A arquitetura medalhão, popularizada com o lakehouse e adotada de forma nativa no Microsoft Fabric sobre o OneLake, resolve isso separando o processamento em três camadas com responsabilidades claras.

Camada	Conteúdo	Formato/estado	Quem consome
Bronze	Cópia fiel da origem (HIS, PEP, TISS, HL7/FHIR)	Bruto, sem transformação, histórico preservado	Engenharia de dados
Prata	Dados limpos, deduplicados, integrados e conformados	Padronizado, chaves resolvidas	Engenharia e analistas
Ouro	Modelo dimensional pronto para consumo	Fatos e dimensões, agregações de negócio	Power BI, diretoria, áreas

A camada bronze é o seu seguro. Ela guarda o dado exatamente como chegou, o que permite reprocessar quando uma regra muda ou quando você descobre um erro seis meses depois. A prata é onde acontece o trabalho pesado: resolver o mesmo paciente que aparece com dois cadastros, tratar códigos de procedimento fora do padrão, unificar unidades de medida. A ouro é o que o Power BI enxerga, já no formato estrela que descrevi acima.

No Fabric, essa arquitetura ganha um recurso que muda o jogo: o modo Direct Lake. Ele lê os dados diretamente das tabelas Delta no OneLake, sem importar para o modelo e sem consultar a origem a cada clique como o DirectQuery faz. Na prática, você tem performance próxima do modo Import com atualização quase imediata do dado do lake. Para um hospital que precisa de censo atualizado várias vezes ao dia, isso é relevante.

Vale um comentário honesto sobre custo. O Fabric mede consumo em Capacity Units e é licenciado por SKUs de capacidade que vão de F2 até F2048 (os planos anteriores P1 a P5 do Power BI Premium seguem a mesma família). Capacidade menor custa menos e aguenta menos processamento simultâneo. Não existe número mágico: o dimensionamento depende do volume de dados, da frequência de atualização e de quantas pessoas consultam ao mesmo tempo. Comece pequeno, meça o consumo real e escale. Preços variam por região e contrato, então confirme na fonte oficial da Microsoft antes de fechar orçamento. Se a decisão entre Fabric e o Power BI tradicional ainda não está clara para o seu caso, escrevemos uma análise específica sobre o que é o Microsoft Fabric e quando vale a pena.

Não é obrigatório usar Fabric para ter arquitetura medalhão. O padrão funciona em qualquer lakehouse. Mas em ambiente Microsoft, o ecossistema com maior penetração no BI brasileiro, a integração nativa entre OneLake, modelo semântico e Power BI reduz o atrito de engenharia. Esse é o tipo de decisão que tratamos em um trabalho de engenharia de dados.

Interoperabilidade não é detalhe técnico, é a condição de existência do warehouse#

Um data warehouse hospitalar vive ou morre pela capacidade de ler os padrões do setor. Ignorar isso é construir um sistema que precisa de retrabalho manual a cada nova integração. Dois blocos importam.

O primeiro é o TISS, o padrão de Troca de Informação em Saúde Suplementar definido pela ANS. Ele é obrigatório na comunicação entre hospitais e operadoras de planos de saúde e estrutura guias, lotes e o retorno de faturamento em XML. É de dentro do fluxo TISS que você extrai o dado de conta, de glosa e de recurso de glosa. Modelar bem a ingestão do retorno TISS na camada bronze é o que permite, lá na frente, um painel de glosa que a diretoria financeira realmente usa.

O segundo bloco é a interoperabilidade clínica, com HL7 e sua evolução moderna, o FHIR (Fast Healthcare Interoperability Resources). O HL7 v2 ainda é onipresente na troca de mensagens entre sistemas hospitalares (admissão, alta, transferência, resultados de exame). O FHIR trabalha com recursos em formato REST/JSON, muito mais amigável para integração moderna, e vem sendo adotado como padrão de referência internacional. No Brasil, a RNDS (Rede Nacional de Dados em Saúde) usa FHIR, o que reforça a aposta nesse padrão para quem pensa em médio prazo.

A recomendação prática: trate TISS, HL7 e FHIR como fontes na camada bronze, cada uma com seu conector e seu histórico. Faça a conciliação na prata. Não tente interpretar um XML TISS dentro do Power BI, porque isso empurra lógica de integração para a camada errada e transforma o relatório em um monstro impossível de manter.

Governança e LGPD precisam estar no projeto, não no fim dele#

Dado de paciente é dado pessoal sensível. A Lei nº 13.709/2018 (LGPD) classifica dado referente à saúde como sensível e impõe base legal específica para tratá-lo. Um warehouse hospitalar concentra exatamente esse tipo de informação em um único lugar, o que aumenta o valor analítico e o risco na mesma proporção. Governança aqui não é burocracia, é requisito de projeto.

Alguns pontos que considero inegociáveis:

• Minimização: leve para a camada ouro apenas o que o consumo analítico exige. Nome completo, CPF e endereço raramente precisam estar em um painel gerencial. Pseudonimize na prata.
• Controle de acesso por perfil: quem vê receita não necessariamente vê o CID do paciente. O Power BI oferece Row-Level Security (RLS) e Object-Level Security (OLS) para restringir linhas e colunas por papel. Use.
• Trilha de auditoria: registre quem acessou o quê. O warehouse deve permitir responder a um pedido de titular ou a uma auditoria da ANS ou da ANPD sem arqueologia.
• Catálogo e linhagem: saber de onde veio cada número é o que sustenta a confiança na camada de ouro. Ferramentas de governança do Fabric ajudam a rastrear a linhagem do dado da origem ao painel.

Governança não é um produto que você compra, é uma disciplina que você mantém. Tratamos isso em profundidade no texto sobre governança de dados, Power BI e LGPD e no nosso serviço dedicado de governança de dados.

Uma sequência de implantação que funciona na prática#

Depois de mais de dois mil projetos de solução Microsoft entregues, a Fynx aprendeu que a ordem importa tanto quanto a arquitetura. A sequência que costuma dar certo:

1. Discovery: mapear origens reais, volumes, padrões de integração e as perguntas de negócio prioritárias. Sem isso, você modela no escuro.
2. Camada bronze primeiro: garantir ingestão confiável de HIS, TISS e clínico antes de pensar em painel.
3. Prata com foco no paciente único: a resolução de identidade do paciente é o problema mais difícil e o que mais impacta a qualidade final.
4. Ouro por domínio: entregar primeiro o domínio de maior dor, normalmente faturamento e glosa, e depois expandir para censo e assistencial.
5. Painéis e adoção: publicar, treinar as áreas e medir uso real.

Resista à tentação de começar pelo painel bonito. Um dashboard sobre um warehouse mal estruturado é uma mentira com boa aparência. Nosso discovery e assessment existe exatamente para essa etapa inicial.

Perguntas frequentes#

Preciso do Microsoft Fabric para montar um data warehouse hospitalar? Não. A arquitetura medalhão e a modelagem dimensional funcionam em qualquer stack de lakehouse ou banco analítico. O Fabric traz vantagens concretas em ambiente Microsoft, como o OneLake unificado e o modo Direct Lake, além da integração nativa com o Power BI, que é o BI dominante no mercado brasileiro. Mas a decisão deve considerar seu ecossistema atual, seu orçamento e sua maturidade de engenharia.

Qual a diferença entre um data warehouse e um lakehouse nesse contexto? Data warehouse descreve o objetivo, um repositório analítico integrado e modelado para decisão. Lakehouse descreve uma arquitetura técnica que combina a flexibilidade do data lake com estruturas de tabela e transações. No Fabric, você constrói o seu warehouse dimensional usando um lakehouse com camadas medalhão. Os termos convivem, não competem.

Como o warehouse trata o TISS e o retorno de glosa das operadoras? O ideal é ingerir os arquivos XML do TISS, incluindo os lotes enviados e os retornos de faturamento, na camada bronze, preservando o formato original. A interpretação de guias, itens e glosas acontece na prata, onde os dados são estruturados e conciliados. Assim, a camada ouro entrega um Fato Conta já limpo, permitindo análise de glosa por convênio e por motivo sem processar XML dentro do Power BI.

Onde entra a LGPD na modelagem de dados de paciente? Desde o desenho. Aplique minimização levando à camada de consumo apenas o dado necessário, pseudonimize identificadores na camada prata, use Row-Level Security e Object-Level Security no Power BI para controlar acesso por perfil e mantenha trilha de auditoria e linhagem. Dado de saúde é sensível segundo a Lei nº 13.709/2018, então a base legal e o controle de acesso precisam estar definidos antes da primeira carga.

Por que separar os fatos de atendimento, conta e censo em vez de uma tabela só? Porque eles têm granularidades diferentes e se comportam de forma distinta na agregação. Atendimento é transacional, conta é item a item e censo é um snapshot diário por leito. Ocupação de leito não se soma no tempo como o faturamento se soma. Juntar tudo em uma tabela cria métricas que dão números errados dependendo do filtro aplicado. Fatos separados, com dimensões conformadas, mantêm cada análise correta.

Quanto tempo leva para colocar um warehouse hospitalar em produção? Depende do número de origens, da qualidade dos dados e do escopo do primeiro domínio. Uma abordagem por incrementos, entregando primeiro o domínio de maior dor, gera valor mais cedo do que tentar tudo de uma vez. O gargalo mais comum não é a tecnologia, é a resolução de identidade do paciente e a conciliação entre sistemas. Um discovery bem feito no início reduz a incerteza de prazo.

Fechamento#

Um data warehouse hospitalar bem estruturado não é sobre ter a ferramenta da moda. É sobre disciplina: fatos e dimensões bem definidos, camadas medalhão que separam bronze de ouro, respeito aos padrões TISS e FHIR, e governança de LGPD desde a primeira linha de código. Quando essas peças estão no lugar, o número para de ser motivo de discussão e passa a ser base de decisão clínica e financeira.

Se o seu hospital ainda convive com painéis que não batem, fale com a gente. A Fynx pode ajudar a desenhar essa arquitetura do jeito certo desde o começo.