Como integrar o prontuário eletrônico e o HIS ao Power BI

O dado clínico existe, mas ninguém consegue enxergar#

Todo hospital que atende há alguns anos já produziu uma montanha de dados. Estão no prontuário eletrônico do paciente (PEP), no sistema de gestão hospitalar (HIS), no ERP financeiro, no laboratório, no PACS de imagem. O problema quase nunca é falta de dado. É que ele fica preso dentro de sistemas transacionais que não foram feitos para responder perguntas de gestão, e cada relatório vira um pedido para a TI que demora semanas. Integrar prontuário Power BI resolve exatamente esse gargalo: transformar o registro clínico e operacional em painéis que a diretoria, a assistência e o faturamento conseguem ler no mesmo dia.

Só que saúde não é varejo. O dado clínico é dado pessoal sensível pela Lei nº 13.709/2018 (LGPD), e uma integração mal desenhada não é só um projeto ruim de BI: é risco jurídico e reputacional. Este texto é sobre como fazer isso de forma técnica e honesta, do conector ao gateway, dos padrões HL7 e FHIR até a camada de dados no Azure ou no Microsoft Fabric, sem prometer atalho que não existe.

Por que você não conecta o Power BI direto no banco do HIS#

A tentação é grande: apontar o Power BI para o banco de produção do HIS e sair fazoendo relatório. Não faça isso. Existem três razões concretas.

Primeiro, desempenho. O banco transacional do HIS está ocupado registrando admissões, prescrições e evoluções em tempo real. Uma consulta analítica pesada disparada em horário de pico concorre com o atendimento. Você não quer que a montagem de um dashboard trave o cadastro de um paciente no pronto-socorro.

Segundo, modelo de dados. O schema de um HIS é normalizado para escrita, com dezenas ou centenas de tabelas, nomes crípticos e regras de negócio embutidas em stored procedures. Isso é ótimo para o sistema operar e péssimo para análise. O Power BI trabalha melhor com um modelo estrela, com tabelas fato e dimensão limpas.

Terceiro, governança e sensibilidade. Ligar o BI direto no PEP significa expor CID, medicação, laudos e identificação do paciente sem uma camada intermediária que anonimiza, filtra e controla acesso. Do ponto de vista de LGPD, isso é indefensável.

A arquitetura correta separa o mundo transacional do mundo analítico. Entre os dois entra uma camada de dados, e é ela que faz o trabalho pesado.

Os caminhos reais de conexão entre a origem e o Power BI#

Antes de escolher a arquitetura, é preciso entender como o dado sai da origem. Na prática hospitalar brasileira você vai encontrar quatro cenários, e a maioria dos projetos combina mais de um.

Origem do dado	Como costuma sair	Cuidado principal
Banco relacional do HIS (SQL Server, Oracle, PostgreSQL)	Réplica de leitura ou extração agendada	Nunca consultar a base de produção diretamente
Interface HL7 v2 (ADT, ORM, ORU)	Mensagens via mecanismo de integração	Precisa de parser para virar tabela
API FHIR (quando o PEP suporta)	REST em JSON, recursos como Patient e Encounter	Autenticação e paginação
Exportações e arquivos (CSV, XML, laudos)	Pasta de rede ou SFTP	Padronizar encoding e layout

O Power BI tem conectores nativos para a maioria dos bancos relacionais e para pastas e SFTP. Para HL7 e FHIR, o padrão é não conectar o Power BI direto na interface: você aterrissa o dado numa camada de dados intermediária e o Power BI lê de lá já estruturado. Isso vale tanto para uma implementação enxuta quanto para um projeto de porte, e é o tipo de decisão que a engenharia de dados resolve no começo do projeto para não virar dívida técnica depois.

HL7 e FHIR sem romantismo: o que cada padrão entrega#

Interoperabilidade em saúde tem dois nomes que aparecem em toda reunião: HL7 e FHIR. Vale entender o que são de verdade, porque a diferença muda o esforço de integração.

O HL7 v2 é o padrão antigo, dos anos 1980, e ainda é o mais presente nos hospitais. Ele funciona por mensagens de texto com campos separados por pipe, disparadas quando algo acontece: uma admissão gera uma mensagem ADT, um pedido de exame gera uma ORM, um resultado gera uma ORU. É robusto e onipresente, mas é verboso e cheio de variações locais. Cada fornecedor implementa um pouco diferente, então quase sempre existe um trabalho de mapeamento.

O FHIR (Fast Healthcare Interoperability Resources), também mantido pela HL7 International, é a geração moderna. Ele expõe os dados como recursos REST em JSON: Patient, Encounter, Observation, Condition, MedicationRequest. É muito mais amigável para quem vem do mundo de APIs e dados. No Brasil, a RNDS (Rede Nacional de Dados em Saúde) adota FHIR, o que aos poucos empurra o ecossistema nessa direção. A Microsoft, inclusive, tem serviços de saúde no Azure voltados a FHIR, o que ajuda quando a camada analítica já vive na nuvem da Microsoft.

Na prática, o cenário realista é híbrido. Você vai puxar dados estruturados direto do banco do HIS para volume e histórico, usar HL7 para eventos que só existem nas interfaces e usar FHIR onde o PEP moderno já oferece a API. Não existe botão mágico que unifica tudo. Existe engenharia.

A camada de dados é onde o projeto vive ou morre#

Aqui está o coração da integração. Entre as origens clínicas e o Power BI você constrói uma camada de dados que ingere, limpa, padroniza, anonimiza quando necessário e serve o dado pronto para análise. Você tem dois grandes caminhos com a Microsoft.

O caminho Azure clássico usa serviços separados. Um Azure Data Factory ou Synapse orquestra a ingestão, um Data Lake guarda o dado bruto e curado em camadas (o padrão bronze, prata e ouro), e um banco analítico serve o modelo final. É maduro, flexível e conhecido.

O caminho Microsoft Fabric, anunciado pela Microsoft em 2023, unifica ingestão, lakehouse, engenharia de dados e Power BI numa plataforma SaaS única sobre o OneLake. A grande vantagem para BI é o modo Direct Lake, em que o Power BI lê os dados diretamente das tabelas Delta no OneLake, sem importar cópia e sem a latência do DirectQuery tradicional. Para um data warehouse hospitalar que cresce rápido, isso é relevante. Se você está avaliando os dois, vale ler nosso guia sobre o que é o Microsoft Fabric e se vale a pena antes de decidir.

Independentemente do caminho, três boas práticas técnicas se aplicam ao modelo que chega no Power BI:

• Modelo estrela sempre. Tabelas fato de atendimentos, internações, exames e faturamento, cercadas por dimensões de paciente, profissional, unidade, tempo e CID. O motor VertiPaq do Power BI comprime colunas por cardinalidade, então dimensões bem modeladas reduzem memória e aceleram consulta.
• Reduza cardinalidade onde puder. Colunas de altíssima cardinalidade, como identificadores longos e timestamps ao segundo, incham o modelo. Separe data e hora, use chaves inteiras.
• DAX limpo desde o início. Métricas de ocupação, tempo médio de permanência e taxa de reinternação viram medidas reutilizáveis. Se DAX não é seu forte, o material sobre boas práticas de modelagem DAX poupa retrabalho.

O gateway de dados local: a ponte obrigatória para o que fica no hospital#

Boa parte do dado hospitalar vive on premises. O HIS roda num servidor dentro do hospital, o banco está numa rede privada, e não vai para a nuvem tão cedo. Para o Power BI no serviço em nuvem enxergar esse dado sem você abrir portas de entrada no firewall, existe o gateway de dados local (o On-premises data gateway).

O gateway é um software que você instala num servidor dentro da rede do hospital. Ele mantém uma conexão de saída com o serviço do Power BI e faz a ponte: quando um relatório precisa atualizar, o serviço pede ao gateway, o gateway consulta a fonte local e devolve o resultado. O tráfego é criptografado e a conexão parte de dentro para fora, o que agrada as equipes de segurança porque não exige expor a base à internet.

Alguns pontos que valem no mundo real:

Aspecto	O que considerar
Modo do gateway	Standard para produção compartilhada, personal só para uso individual
Alta disponibilidade	Instale gateways em cluster para não ter ponto único de falha
Dimensionamento	Servidor dedicado, com CPU e memória para as atualizações de pico
Credenciais	Ficam armazenadas de forma criptografada, com o mínimo privilégio necessário
Atualização de dados	Agende janelas fora do pico assistencial

O gateway é infraestrutura crítica. Se ele cai, os painéis param de atualizar. Por isso ele entra no escopo de sustentação de BI, com monitoramento e responsável definido, e não é algo que se instala e esquece.

LGPD e dado sensível: onde a maioria dos projetos falha#

Este é o ponto em que sou mais direto. Dado de saúde é dado pessoal sensível pela LGPD, Lei nº 13.709/2018. Isso exige base legal adequada para o tratamento e cuidado redobrado. Um dashboard de BI que expõe nome, CPF, CID e prescrição para quem não precisa daquilo é uma violação esperando para acontecer.

O princípio que organiza tudo é o da minimização: o painel só deve conter o dado estritamente necessário para a finalidade. Gestão de leitos não precisa saber o nome do paciente. Faturamento não precisa do laudo completo. Indicadores epidemiológicos funcionam com dado agregado e anonimizado.

Na prática, dentro da arquitetura Microsoft, você combina algumas camadas de proteção:

• Pseudonimização na camada de dados. Substitua identificadores diretos por chaves surrogate antes do dado chegar ao modelo. O nome real fica na origem controlada, não no relatório.
• Row-Level Security (RLS) no Power BI. Cada usuário enxerga apenas os dados da sua unidade, especialidade ou perfil. Um coordenador de UTI não vê os dados da maternidade se a regra não permitir.
• Rótulos de sensibilidade. A integração do Power BI com o Microsoft Purview Information Protection permite classificar relatórios como confidenciais e restringir download e compartilhamento.
• Trilha de auditoria. Registre quem acessou o quê. Em incidente ou fiscalização, log é o que separa uma resposta defensável de uma multa.

Isso não é acessório do projeto. É pré-requisito, e precisa ser desenhado junto com a modelagem, não depois. É o tipo de trabalho que tratamos dentro de governança de dados, e há um aprofundamento específico no artigo sobre governança de dados no Power BI e LGPD.

Licenciamento e capacidade: o que muda a conta#

Vale alinhar expectativa sobre custo, porque muda a arquitetura. O Power BI tem licenças por usuário: o Pro e o Premium Per User (PPU). Para publicar e compartilhar relatórios de forma ampla no hospital, cada consumidor precisa de pelo menos uma licença Pro, ou você aloca capacidade dedicada.

A capacidade dedicada existe nas SKUs Premium por capacidade (a família P1 a P5) e, no Microsoft Fabric, nas SKUs de capacidade F2 a F2048, cobradas em Capacity Units (CU). O Fabric mede o consumo de todas as cargas, incluindo Power BI, em CU sobre a capacidade contratada. Para o hospital, a leitura prática é: poucos autores e muitos leitores costumam pedir capacidade dedicada em vez de licença por cabeça, mas o ponto de equilíbrio depende do número de usuários.

Não vou citar valores fechados porque preços variam por região, contrato e câmbio, e devem ser confirmados no site oficial da Microsoft. O que dá para afirmar com segurança é que o dimensionamento errado de capacidade é uma das principais fontes de desperdício ou de lentidão em projetos de BI. Faz parte de um bom discovery e assessment definir isso antes de comprar.

Como um projeto real se organiza#

Para dar concretude, esta é a sequência que costuma funcionar num hospital de médio porte:

1. Discovery. Mapear origens (HIS, PEP, laboratório, ERP), padrões disponíveis (HL7, FHIR, arquivos) e as perguntas de negócio prioritárias.
2. Arquitetura de dados. Definir Azure clássico ou Fabric, camadas do lake e estratégia de anonimização.
3. Ingestão. Construir os pipelines, réplicas de leitura e parsers de HL7 ou FHIR conforme o caso.
4. Modelagem. Montar o modelo estrela, medidas DAX e regras de RLS.
5. Gateway e publicação. Instalar o gateway local, agendar atualizações e publicar no serviço.
6. Governança e sustentação. Rótulos de sensibilidade, auditoria e monitoramento contínuo.

Cada etapa tem armadilha própria, mas nenhuma é insolúvel. O erro comum é pular direto para o dashboard bonito e deixar arquitetura e LGPD para depois. Em saúde, isso cobra caro.

Perguntas frequentes#

Dá para integrar o prontuário eletrônico ao Power BI sem passar dados pela nuvem? Dá, em parte. Com o gateway de dados local e o Power BI Report Server on premises é possível manter dado e relatório dentro do hospital. A limitação é que você abre mão de recursos que só existem no serviço em nuvem, como o modo Direct Lake do Fabric e vários recursos de colaboração. A decisão é caso a caso, pesando exigência de residência do dado contra funcionalidade.

HL7 v2 ainda é usado ou já dá para trabalhar só com FHIR? HL7 v2 continua dominante nos hospitais brasileiros e não vai desaparecer tão cedo. FHIR cresce, empurrado pela RNDS e pelos PEP mais novos, mas o cenário realista por vários anos ainda é híbrido. Planeje suportar os dois.

O gateway de dados local tem custo de licença? O gateway em si é um software gratuito da Microsoft. O custo está na infraestrutura onde ele roda (o servidor) e nas licenças de Power BI ou capacidade Fabric que consomem os dados. Para produção, recomenda-se servidor dedicado e configuração em cluster para alta disponibilidade.

Como a LGPD afeta quem pode ver cada dado no painel? Diretamente. O princípio da minimização exige que cada usuário veja apenas o necessário para sua função. No Power BI isso se implementa com Row-Level Security, pseudonimização na camada de dados e rótulos de sensibilidade. Dado de saúde é sensível pela Lei nº 13.709/2018 e pede base legal e controle de acesso rigoroso.

Vale a pena migrar direto para o Microsoft Fabric ou começar no Azure clássico? Depende da maturidade e do volume. Fabric simplifica a plataforma e o modo Direct Lake é atraente para data warehouses que crescem rápido, mas exige entender o consumo em Capacity Units. O Azure clássico é mais granular e conhecido. Um assessment técnico honesto responde melhor que uma regra geral.

Quanto tempo leva um projeto desses? Não existe número universal, porque varia com o número de origens, a qualidade dos dados e o escopo dos indicadores. O que reduz prazo é começar por um escopo prioritário bem definido em vez de tentar integrar tudo de uma vez. Discovery bem feito encurta o resto do caminho.

Onde a Fynx entra#

Integrar o prontuário eletrônico e o HIS ao Power BI é um projeto de engenharia de dados com camada de governança clínica, não uma configuração de conector. Na Fynx, com seis anos de mercado, mais de 50 clientes e mais de 2.000 soluções Microsoft entregues, tratamos os três lados juntos: a arquitetura de dados no Azure e no Fabric, a modelagem e a visualização no Power BI e a conformidade com a LGPD desde o desenho. Se o dado clínico do seu hospital existe mas ninguém consegue enxergar, fale com a gente.