Como integrar sistemas de gestão em saúde (HIS e ERP) ao Power BI

Seus dados de saúde estão presos em sistemas que não conversam entre si#

Todo gestor hospitalar já viveu esta cena: o diretor pede a taxa de ocupação de leitos por especialidade cruzada com glosa TISS do mês, e a resposta demora três dias porque alguém precisa exportar planilha do HIS, outra pessoa do ERP financeiro e um terceiro do sistema de faturamento. Integrar HIS Power BI não é um capricho de dashboard bonito, é a diferença entre decidir com dado de ontem ou decidir com dado de três semanas atrás. E na saúde, onde margem operacional é apertada e regulação é pesada, esse atraso custa caro.

O problema raramente é o Power BI em si. O Power BI é maduro, a Microsoft é reconhecida há anos como Líder no Quadrante Mágico do Gartner para plataformas de Analytics e BI, e a penetração do ecossistema Microsoft no Brasil torna a ferramenta uma escolha natural. O desafio real está na origem: sistemas de gestão em saúde são um ecossistema fragmentado de HIS, HMIS, ERP hospitalar, prontuário eletrônico (PEP) e módulos de faturamento TISS, muitos deles legados, on-premises e mal documentados. Este artigo é sobre como atravessar essa fragmentação de forma técnica e sustentável.

O ecossistema de sistemas de saúde é mais heterogêneo do que parece#

Antes de conectar qualquer coisa, você precisa mapear a origem. Na prática, um hospital ou operadora de médio porte tem pelo menos quatro famílias de sistemas, cada uma com um perfil de integração diferente.

Sistema	O que contém	Como costuma expor dados	Dificuldade de integração
HIS / HMIS	Admissão, leitos, agenda, atendimentos, ordens médicas	Banco relacional on-premises (SQL Server, Oracle), às vezes API	Média
ERP hospitalar	Financeiro, contas a pagar/receber, estoque, compras, RH	Banco relacional, alguns com API REST ou views	Média a baixa
Prontuário eletrônico (PEP)	Evolução clínica, prescrições, resultados, exames	Bancos proprietários, HL7 v2, cada vez mais FHIR	Alta
Faturamento TISS	Guias, procedimentos, glosas, remessas para operadoras	Arquivos XML no padrão TISS da ANS	Média (parsing de XML)

A lição de campo é simples: não existe um único conector que resolva tudo. Você vai combinar acesso direto a banco, leitura de XML e, nos cenários modernos, APIs REST e FHIR. Quem promete plug and play para saúde nunca fez faturamento TISS na vida real.

Comece pela pergunta de negócio, não pelo conector#

Erro clássico de projeto de BI em saúde: começar listando tabelas do HIS. O caminho certo é inverso. Defina primeiro os indicadores que importam, taxa de ocupação, tempo médio de permanência, giro de leito, ticket médio por convênio, índice de glosa, margem por linha de serviço. Só então descubra onde cada campo mora. Isso evita trazer 400 tabelas quando você precisa de 12, e mantém o modelo enxuto, o que o motor VertiPaq do Power BI agradece, já que ele comprime colunas por cardinalidade e sofre com granularidade desnecessária.

Se a sua organização ainda não tem esse mapa de indicadores estruturado, um trabalho de discovery e assessment antes de escrever a primeira query economiza meses de retrabalho. Vale a pena discutir também com quem cuida de engenharia de dados, porque a arquitetura de origem determina quase tudo que vem depois.

As quatro abordagens reais de integração#

Na prática há um espectro de arquiteturas, do mais simples e frágil ao mais robusto. Escolha conforme o volume, a criticidade e a maturidade do time.

Conexão direta ao banco via gateway on-premises#

A maioria dos HIS e ERP hospitalares roda on-premises. Para o Power BI Service alcançar esses bancos, você instala o On-premises data gateway, um serviço que faz a ponte segura entre a nuvem e a rede interna do hospital. O gateway suporta atualização agendada e, para algumas fontes, DirectQuery. É a porta de entrada mais comum.

Aqui vai o conselho honesto: nunca aponte o Power BI direto para o banco de produção do HIS em horário de pico. Sistemas de saúde têm carga transacional 24 por 7 e uma consulta analítica mal comportada pode degradar o atendimento. Use réplica de leitura, banco de staging ou uma janela de extração noturna. A camada de BI não pode competir com o leito.

Leitura e parsing de arquivos TISS XML#

O faturamento para operadoras no Brasil segue o padrão TISS (Troca de Informações na Saúde Suplementar) da ANS, que trafega guias e demonstrativos em XML estruturado. Esses arquivos são uma fonte riquíssima para análise de glosa, mas exigem parsing. O Power Query lê XML nativamente, e para volumes grandes ou versões variadas do schema TISS o ideal é processar o XML numa camada de dados antes, transformando em tabelas relacionais limpas. Tentar fazer todo o achatamento do XML dentro do Power Query de um relatório único é receita para lentidão e manutenção infernal.

Camada de dados no Azure ou Microsoft Fabric#

Quando o cenário cresce, você para de conectar o Power BI direto às origens e passa a construir uma camada intermediária. Aqui entram Azure SQL, Azure Data Lake, Synapse ou o Microsoft Fabric, anunciado pela Microsoft em 2023 como plataforma unificada de dados. No Fabric, o consumo é medido em Capacity Units (CU) e as SKUs vão de F2 a F2048, permitindo começar pequeno e escalar. O modo Direct Lake lê os dados diretamente do OneLake sem importação nem DirectQuery tradicional, combinando desempenho de import com dado fresco, o que é excelente para volumes hospitalares.

Se você está avaliando se essa camada faz sentido para a sua realidade, vale ler nosso guia sobre Microsoft Fabric antes de decidir. Nem todo hospital precisa de Fabric no dia um, mas quase todo hospital com mais de um sistema de origem vai precisar de alguma camada de dados eventualmente.

Integração via API e padrões de interoperabilidade#

Sistemas mais novos expõem APIs REST, e o padrão que está se consolidando globalmente na saúde é o HL7 FHIR (Fast Healthcare Interoperability Resources), que estrutura dados clínicos como recursos consultáveis via API. O antecessor, HL7 v2, ainda é onipresente em integrações hospitalares baseadas em mensagens. O Power Query consome APIs REST e JSON, mas para FHIR de verdade, com paginação, autenticação OAuth e recursos aninhados, o certo é ingerir via pipeline de dados e materializar em tabelas, deixando o Power BI consumir o resultado tratado.

Comparando as abordagens para escolher a sua#

Abordagem	Quando usar	Dado em tempo quase real	Complexidade	Risco na origem
Gateway direto ao banco	Poucos sistemas, volume moderado	Parcial (DirectQuery)	Baixa	Alto se apontar produção
Parsing de TISS XML	Análise de faturamento e glosa	Não (lote)	Média	Baixo
Camada Azure / Fabric	Múltiplas origens, escala, histórico	Sim (Direct Lake)	Média a alta	Baixo (isola a origem)
API REST / FHIR	Sistemas modernos, interoperabilidade	Sim	Alta	Baixo

Não existe abordagem única vencedora. Um projeto maduro combina três delas: gateway para o ERP, parsing de TISS para faturamento e uma camada Fabric consolidando tudo com histórico. Isole as origens transacionais o quanto antes e deixe o Power BI conversar com uma camada estável.

Casos de uso que justificam o esforço#

Integração não é fim, é meio. Estes são os usos que pagam o projeto rapidamente:

• Gestão de leitos e capacidade: ocupação por unidade, especialidade e turno, com previsão de alta, cruzando HIS e escala.
• Faturamento e glosa: índice de glosa por operadora, procedimento e motivo, lendo o TISS XML e o financeiro do ERP juntos. Reduzir glosa é caixa direto.
• Margem por linha de serviço: receita do faturamento contra custo do ERP por centro de custo, revelando quais procedimentos dão prejuízo.
• Indicadores assistenciais e regulatórios: tempo de permanência, taxa de reinternação, infecção hospitalar, alimentando painéis clínicos e obrigações de qualidade.
• Fluxo de pronto-socorro: tempo porta a médico, gargalos de triagem, combinando dados do PEP e do HIS.

Nesses painéis, a qualidade do modelo importa tanto quanto a integração. Recomendo revisar nossas boas práticas de modelagem e DAX, porque um modelo estrela bem construído é o que faz esses cálculos rodarem rápido sobre milhões de atendimentos.

Governança e LGPD não são opcionais na saúde#

Dado de saúde é dado pessoal sensível pela LGPD (Lei nº 13.709/2018), que exige base legal específica e cuidado reforçado no tratamento. Isso muda como você projeta a integração. Alguns princípios não negociáveis:

• Minimização: traga para o BI só o que o indicador exige. Nome completo e CPF do paciente raramente precisam estar num painel de ocupação. Pseudonimize na camada de dados.
• Controle de acesso: use Row-Level Security (RLS) no Power BI para que cada gestor veja só a sua unidade, e trate acesso a dado clínico com rigor maior que dado administrativo.
• Rastreabilidade: registre de onde veio cada dado e quem acessou o quê. O Microsoft Purview e os logs do tenant ajudam.
• Segregação de ambientes: dado sensível não transita por workspace de desenvolvimento sem controle.

Governança em saúde é assunto denso, e vale aprofundar no nosso material sobre governança de dados, Power BI e LGPD. Fazer isso depois que o painel já está no ar é sempre mais caro que fazer desde o começo, com apoio de quem entende de governança de dados.

Licenciamento: o que você precisa saber antes de dimensionar#

O modelo de licença influencia a arquitetura. Em linhas gerais, Power BI Pro e Power BI Premium Per User (PPU) são licenças por usuário, enquanto capacidade dedicada vem via SKUs P (P1 a P5) ou via Fabric (F2 a F2048). Para compartilhar relatórios de forma ampla numa operadora com muitos usuários, capacidade dedicada costuma sair mais racional que licença por cabeça. Preços variam e devem ser confirmados na fonte oficial da Microsoft, não confie em valor de blog, incluindo este.

Para o panorama completo de adoção e licenciamento no país, o guia completo de Power BI para empresas no Brasil cobre o tema em profundidade.

Como começar sem quebrar o hospital#

Um roteiro pragmático que já rodamos em campo:

1. Escolha um único caso de uso de alto valor, tipicamente glosa TISS ou ocupação de leitos. Nada de big bang.
2. Mapeie a origem real daquele indicador, tabelas, campos, granularidade e frequência de atualização.
3. Monte uma camada de staging fora do banco de produção, mesmo que simples, para nunca consultar a produção direto.
4. Modele em estrela com fato e dimensões limpas, respeitando a compressão do VertiPaq.
5. Aplique RLS e minimização antes de publicar, não depois.
6. Valide com quem opera, o faturista e o gestor de leitos sabem se o número está certo melhor que qualquer engenheiro.
7. Só então escale para o próximo caso de uso, reaproveitando a camada de dados.

Esse incremental funciona porque entrega valor em semanas e constrói a arquitetura de forma sustentável. Com a base de pé, evoluir para analytics avançado, como previsão de demanda de leitos, fica muito mais viável.

Perguntas frequentes#

Preciso do Microsoft Fabric para integrar meu HIS ao Power BI?

Não necessariamente. Para poucos sistemas e volume moderado, um gateway on-premises com um banco de staging resolve. O Fabric ganha valor quando você tem múltiplas origens, precisa de histórico consolidado, volumes grandes ou quer o desempenho do Direct Lake lendo do OneLake. Comece pelo caso de uso e deixe a arquitetura crescer conforme a necessidade real.

Como o Power BI lê arquivos TISS XML?

O Power Query lê XML nativamente, então tecnicamente é possível conectar direto. Na prática, para volumes reais e variações do schema TISS da ANS, o recomendado é processar e achatar o XML numa camada de dados antes, transformando em tabelas relacionais limpas. Isso mantém os relatórios rápidos e a manutenção sã.

Posso conectar o Power BI direto ao banco de produção do HIS?

Tecnicamente sim, mas é arriscado. Sistemas de saúde têm carga transacional constante e uma consulta analítica pesada pode degradar o atendimento. Use réplica de leitura, banco de staging ou janela de extração noturna. A regra é nunca deixar o BI competir com o sistema que sustenta o leito.

O que é HL7 FHIR e por que importa para BI em saúde?

FHIR é o padrão moderno de interoperabilidade em saúde, que estrutura dados clínicos como recursos consultáveis via API REST. Importa porque sistemas novos o adotam e ele facilita trazer dados clínicos de forma padronizada. Para consumir FHIR de verdade, com autenticação e paginação, use um pipeline de ingestão e deixe o Power BI ler o resultado já tratado.

Como fica a LGPD com dados de saúde no Power BI?

Dado de saúde é dado pessoal sensível sob a LGPD, com exigências reforçadas. Na prática isso significa minimizar os dados trazidos, pseudonimizar identificadores, aplicar Row-Level Security, registrar acessos e segregar ambientes. Governança não é etapa final, é premissa de projeto desde a primeira conexão.

Quanto tempo leva um primeiro painel integrado?

Depende da origem, mas um caso de uso único e bem escopado, como índice de glosa ou ocupação de leitos, costuma sair em poucas semanas quando a origem é acessível e o indicador está claro. Projetos que tentam integrar tudo de uma vez é que se arrastam por meses. Fatie o escopo.

Integrar dados de saúde é engenharia, não mágica#

Conectar HIS, ERP, prontuário e faturamento TISS ao Power BI é totalmente factível, mas exige respeito à complexidade da origem, cuidado com a operação assistencial e governança de dado sensível desde o primeiro dia. Quem trata isso como um clique de conector fracassa. Quem trata como projeto de engenharia de dados com foco em indicador de negócio, entrega valor rápido e escala com segurança.

Se você quer discutir a arquitetura certa para o seu cenário de saúde, seja um gateway simples ou uma camada completa no Fabric, fale com a gente. A Fynx tem seis anos de mercado, mais de 50 clientes e mais de 2.000 soluções Microsoft entregues, e ajuda a montar a integração e o Power BI do jeito que a saúde exige.