Como estruturar um data warehouse para a área da saúde

O dado de saúde chega bagunçado, sensível e cobrado de todos os lados#

Quem trabalha com dados em hospital, operadora ou clínica conhece a cena: o prontuário eletrônico não conversa com o ERP financeiro, o faturamento TISS vive numa planilha paralela e cada gestor apresenta a sua própria versão da taxa de ocupação. Montar um data warehouse saúde não é um projeto de infraestrutura, é uma decisão de governança. Você reúne, num único lugar, informação clínica sensível, dado financeiro e obrigação regulatória, e responde por isso perante a LGPD, a ANS e o corpo clínico ao mesmo tempo.

Este artigo é técnico e opinativo. Vou tratar de modelagem dimensional aplicada a atendimento, das camadas medalhão no Microsoft Fabric e no Azure, de interoperabilidade real (TISS, HL7 e FHIR), de governança sob a LGPD e, no fim, de como começar sem construir um monumento que ninguém usa. A saúde tem particularidades que não perdoam atalhos, e é sobre elas que a maior parte dos projetos tropeça.

O que torna o dado clínico diferente de qualquer outro domínio#

Antes de desenhar tabela, entenda três coisas. Primeiro, o dado de saúde é sensível por definição legal. A LGPD (Lei nº 13.709/2018) classifica dado referente à saúde como dado pessoal sensível no artigo 5º, inciso II, e isso muda o tratamento inteiro: base legal, minimização, controle de acesso e registro de operações.

Segundo, o dado clínico é historicamente denso. Um mesmo paciente muda de convênio, de plano, de endereço e até de nome ao longo dos anos. Se o seu modelo não trata mudança de atributo ao longo do tempo, você perde a capacidade de responder perguntas simples como "qual era o convênio do paciente na data do atendimento".

Terceiro, a saúde é padronizada por fora. Você não decide sozinho o formato do dado: o faturamento com operadoras segue o padrão TISS da ANS, a interoperabilidade clínica caminha para o HL7 FHIR, e há terminologias como CID-10, TUSS e SIGTAP que ditam como procedimento e diagnóstico são codificados. Ignorar esses padrões é assinar retrabalho.

A modelagem dimensional continua sendo a base certa#

Muita gente acha que camada medalhão substitui modelagem. Não substitui. Medalhão é organização de pipeline; modelagem dimensional é o desenho do modelo analítico que a diretoria vai consumir. Na saúde, o esquema estrela de Kimball funciona muito bem porque a pergunta de negócio quase sempre é "quantos atendimentos, de que tipo, para qual paciente, em qual convênio, com qual desfecho".

A tabela fato central costuma ser o atendimento (ou o encontro clínico, o encounter do FHIR). Cada linha é um evento: uma consulta, uma internação, um exame, uma sessão. Ao redor dela ficam as dimensões.

Elemento do modelo	Tipo	Papel no data warehouse saúde
Fato atendimento	Fato transacional	Uma linha por atendimento, com chaves para paciente, procedimento, convênio, unidade e tempo
Fato faturamento	Fato transacional	Guia TISS, valor apresentado, valor glosado, valor pago
Fato ocupação de leito	Fato periódico (snapshot)	Foto diária de leitos ocupados e livres por unidade
Dim paciente	Dimensão (SCD tipo 2)	Identificação pseudonimizada, sexo, faixa etária, cidade
Dim procedimento	Dimensão	Código TUSS ou SIGTAP, descrição, grupo, porte
Dim convênio	Dimensão	Operadora, plano, tipo de contratação, registro ANS
Dim tempo	Dimensão	Calendário com dia, mês, competência de faturamento
Dim profissional	Dimensão	CRM pseudonimizado, especialidade, unidade

Duas decisões de modelagem valem por metade do projeto. A primeira é usar dimensão de mudança lenta (SCD tipo 2) para paciente e convênio, guardando datas de vigência de cada versão do registro. Assim você responde perguntas históricas sem falsear o passado. A segunda é separar métricas aditivas (contagem de atendimentos, valor faturado) de métricas não aditivas (taxa de ocupação, tempo médio de permanência), porque as não aditivas não podem ser simplesmente somadas e precisam de medidas DAX bem escritas. Se DAX é o seu ponto fraco, vale ler boas práticas de modelagem e DAX no Power BI antes de calcular indicador clínico.

Um detalhe de engenharia que a saúde castiga: cardinalidade. O motor VertiPaq, que sustenta o modelo tabular do Power BI e do Fabric, comprime coluna por coluna e é muito sensível à cardinalidade. Colunas de altíssima cardinalidade, como número de guia ou identificador único de atendimento em texto longo, incham o modelo e derrubam performance. Guarde esses identificadores, mas não os traga para o modelo de consumo sem necessidade.

As camadas medalhão organizam o caos antes de ele virar dashboard#

A arquitetura medalhão (bronze, silver e gold) é a forma mais sã de estruturar o pipeline no Microsoft Fabric e no Azure. Ela não é um capricho de nomenclatura: cada camada tem uma responsabilidade e um contrato de qualidade.

Camada	O que contém	Estado do dado clínico
Bronze	Ingestão bruta, como veio da fonte (HIS, ERP, arquivos XML TISS, mensagens FHIR)	Cru, sem transformação, histórico preservado para auditoria
Silver	Dado limpo, deduplicado, padronizado e conformado	Terminologias resolvidas, pacientes deduplicados, tipos corrigidos
Gold	Modelo dimensional pronto para consumo	Fatos e dimensões, agregações, métricas de negócio

Na prática, na camada bronze você aterrissa o arquivo XML do TISS e a mensagem HL7 exatamente como chegaram, porque em saúde a rastreabilidade da origem é exigência de auditoria e defesa em glosa. Na silver você faz o trabalho pesado: resolve o mesmo paciente que aparece com CPF em três grafias, converte diagnóstico para CID-10 padronizado, concilia procedimento entre TUSS e SIGTAP. Na gold você entrega o esquema estrela que descrevi acima.

No Fabric, isso vive tipicamente em Lakehouses conectados ao OneLake, o armazenamento unificado da plataforma. Um ponto que muda o jogo é o modo Direct Lake do Power BI: ele lê os arquivos Delta diretamente do OneLake, sem importar para dentro do modelo e sem consultar a fonte em tempo real como o DirectQuery. Para volumes hospitalares, isso combina a performance do modo Import com a atualização de dados próxima do tempo real, desde que a camada gold esteja bem escrita em Delta Parquet. Se você ainda está avaliando a plataforma, o texto Microsoft Fabric: o que é e vale a pena em 2026 ajuda a decidir com critério.

Vale um aviso honesto sobre custo. O Fabric mede consumo em Capacity Units e é licenciado por SKUs de capacidade, do F2 ao F2048, além das antigas capacidades Premium P1 a P5. Pipeline de saúde tende a ser pesado de transformação, então dimensione a capacidade pela carga real de processamento, não pelo tamanho do banco. Reprocessar toda a base clínica todo dia numa capacidade pequena é receita de fila e frustração. A construção sólida dessas camadas é trabalho de engenharia de dados, não de quem só monta relatório.

Interoperabilidade é onde o projeto de saúde ganha ou perde#

Aqui está a diferença entre um data warehouse de varejo e um de saúde. No varejo você negocia o formato com a origem. Na saúde, o formato já existe e é obrigatório em vários casos.

O padrão TISS (Troca de Informações na Saúde Suplementar), mantido pela ANS, define a comunicação entre operadoras e prestadores para autorização, elegibilidade e faturamento. Ele chega em XML estruturado e é a sua principal fonte de dado financeiro assistencial. Modelar bem o TISS na camada silver é o que permite analisar glosa com seriedade, tema que trato em análise de glosas na saúde.

No lado clínico, o HL7 é a família de padrões de mensageria em saúde, e o HL7 FHIR é a evolução moderna, baseada em recursos (resources) trafegados por API REST, com representação em JSON ou XML. Recursos como Patient, Encounter, Observation e Condition mapeiam quase diretamente para dimensões e fatos do seu modelo. Quem estrutura o warehouse pensando em FHIR desde o começo colhe interoperabilidade com prontuário, laboratório e sistemas nacionais com muito menos atrito.

O caminho prático de ingestão fica mais ou menos assim:

• Extrair do HIS e do ERP por conector, API ou banco de réplica.
• Receber TISS em XML e mensagens HL7/FHIR em bronze, sem alterar o original.
• Analisar (parse) e conformar em silver, resolvendo terminologias e identidade do paciente.
• Publicar o modelo dimensional em gold.

Se as suas fontes são um HIS legado e um ERP financeiro que não se falam, o problema real é integração antes de análise, e é isso que discutimos em como integrar HIS e ERP ao Power BI.

Governança e LGPD não são camada final, são fundação#

O erro mais comum em saúde é tratar segurança e conformidade como a última tarefa antes de publicar. Em dado sensível, a governança precede o pipeline.

Comece pela base legal do tratamento. Dado de saúde tem regime próprio na LGPD, e você precisa saber sob qual hipótese trata cada conjunto: tutela da saúde por profissional, cumprimento de obrigação legal ou regulatória, ou outra base aplicável. Isso não é papel de jurista distante do projeto, é decisão de arquitetura, porque define o que pode entrar em gold e quem enxerga o quê.

Alguns controles são inegociáveis num data warehouse saúde:

• Pseudonimização de identificadores diretos (nome, CPF, cartão nacional de saúde) já na camada silver, mantendo a chave de reidentificação isolada e com acesso restrito.
• Minimização de dados: a camada gold analítica raramente precisa do nome do paciente. Faixa etária, sexo e município costumam bastar para gestão. Traga identificação direta só onde o processo assistencial exige.
• Controle de acesso por papel, aplicando segurança em nível de linha (RLS) para que cada unidade ou especialidade veja apenas o seu recorte.
• Trilha de auditoria: registrar quem acessou qual dado e quando, aproveitando os logs da plataforma.

Fabric e Power BI ajudam com rótulos de sensibilidade herdados do Microsoft Purview, RLS nativo e logs de auditoria. Mas ferramenta não substitui política. Sobre a régua de conformidade aplicada ao ecossistema Microsoft, vale ler governança de dados no Power BI e LGPD, e a estruturação disso é o núcleo do nosso serviço de governança de dados.

Como começar sem construir um monumento inútil#

A pior forma de iniciar é tentar modelar o hospital inteiro de uma vez. A melhor é escolher um processo de negócio que dói e entregar a fatia vertical completa dele, do dado bruto ao painel, passando por todas as camadas. Isso valida a arquitetura de ponta a ponta com risco controlado.

Uma sequência que funciona:

1. Escolha um assunto de alto valor e escopo fechado, como glosa TISS ou ocupação de leitos. Um processo, poucas fontes, uma dor cara.
2. Faça um discovery honesto das fontes: onde está o dado, em que qualidade, com que frequência atualiza, quem é dono. Boa parte do prazo do projeto se decide aqui, e é o que fazemos em discovery e assessment.
3. Construa as três camadas para esse assunto, com contrato de qualidade explícito na passagem de silver para gold.
4. Modele o esquema estrela desse processo e publique em Power BI com RLS e rótulo de sensibilidade.
5. Meça, corrija e só então avance para o próximo assunto, reaproveitando dimensões conformadas.

Repare que dimensão de paciente, convênio e tempo é compartilhada entre quase todos os assuntos. Construídas uma vez com qualidade, elas viram o alicerce reutilizável do warehouse. Esse é o retorno composto da modelagem dimensional bem feita: o segundo caso custa uma fração do primeiro.

Sobre plataforma, uma opinião direta. O ecossistema Microsoft é a escolha de menor atrito para a maioria das operações de saúde no Brasil, pela penetração já existente de Office, Azure e Power BI e pela integração nativa entre Fabric, OneLake e Power BI. A Microsoft é reconhecida como Líder no Quadrante Mágico do Gartner para plataformas de Analytics e BI, e o Fabric, anunciado em 2023, consolidou ingestão, engenharia e analytics numa mesma superfície. Se a sua casa já é Microsoft, remar contra isso raramente compensa. Para o consumo final, o Power BI segue sendo o padrão, e o guia de Power BI para empresas no Brasil cobre o entorno.

Perguntas frequentes#

Qual a diferença entre data warehouse e data lake para saúde?

O data lake armazena dado bruto em qualquer formato, ótimo para as camadas bronze e silver e para guardar XML TISS e mensagens FHIR como chegaram. O data warehouse entrega dado modelado, tratado e pronto para consulta analítica, o papel da camada gold. No Fabric, o Lakehouse une as duas ideias no OneLake, então a discussão hoje é menos "um ou outro" e mais como organizar as camadas dentro da mesma plataforma.

Preciso migrar tudo para a nuvem para ter um data warehouse saúde?

Não obrigatoriamente, mas a nuvem simplifica muito segurança, escala e conformidade. Fabric e Azure oferecem controles de acesso, criptografia e auditoria que seriam caros de reproduzir on premises. Dado sensível pode ir para a nuvem desde que a base legal, a pseudonimização e os controles de acesso estejam corretos. A LGPD não proíbe nuvem, ela exige tratamento adequado.

Como o modo Direct Lake se compara a Import e DirectQuery em cenário hospitalar?

O Import traz o dado para dentro do modelo e é rápido, mas exige atualização agendada. O DirectQuery consulta a fonte em tempo real e tende a ser lento em volume clínico alto. O Direct Lake lê os arquivos Delta direto do OneLake, entregando performance próxima do Import com dado mais fresco, desde que a camada gold esteja bem escrita em Delta Parquet. Para a maioria dos casos de saúde no Fabric, Direct Lake é o ponto de partida.

Quanto custa manter uma capacidade Fabric para um projeto de saúde?

Depende da carga de processamento, não do tamanho do banco. O Fabric mede consumo em Capacity Units e cobra por SKU de capacidade, do F2 ao F2048, além do licenciamento de usuário via Power BI Pro ou PPU. Como pipelines de saúde são pesados de transformação, os valores variam bastante conforme volume e frequência de reprocessamento. Trate qualquer estimativa como faixa aproximada e confirme sempre na fonte oficial da Microsoft antes de fechar orçamento.

Como garantir a conformidade com a LGPD no data warehouse saúde?

Trate governança como fundação, não como etapa final. Defina a base legal do tratamento, pseudonimize identificadores diretos na camada silver, minimize o dado que chega à gold, aplique segurança em nível de linha por papel e mantenha trilha de auditoria. Dado de saúde é sensível pela própria LGPD (Lei nº 13.709/2018), então o padrão de rigor é mais alto que o de um projeto comum de BI.

Por onde começo se hoje só tenho planilhas e relatórios soltos?

Escolha um único processo caro, como glosa ou ocupação de leitos, e entregue a fatia vertical completa dele, do dado bruto ao painel. Um discovery de fontes bem feito no início evita a maior parte das surpresas de prazo. A partir daí, reutilize as dimensões conformadas de paciente, convênio e tempo para acelerar os próximos assuntos.

Conclusão#

Estruturar um data warehouse saúde é menos sobre tecnologia e mais sobre disciplina: modelar bem, respeitar os padrões de interoperabilidade que a saúde impõe e tratar governança e LGPD como fundação. Comece pequeno, entregue uma fatia vertical de valor e deixe as dimensões conformadas trabalharem a seu favor no próximo caso. É assim que o warehouse deixa de ser projeto de infraestrutura e vira ativo de decisão.

Se você quer montar essa base com quem já entregou milhares de soluções Microsoft e conhece a régua da saúde brasileira, fale com a gente.