Gestão de pronto-socorro: indicadores e fila no Power BI

O pronto-socorro é o setor onde a falta de dado custa mais caro#

Em nenhum outro ponto do hospital a informação envelhece tão rápido quanto no pronto-socorro. Um paciente classificado como laranja há 20 minutos e ainda sem médico não é um número num relatório mensal: é um risco clínico acontecendo agora. Por isso, montar bons indicadores de pronto-socorro no Power BI não é um exercício de dashboard bonito, é a diferença entre enxergar a operação e reagir por reclamação.

Neste artigo eu vou direto ao que importa: quais KPIs de PS realmente valem a pena, como calculá-los sem inventar métrica, e como construir um painel de fila que reflete o que está acontecendo na sala de espera com poucos minutos de defasagem. Vou ser honesto também sobre onde o Power BI ajuda de verdade e onde ele não é a ferramenta certa.

Os indicadores de pronto-socorro que sustentam a operação#

A tentação em saúde é criar 60 indicadores. O resultado costuma ser um painel que ninguém olha. No PS, poucos KPIs bem definidos carregam quase toda a decisão operacional. Estes são os que eu priorizo.

Classificação de risco (Protocolo de Manchester). O Manchester é o sistema de triagem mais adotado no Brasil. Ele estratifica o paciente em cinco níveis por cor, cada um com um tempo-alvo máximo até o atendimento médico:

Cor	Nível de prioridade	Tempo-alvo até atendimento
Vermelho	Emergência	Imediato (0 min)
Laranja	Muito urgente	10 min
Amarelo	Urgente	60 min
Verde	Pouco urgente	120 min
Azul	Não urgente	240 min

O indicador aqui não é só "quantos de cada cor". É aderência ao tempo-alvo por cor: dos pacientes laranja, quantos foram vistos dentro de 10 minutos. Esse é o KPI que expõe gargalo real de equipe médica versus demanda.

Tempo porta-médico. É o intervalo entre a chegada (registro na recepção ou na classificação) e o primeiro contato com o médico. É provavelmente o indicador mais sensível do PS, porque combina fila, disponibilidade de médico e eficiência da triagem num número só. Meça sempre por mediana e por percentil 90, nunca só pela média. A média esconde a cauda, e no PS a cauda é onde estão os problemas.

Tempo total de permanência. Da chegada à alta, transferência ou internação. Permanências longas indicam represamento a jusante: exame que demora, laudo que não sai, leito de internação que não vaga. Um PS que "não desafoga" quase nunca tem problema de porta de entrada, tem problema de saída.

Taxa de evasão. Percentual de pacientes que entram, são classificados e vão embora antes de serem atendidos. É o indicador de insatisfação e de risco mais direto que existe. Evasão alta em pacientes verde e azul fala de espera; evasão em amarelo ou laranja é sinal de alerta clínico e jurídico.

Reconsulta em 72 horas. Percentual de pacientes que retornam ao PS em até 72 horas por queixa relacionada. Ele mede qualidade da conduta, não volume. Reconsulta alta pode indicar alta precoce, diagnóstico incompleto ou orientação insuficiente na primeira passagem.

Repare no padrão: nenhum desses depende de estatística de fora. Todos saem do próprio dado do hospital, com definição clara de início e fim. Métrica em saúde que você não consegue explicar em uma frase para o coordenador da noite é métrica que vai gerar discussão em vez de decisão.

De onde vem o dado: o HIS é a fonte, não o Excel#

Todos esses indicadores nascem do sistema de gestão hospitalar, o HIS (Hospital Information System) ou o prontuário eletrônico. É lá que ficam registrados os eventos com carimbo de tempo: hora do registro, hora da classificação, hora do primeiro atendimento médico, hora da alta. O trabalho de BI é transformar esse fluxo de eventos em indicador confiável.

A arquitetura que eu recomendo separa claramente três camadas. Na origem, o HIS e seus bancos transacionais. No meio, uma camada de dados tratada, onde os eventos viram uma tabela de fatos por atendimento com todos os timestamps normalizados. No topo, o Power BI consumindo esse modelo já limpo. Empurrar transformação pesada para dentro do relatório é o erro clássico que deixa o painel lento e o cálculo inconsistente. Se a sua operação vai crescer, vale conversar sobre a base com quem cuida de engenharia de dados antes de encher o Power BI de Power Query.

Um ponto técnico que importa muito no PS: cardinalidade e o motor VertiPaq. O VertiPaq, engine colunar do Power BI, comprime cada coluna em função da cardinalidade. Colunas de alta cardinalidade, como um datetime completo até o segundo, comprimem mal e incham o modelo. A prática correta é quebrar o carimbo de tempo em uma coluna de data (para relacionar com a dimensão calendário) e uma coluna de hora com granularidade adequada, tipicamente minuto. Isso reduz o tamanho do modelo e acelera as medidas sem perder precisão para os indicadores de PS.

Como calcular os KPIs em DAX sem armadilha#

Os cálculos de tempo no PS são todos diferenças entre eventos, mas o diabo mora na definição do "início". Alinhe isso com a equipe clínica antes de escrever qualquer medida, porque cada hospital tem uma convenção.

Alguns princípios de modelagem que evitam retrabalho:

• Trate cada atendimento como uma linha na tabela fato, com colunas separadas para cada timestamp do fluxo. Diferenças de tempo ficam triviais e você evita medidas que varrem o histórico.
• Prefira mediana e percentil a média para tempos. Em DAX, MEDIAN resolve a mediana direto; para percentil, PERCENTILEX.INC sobre a tabela de atendimentos.
• Para aderência ao Manchester, uma coluna calculada ou medida que compara o tempo porta-médico observado contra o alvo da cor, e depois DIVIDE de dentro do alvo sobre o total. Sempre DIVIDE, nunca o operador de divisão nu, para não estourar com denominador zero em turnos de baixo volume.
• Reconsulta em 72h exige olhar o mesmo paciente em atendimentos diferentes. Isso é lógica de autorrelacionamento por identificador do paciente e janela de tempo, não um contador simples. É o cálculo mais delicado do conjunto.

Se a sua equipe ainda escreve DAX na tentativa e erro, o material sobre modelagem e boas práticas de DAX economiza muita dor de cabeça antes de colocar isso em produção.

O painel de fila precisa de dado fresco, e isso muda a arquitetura#

Aqui está a distinção que muita gente ignora. Os indicadores gerenciais (aderência, permanência, evasão, reconsulta) são analíticos: uma atualização a cada 30 ou 60 minutos serve perfeitamente. Já o painel de fila é operacional. Ele mostra quem está esperando agora, há quanto tempo, em qual cor, e quem já passou do tempo-alvo. Um dado de uma hora atrás nesse painel é inútil.

Power BI não é um sistema de tempo real de verdade, e é importante ser honesto sobre isso. O que ele oferece é tempo quase real, e há três caminhos:

Abordagem	Como funciona	Defasagem típica	Quando usar
Import com refresh frequente	Atualização agendada em intervalos curtos	Minutos	Fila com tolerância de alguns minutos
DirectQuery	Consulta o banco a cada interação	Segundos a poucos minutos	Fila sobre base preparada e performática
Streaming / push dataset	Eventos empurrados via API para o dataset	Segundos	Contadores e placares ao vivo

Na prática, para painel de fila de PS eu costumo combinar. Um modelo em DirectQuery ou Import com refresh curto sobre uma tabela de "atendimentos em aberto" mantida pela camada de dados, e a página de fila usando atualização automática de página quando em DirectQuery. Colocar DirectQuery direto sobre o banco de produção do HIS é pedir problema: você concorre com o sistema que atende o paciente. O certo é replicar os eventos para uma base analítica e apontar o Power BI para lá.

Vale registrar o cenário atual da plataforma. O Microsoft Fabric, anunciado pela Microsoft em 2023, trouxe o modo Direct Lake, que lê os dados diretamente do OneLake sem importar nem consultar via SQL a cada clique. Para saúde, isso é promissor em volume e frescor de dado, mas exige capacidade Fabric, medida em Capacity Units nas SKUs F (de F2 a F2048). Se você está avaliando se compensa, vale ler nossa análise honesta sobre o que é o Microsoft Fabric e quando vale a pena antes de assumir que precisa dele. Muito PS opera muito bem com Power BI Pro ou PPU e um refresh bem desenhado.

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

Dado de PS é dado pessoal sensível. A LGPD, Lei nº 13.709/2018, trata dado de saúde como categoria especial, com exigências mais rígidas de finalidade, acesso e segurança. Isso tem consequência prática direta no seu painel.

O coordenador do PS precisa ver o nome do paciente na fila para operar. O diretor que olha o indicador de permanência do mês não precisa, e não deve. A resposta é segurança em nível de linha e de objeto no Power BI, separando a visão operacional identificada da visão gerencial agregada e anônima. Log de acesso, princípio do menor privilégio e minimização de dado deixam de ser burocracia e viram requisito. Quem trata isso a sério estrutura desde o início a governança de dados alinhada à LGPD, porque em saúde o custo de vazamento não é só multa, é reputação e responsabilidade.

O que costuma dar errado e como evitar#

Depois de vários projetos em ambiente hospitalar, os tropeços se repetem. Vale nomear os principais.

• Definição de tempo sem consenso clínico. Se "porta" para uns é a recepção e para outros é a classificação, seu indicador não significa nada. Alinhe e documente antes do primeiro cálculo.
• Média em vez de mediana. A média de tempos no PS é sistematicamente enganosa por causa dos casos extremos. Adote mediana e percentil 90 como padrão.
• DirectQuery no banco de produção. Deixa o HIS lento e coloca o BI concorrendo com o atendimento. Sempre uma base analítica no meio.
• Painel de fila e painel gerencial no mesmo modelo com o mesmo refresh. São necessidades diferentes de frescor. Separe.
• Ignorar a evasão e a reconsulta. São os indicadores de qualidade que ninguém gosta de olhar, e justamente por isso os mais reveladores.

Nada disso é limitação do Power BI. É desenho de solução. A ferramenta entrega, desde que a base e as definições estejam certas. Para quem já tem um painel rodando e quer profissionalizar sem recomeçar do zero, um trabalho de sustentação de BI costuma resolver mais rápido do que um projeto novo.

Perguntas frequentes#

O Power BI atualiza a fila do PS em tempo real de verdade? Não em tempo real estrito. Ele opera em tempo quase real, com defasagem de segundos a poucos minutos dependendo da abordagem. Com DirectQuery sobre uma base analítica preparada e atualização automática de página, ou com push dataset via API, você chega a poucos segundos, o que é suficiente para operar a fila. Sistema de tempo real crítico com garantia de milissegundos não é papel do Power BI.

Preciso do Microsoft Fabric para montar isso? Não necessariamente. A maioria dos prontos-socorros consegue indicadores sólidos e painel de fila com Power BI Pro ou PPU, mais uma camada de dados bem feita e refresh bem calibrado. O Fabric, com Direct Lake lendo do OneLake, ajuda em volume alto e frescor de dado, mas cobra capacidade em Capacity Units nas SKUs F. Avalie pela necessidade real, não pela novidade.

Como conecto no HIS sem derrubar o sistema? Não aponte o Power BI diretamente para o banco transacional do HIS em produção. Replique os eventos relevantes para uma base analítica intermediária e conecte o BI nela. Isso protege o desempenho do sistema que atende o paciente e ainda te dá liberdade para tratar e padronizar os carimbos de tempo.

Qual a diferença entre média e mediana no tempo porta-médico e por que importa tanto? A média é puxada pelos casos extremos, aqueles poucos pacientes que esperaram horas. Ela pode parecer aceitável enquanto metade da fila sofre, ou parecer péssima por causa de dois outliers. A mediana mostra o paciente do meio, e o percentil 90 mostra o quão ruim fica a cauda. Juntos, dão a foto real. Só a média, no PS, engana.

Como fica a LGPD com dado de paciente no painel? Dado de saúde é sensível pela LGPD, Lei nº 13.709/2018, e exige controle rígido. Na prática, use segurança em nível de linha e de objeto para que a visão operacional identificada fique restrita a quem opera a fila, enquanto gestores veem apenas indicadores agregados e anônimos. Adote menor privilégio, minimização de dado e registro de acesso desde o desenho do projeto.

Quanto custa um projeto desses? O custo varia muito com o estado da base, a integração com o HIS e o número de painéis, então qualquer número fechado seria chute. As licenças de usuário como Power BI Pro e PPU têm faixas de preço por usuário ao mês, e capacidade Fabric é cobrada à parte por Capacity Units. Confirme sempre os valores na fonte oficial da Microsoft, porque mudam. O maior custo real de um projeto de PS raramente é licença, é a engenharia de dados e o alinhamento das definições clínicas.

Fechamento#

Indicador de pronto-socorro bom é o que cabe numa frase e sai direto do HIS: aderência ao Manchester, tempo porta-médico por mediana e percentil, permanência total, evasão e reconsulta em 72h. Some a isso um painel de fila com dado fresco de verdade e governança que respeita a LGPD, e você sai da gestão por reclamação para a gestão por evidência. O resto é desenho de solução bem feito.

Se você quer estruturar os indicadores de pronto-socorro do seu hospital com quem já entregou mais de 2.000 soluções Microsoft, fale com a gente.